Date: Sun, 15 Oct 2000 13:19:25 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: M_{LEADING,TRAILING}SPACE definitions.
Message-ID: <20001015131925.I272@fw.wintelcom.net>
In-Reply-To: <200010152018.aa65610@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Sun, Oct 15, 2000 at 08:18:24PM %2B0100
References: <200010152018.aa65610@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
* David Malone <dwmalone@maths.tcd.ie> [001015 12:18] wrote: > I'm just looking at implimenting writeable external storage management > for mbufs. Most parts of the kernel are quite conservative about > writing to anything that isn't a plain mbuf, and this work should > allow it more freedom. [snip] > 1) Both return 0 if the storage isn't writable. > 2) Have both return the amount of space, but make the kernel check > M_WRITABLE(m) before writing to it. > > M_LEADINGSPACE is only used about 16 times in the kernel and it's > users tend to assume that the space in question will be writable. > M_TRAILINGSPACE is used about 60 times, most consumers seem to > ensure the writeability themselves. This suggests I should go for > option 2 and then check the places where M_LEADINGSPACE is called. How about M_TRAILINGSPACE_WRITABLE/M_LEADINGSPACE_WRITABLE? This is self documenting and would probably prevent such errors in the future. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001015131925.I272>