From owner-freebsd-stable  Thu Jul 15 10:11:23 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP
	id 632F4155AA; Thu, 15 Jul 1999 10:10:48 -0700 (PDT)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id NAA03267;
	Thu, 15 Jul 1999 13:08:45 -0400 (EDT)
Date: Thu, 15 Jul 1999 13:08:45 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <199907151708.NAA03267@pcnet1.pcnet.com>
To: jkh@zippy.cdrom.com, tg@ihf.rwth-aachen.de
Subject: Re: seg fault in mutex_queue_enq
Cc: eischen@vigrid.com, hackers@FreeBSD.ORG, kip@lyris.com,
	stable@FreeBSD.ORG
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > Jordan should have to say something about this. AFAIR, bumps are
> > allowed but only by one between releases. We will have to provide
> > libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this 
> > anyway by the time 4.x is released).
>
> I'd prefer not to bump it...  John Birrell and I are already not
> entirely in agreement that the change required a version bump at
> all.  It didn't change any interfaces.

I don't care one way or the other.  I could leave out the wrapped
poll() very easily and avoid the issue all together.  This would
provide -stable with everything -current has, except of course
poll().  I'd prefer to add poll, though...

If you don't bump the version in -stable, then you could end up
with two versions of libc_r that are not different (assuming -current
doesn't make any subsequent changes that warrant a version bump).

Just tell me what to do, and I'll do it :-)

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message