Re: The argument for fs assistance in handling archives

[Helge Hafting]

Tonnerre wrote:

> Salut,
>
> On Fri, Sep 03, 2004 at 10:22:55AM +0200, Helge Hafting wrote:
>  
>
> > Requiring another syscall to open forks other than the primary
> > breaks _all_ existing software because it obviously don't use that
> > syscall yet.  And then it doesn't provide any advantages over the
> > file-as-plain-directory way. . .
> >    
>
> Actually...
>
> We might tune the sys_open()  call to take an additional argument (the
> stream ID),  and introduce a compatibility interface  into *libc which
> chooses strid=0 by default if the plain old open call is being used.
>  
But this isn't necessary, as I pointed out above.
There is no _need_ for a new kind of open(), so
why make one in libc?

If you can open a fork/substream/whatever by issuing
open("filename/forkname", ...
then the old-fashioned open() works with multi-fork files too.
An tools based on "open() something, then work with
the resulting file descriptor" will work _unchanged_
with such a multi-fork fs.

Tools that rely on "stat" or directory traversals might need
some updating to work perfectly with such a fs, but not something
that just opens by name.

Helge Hafting


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/