Date: Tue, 8 Oct 2002 11:25:41 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <Pine.BSF.4.21.0210081117280.11243-100000@root.org> In-Reply-To: <3DA28F08.658274C3@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Oct 2002, Terry Lambert wrote: > 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'. Well, I killed vtagtype in -current. > 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. I am really against using an extremely large space (32 bits) in a sparse manner just because the algorithm is non-deterministic. The only exception is when the system may be attacked (i.e. a cryptographic hash function). In this situation, all players are cooperating but may make mistakes or be lazy if the system is difficult. Whatever system is chosen, there is no reason to make the algorithm non-deterministic. -Nate 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?Pine.BSF.4.21.0210081117280.11243-100000>