Eric Youngdale writes:
>
> On Thu, 11 Mar 1999, Richard Gooch wrote:
>
> > Eric Youngdale writes:
> > > My main objection to this was that it never seemed obvious
> > > that this is something that really had to be in the kernel. There
> > > has got to be a user-space solution to this issue that wouldn't
> > > bloat the kernel.
> >
> > It's a pity so much FUD has been spread about devfs. I have raised
> > points that show that there are certain things you simply can't do
> > without devfs, and I have *NEVER* heard from the anti-devfs crowd how
> > you could do *all* these things in user space.
>
> It doesn't have to be an all or nothing proposition. OK, you
> do the things in the kernel that can't be done in user space, and do
> the rest in user space. Just because you can't do the whole thing
> in user space doesn't mean the whole thing absolutely must be in the
> kernel.
So just what do you think can be moved to user space without reducing
the functionality?
> > Maybe it's because I'm down under and I'm too far away to come over
> > and meet in person with the inner circle, so people don't feel I'm a
> > real person with something to contribute.
>
> No that's not it :-). There is nothing personal here, at least
> from me.
Like I said: it wasn't you I was complaining about.
> My major point is that in general we want to keep the kernel
> as small and lightweight as possible. People who want a heavyweight
> kernel can run Windows-NT :-). Honestly - how much does memory
> usage increase when you turn on devfs (both code and data)?
I agree with the principle of not bloating the kernel, but there are
times when it really makes sense to put it into the kernel. Now, as
far as the actual bloat is concerned, here's some numbers:
Take a random module: sr_mod. It grows from 23677 bytes to 23982
bytes. A measly 305 bytes (1%) increase.
Looking at the kernel image (uncompressed): grows from 1226325 bytes
to 1255565 bytes. A growth of 29240 bytes (2%). That includes many
devfs-capable drivers and the devfs core (29654 bytes for devfs.o,
unstripped). Just over 7 pages of code, some of that is
initfuncs. Let's call it 8 pages of code.
Data: a devfs entry is 44 bytes + filename (excluding
directory). Average length is 5 bytes, so that's 49 bytes. Add 44
bytes for the devfs inode (which in theory could generally be saved)
and you have 93 bytes per device entry assuming devfs is only mounted
once and you access all inodes.
On my system I have an IDE drive, two SCSI HDDs, a SCSI CD-ROM,
RAMDISCs, a floppy and sundries. I have 257 entries in /dev. So I'm
consuming 23901 bytes in data space. Call it 6 pages of data.
So, 6 pages of data, 8 pages of code for a grand total of 14 pages.
On a small 16 MByte system (4096 pages), that's 0.3%. And this is a
system with a reasonable number of drivers. A small system (like a
router) with less RAM is going to have less devices, so the ratio will
probably be the same.
I actually have 192 MBytes of RAM, (49152 pages), so it's costing me
0.03%.
Now, is that really bloat? Are we worried about a cost of 0.3% on
small systems? I think your average system today has 32 MBytes or
more, so the average cost is 0.2% or less.
> I believe that the NFS filesystem used to be handled by a
> userspace process - it only got brought into the kernel for
> performance reasons. There should be any number of creative ways of
> balancing the requirements with no loss in functionality.
I haven't seen someone present a way to preserve *all* the
functionality without having devfs. I'm open to proposals, but I
haven't seen any yet.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
