Messages in this thread |  | | | Date | Wed, 9 Jun 1999 09:03:03 +1000 | | From | Richard Gooch <> | | Subject | Re: Migrating to larger numbers |
| |
Matt Aubury writes: > > On Tue, Jun 08, 1999 at 02:10:24PM -0400, Stephen Frost wrote: > > 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. > > I think the simple answer is: the scheme I've outlined doesn't work > with on-demand loading drivers. Richard has indicated that devfs can > manage both cases which is great. [ Although I've never been entirely > sure that demand loading based on accesses to device inodes is the > right level of abstraction -- at a higher level it could be accesses > to "services" of some kind, which can in turn invoke scripts, install > modules etc etc ].
What kind of abstraction are you thinking about? I can easily extend the devfsd protocol so an attempt to lookup a non-existent device node will send a message to devfsd which can then run a script. Once the script finishes, devfsd wakes up and the lookup() method returns.
% ls -lF /dev/tricks % ls -lF /dev/tricks/magic-device total 0 prw-r--r-- 1 root root 0 Jun 9 07:27 /dev/tricks/magic-device % ls -lF /dev/tricks prw-r--r-- 1 root root 0 Jun 9 07:27 magic-device
Pretty amazing. However, I can't really see the point. If you've got a daemon at the other end of that pipe, you may as well start it at boot time and have it create the pipe.
The point of this example is to show that you can do all kinds of cool stuff if you wanted to.
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/
|  |