Date: Mon, 7 Oct 2002 23:33:20 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: nate@root.org, tlambert2@mindspring.com, sam@errno.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <Pine.BSF.4.21.0210072329190.37238-100000@InterJet.elischer.org> In-Reply-To: <200210080606.g9866OvU034411@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Oct 2002, Don Lewis wrote:
> On 7 Oct, Nate Lawson wrote:
> > On Mon, 7 Oct 2002, Julian Elischer wrote:
>
> >> 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?
>
> 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.
>
>
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.0210072329190.37238-100000>