Careful. That "code" was typed in while writing the email, and it was
never compiled nor even really thought about very hard. It _should_ be
fairly close to working, but there might be bad thinko's there. One I
know of is the readdir() thing - it assumes that the linked list is
untouched while it copies the names with "filldir()", so it should
really be protected with a semaphore against adding or deleting entries
etc etc.
>> Too bad we didn't have the dcache when the original
>> /proc was done, but these days you could actually populate /proc with the
>> generic dcache functions.
>But the problem there is that then we need an inode for every file (don't
>we?), and inodes are big structures (which it probably shouldn't be, but
>that is a topic for another day).
Right. The inode is a tad too big for comfort, and yes, we'd end up
keeping them all in memory. We could avoid it, but it's _so_ much
easier to keep them in memory all the time, because then we can also use
the very same inode to directly contain all the information we want it
to contain (ie permissions, ownership, times etc etc).
But the good thing with a devfs would be that the /dev directory would
only be populated with devices that we actually have - so it wouldn't be
nearly as large as a "real" /dev.
Btw, devfs should probably think long and hard about pty's...
Linus