Messages in this thread |  | | | Date | Wed, 9 Jun 1999 00:19:49 +1000 | | From | Richard Gooch <> | | Subject | Re: Migrating to larger numbers |
| |
Stephen Frost writes: > Hmm, I think maybe the question is, which way is it driven? > Does the kernel automagically load the driver when the device is > detected, or does the user attempt to access a device, which the kernel > then has to go out and see if it exists (And if it can load a module > for it). I've seen it both ways. > If the kernel detects it, then having a user-space daemon > running that handles the modprobe or whatnot and the creation of the > devices will work (pcmcia seems to work in this way). However, what > about devices that exist at all times in a system, but are compiled by > the user as modules to perhaps save memory? Or the issue with printers > and zip drives, where IIRC the user can rmmod and insmod the appropriate > modules depending on which device he wants to talk to. > > I don't know if devfs handles all of these or not, I'm just > trying to bring up points where it would be nice to have something that > handles these different situations, and handles them in One way (if at > all possible) to make it easier for the user.
Devfs handles it both ways. In the former case, a device driver registers device entries with devfs. So that can happen in response to a device plug/unplug event, and doesn't even need interaction from user space.
In the latter case, an attempt to access a device node for which there is no loaded driver (and thus no entry in devfs) generates a module load. That module load will in turn result in the appropriate device entry being registered and magically appearing. So it all just works.
Regards,
Richard.... - 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/
|  |