Date: Tue, 08 Oct 2002 00:53:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Don Lewis <dl-freebsd@catspoiler.org>, nate@root.org, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <3DA28F08.658274C3@mindspring.com> References: <Pine.BSF.4.21.0210072329190.37238-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > Why not name them? At boot or module load time stuff the name in a > > table and use the table index as the 16 bit ID. Is there any reason the > > ID has to be the same each time the system is booted? > > I want to be able to specify an OLD API and the NEW version > if I can only get a particular node in object form, and I knowi uses the > old version, and some other code I have uses the new version, > and I need them to co-exist. > > one binary sync driver and one opensource drive,, running 2 sync cards, > both feeding into the "framerealy" code. > > All the "perfect" methods are more work than this really requires sonce > I'm pretty sure that a collision will not occur in the lifetime of this > civilisation. I've often thought that an interning process for atoms was actually a good idea for the kernel. The place I first thought of using this approach is for FS ID's. As things currently sit, there are header files that need to be hacked to add new members to (theoretically) anonymous classes of objects. One of the most egregious files in this regard is vnode.h, for the enumerated type values in 'vtype' and in 'vtagtype'. As an example, copy the NULLFS code to "FOOFS" instead, do all the name replacement in it, and see what breaks and/or wht gets accounted incorrectly. 8-(. Among other things, if you could intern them, and then enumerate them, based on defined classes, you could get rid of things like the socket protocol family crap, and most of the places where you end up pushing strings in API's across the user/kernel boundary. IMO, most strings you push across should be considered const members of range restricted sets. This is happy, in that it would work for the netgraph API ID code, as well (you look up a value by looking up the atom in a class table to get an ID, and then pass the ID around. I think the ID should be opaque, but you could call it a 16 or 32 bit calue, if you wanted to insist that it not be a pointer. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DA28F08.658274C3>