lkml.org 
[lkml]   [2003]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: State of devfs in 2.6?
Replying to Andrew Walrond:
> My initial query has thrown up lots of interesting debate :)
>
> I, like most people I suspect, love the concept of a complete auto-populated
> dev directory, and not having to MAKEDEV.
>
> devfs provided this, but like most people who read LKML, I stopped using it
> when it's problems were discussed.
>
> I really hope udev lives up to its promise, unlike devfs. Manually creating /
> dev just annoys me for no apparent reason other than it's plain inelegance I
> suppose.

The one of main benefits I considered when focusing my attention on
devfs-like approach is space consumption. Somewhat-populated dev
subdirectory (looking at fedora 1) have about 7k items inside, each of
them eating its inode and (depends on underlying fs) a block.

I agree that previous implementation may be racy, domb, gooched,
whatever.
but
is it sane that for system to function correcly I should carry over
a whole bunch of directory entries, when I actually have all
information about it in kernel, somewhere buried under major-minor
declarations.

That is, udev backed on tmpfs approach are almost
solving our problem. But not completely. Module autoloading is useful,
actually, was useful in conjunction with module unloading - if
unloading support is poor autoloading is almost useless ...

--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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