Date: Mon, 7 Oct 2002 23:28:29 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Nate Lawson <nate@root.org> Cc: Terry Lambert <tlambert2@mindspring.com>, Sam Leffler <sam@errno.com>, freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch Message-ID: <Pine.BSF.4.21.0210072325060.37238-100000@InterJet.elischer.org> In-Reply-To: <Pine.BSF.4.21.0210072203180.9216-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210072325060.37238-100000>