Fwd: Re: A common VFS and a Common conf-system [Part II]

[Kevin Krammer]

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
/dvfs/http/host/path/file?query
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?

Cheers,
Kevin