Re: devfs again, (was RE: USB device allocation)

david parsons (orc@pell.portland.or.us)
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/