lkml.org 
[lkml]   [1998]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: devfs
Michael O'Reilly writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> > > Laugh. Think 'caching' which is done right now for the current
> > > scheme. Even 1000 people logged in for 2000 inodes is a trivial
> > > number of inodes.
> >
> > Hmmm, a 64 kB /dev with linear ext2 searching. Ouch.
> > But that isn't as bad as it gets when you add SCSI.
>
> You clearly don't understand what's going on here. The directory
> search is _only_ done for a filename lookup. I.e. at the moment, only
> when someone logs in. After that the tty is referenced by
> inode. Updates are in-memory, and at very very low cost.

Yes, but as the /dev directory gets larger, it takes longer to read
the inode into memory. For a 1000 inodes, it's not so bad, but if you
grow /dev it gets progressively worse.
I seem to recall you were proposing hacks to ext2 to speed inode reads
;-)

However, these times are not such a big deal. As I said in my README,
the real fun begins when you have 16 bit major and minor numbers, and
you consider the link between inode (already in memory, for the sake
of this argument) and the device driver file_operations.

> > > Posix complient means nothing. Go and see what you actually need to
> > > make posix. It's bugger all. Certainly not a terribly useful system.
> > >
> > > pty's aren't minimal posix to start with, ditto devices!
> >
> > Yes, which is why an NTFS system requires a devfs. I guess you agree.
>
> Why stop at devices? What about unix pipes? what about hard links? The
> fact that NTFS is missing a bunch of features means NTFS has a
> problem. Why muck up the rest of the kernel because of NTFS
> limitations.
>
> As a sanity check: How many people would seriously want to run NTFS as
> root filesystem?

Who knows? I've heard various people asking about it from time to
time, so there must be some level of demand. Personally I wouldn't
touch NT with a 10 metre barge pole.

> > > This isn't an argument for devfs. This is an argument for a larger
> > > dev_t size. Before you can claim this as a reason for building a
> > > devfs, you need to detail exactly how a devfs is magically going to
> > > fix the above problem.
> >
> > Sanity check time! Let's see if your "fix" would work.
> >
> > bus 4 bits
> > unit 8 bits
> > LUN 8 bits
> > partition 6 bits
> > raw/cook/etc 2 bits
> >
> > Fine, /dev will be 4 to 8 GB. The linear search will be fun!
> > Seriously, a larger dev_t will _not_ fix this problem.
>
> This is truely nonsense. You don't need to create every possible
> device. Even in the current scheme, most people don't have a /dev/sdf*
> in there.
>
> You create the devices you need. It isn't terrible hard!

It's easy enough. However, for a larger system (i.e. more SCSI hosts
or buses), you either use MAKEDEV to create inode en-masse (chew up
space and increase directory search/inode load times) or you
selectively create inodes as needed. It's that bit of extra work that
wastes time.
Even if you had a programme which automagically creates /dev nodes,
you still have to run it (unless you do it at boot in which case the
boot process slows down that little bit more).
The devfs solution is faster, and has the distinct advantage of being
actively written, whereas I'm not aware of a robust, generally
available auto-makedev (feel free to take that as a challenge:-).

Anyway, I think the biggest single argument for devfs is the
inode->fops lookup with 16 bit major and minor numbers.

> So far, the only reasons I've seen for a devfs are:
> #1. NTFS doesn't have devices.
> #2. Some people want fixed scsi device numbering.
> #3. Ptys are a bit of a kludge, and people would like to be
> able to securely use them w/o being root.
>
> #1 is furphy.
> #2 There already exists a working solution for this in userspace. Find
> it and use it!
> #3 ptys need a better fix than a devfs kludge. They don't really
> belong in the device space anyway, more the unix pipe space.

One man's kludge is another man's clean solution.

Taking a different approach: I can see that you don't think that devfs
is *essential*, however, why are you vehemently opposed to it? Not
everything has to be essential for it to be worthwhile.

Regards,

Richard....

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