lkml.org 
[lkml]   [1998]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)


On Tue, 11 Aug 1998, Theodore Y. Ts'o wrote:

> Date: Sat, 8 Aug 1998 21:35:28 +1000
> From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
>
> The reason I think that persistence is a side issue is because adding
> it will not change the API nor the way the devfs internal management
> is done. However, I expect we'll continue to disagree on this point.
> That said, I'd rather look to the future. I'm currently considering
> two options for persistence:
>
> - using a block device
>
> - peeking through to the underlying disc-based inodes.
>
> Ted, do you have any particular preferences/suggestions on this?
>
> My preference would be to store the inodes in the filesystem. If you're
> going to be using a user mode daemon anyway, as you've suggested in
> other mail messages, then let's define a well-defined interface for the
> kernel to notify the user mode daemon that new devices has apeeared
> (either at boot time or due to a PCMCIA/USB/1384 device getting
> inserted), so that the user mode daemon can create the devices as
> necessary.

I like this suggestion. It opens the door to having an /etc/dev.conf
with permissions, ACLs, post-scripts, user-defined naming schemes (I
think that would solve most people's problems immediately :-).

But isn't this remarkably similar to the kerneld idea?

I especially like the idea that modules still notify something there
is a need for a /dev - so /dev remains dynamic, only shows you those
devices which exist, etc - but very little exists in the kernel.

> This follows the fundamental principal of keeping policy out of the
> kernel (an argument which you yourself have advanced), and doing as much
> as possible in usermode. Performance won't be an issue, since if the
> user-mode daemon is automatically creating the devices, you won't have
> "8 million devices" in /dev (despite that favoriate devfs strawman
> argument). True, lookups will still have to go through /dev, but the
> dcache pretty much obviates that argument. (Also consider that opening
> devices is generally in the noise as far as most applications are
> concerned. It's hardly a common case that we need to optimize.)

The only issue is that you then lose /dev on filesystems which don't
support UNIX nodes (ie devfs on ms-dos partitions). Though there are
other ways of achieving the same effect, so it's no big loss.



-
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.altern.org/andrebalsa/doc/lkml-faq.html

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