RE: updates?

[Paul Hepworth <phepworth s-vision com>]

> > Too bad.  However, hacking the gnu utils to support the VFS is not
> totally
> > unreasonable -- should be as simple as hacking gnu libc (open, write,
> read,
> > etc.) and recompiling the utils (or not even recompiliing since libc is
> a
> > shared lib).
> 
>  This I think is worse then using filesysten EA( and default EA when
> EA are not awailable). Even hacking EA extentions in to nfsd and nfs
> support in kernel looks nicer then hacking gnu libc and utilites to
> carry around those hidden files.
> 
Actually, I'm not advocating adding EAs to glibc.  I'm advocating adding VFS
support to glibc.
(It's up to VFS to support EAs.)  This is not just for EAs but to allow VFS
to be used from any C program.  All the standard file functions in glibc
would map to VFS rather than native FS functions (the native FS functions
would be renamed), thus without changing any code, any application can use
files on the VFS.  For files that are on the native filesystem, this results
in very little overhead.

On second thought, it could be accomplished thusly:
create a header file that maps via #define the standard file functions to
VFS file functions.
(enable_vfs.h would include such things as #define fopen vfs_fopen.)

Thus to use VFS in any app, just do #include <enable_vfs.h>.  If you don't
want to automatically convert your fopen, fwrite, etc. calls to VFS, just
#include <vfs.h> and use vfs_fopen et al explicitly.


Paul