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>