A filesystem without directories

A filesystem without directories

[Gavin Lambert]

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

Re: A filesystem without directories

[Christian Stroetmann]

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
>