On Wed, Apr 12, 2000, Ricky Beam <jfbeam@bluetopia.net> wrote:
>
> > Come on now. Solaris royally sucked if you went to the /devices
> >directory but it only mildly sucked if you went to the /dev directory
>
> devfs makes /dev look alot more like the solaris /devices than anything
> else. How long do you think it will be before pci id's end up in the devfs
> name tree? (And don't say it won't because I know damn well it will.)
And what if it does?
I'm sure it will one day, but I don't see the problem with it.
> > /devfs is fine with me, but I though the $#@$# thing booted on
> >/dev. In fact, a check of 2.3.99-pre5 confirms it. It's not overlaying
> >/devfs, it's going over /dev unless you tell lilo append="devfs=nomount"
> >and then mount devfs on /devfs yourself in /etc/fstab (which is exactly
> >what I'm doing right now).
>
> Alright, that's it. This is grounds for immediate execution. The only thing
> the kernel should ever mount without an explicit sys_mount() is the rootfs
> (and someone told it what to mount there.) The kernel should never, and I
> repeat, in caps, NEVER, mount something I didn't tell it to mount.
/dev is just as important as / for the system to run.
It automatically mounts it since that's what most people want. However,
you have your option to not do it.
It's just a default option, don't get too upset over it.
> (And if you _must_, why the bloody fuck don't you automount /var/shm!)
Because it's not important for the system to run? My machine works
pretty well without it, but granted it works better without it.
> >> If you wanted to be a purist, modules need a new function for reporting
> >> devfs information... init_module, delete_module(?), devfs_module? That
> >> certainly fixes one problem (and kills the need for devfsd.)
> >
> > Bizzzt... Wrong answer. Actually, it's a great idea and I wish it
> >would solve the problem. Unfortunately, it doesn't solve the problem for
> >USB, PCMCIA, Firewire, hot-swappable SCSI, hot-swappable IDE, or any other
> >thing (the list goes on and on) where devices may come and go while the
>
> HOT SWAP is an evil unto itself. In the case of "who the hell knows"
> hardware, devfs only needs to know of the directory inwhich the node
> belongs to autoload the module. However, in most cases, loading at
> first access is too late. Look at USB... if you plug in a device that
> does have a driver but isn't loaded, the usb core will complain about
> no registered driver for it. In such cases, it'd be up to the core
> to ask for a module to be loaded.
>
> Devfs isn't very useful here unless you have a robotic arm to plug/unplug
> USB devices for you *grin*
Whoa, wrong. I wrote much of the USB core and now I'm working on the
auto loading of drivers and binding them to the device. I am intimitely
involved in this problem.
devfs is very useful here since it already provides a way to export
connect/disconnect events to userspace. I hacked support into devfsd to
grab some information about the device (idVendor, idProduct,
bDeviceClass, bDeviceSubClass, and bDeviceProtocol) then look in a
database to find out what driver is responsible for the device. If it's
not loaded, load it. Then it binds the device to the driver.
Since which driver is responsible for each device is policy, it belongs
in userspace, and devfs has a nice userspace portion, devfsd.
Search the linux-usb mailing list archives for the patch.
I'm working on another feature to track modes for a device, and restore
them to the device when it gets plugged back in, no matter what the USB
id (and thusly device node) it was assigned this time. Since USB id's
are completely arbitrary and assigned when a device is plugged, they are
essentially random.
This is a solution devfs helps us solve relatively easily.
It isn't a silver bullet for hot swap devices tho. We still have device
naming issues. How do I track that this USB to Ethernet device is eth1
and assign eth1 to it all the time.
JE
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:19 EST