Subject: RE: openat(2) and friends
To: Steinar Hamre <tech-kern@NetBSD.org>
From: Gordon Waidhofer <gww@traakan.com>
List: tech-kern
Date: 03/01/2005 22:19:16
> Steinar Hamre <steinarh@pvv.ntnu.no> writes:
>
> > "Gordon Waidhofer" <gww@traakan.com> writes:
> >
> > > The upshot is that I certainly support Solaris
> > > style subfiles. They aren't really "attributes".
> > > I strongly recommend renaming them to reflect
> > > their ultimate role as subfiles (opensf rather
> > > than openat).
> >
> > openat(2) is not related to extended attributes of either variant.
>
> Ops! This is wrong. The low level interface to open extended
> attributes, is indeed openat(2) with O_XATTR.
>
> Note, however, that this is not the only use of openat(2). I would be
> quite happy with a openat(2) without any O_XATTR.
Wow. Thanx for the good turn. I'd complete missed
that the Solaris *at() family of interfaces had uses
other than ATtributes. Apparently the "at" is as in
"AT this point." It's (probably) had the effect
of making me less resistent to the Solaris name choices.
As paths go, this looks like a very good one.
Ultimately I'd like to see NetBSD (and other UN*Xes)
adopt the Solaris model of subfiles (unfortunately
called XATTR at this time). Laying groundwork with
the *at() interfaces gets the ball rolling in
a good direction.
Whatever the names, the momentum for NFSv4
Named Attributes is heading for these semantics.
The Samba folks desire for subfile support adds
to the momentum. The rub is NFSv4 has only one
mechanism for this sort of thing (Named Attribute)
so it will be quite impractical to support both
the NetApp/NT/Solaris model and the OS2/Linux/BSD
model of named-opaque-thingy. The former is
most likely to prevail.
Thanx for the good turn.
>
> Steinar
>