Re: [ANNOUNCE] ndevfs - a "nano" devfs

[Michael Tokarev]

Greg KH wrote:
> On Fri, Jun 24, 2005 at 04:23:49PM +0400, Michael Tokarev wrote:
>>And another question.  Why it isn't possible to use
>>plain tmpfs for this sort of things?
> 
> What do you mean?  What's wrong with a ramfs based fs?  To use tmpfs
> would require a lot more work.  But if you want to do it, I'll gladly
> take patches :)

Hmm.  Ramfs and Tmpfs...  I mean, we already have several filesystems
which works, and are complete filesystems.  Tmpfs is just one of them.

The point is as the following.  Instead of creating completely new
filesystem, there should be a possibility to create just a small
layer on top of existing, feature-complete (think directories)
filesystem, like tmpfs, with the only difference is that it's
especially known by the kernel as containing device nodes (where
the kernel should create/delete the nodes), and is mountable as
such (not as any generic tmpfs).  When a new device is created,
ndevfs_mknod() (or similar) is called as in your patch, but the
node is created in normal, regular tmpfs, instead of on some
stripped-down filesystem.

This tmpfs will be mountable ofcourse, *and* it will support all
the other normal filesystem operations.  But...

>>Why to create another filesystem, instead of just using current
>>tmpfs and call mknod/unlink on it as appropriate?
> 
> Um, that's about all that this code does.

....Ah ok.  Well.  Hmm.  So I misread the code it seems.
I thought it does not support directories and symlinks..

>>This same tmpfs can be used by udev too (to create that "policy"-based
>>names), and it gives us all the directories and other stuff...
> 
> udev doesn't need a kernel specific fs.

I know.  But it should be able to run on top of such an FS
to (at least I don't see why it shouldn't), provided it only
maintains that "policy" names (symlinks) to "canonical" device
nodes (which is easily doable by just stripping config file).

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/