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