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

[Greg KH <greg@kroah.com>]

On Fri, Jun 24, 2005 at 07:40:42PM +0400, Michael Tokarev wrote:
> 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.

Heh, I know this quite well :)

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

Again, that's exactly what this patch does.

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

It supports it, but I stipped it down to not allow that, I'll have to
add code to enable that, if enough people complain :)

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

I eagerly await your patch to show what you are referring to.

thanks,

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