extattr in-kernel interface

[Robert Watson]

On Tue, 18 Apr 2000, Ilmar S. Habibulin wrote:

> Can you publish the way i can get extattr from kernel functions? What
> functions should i call and how should i (or should i) manage vnodes
> lock/put/etc?

I hope to have some example code in the form of the capability stuff in a
day or two.  In the mean time, take a look at extattr(9),
VOP_GETEXTATTR(9) and VOP_SETEXTATTR(9) which should all be available as
of 4.0-RELEASE.  The SETEXTATTR call requires a lock to be held on the
vnode. 

Also, you can take a look at the syscall interface exposed to userland--it
can be found in src/sys/kern/vfs_syscalls.c, towards the bottom.  The
specific syscalls for extended attributes are:

355     STD     BSD     { int extattrctl(const char *path, int cmd, \
                            const char *attrname, char *arg); }
356     STD     BSD     { int extattr_set_file(const char *path, \
                            const char *attrname, struct iovec *iovp, \
                            unsigned iovcnt); }
357     STD     BSD     { int extattr_get_file(const char *path, \
                            const char *attrname, struct iovec *iovp, \
                            unsigned iovcnt); }
358     STD     BSD     { int extattr_delete_file(const char *path, \
                            const char *attrname); }

I'll be committing man pages for the syscalls in a week or two, most
likely.  The syscall semantics were discussed some when I first proposed
the interface on freebsd-arch around December, but for some reason I
neglected to convert the proposal into man pages for the syscalls
(although all the VOP's went in).  The syscalls, needless to say,
demonstrate the use of the calls from userland.  To do so in kernel will
require you to set up the appropriate aio structures pointing to the data
you want to read/write in kernel, and then call the VOP_'s, much the same
as calling the normal VOP_WRITE and VOP_READ routines.

One thing that does need to be decided is whether or not to include MAC
labeling and capability flags at the VFS layer, or whether it's
easier/more appropriate to instead have those semantics be imposed by the
code that sits on top of VFS, which would just use extended attributes to
retrieve data.  Certainly in the short term, directly accessing the data
via the extended attribute calls makes sense--however, abstracting that
retrieval is also a good idea :-).

I've been participating in some discussion on the Linux ACL developers
mailing list concerning extended attribute semantics, and implementation
issues, and will attempt to summarize that discussion here once it's
wrapped up a bit.  We're interested in developing a consistent API across
platforms if they decide to go the extended attribute route for backing
ACL data for inodes.  It sounds like they are quite interested in that
option at this point, but will probably modify the filestore to link
attributes to inodes, rather than using backing files.  This has a number
of advantages (performance, consistency, flexibility)--on the other hand,
it continues to require that the base file system be modified, imposing
substantial development costs, and lowering the chances of integration
with the base file system.  In the long term, I see us moving in the same
direction, but the current extended attribute backing mechanism works and
allows us to make forward progress.  If we can develop a consistent API
addressing all the requirements of both storage models, that would be the
best of both worlds :-).

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message