Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jan 2003 09:33:06 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Alfred Perlstein <alfred@FreeBSD.org>
Cc:        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_da.c         scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...
Message-ID:  <Pine.NEB.3.96L.1030121092713.60586B-100000@fledge.watson.org>
In-Reply-To: <200301210856.h0L8uGF3078830@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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
KASSERT(M_WAITOK^M_NOWAIT, ("Bad malloc sleep flags")).  With the SMP
kernel work, it's rapidly become clear that we want developers to actually
think about every allocation and sleep case, rather than relying on a
default.  One further caveat: with this change, we should be even more
careful to document that M_WAITOK in the case if malloc() will sleep
forever, and that with the mbuf code, you can get back NULL.  In principle
though, I think doing this sort of cleanup is a good idea. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories


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?Pine.NEB.3.96L.1030121092713.60586B-100000>