[lkml]   [2001]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] VFS interface for extended attributes
At 00:32 13/11/01, Alexander Viro wrote:
>On Mon, 12 Nov 2001, Andreas Gruenbacher wrote:
> > There is one difference between the interfaces you are complaining about
> > above and the proposed EA interface for EA's: In those interfaces you have
> > wildcard parameters that are used for who-knows-what, depending on a
> > command-like parameter, including use as a value, use as a pointer to a
> > value/struct, etc.
>Yes, and? You've got more than enough material for the same kind of
>abuse. What's more, you _already_ have it - in some of the subfunctions
>*data is read from, in some - written to, in some - ignored. Worse
>yet, in some subfunctions we put structured data in there, in some -
>just a chunk of something.
>With all that, who had said that a year down the road we won't get a
>dozen of new syscalls hiding behind that one?
>Sorry, folks, but idea of private extendable syscall table (per-filesystem,
>no less) doesn't look like a good thing. That's _the_ reason why ioctl()
>is bad.


Out of interest, which access interface(s) would you like to see used?

Giving a few suggestions you would be happy with would be a lot easier on
anyone trying to develop a filesystem API than for them having to come up
with one after the other until one is found which you approve of... (-;

Best regards,


"I've not lost my mind. It's backed up on tape somewhere." - Unknown
Anton Altaparmakov <aia21 at> (replace at with @)
Linux NTFS Maintainer / WWW:
ICQ: 8561279 / WWW:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.071 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site