Sure looks good to me :)

The opensf() rename of openat() fell pretty flat
with folks. When I found out that the "at" wasn't
a shorthand for "attribute", but rather really meant
"at this point in the name space", it made sense
nobody wanted to change it. Attropen(3) is a wrapper
around openat() and so should be considered
the primary interface. There was some discussion
on this list a few months ago to bring openat()
and friends into NetBSD for reasons other than
attributes/subfiles.

All that said, I still *HATE* the name "attropen()"
and would prefer "subfileopen()". But I HATE
divergence even more.

The pax/tar extension ('E' records I think) are
used for subfiles.

I'm told that subfile support is high on the Samba
teams wish list. Preview images (View Thumbnails)
are an easy example of why.

Nice summary, Reinoud.

Regards,
	-gww


> -----Original Message-----
> From: Reinoud Zandijk [mailto:reinoud@netbsd.org]
> Sent: Tuesday, June 28, 2005 7:08 PM
> To: Jason Thorpe
> Cc: Gordon Waidhofer; tech-kern@netbsd.org
> Subject: Sumup Re: CVS commit: src
>
>
>
> On Tue, Jun 28, 2005 at 10:54:34AM -0700, Jason Thorpe wrote:
> > On Jun 28, 2005, at 6:28 AM, Reinoud Zandijk wrote:
> > It should be pretty straight-forward to encapsulate this type of sub-
> > file handling into the file system itself... OTOH, it might map
> > pretty well to what Gordon wants with openat() and friends.
>
> On the ''2004 NAS Industry Conference'' paper of Gordon Waithofer
> (http://www.nasconf.com/pres04/waidhofer.pdf) he proposes to do Linux's
> getxattr/setxattr as ioctl-style attributes and use Solaris form of
> subfiles though openat(,X_ATTR) or attropen(3C) renamed to opensf() (for
> open-sub-file) to remove confusion with attributes. We then don't
> need the
> `..namedfork' hack anymore if we define a `list sub files'
> primitive using
> readdir as shown below:
>
>
> For a summary of Solaris's `attribute' interface :
>    "http://docs.sun.com/app/docs/doc/817-0699/6mgfuai80?a=view"
>
> According to Solaris opening a sub-file goes with :
>   attrfd = attropen("test", dp->d_name, O_RDONLY);
>   --or--
>   attrfd = openat(attrdirfd, dp->d_name, O_RDONLY /* ,mode ?*/);
>
>
> BUT will this work with subfiles associated with directories?
> shouldn't the
> X_ATTR flags be set in above example of openat?
>
>
> Listing the associated sub-files goes like :
>   attrdirfd = attropen("test", ".", O_RDONLY);
>   dirp = fdopendir(attrdirfd);
>   while (dp = readdir(dirp)) {
>   ...
>
> note that the name attr is confusing again for it is about
> subfiles and not
> about attributes !
>
> where "The attropen() function is a convenience function and is
> equivalent
> to the following sequence of operations:
>
>   fd = open (path, O_RDONLY);
>   attrfd = openat(fd, attrpath, oflag|O_XATTR, mode);
>   close(fd);
>
> The set of existing attributes can be browsed by calling attropen()
> with "." as the attribute name. The list of attributes is obtained by
> calling getdents(2) (or fdopendir(3C) followed by readdir(3C), see below)
> on the returned file descriptor."
>
>
>
>
> So to properly support extended attributes IMHO :
>
> 1) use getxattr/setxattr with named arguments and defined structures. All
>    conversion to/from on-disc structures are done in the fs. We
> could also
>    use this to get/set ACL API ``for free'' like linux does.
> 2) if noone does it, start a named attribute definition reference
> document
>    and hopefully try to get it synced with Linux and the other bsd's.
> 3) update our pax/tar to preserve ext. attributes
>
>
>
> To properly use subfiles (streamdirs) IMHO :
>
> 1) rather use a dedicated opensf()/openat(,X_ATTR) ... than name mangling.
> 2) extend libc with fdopendir() implementation
> 3) we could alias opensf() to openat(,X_ATTR) for portability or vice
>    versa
> 4) once the files are opened, all goes trough the normal FS.
> 5) update our pax/tar to preserve subfiles.
>
>
>
> Thoughts?
> Reinoud
>
>