lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc ation) )
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.022 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site