Messages in this thread | | | From | (david parsons) | Subject | Re: devfs again, (was RE: USB device allocation) | Date | 11 Oct 1999 14:31:14 -0700 |
| |
In article <linux.kernel.Pine.LNX.4.05.9910111308430.29538-100000@ns.snowman.net>, Stephen Frost <sfrost@ns.snowman.net> wrote: >On Mon, 11 Oct 1999, Bernhard Rosenkraenzer wrote: > >> On Thu, 7 Oct 1999, Horst von Brand wrote: >> >> > /dev is in the _filesystem_, and can be kept there. >> >> can: yes. >> must: not really, why not try a different approach if there are >> arguments for it? >> >> "It has always been that way" is NOT a reason for "it must always stay >> that way". > > Other arguments have been brought up against it (persistance, more >work in kernel memory, others).
With my configuration, devfs adds 33k to the kernel.
14k of that is the driver glue, and it looks like fs/devfs/core.c has about a 40/60% split between the kernel database and the presentation layer.
Say the presentation layer is about 16k. It's perfectly possible that the fs interface is not the cleanest in the world (I'd be delighted to know _in detail_ what the problems are with the current interface; there has been enough vague handwaving about possible shortcomings to fill a small boat), and you could probably get some minor savings by stripping out some of the features and present a flat filesystem without the namespace code.
I don't think you can do much better with an emasculated version of the code; as it stands right now, the notifier code could be changed to spit out
add device=sdxx major=? minor=? options=?
to clients hanging of .devfsd with no more kernel impact than the format string for the abovementioned line.
Richard, if I produced an emasculated version of the patch that only populates a flat filesystem with major and minor numbers required, would you accept it?
____ david parsons \bi/ I hate kernel hacking. \/
- 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/
| |