[lkml]   [1998]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
   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

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.)

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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