From owner-cvs-all Tue Jan 21 17:42:38 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 677FE37B401; Tue, 21 Jan 2003 17:42:32 -0800 (PST) Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1265E43E4A; Tue, 21 Jan 2003 17:42:32 -0800 (PST) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6+Sun/8.11.6) with ESMTP id h0M1feK10425; Tue, 21 Jan 2003 17:41:40 -0800 (PST) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA29041; Tue, 21 Jan 2003 17:41:39 -0800 (PST) Received: from btc.adaptec.com (hollin [10.100.253.56]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA21557; Tue, 21 Jan 2003 18:41:36 -0700 (MST) Message-ID: <3E2DF620.2040700@btc.adaptec.com> Date: Tue, 21 Jan 2003 18:38:40 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bosko Milekic Cc: Nate Lawson , Bruce Evans , Alfred Perlstein , 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 References: <20030122100003.K30758-100000@gamplex.bde.org> <20030121203745.A74950@unixdaemons.com> In-Reply-To: <20030122100003.K30758-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bosko Milekic wrote: > On Tue, Jan 21, 2003 at 05:29:47PM -0800, Nate Lawson wrote: > > >On Wed, 22 Jan 2003, Bruce Evans wrote: > > > >>>On Tue, 21 Jan 2003, Alfred Perlstein wrote: > >>> > >>>> Log: > >>>> Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0. > >>>> Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT. > >> > >>Robert Watson wrote: > >> > >>>Hmm. I guess I missed the discussion; I'm a bit behind on mailing > lists. > >>>To improve code portability and careful thinking by developers, > what I'd > >>>like to see is something more like the following: M_WAITOK, which > >>>explicitly requests sleeping indefinitely, M_NOWAIT, which explicitly > >>>requests no sleeping. Rather than a "default" value, a > >> > >>That's exactly what M_WAITOK was supposed to do. Developers just had to > >>think about it since it wasn't really a flag so it was not easy to check > >>automatically. > > > >I like Robert's approach -- keep the flags as they were before but give > >M_WAITOK a value other than 0 and deprecate passing in 0 as an arg. This > >change only would affect binary kld compat and if 0 only generated a > >printf warning (one-shot) but still meant M_WAITOK for a little while, > >that would ease the migration. > > > >-Nate > > > 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. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message