On Fri, 27 Oct 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, Oct 27, 2000 at 01:11:44AM +0200, Ragnar Kj?rstad wrote:
> > On Fri, Oct 27, 2000 at 12:24:19AM +0200, Andreas Gruenbacher wrote:
> > > I don't think so. My suggestion would be this: All user EAs are prefixed
> > > with "user." when passed to the kernel. The prefix is not actually stored
> > > on the filesystem. Likewise, all root EAs are prefixed with "root.".
> >
> > If they are to be "stripped" of by the kernel, would it not be better to
> > keep it in a seperate field?
> >
> That would be my preference, but I'm happy either way as long as we
> can pass in the namespace information in some way.
One argument for using a text prefix instead of a separate name is the
kernel can provide additional prefixes, without a need to provide a
mapping in userspace. On the other hand, such a mapping can trivially be
provided in a simple configuration file, say /etc/ea.conf, as a simple
table:
# Attribute namespace to namespace identifier mapping
prefix system 0 # kernel managed
prefix inode 1 # owner managed
prefix user 2 # ACL determines permissions
prefix trusted 3 # trusted subsystem in userland
prefix root 4 # XFS root namespace
...
That's even a bit more efficient in the kernel.
A similar approach could be used for otherwise cryptic EA names (say,
numbered EAs that also have textual names associated with them:
alias user.x11icon 4711
. . .
I don't know if the latter is a useful idea, though...
Nevertheless, I'd prefer to have human readable clear-text EA names
presented to users, so such translations would have to be done in a
userspace library.
> > It is always a prefix and a name, right? A hirarchie is out of the
> > question? (A hirarchie can of course not be represented in two fields)
>
> Why would you want a hierarchy? I'm not against it in principle, but
> I'm definitely against complicating the interface without having any
> good reason for doing so.
I would say that a real hierarchy is out of the question. I don't really
want to invent mechanisms to efficiently support deeply nested
hierarchies. That would add a lot of complexity to the implementation that
I see no real need for.
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
