Date: Tue, 14 Nov 2000 15:15:06 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Julian Elischer <julian@elischer.org> Cc: Bosko Milekic <bmilekic@dsuper.net>, David Malone <dwmalone@maths.tcd.ie>, iedowse@maths.tcd.ie, freebsd-net@FreeBSD.ORG Subject: Re: M_RDONLY: review & comment Message-ID: <20001114151506.F11449@fw.wintelcom.net> In-Reply-To: <3A11329A.D54E17E3@elischer.org>; from julian@elischer.org on Tue, Nov 14, 2000 at 04:39:54AM -0800 References: <Pine.BSF.4.21.0011121119030.11341-100000@jehovah.technokratis.com> <3A11329A.D54E17E3@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [001114 14:59] wrote: > Bosko Milekic wrote: > > > > On Sun, 12 Nov 2000, David Malone wrote: > > > > > > The other option I thought of is to use a char *. You could point > > > to a static string describing the type of external storage. This > > > way is still fast comparing types, just compare the pointers. If > > > you want to know what the type is in human readable format (for > > > debugging) you just look at the string it points at. Also the > > > kernel allocates different addresses for different strings, so > > > it automatically solves the problem of allocating unique numbers > > > to each type. > > > > > > David. > > > > using char * is unsafe if the aim is to tag mbufs that were allocated > by some module, if the midule is unloaded.. > (the mbufs may hang around in some queu way afte the module has gone.. > and an attempt to follow the char 8 pointer......) That doesn't have to be true, see src/sys/kern/uipc_accf.c, as long as the char * is malloc'd and not forceably free'd on module unload we're safe although we may leak memory. -- -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?20001114151506.F11449>