This is utterly wrong. I'm going to say this only once. Devfs allows
for automatic notification of device changes as well as any inode
changes or lookups. All notification is done via $DEVFS/.devfsd
without a single extra syscall, and the data transferred is very
compact.
Horst, you are entitled to your opinions on the merits (or not) of
devfs. But you continue to make statements about how devfs "works",
which are not based in reality. I don't know where you get these ideas
from. Many of your "descriptions" of how devfs works are not only
totally different from how *my* devfs works, they are very different
from how I would conceive *any* devfs to work.
You do this time and time again. I don't know if it's deliberate FUD,
or simply that you've never bothered to read the FAQ or the source.
But I do know that so often when you describe how devfs "works", it is
completely wrong. I'm getting really tired of this.
> Why do you want to trap inode lookups? Trapping access to
> nonexistent devices is done now for module loading; once the device
> file has been created by devd, everything works just as
> today. Devices get added by conecting to the system, not by trying
> to access them.
I've exaplained this before.
> Speculatively creating namespaces is something that can't be done
> automatically AFAIKS, so it will have to be done by hand, using
> MAKEDEV or such should be fine for that.
It's done *NOW*. It *WORKS*. Configure devfsd and observe!
> > - since you need to store the device tree structure in the kernel
> > anyway (see above), you may as well allow it to be mounted, which
> > gives maximum flexibility to users (and adds very little extra
> > code).
>
> There might very well be a quite different tree structure for human
> consumption. I.e., /dev/printers/[0-5] is a parallel printer, a serial
> port, a few USB printers and even a pipe to a "virtual printer" over the
> net.
>
> > /proc/device_notifier is a functional subset of devfs, but prohibits
> > users to make the choice to have a virtual /dev.
>
> Why a virtual /dev, in the first place?
I've been through all this.
> A daemon doing this on the disk is in the user's hand, potentially
> _much_ more flexible (offer half a dozen alternative handlers, or
> one swiss army knife with a forbidding configuration file syntax
> plus a frontend a la linuxconf, or have everybody write their own as
> a bunch of scripts like /etc/rc.d/ that call simple tools). Any
> dynamic /dev _forces_ decisions on policy into the kernel because
> access to kernelsea is very limited from userland, unless you add a
> whole new forest under /proc or add oodles of ioctl(2)s, or both. It
> also is always resident in RAM and is part of the kernel, so it will
> be severely limited in size and complexity for security and
> stability reasons, and the very real need for running Linux on
> hardware challenged machines. Note that my kernel here is a bit
> larger that 1Mb, linuxconf (with which a full handler would have to
> be comparable, roughly) is 700Kb, without libraries.
This is all untrue, as I've said time and again. No "oodles" of
ioctl()s or syscalls. A handful of pages for devfs code and data.
RTFS!
> > Having devfs in the kernel *absolutely does not* mean that each device
> > driver has to call <devfs_register>. In the early days of the patch,
> > not all the device drivers I use were patched. Nevertheless, my system
> > continued to work.
>
> In the end, if HPA's scheme gets implemented, there will be a
> <dev_register> that handles all anyway, so this isn't the point. His
> point (IIUC) is that showing this information though a dynamic /dev
> _forces_ you to depend on it, a /proc/devices can be cleanly
> complemented by a dynamic /dev if need be, without affecting
> anything else.
This again is untrue. I've explained this elsewhere.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/