Date: Sun, 12 Nov 2000 13:10:32 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Bosko Milekic <bmilekic@dsuper.net> Cc: iedowse@maths.tcd.ie, freebsd-net@freebsd.org Subject: Re: M_RDONLY: review & comment Message-ID: <200011121310.aa19093@salmon.maths.tcd.ie> In-Reply-To: Your message of "Fri, 10 Nov 2000 00:54:09 EST." <Pine.BSF.4.21.0011100039040.92343-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> dwmalone, anything to add? (I modified the behavior in m_pulldown() > just a bit w.r.t. the original patch, so feel free to glance at > that). Ahhh, crap, I ment to reply to you about this before you committed it, but I've been too busy. (I'm also not on freebsd-net, so I didn't notice the post until Ian pointed it out ;-() I was talking to Ian about the ext_type stuff, and there is a problem with it. The problem is that you need to allocate a static number for each type in question, which is not good for loadable modules which might define their own types. In general people are trying to get away from fixed things like major device numbers and this seems to be just another of these things. I can think of two possible alternatives. One is to get rid of the ext_type stuff, as it doesn't really buy us anything, except maybe slightly clearer code or being able to tell the type while debugging. 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. 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? <200011121310.aa19093>