Messages in this thread | | | From | (david parsons) | Subject | Re: My $0.02 on devd and devfs | Date | 12 Oct 1999 09:35:46 -0700 |
| |
In article <linux.kernel.199910120618.DAA04453@sleipnir.valparaiso.cl>, Horst von Brand <vonbrand@sleipnir.valparaiso.cl> wrote: >orc@pell.portland.or.us (david parsons) >> In article <linux.kernel.380254A4.F0C32162@pobox.com>, >> Jeff Garzik <jgarzik@pobox.com> wrote: >> >Khimenko Victor wrote: > >> >> See above. Try to turn on printer, do `cat something > /dev/printer/0` >> >> with devfs and explain how it'll be handled with devd. > >> >Are you implying here that /dev/printer/0 is created at open() time? >> >IMHO that is a bad idea. > >> I think that if /dev/printer/0 is controlled by a lkm'ed driver, >> that's exactly what happens, no matter what. I'd expect that in >> the devd case, you'd have to populate /dev with every possible >> device so that you could actually do the open, have the kernel tell >> kmod to load the driver, then the information would go off to devd >> to, ummm.... > >Nope. devd is notified when the device shows up.
How?
If /dev/printer/0 will be a PC-style parallel port, and I've built the driver as a module, the device has shown up when the machine is built, but the driver is sitting there waiting for kmod to drag it into core.
If the file /dev/printer/0 doesn't exist, I can't open it and can't tell kmod to load the driver.
So what I need to do is either discard modules altogether or do a speculative load of every driver module in the system at bootup so that I can generate the appropriate detect messages for devd to populate /dev. If I have to jump through all of these hoops, what do I gain over just populating /dev with every possible device?
____ david parsons \bi/ devd: just say no. \/
- 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/
| |