> From: Horst von Brand [mailto:vonbrand@inf.utfsm.cl]
> Subject: Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device
> allocation))
>
> >Reasons against devfs:
>
> >- Permanent attributes are kludged on
>
> Maybe we shouldn't have a ramdisk. This is not a design flaw.
> Given, for some it is in fact a CON to consider, it isn't a
> reason for exclusion.
>
> >- Breaks filesystem semantics in several ways, makes it very hard to check
> > ramifications
>
> Several being lack of persistence? Hard to check ramifications?
>
> >- Impacts system administration, making device managing a lot less Unixy
>
> When you say CONFIG_DEVFS, and for the most part, everything
> is just the same.
>
> >- Impacts _every_ single driver in the kernel, even if it isn't used
>
> Only if you want devfs device nodes. You can put regular mknoded files in
> a devfs.
>
> >- What can be done with devfs can be done without it. Granted, it is less
> > convenient. But I add/remove devices from my machines perhaps once a
> > month, so that doesn't cut it for me.
>
> No it can't. USB, PCMCIA, major/minor limitations, SCSI re-addressing
> (sdc turning into sdb when sdb goes away), among others...
For some reason my laptop w/o devfs seems to be working just fine
w/ it's PCMCIA devices... The major/minor limitations are about the only
thing I see here, and I agree it would be nice to find a way around those.
> >Reasons for devfs:
> >- Makes handling hot-plug easier, but marginally so
> Correction, makes it POSSIBLE.
Not true, userspace daemons can handle hot-plugging, and w/
static major,minor's you can actually just slap something on and talk to
it via the major,minor appropriate for that device, at least once the
kernel is updated, but you can do that for at least some things w/o devfs
(I seem to recall you can force a scsi rescan/reset for new devices).
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/