From owner-freebsd-net Mon Oct 7 23:40:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAD8437B401; Mon, 7 Oct 2002 23:40:09 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E6343E75; Mon, 7 Oct 2002 23:40:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008064008.CZCQ18767.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 06:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA38152; Mon, 7 Oct 2002 23:28:30 -0700 (PDT) Date: Mon, 7 Oct 2002 23:28:29 -0700 (PDT) From: Julian Elischer To: Nate Lawson Cc: Terry Lambert , Sam Leffler , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 7 Oct 2002, Nate Lawson wrote: > On Mon, 7 Oct 2002, Julian Elischer wrote: > > On Mon, 7 Oct 2002, Terry Lambert wrote: > > > On Mon, 7 Oct 2002, Julian Elischer wrote: > > > > Your tags have a single 16 bit tag ID field. > > > > This is insufficient for my needs. > > > > I need to be able to store the API cookie which is a 32 bit > > > > unsigned number, and on top of that, I also need a 16 bit type field > > > > that specifies what the data is within teh given API and a 16 bit > > > > length to allow opaque handling. > > > > > > This is insufficient for Alpha and other 64 bit architectures. I > > > think what you are asking for is really a 'void *'. > > > > IT IS NOT A POINTER! > > > > it is a 32 bit unsigned number. > > Ok. > > > > The other issue here is that your idea of an opaque API/ABI indicator > > > is in conflict, unless you say that this is a pointer, and then format > > > the initial information pointed to by the pointer. Otherwise, you > > > will need a small indirection structure that's pointed to the pointer, > > > AND which contains the API/ABI identifier (i.e. you will need two, not > > > one piece of information for that -- which is what you show, but not > > > what you describe in your text). > > > > it is not used to look up anything.. > > it is used to verify only. > > > > it is just working on the principal that there is not going to be > > a collision in the 32 bit space. Especially when we create them from > > "time since the epoch", and when teh various authors can see each > > other's choices of value. > > There are deterministic ways to generate them. > 1. A counter -- gettag() { return tag++; } > 2. A LCRG -- gettag() { return (A * tag) % n; } > 3. A global registry -- "Hey, gimme a major" > > There are non-deterministic ways as well, i.e. hash functions and > PRNGs. And if code can run faster than a given time source, the output of > that source or permutation thereof can produce collisions. > > What leads you towards the time-based option vs. the others, especially > the deterministic ones? > > > > This is moderately bogus. > > > > no it is not. > > > > I estimate that the chance of having a collision given all the > > factors is 1:2^50 or so ASSUMING THAT 1000000 PEOPLE DEVELOP THEIR OWN > > MODULES AND DO NOT CHECK THEM IN BUT DO ALL SHARE THEM WITH EACH OTHER. > > Hmmm, if they choose them at random, the chance of a collision is > sqrt(n) or 1/(2^16). If they choose them perfectly coordinated, the > chance is 1/(2^32). Much less than 2^50. Nate, what is the chance you will load 1 million netgraph node types? If you load 3, what is the chance they were all non-checked in nodes and the authors weren't communicating, and you are the first person to ever combine them? now multiply That by 2^32 down 2 > > -Nate > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message