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.
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html