[no subject]

In a lot of ways, the Linux approach is superior, although their
maintaining the old interfaces in the newer version of the glibc
is actually a bad thing: this is the same problem that Novell had
wth it's API's, and I rather expect that Linux will see the same
result: everyone will code for the older API's, since it will give
them the largest possible potential user base.  However, the beauty
of the Linux approach is that they can rev. the ABI in the kernel
to support only a single paradigm, and the conversion is handled in
user space at the library level.

For FreeBSD, the moral equivalent would be the ability to build an
older version of a shared library, with the ability to use a newer
version of the host ABI.  FreeBSD doesn't really support that, at
this point, unfortunately, because FreeBSD still supports static
binaries, and static binaries imply a static ABI support that must
be carried forward.

> > His approach avoids the proliferation of system call entry points, which
> > may conflict with those of other BSDs (among other things).  BSDI
> > limited the number of available additional FreeBSD system calls in a
> > standardization effort a while back, if you'll remember, so a
> > proliferation of calls is Bad.  In addition, the compatability required
> > this proliferation going forward.
> 
> I suspect that this may end up being a red herring.  You do realize that
> OpenBSD and NetBSD have *already* made precisely the change I am
> describing?  Here's the exerpt from OpenBSD's ipc.h:

Yes, I understand that they have made this change.  I'm not really
objecting to changing ipc_perm.


> We're *improve* our compatibility with other BSD platforms by making these
> changes.

With respect, this will only become relevent when we rely on
OpenBSD or NetBSD ABI support for access to applications.

As to the general argument of "we should share code where
possible", one could argue that we should start with the VFS
interfaces, since NetBSD has working VFS stacking.  There are
a lot of other interfaces in this category, e.g. NetBSD's
support for running ABI's from a much larger number of foreign
platforms for a CPU architecture, and the fact that the FreeBSD
and NetBSD and OpenBSD SYN cache code are not totally congruent.
The FreeBSD and NetBSD "cookie" interface for restart of directory
traversals are similarly inverted.  There are millions of examples
of gratuitous differences that could be corrected -- and should be,
before trying to make this argument.


> > FWIW, I would agree with you, if you were advocating a cross-OS ABI
> > definition of manifest constants, so that FreeBSD's new ABI, and, say,
> > Solaris or Linux's ABI, were more congruent (you could get this without
> > a new sstem call vector entry point, by using a different "ELF brand"
> > value), but that's not what you are advocating.
> 
> I'm advocating we adopt pretty much the ABI for these calls that Solaris
> uses.  If you inspect their ipc.h, you'll see that they define two
> versions of the structure, ipc_perm, and ipc_perm32.  ipc_perm is the
> version that makes use of types such as uid_t and gid_t; ipc_perm32
> hard-codes these fields to 32-bit and can be used for compatibility.

No, actually you are suggesting adopting the API, with a similar
looking, but inequal ABI.  That's very different than the point I
was trying to make here.

If you are going to follow, rather than lead, then you would be best
served to follow the system with the largest software based that is
most similar to your own trarget market, in hopes of being able to
capture converts on the basis of binary compatability with the least
amount of pain.

Right now, in order to run Solaris binaries, FreeBSD requires a lot
of hacking, including the installation of commerciall licensed
shared libraries.


> > Also FWIW, my personal preference would be to follow the Solaris ABI;
> > it's the least volatile of all ABI's in this area.  In terms of the
> > available applications, Linux is probably a better choice, but in terms
> > of the amount of maintenance work required, Solaris is far and away the
> > leader.
> 
> We already have the SysVIPC wrappers for the Linux code, but those are
> actually broken because they don't take into account our truncation bugs.

ABI, not API.

And out "truncation bugs" are a result of a partial conversion of
the APIs.  If you are suggesting a complete conversion, well, I will
again point out that doing this job correctly touches a hell of a
lot more code than we should be looking at touching, just prior to
a major (not even a point!) release (starting with the on disk
quota structures, etc.).

-- Terry

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-current" in the body of the message