From owner-freebsd-arch Tue Oct 8 0:55: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 288C237B401; Tue, 8 Oct 2002 00:55:05 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EF443E77; Tue, 8 Oct 2002 00:55:04 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0058.cvx21-bradley.dialup.earthlink.net ([209.179.192.58] helo=mindspring.com) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ypCi-0004Yb-00; Tue, 08 Oct 2002 00:54:56 -0700 Message-ID: <3DA28F08.658274C3@mindspring.com> Date: Tue, 08 Oct 2002 00:53:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Don Lewis , nate@root.org, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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