Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 21:50:27 +0600
From:      Alexey Dokuchaev <danfe@nsu.ru>
To:        Scott Long <scott_long@btc.adaptec.com>
Cc:        Bosko Milekic <bmilekic@unixdaemons.com>, Nate Lawson <nate@root.org>, Bruce Evans <bde@zeta.org.au>, Alfred Perlstein <alfred@freebsd.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi
Message-ID:  <20030122155027.GB63624@regency.nsu.ru>
In-Reply-To: <3E2DF620.2040700@btc.adaptec.com>
References:  <20030122100003.K30758-100000@gamplex.bde.org> <Pine.BSF.4.21.0301211726290.66961-100000@root.org> <20030121203745.A74950@unixdaemons.com> <3E2DF620.2040700@btc.adaptec.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 21, 2003 at 06:38:40PM -0700, Scott Long wrote:
> Bosko Milekic wrote:
> >
> >  The compatibility argument doesn't really carry that much weight
> >  'cause you have to remember that our semantics are actually different
> >  from the other BSDs.  I can certainly confirm this for the mbuf code.
> >  For example, we already have a different name for the "wait"
> >  equivalent of the flag (it's M_TRYWAIT not M_WAIT) and, further,
> >  calling the allocator function with M_TRYWAIT for us doesn't mean the
> >  same thing as calling the allocator function with M_WAIT does on the
> >  other BSDs (for the mbuf code, anyway).  Furthermore, I think that the
> >  other BSDs still actually 'share' the wait and dontwait flags with the
> >  between the malloc() and mbuf allocator subsystems (somewhat for
> >  historical reasons on which I can elaborate if you think that it's
> >  necessary).
> >
> >  Clearly, we've already got not only API differences but even more
> >  importantly semantics differences with the other BSDs in this area.
> >  Fighting to keep the old code for 'compatibility' reasons is therefore
> >  kind of pointless.
> >
> >Regards,
> 
> Bosko,
> 
> I think that Nate's concern was *binary* compatibilty with 5.0, i.e. being
> able to load 5.0 kld's on a 5.1 system.  It's a very noble and worthy goal
> to attempt, though at this point I don't know if it's possible.

Considering "special" status of 5.0, it seems fine to treat binary
compatibility as ability yo load >=5.1(2) kld's on further 5.x series.

./danfe


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122155027.GB63624>