[lkml]   [2001]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Revised extended attributes interface
On December 6, 2001 06:41 am, Nathan Scott wrote:
> hey there.
> > I still don't like the class parsing inside the kernel, it's hard to see
> > what is good about that.
> I guess it ultimately comes down to simplicity. The IRIX interfaces
> have this separation of name and namespace - each operation has to
> indicate which namespace is to be used. That becomes very messy when
> you wish to work with multiple attribute names and namespaces at once.
> Since the namespace is intimately tied to the name anyway, this idea
> of specifying the two components together provides very clean APIs.

Right now we have two namespaces, user and system. That's one bit of
information, and the proposal is to represent it with 5-7 bytes, passing it
on every call, and decoding it with a memcmp or similar. This is just extra
fluff as far as I can see, and provides every bit as much opportunity for
implementing a private API as the original cmd parameter did, by encoding
whatever one pleases before the dot.

> The term "parsing" is a bit of an overstatement too. We're talking
> strncmp() complexity here, not lex/yacc. ;) And its not clear that
> you can get out of doing that level of parsing in the kernel anyway
> (unless you go for a binary namespace representation, and that's a
> real can of worms).

I'm suggesting we take a look at that.

> > Is there a difference between these two?:
> >
> > long sys_setxattr(char *path, char *name, void *value, size_t size,
int flags)
> > long sys_lsetxattr(char *path, char *name, void *value, size_t size,
int flags)
> >
> Yes, definately. The easiest reason - there are filesystems which
> support extended attributes on symlinks already (XFS does), coming
> from other operating systems, and there should be a way to get at
> that information too.

OK, well it looks like you're going a little overboard here in dividing out
the functionality. What you're talking about is 'follow symlink or not',
right? That really does sound to me as though it's naturally expressed with
a flag bit. I really don't see a compelling reason to go beyond 8 syscalls:

get, fget, set, fset, del, fdel, list, flist

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.316 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site