> I think we would do wise to try to convince Sun to change the name to
> subfileopen() or the like. On their online manpage its still stated as
> "Interface Stability Evolving" so they might still be able to be
> temped to change it still and alias it for backwards compatibility.
>
> Also the X_ATTR would do better of as O_SUBFILES.

I think it possible to find receptive persons at Sun to
that idea. Still, I'm not sure there would be an actual
formal change. I'm told there is a fair bit of internal
debate, still, on what the full semantics are. For example,
does writing to a subfile update the primary mtime/ctime?
Should it? Is there one set of access control for all
streams, or are the per-stream access controls? Nobody knows.
Expect Sun and Microsoft to both advance answers to
these kinds of questions. And, yes, I believe there is
ample room for BSD/Linux communities to participate in the
formation. I believe a credible effort would find warm welcome.

My vote would be to prefer subfileopen() and openat(....O_SUBFILES).
Subfileopen() is the important one. Keep X_ATTR and attropen()
as deprecated compatibility. But that's just one vote.

>
> We could form a petition where the core's of NetBSD/FreeBSD/OpenBSD and
> maybe some Linux representatives could device one front and propose one
> interface.

And there may be some rumblings out there. The NFSv4 Linux/BSD folks
would be good contacts (U Mich). They also did a lot of work on
NFSv4 on the BSDs. I disuaded, or at least delayed, the U Mich
folks coupling NFSv4 OPENATTR to Linux/BSD extended attributes.
The inadequate capacity between those and what Solaris/NetApp/NT
provide for NFSv4 OPENATTR was pretty convincing. Similarly
the Samba team might of documents on their requirements and
opinion of the Solaris model.
>
> > I'm told that subfile support is high on the Samba
> > teams wish list. Preview images (View Thumbnails)
> > are an easy example of why.
>
> Yeah... one of the better uses indeed.
>
> Do you think we could make a standardised form acceptable? I could try to
> work out a full specification if only for *BSD and Linux...

A solid stake-in-the-ground would go a long way. Any proposal
necessarily needs at bit of history including clarification on
the difference between attributes and subfiles, the activities
of Solaris, NetApp, and NT, and justification for interface
names. Some statement of requirements would be good, including
UDF/NFSv4/HFS+ issues. I would include a plea for convergence.

After that, a pilot implementation would be good. Demonstrate
the adequecy of the interfaces for UDF, HFS+, and NFSv4.
I wouldn't count on that being adopted overnight. But it
would at least give folks something concrete to examine
and discuss.

>
> BTW, i see the specs on the Sun website are from Solaris 9 (aka
> SunOS 5.9)
> from 2001(!) ... do they still evolve Solaris ? Are there newer specs?

As far as I know, Solaris 10 made no changes in this area.
NFSv4 is being deployed by Sun now with the usual caveats.
Expect changes.

>
> Cheers,
> Reinoud
>

Cheers,
	-gww