Messages in this thread | | | From | (david parsons) | Subject | Re: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc ation) ) | Date | 10 Oct 1999 01:58:00 -0700 |
| |
In article <linux.kernel.Pine.LNX.4.05.9910100740500.25913-100000@ns.snowman.net>, Stephen Frost <sfrost@ns.snowman.net> wrote: >On 9 Oct 1999, david parsons wrote: > >> >I like the /proc/devices idea. It's relatively simple. >> >> But it's not as versatile as a real devfs is, and I don't see that >> stripping functionality out of a devfs (without any benefit over >> the real thing; you still have to write the filesystem glue, plus >> you still need to tweak all the appropriate-level drivers to populate >> the filesystem) _just to prevent people from mounting it on /dev_ >> is anything other than a political instead of a technical decision. > > Err, no, /proc/devices isn't a filesystem, it's a FILE.
Inside the kernel, it's a database, it's just the presentation layer that's different.
No matter what, you'll still need the glue to maintain the database; fs/devfs/base.c is a bit large, but the bulk of it appears to be code that maintains the database and the changelog for v1-v123. And certainly you'll need the code in the drivers to register and unregister devices, which will look amazingly similar to the way devfs does it now (modulo the code that implements the useful, though not essential, new files that give absolute controller/ unit/lun/partition access to devices.)
____ david parsons \bi/ A file-oriented presentation layer is not that \/ expensive codewise.
- 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/
| |