RFC: libkse*.a in 7.0

[Alexander Leidinger]

Quoting Daniel Eischen <deischen at freebsd.org> (Tue, 11 Dec 2007 08:52:30 -0500 (EST)):

> On Tue, 11 Dec 2007, Kostik Belousov wrote:
> 
> > On Tue, Dec 11, 2007 at 08:02:16AM +0100, Alexander Leidinger wrote:
> >> I work in the office of SUN in Luxembourg, and one of our ideas for a
> >> client was to run a Solaris 8/9 in a zone of a Solaris 10 as a
> >> replacement for machines with Solaris 8/9. As we have a service
> >> contract with our client, we have to take some business constraints
> >> into account. And one of those business constraints is that Solaris
> >> 8/9 in a zone of Solaris 10 is not supported, as the kernel interface
> >> (syscalls) changed in an incompatible way.
> > 
> > Look at the project Etude.

Until it is in an official Solaris release, our client can not be
convinced to consider it.

> The syscalls are only exposed in an ABI compliant way through the
> libraries, which is what we should do also.  But I think if you

I don't think so. So far we had no problems with having the
compatibility in the kernel, and I haven't read on current, arch or
hackers that this is a major roadblock for something. And as long as
this is not the case, I think we should support (and I mean _really_
support it, and not a half-backed yes and not trying to find a
compatible solution if it is not directly obvious) the kernel
compatibility.

> were to plop the Solaris 10 libraries (at least the symbol-versioned
> ones) over the Solaris 8/9 image, it might have a chance of working
> for you.  Hmm, unless the Sun private symbols in Solaris 8/9 were
> not versioned and kept as compatible versions in Solaris 10.
> It might be interesting to try it and see what happens ;-)

And then you lose support for Legato Networker, Oracle and other
commercial software, as you don't run in a certified environment (which
is not an argument for FreeBSD, but for our Solaris installation at
work).

Our client is shy. We all know this kind of management decisions: some
systems which can not be upgraded stay at this level "forever", even if
there's no support at all in the end anymore (because it just works,
and with the other solution there may be a problem because it is not
officially supported).

Now, what if we abandon our official support we had in this regard?
Some manager asks if it is supported, the technician doesn't want to
lie, says no, and the manager says forget about FreeBSD, in Linux we
don't have this compatibility too, but we get commercial support from
companies which outweights the remaining features.

Do we want that?

I don't think having compatibility in the libs is a bad idea. I like
this idea, as it allows to run old programs without the need to install
a compat package from ports. I just want to make sure that we all know
that we have a very valuable feature by ensuring backwards
compatibility in the kernel, and that we should not throw it away.
Having backward compatibility in the libs is an _additional_ feature I
look forward to.

Bye,
Alexander.

-- 

http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137