Date: Thu, 28 Nov 1996 11:03:14 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Cc: current@freebsd.org Subject: Re: users of "ft" tapes, please test! Message-ID: <199611280003.LAA02208@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>kernels. How much is saved by this change? > >4k in VM-space available for user-land. A seriously strained resource >if 4MB installs are to be possible. Unless the 512(?)-byte code bloat costs another text page? >>but it is harder to debug. How about a new flag M_NOFAIL which causes >>a panic if malloc() would fail. M_WAITOK is rarely correct in probes >>(hanging is worse than panicing) and M_NOWAIT is inconvenient if you >>actually check for errors. > >Good idea. Maybe, M_PANICFAIL is more obvious. I just thought of another one: M_WAITREALLYOK. Failures would cause panics if this isn't set and malloc() would wait and malloc() was called at splnonzero(). Few callers running at a nonzero spl are prepared to be context switched, since switching exposes them to state changes by both interrupt handlers and other processes. E.g., sioopen() attempts to nail things down using spltty() but it calls ttyopen() via l_open() and ttyopen() calls clist_alloc_cblocks() which calls malloc(..., M_WAITOK). Callers that are prepared to block can call spl0() and/or would like to know if they did block so that they can skip recovering from state changes if they didn't. This would get messy for nested callers. I think the end result would be that M_WAITOK would rarely be used in device drivers. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611280003.LAA02208>