Re: A filesystem without directories

[Christian Stroetmann <stroetmann@ontolinux.com>]

Hello Hardcore Coders, Hello Gavin;

Could you please tell us more about your:
inspiration,
intention, and
application,
as well as your agenda?



Regards
Christian Stroetmann

> I asked this question on StackOverflow a few days ago but haven't had any
> replies.  I'm hoping that I'll be more fortunate here.
>
> http://stackoverflow.com/questions/38219163/providing-a-basic-filesystem-fro
> m-a-char-driver
>
> The short(ish) version is that I have a char driver that (among other
> things) can provide named read or write streams from a remote device.
> Currently it does this by means of a blocking ioctl that provides the
> complete data preloaded into RAM.
>
> I'm wondering if it's possible to make it provide an fd that can be used
> with normal read or write userspace APIs (or even the async APIs), either
> through a special ioctl that can return an open fd, or via a "real"
> filesystem.
>
> I'm not really sure how to do the former, and the latter seems problematic
> as despite having filenames, there's no concept of a directory --
> specifically, the only way to test whether a given name is valid is to
> actually try to open it for read or write; it's not possible to get a list
> in advance.  (Internally it uses a protocol similar to TFTP.)
>
> Is this something that VFS can support?  And is it possible to use a
> non-block-device as a mount source?  (There may be multiple instances of the
> char device on a given system, so I either need to be able to specify which
> one to mount, or it needs to have a shared FS with subdirectories or
> something to identify which device to use.)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>