On Sun, Mar 14, 2010 at 04:43:18PM -0400, der Mouse wrote:
> >> In some respects. But lurking under all this has been doing away
> >> with st_rdev, which [...]
> > Well, no, we're doing away with a specific interpretation of the
> > contents of st_rdev. Getting rid of st_rdev itself doesn't se
>> In some respects. But lurking under all this has been doing away
>> with st_rdev, which [...]
> Well, no, we're doing away with a specific interpretation of the
> contents of st_rdev. Getting rid of st_rdev itself doesn't serve much
> further purpose.
If we do away with device numbers - I thin
On Sat, Mar 13, 2010 at 08:02:51AM -0500, der Mouse wrote:
>>> [st_dev] does not have to correspond, though, to anything else in
>>> the system.
>> Not really, no, but it may as well be the same as what's in st_rdev.
>
> If there still is an st_rdev. I see no particular reason that needs to
On Sun, Mar 14, 2010 at 03:33:19PM +0900, Masao Uebayashi wrote:
> > I did; bus attachments.
>
> If you pay a little more respect to engineers, you'll find this is
> almost same as Iain's saying and what I wrote in the first mail.
huh? he asked me what I meant, I said what I meant...
--
Dav
On Sat, Mar 13, 2010 at 3:23 PM, David Holland wrote:
> I did; bus attachments.
If you pay a little more respect to engineers, you'll find this is
almost same as Iain's saying and what I wrote in the first mail.
Masao
On Sat, Mar 13, 2010 at 6:04 AM, David Young wrote:
> On Thu, Mar 11, 2010 at 10:16:56AM +0900, Masao Uebayashi wrote:
>> On Thu, Mar 11, 2010 at 12:13 AM, David Young wrote:
>> OK, you want to match device by ID. Like:
>>
>> fxp* macaddr xx:xx:xx:xx:xx:xx
>>
>> That might make sense.
>>
On Fri, Mar 12, 2010 at 12:04 AM, der Mouse wrote:
>> Nah, I don't see any gains. Only losses. The current entries in
>> /dev is working better than this, in combination with MAKEDEV, [...]
>
> For your use cases, yes, perhaps. My use cases too, most of them at
> least. But there are other use
On Fri, Mar 12, 2010 at 6:00 PM, Iain Hibbert wrote:
> On Fri, 12 Mar 2010, David Holland wrote:
>> Line disciplines are a bad example, because they're a prehistoric kind
>> of hacked-up bus attachment and as such ought to be rototilled out of
>> existence.
>
> Well, line discipline is a solution
On Fri, Mar 12, 2010 at 7:34 AM, Greg A. Woods wrote:
> At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi
> wrote:
> Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>> I think labels should be resolved by some name service. It's not
>> diffe
On Fri, Mar 12, 2010 at 5:09 AM, der Mouse wrote:
>>> This could also enable you to do
>>> mount -t devfs /etc/devfs-bindchroot.db /var/chroot/bind/dev
>>> for example.
>
>> I don't think a static database will cut it. What happens when
>> someone attaches a new USB stick and devfs generates a
On Thu, Mar 11, 2010 at 10:37 PM, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz wrote:
>> Somthing else comes to my mind: Kernel configuration and devfs
>> configuration interact closely. E.g. you can give the device
>> enumeration order in the kernel configuration by "nai
At Fri, 12 Mar 2010 20:22:25 +0100, Manuel Bouyer
wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> On Thu, Mar 11, 2010 at 05:54:11PM -0500, Greg A. Woods wrote:
> > Indeed -- I do agree with that much at least!
> >
> > I've had d
>> [st_dev] does not have to correspond, though, to anything else in
>> the system.
> Not really, no, but it may as well be the same as what's in st_rdev.
If there still is an st_rdev. I see no particular reason that needs to
be preserved.
> The files in procfs and kernfs are for the most part s
On Fri, Mar 12, 2010 at 09:00:11AM +, Iain Hibbert wrote:
Could you show one (or more) real example(s) / senario(s)? That would
help to understand problems & clarify requirements...
>>>
>>> Well, a line discipline which takes serial IO and converts it into a soft
>>> device whic
On Thu, Mar 11, 2010 at 10:52:53PM -0500, der Mouse wrote:
> > (1) dev_t cannot go away, because a fairly fundamental guarantee in
> > Unix is that two files are the same if stat returns the same (st_dev,
> > st_ino) pair for each.
>
> This dev_t does not have to correspond, though, to anythi
On Sat, Mar 13, 2010 at 12:37:39AM +0100, Matthias Drochner wrote:
>
> dyo...@pobox.com said:
> > Then we can, as you suggested at the top of this thread, create the
> > ether(4) pseudo-device that is analogous to audio(4). Let us attach a
> > particular ether(4) instance to an ethernet h/w insta
dyo...@pobox.com said:
> Then we can, as you suggested at the top of this thread, create the
> ether(4) pseudo-device that is analogous to audio(4). Let us attach a
> particular ether(4) instance to an ethernet h/w instance according to
> the h/w's properties.
This looks somewhat shortsighted. "
mo...@rodents-montreal.org said:
> mainbus0 does not necessarily correspond to any physical bus.
Well, not physical in a sense that you can look at the wires, but
commonly it has a number of interface attributes which match the
capabilities of the the host bridge and some more platform
specific t
On Thu, Mar 11, 2010 at 10:16:56AM +0900, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 12:13 AM, David Young wrote:
> OK, you want to match device by ID. Like:
>
> fxp* macaddr xx:xx:xx:xx:xx:xx
>
> That might make sense.
>
> What doesn't make sense there is to *fix* device unit nu
On Thu, Mar 11, 2010 at 05:54:11PM -0500, Greg A. Woods wrote:
> Indeed -- I do agree with that much at least!
>
> I've had diskless systems running for a long while now (since 2003)
> where /dev is created by init(8) on every boot (by running
> /sbin/MAKEDEV, as I've renamed it).
>
> In the extr
On Fri, 12 Mar 2010, David Holland wrote:
> On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote:
> > > Could you show one (or more) real example(s) / senario(s)? That would
> > > help to understand problems & clarify requirements...
> >
> > Well, a line discipline which takes serial
> (1) dev_t cannot go away, because a fairly fundamental guarantee in
> Unix is that two files are the same if stat returns the same (st_dev,
> st_ino) pair for each.
This dev_t does not have to correspond, though, to anything else in the
system.
> (3) It is also necessary that device nodes conti
>> have pseudo0 attach at mainbus0 [...]
>> I did this because I needed a struct device
> That's what attach_pseudo does...
I probably could have done it that way, but it looked easier to do it
as a pseudo-bus, and for the purposes at the time, the method didn't
matter all that much.
> I think it
On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote:
> > Could you show one (or more) real example(s) / senario(s)? That would
> > help to understand problems & clarify requirements...
>
> Well, a line discipline which takes serial IO and converts it into a soft
> device which inter
On Wed, Mar 10, 2010 at 10:22:40AM -0500, der Mouse wrote:
> Everything starts somewhere. I would never go near Uebayashi-san's
> devfs in any of the incarnations described so far on a production
> system. But I think it's high time someone started thinking about, and
> experimenting with, al
On Thu, Mar 11, 2010 at 01:36:41AM +0900, Masao Uebayashi wrote:
> > Well, yes. ?But research efforts are like that. ?Robustness is pretty
> > much necessary for production use but not for the stage this appears to
> > be at.
>
> I'm not a researcher. I'm an engineer. I like steady move &
On Wed, Mar 10, 2010 at 11:47:49AM +0900, Masao Uebayashi wrote:
> I wonder what is the best design / implementation of devfs.
"none"
When you go and do it right it turns into some automount logic and a
tmpfs.
--
David A. Holland
dholl...@netbsd.org
At Fri, 12 Mar 2010 00:35:24 +0900, Masao Uebayashi wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> Speaking of tracking state... I've found that keeping track of state
> in devfsd is very wrong.
Indeed -- I do agree with that much at least!
I&#
At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods wrote:
> > At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
> > wrote:
> > S
mo...@rodents-montreal.org said:
> have pseudo0 attach at mainbus0 and then my device attach at pseudo0
If we are taking the "interface attribute" abstraction serious this
doesn't work easily: A device doesn't attach at a device but at
an interface attribute (which is usually provided by a device
>> I think the "pseudo-device" abstraction is unnecessary
> I think it makes sense, because it allows to limit use of the
> interface-attribute-less "root" to a minimum. There is a reason that
> many/most ports use just one "mainbus" at root.
That doesn't make the pseudo-device abstraction neces
plu...@rya-online.net said:
> > We can discard the pseudo-devices concept, if need be.
> If a device has no parent, just attach it at root (similar to mainbus*),
> with parent == NULL, or even pseudo* at root, and pseudo-dev* at pseudo?
one can do so, but...
> it is not
> possible to pass config
>> This could also enable you to do
>> mount -t devfs /etc/devfs-bindchroot.db /var/chroot/bind/dev
>> for example.
> I don't think a static database will cut it. What happens when
> someone attaches a new USB stick and devfs generates a bunch of new
> nodes? What ownership and permissions sho
On Thu, 11 Mar 2010, Adam Hoka wrote:
> On Thu, 11 Mar 2010 18:18:54 +0100
> Joerg Sonnenberger wrote:
>
> > On Thu, Mar 11, 2010 at 06:12:40PM +0100, Adam Hoka wrote:
> > > Im wondering if it would be too hack-ish to make devfs file
> > > backed (at least optionally, in case of early boot or re
On Thu, 11 Mar 2010 18:18:54 +0100
Joerg Sonnenberger wrote:
> On Thu, Mar 11, 2010 at 06:12:40PM +0100, Adam Hoka wrote:
> > Im wondering if it would be too hack-ish to make devfs file
> > backed (at least optionally, in case of early boot or read
> > only rootfs).
> >
> > For example: mount -t
On Thu, Mar 11, 2010 at 03:33:27PM +, Iain Hibbert wrote:
[...]
> and would also solve the (very slight) race condition, and moreover it
> would not require malloc of cfdata.
You can use a static cfdata_t, you know. The malloc'ing was a mistake
made initially and carried upon since.
--
Quen
On Wed, Mar 10, 2010 at 10:15:59AM -0500, der Mouse wrote:
> I'm a little confused, here. How can chmod and chown on /dev/wd0a do
> anything useful if /dev/wd0a just gets redirected to (say)
> /dev/default/wd0a? Removing access helps in only a few cases, because
> someone wishing to bypass the re
On Thu, Mar 11, 2010 at 06:18:54PM +0100, Joerg Sonnenberger wrote:
> On Thu, Mar 11, 2010 at 06:12:40PM +0100, Adam Hoka wrote:
> > Im wondering if it would be too hack-ish to make devfs file
> > backed (at least optionally, in case of early boot or read
> > only rootfs).
> >
> > For example: mou
On Thu, Mar 11, 2010 at 06:12:40PM +0100, Adam Hoka wrote:
> Im wondering if it would be too hack-ish to make devfs file
> backed (at least optionally, in case of early boot or read
> only rootfs).
>
> For example: mount -t devfs /etc/devfs.db /dev
How is that different from mounting devfs and ca
On Fri, 12 Mar 2010 00:35:24 +0900
Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi wrote:
> > On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
> >> I missed when Jochen wrote this, so I'll comment now.
> >> This might sound tempting, but I don't think it is a
On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
>> I missed when Jochen wrote this, so I'll comment now.
>> This might sound tempting, but I don't think it is a good idea.
>> Keeping track of changes and trying to retain them ov
On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 6:56 PM, Iain Hibbert wrote:
> > On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> >> > We can discard the pseudo-devices concept, if need be.
> >>
> >> In what sense?
> >>
> >> As I explained in the first post, pseudo device is st
First, a note - I asked a Linux person I work with why the penguins
switched from devfs to udevd. He said that it was a question of
pulling relatively complex policy issues out of the kernel into
userland, the stance being that things like "users in group pix should
be able to access any USB scann
On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist wrote:
> I missed when Jochen wrote this, so I'll comment now.
> This might sound tempting, but I don't think it is a good idea.
> Keeping track of changes and trying to retain them over reboots is
> risky. And the mappings need to be able to hand
Masao Uebayashi wrote:
On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz wrote:
Somthing else comes to my mind: Kernel configuration and devfs
configuration interact closely. E.g. you can give the device
enumeration order in the kernel configuration by "nailing down"
devices. Now those symbolic kern
On Thu, Mar 11, 2010 at 6:56 PM, Iain Hibbert wrote:
> On Thu, 11 Mar 2010, Masao Uebayashi wrote:
>> > We can discard the pseudo-devices concept, if need be.
>>
>> In what sense?
>>
>> As I explained in the first post, pseudo device is strict definition;
>> it has no parent in terms of physiical
On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz wrote:
> Somthing else comes to my mind: Kernel configuration and devfs
> configuration interact closely. E.g. you can give the device
> enumeration order in the kernel configuration by "nailing down"
> devices. Now those symbolic kernel devices like co
On Thu, 11 Mar 2010, Masao Uebayashi wrote:
> > We can discard the pseudo-devices concept, if need be.
>
> In what sense?
>
> As I explained in the first post, pseudo device is strict definition;
> it has no parent in terms of physiical topology. It may have parents
> in terms of components. I'
On Thu, Mar 11, 2010 at 10:16 AM, Masao Uebayashi wrote:
> On Thu, Mar 11, 2010 at 12:13 AM, David Young wrote:
>> On Wed, Mar 10, 2010 at 01:49:02PM +0900, Masao Uebayashi wrote:
>>> > The code providing DKWEDGE_METHOD_GPT already has the knowledge. I
>>> > don't think that the knowledge has to
On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods wrote:
> At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
> wrote:
> Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>>
>> So, you want to be able to mount a disk by the label:
>>
>&
On Thu, Mar 11, 2010 at 12:13 AM, David Young wrote:
> On Wed, Mar 10, 2010 at 01:49:02PM +0900, Masao Uebayashi wrote:
>> > The code providing DKWEDGE_METHOD_GPT already has the knowledge. I
>> > don't think that the knowledge has to move from there. All that dk(4)
>> > has to do is to match de
On Tue, Mar 09, 2010 at 10:52:17PM -0500, Steven Bellovin wrote:
>
> On Mar 9, 2010, at 10:43 PM, Masao Uebayashi wrote:
>
> >> I think that Joerg's proposal doesn't prevent you from doing what you
> >> want, though I don't think it helps, either. He suggested that /dev/uuid
> >> and /dev/labe
At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
>
> So, you want to be able to mount a disk by the label:
>
> $ mount -t msdosfs -o label "foobar" /external_disk_foobar
Yes, some
On Wed, 10 Mar 2010 10:22:40 -0500 (EST)
der Mouse wrote:
> With that in mind, I'd say that the more radical Uebayashi-san's devfs
> is, the less like past (failed) attempts at devfses it is, the more
> likely it is to turn out to be a better way. Eliminating (this use of)
> dev_t is an example.
> Well, yes. But research efforts are like that. Robustness is pretty
> much necessary for production use but not for the stage this appears to
> be at.
I'm not a researcher. I'm an engineer. I like steady move & feasible project.
I think everyone agrees that having /dev/id is useful even onl
>> dev_t will be no longer used.
> I'm not sure if something that blatant (unqualified) is actually what
> you meant to say, but if it was, you cannot do that.
I don't see why not. It breaks a few things, but only a few.
> dev_t (however poorly designed you might think it to be) is a part of
>
Date:Wed, 10 Mar 2010 15:41:44 +0100
From:Joerg Sonnenberger
Message-ID: <20100310144144.gb23...@britannica.bec.de>
| The only property of dev_t that userland really cares is that it is a
| number and that it is unique per device.
For the vast majority of userla
>> /dev has a few reserved directory (like /dev/id). You have no
>> freedom there. Any access other than that goes to devfsd. It has
>> knowledge equivalt to sys/arch/*/conf/majors.* as reference. And it
>> tracks mknod(2), rename(2), etc per-mount point.
>> When you do mknod(/dev/wd0a); renam
On Wed, Mar 10, 2010 at 01:49:02PM +0900, Masao Uebayashi wrote:
> > The code providing DKWEDGE_METHOD_GPT already has the knowledge. I
> > don't think that the knowledge has to move from there. All that dk(4)
> > has to do is to match device-properties lists, and for that it can use
> > the same
On Wed, Mar 10, 2010 at 09:03:31PM +0700, Robert Elz wrote:
> dev_t (however poorly designed you might think it to be) is a part of
> the kernel/application API that has been there forever, and is not
> going away any time soon.
The only property of dev_t that userland really cares is that it is a
Date:Wed, 10 Mar 2010 21:21:21 +0900
From:Masao Uebayashi
Message-ID: <70f62c5e1003100421s5c54035bkdee5917165b01...@mail.gmail.com>
| dev_t will be no longer used.
I'm not sure if something that blatant (unqualified) is actually what
you meant to say, but if it was
Joerg Sonnenberger wrote:
On Wed, Mar 10, 2010 at 01:57:23PM +0100, Johnny Billquist wrote:
2) As I mentioned before - I know I have seen a program which will
spit out the config neccesary to actually get a static setup in
place, based on the current configuration.
That program was recently re
On Wed, Mar 10, 2010 at 10:06 PM, Johnny Billquist wrote:
> No kernel rebuilding is neccesary.
You built non-GENERIC in the first place.
Masao
On Wed, Mar 10, 2010 at 01:57:23PM +0100, Johnny Billquist wrote:
> 2) As I mentioned before - I know I have seen a program which will
> spit out the config neccesary to actually get a static setup in
> place, based on the current configuration.
That program was recently retired from pkgsrc becaus
Masao Uebayashi wrote:
On Wed, Mar 10, 2010 at 4:54 PM, Jochen Kunz wrote:
On Wed, 10 Mar 2010 11:53:43 +0900
Masao Uebayashi wrote:
[device node ownership and modes on devfs]
Is it acceptable for you to do such things by some layering?
Anything else but "chown jkunz.users /dev/ttyU0" is aw
On Wed, Mar 10, 2010 at 9:57 PM, Johnny Billquist wrote:
> Hmm, I just realized that I didn't completely follow how your file system
> design will even solve which controller gets which path. Maybe it was in
> your original mail, but I have forgotten that detail in that case. If you
> have two dis
Iain Hibbert wrote:
On Tue, 9 Mar 2010, Johnny Billquist wrote:
The problem you are highlighting is another one, and one which I agree it
would be nice to have a solution to. But the only solution I can come up with
is to be able to refer to disks by their name in the disk label, or something
s
Masao Uebayashi wrote:
One of the problems is that such a long term user like you have to
know the full detailed dmesg and analyze it. That doesn't meet my
goals. Imagize admins hot-swap multiple disks/NICs on missiong
critical servers.
And you have to disable configuration other PCI buses to
Masao Uebayashi wrote:
"More or less", because I don't have all the details. If you were to post
the dmesg from your booting, I could give you the exact thing.
One of the problems is that such a long term user like you have to
know the full detailed dmesg and analyze it. That doesn't meet my
g
On Wed, Mar 10, 2010 at 8:44 PM, haad wrote:
> This seems as wrong approach to me. I was in contact with mjf@ when he
> designed his devfs and I think that his approach was not the best but
> reasonable. We do not want to have any sort of static major number
> definition everything should be dynam
Hi uebs,
>
> Fair enough.
>
> After some thinking, providing "traditional" view and persistent bits
> turns out to be not that difficult.
>
> /dev has a few reserved directory (like /dev/id). You have no freedom
> there. Any access other than that goes to devfsd. It has knowledge
> equivalt to
On Wed, Mar 10, 2010 at 4:54 PM, Jochen Kunz wrote:
> On Wed, 10 Mar 2010 11:53:43 +0900
> Masao Uebayashi wrote:
>
> [device node ownership and modes on devfs]
>> Is it acceptable for you to do such things by some layering?
> Anything else but "chown jkunz.users /dev/ttyU0" is awkward to me.
> S
On Tue, 9 Mar 2010, Johnny Billquist wrote:
> The problem you are highlighting is another one, and one which I agree it
> would be nice to have a solution to. But the only solution I can come up with
> is to be able to refer to disks by their name in the disk label, or something
> similar, which i
On Wed, 10 Mar 2010 11:53:43 +0900
Masao Uebayashi wrote:
[device node ownership and modes on devfs]
> Is it acceptable for you to do such things by some layering?
Anything else but "chown jkunz.users /dev/ttyU0" is awkward to me.
So what ever solution for this problem is introduced (udevd,
rc.sc
> The code providing DKWEDGE_METHOD_GPT already has the knowledge. I
> don't think that the knowledge has to move from there. All that dk(4)
> has to do is to match device-properties lists, and for that it can use
> the same library function as every other match routine will use.
What if you wan
> That's also my understanding, but since this system is also very simple,
> even a kernel implementation would probably be nice to do this, in
> which case users of such a system could add an entry in
> their /etc/fstab to mount the uuid fs under /dev/uuid/ ?
Yes. That's exactly same view with m
On Tue, 9 Mar 2010 22:52:17 -0500
Steven Bellovin wrote:
>
> On Mar 9, 2010, at 10:43 PM, Masao Uebayashi wrote:
>
> >> I think that Joerg's proposal doesn't prevent you from doing what you
> >> want, though I don't think it helps, either. He suggested that /dev/uuid
> >> and /dev/label just
> One of the problems is that such a long term user like you have to
> know the full detailed dmesg and analyze it. That doesn't meet my
> goals. Imagize admins hot-swap multiple disks/NICs on missiong
> critical servers.
And you have to disable configuration other PCI buses to prevent
unwanted
On Mar 9, 2010, at 10:43 PM, Masao Uebayashi wrote:
>> I think that Joerg's proposal doesn't prevent you from doing what you want,
>> though I don't think it helps, either. He suggested that /dev/uuid and
>> /dev/label just have symlinks to the usual device file, so no user-level
>> daemons w
> I think that Joerg's proposal doesn't prevent you from doing what you want,
> though I don't think it helps, either. He suggested that /dev/uuid and
> /dev/label just have symlinks to the usual device file, so no user-level
> daemons would be involved.
He said it has to be done in userland d
On Mar 9, 2010, at 4:45 PM, Thor Lancelot Simon wrote:
> On Tue, Mar 09, 2010 at 02:58:43PM -0500, Steven Bellovin wrote:
>>
>> On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
>>
>>>
>>> That's a matter for the kernel to decide -- not one for some userspace
>>> program which could be ta
> I programm microcontrolers with a serial programmer. I use a serial
> connection to the target microcontroler for debugging. So I want to
> be able to read/write the serial port device node (e.g. /dev/tty03
> or /dev/ttyU0) directely. But I don't want other users grant access to
> my serial devic
> These two are traditionally a source of real problems for devfs or
> arrangements like it. I had an Irix system once where I wanted to be sure
> disks attached to the external scsi connectors -- used only for a
> tape drive -- couldn't be used.
>
> What a pain that was. Yet the internal disk sl
> I had to deal with every of those scenarios, and never could stand
> existing devfs implementations on my systems; I however previously
> participated to a thread about devfs with ideas and suggestions for a
> possibly less broken pipe-dream implementation, but it simply tought me
> how complex a
Heh, you want everything.
And all of you understand how difficult it's to implement a
full-featured filesystem? There are tradeoffs. My intent is to keep
simple and intuitive. I also assume NetBSD users are not stupid to
learn new things.
> - I want to present a subset of devices to a chrooted
> "More or less", because I don't have all the details. If you were to post
> the dmesg from your booting, I could give you the exact thing.
One of the problems is that such a long term user like you have to
know the full detailed dmesg and analyze it. That doesn't meet my
goals. Imagize admins
Quentin Garnier wrote:
On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
Quentin Garnier wrote:
[...]
My answer only intended to show that the device enumeration isn't
random, depending on if you add/remove other devices, which is what
Masao was claiming.
Your answer only say
On Tue, 9 Mar 2010 21:59:23 + (UTC)
chris...@astron.com (Christos Zoulas) wrote:
> In article <70f62c5e1003091104l20b98c5ex66842f01e6f17...@mail.gmail.com>,
> Masao Uebayashi wrote:
> >> Wow, that sucks. Not being able to change permissions (and less
> >> importantly,
> >> mv or rm the dev
On Tue, Mar 09, 2010 at 09:59:23PM +, Christos Zoulas wrote:
>
> - I want to prevent access to the device completely by not providing a device
> node.
> - I want to preserve those changes across boots.
These two are traditionally a source of real problems for devfs or
arrangements like it.
In article <70f62c5e1003091104l20b98c5ex66842f01e6f17...@mail.gmail.com>,
Masao Uebayashi wrote:
>> Wow, that sucks. Not being able to change permissions (and less importantly,
>> mv or rm the device files) would definitely be a problem.
>
>Could you show me use cases how it sucks? I need more
On Mar 9, 2010, at 3:41 PM, Quentin Garnier wrote:
> On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
>> Quentin Garnier wrote:
> [...]
>> My answer only intended to show that the device enumeration isn't
>> random, depending on if you add/remove other devices, which is what
>> M
On Tue, Mar 09, 2010 at 02:58:43PM -0500, Steven Bellovin wrote:
>
> On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
>
> >
> > That's a matter for the kernel to decide -- not one for some userspace
> > program which could be tampered with by any process running with euid 0.
> >
> > At le
On Tue, Mar 09, 2010 at 09:14:09PM +0100, Johnny Billquist wrote:
> Quentin Garnier wrote:
[...]
> My answer only intended to show that the device enumeration isn't
> random, depending on if you add/remove other devices, which is what
> Masao was claiming.
Your answer only says that device enumera
On Tue, Mar 09, 2010 at 03:52:09PM -0500, der Mouse wrote:
> >>> Lack of chmod/chown/etc in /dev would be a total showstopper (for
> >>> me, at the very least) for production use.
> >> Could you tell me the senario how it sucks?
> > [...example, plain user access to serial line...]
>
> That's one
>>> Lack of chmod/chown/etc in /dev would be a total showstopper (for
>>> me, at the very least) for production use.
>> Could you tell me the senario how it sucks?
> [...example, plain user access to serial line...]
That's one of the scenarios I've run into, though for me it's at least
as often be
On Wed, 10 Mar 2010 04:38:03 +0900
Masao Uebayashi wrote:
> Lack of chmod/chown/etc in /dev would
> > be a total showstopper (for me, at the very least) for production use.
> Could you tell me the senario how it sucks?
I programm microcontrolers with a serial programmer. I use a serial
connection
Quentin Garnier wrote:
On Tue, Mar 09, 2010 at 08:51:48PM +0100, Johnny Billquist wrote:
"More or less", because I don't have all the details. If you were to
post the dmesg from your booting, I could give you the exact thing.
Are you sure your USB disk shows up as sd? Looking at the config
file
On Tue, Mar 09, 2010 at 08:51:48PM +0100, Johnny Billquist wrote:
> "More or less", because I don't have all the details. If you were to
> post the dmesg from your booting, I could give you the exact thing.
>
> Are you sure your USB disk shows up as sd? Looking at the config
> file, I would have t
On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
> On Tue, Mar 09, 2010 at 08:45:09PM +0100, Joerg Sonnenberger wrote:
>> On Tue, Mar 09, 2010 at 02:23:13PM -0500, Thor Lancelot Simon wrote:
>>> I want to be able to tell the kernel to mount a device reliably identified
>>> by some kind of u
On Tue, Mar 09, 2010 at 08:45:09PM +0100, Joerg Sonnenberger wrote:
> On Tue, Mar 09, 2010 at 02:23:13PM -0500, Thor Lancelot Simon wrote:
> > I want to be able to tell the kernel to mount a device reliably identified
> > by some kind of unique, symbolic name. I want to be able to load a list
> >
1 - 100 of 167 matches
Mail list logo
