Fwd: Re: A common VFS and a Common conf-system [Part II]
kevin.krammer at gmx.at
Wed Mar 9 21:34:38 EET 2005
On Wednesday 09 March 2005 19:26, gtg990h at mail.gatech.edu wrote:
> Quoting Kevin Krammer <kevin.krammer at gmx.at>:
> > I am pretty sure a file:// "plugin" isn't going to open the partitions as
> > files and then implementing the filesystem access in user space.
> Undoubtedly, but my point was that D-VFS should be designed so that any
> plugin can be implemented using the native API. To the extent that doing so
> is possible, it is desirable.
I am confused a little bit :)
As far as I understand you the plugins would be _below_ the native file access
API, above would be only some kind of convenience library wrapping system
specific system calls, right?
Using an example:
A webbrowser gets an URL like http//host&path/file?query
It uses a convenience function to transform it into a system specific path, on
Unix likely something like
and then use open() to open that "file"
The kernel would see that it has dvfs mounted on /dvfs and relay the open to
the dvfs "filesystem"., which would pass the request to the D-VFS daemon.
The daemon decodes the "filename" into its URL form, creates a socket and
returns when its open() returns.
Same for read(), etc
I am not very experienced with the native API regarding non blocking IO.
Can an application open a file non-blocking and then use select/poll on it
without loosing quite some performance?
More information about the xdg