atom feed40 messages in org.freebsd.freebsd-archRe: CFR: m_tag patch
FromSent OnAttachments
Sam LefflerOct 6, 2002 9:38 pm 
Nate LawsonOct 6, 2002 10:01 pm 
Sam LefflerOct 6, 2002 10:21 pm 
Terry LambertOct 6, 2002 11:09 pm 
Julian ElischerOct 6, 2002 11:32 pm 
Julian ElischerOct 7, 2002 12:29 am 
Sam LefflerOct 7, 2002 9:24 am 
Sam LefflerOct 7, 2002 9:31 am 
Sam LefflerOct 7, 2002 9:46 am 
Julian ElischerOct 7, 2002 2:20 pm 
Terry LambertOct 7, 2002 3:34 pm 
Sam LefflerOct 7, 2002 3:52 pm 
Julian ElischerOct 7, 2002 4:10 pm 
Julian ElischerOct 7, 2002 4:22 pm 
Luigi RizzoOct 7, 2002 4:30 pm 
Julian ElischerOct 7, 2002 4:55 pm 
Sam LefflerOct 7, 2002 5:06 pm 
Julian ElischerOct 7, 2002 5:10 pm 
Julian ElischerOct 7, 2002 5:14 pm 
Julian ElischerOct 7, 2002 5:23 pm 
Terry LambertOct 7, 2002 5:31 pm 
Terry LambertOct 7, 2002 5:47 pm 
Nate LawsonOct 7, 2002 10:42 pm 
Don LewisOct 7, 2002 11:06 pm 
Julian ElischerOct 7, 2002 11:28 pm 
Julian ElischerOct 7, 2002 11:32 pm 
Terry LambertOct 8, 2002 12:42 am 
Terry LambertOct 8, 2002 12:53 am 
Harti BrandtOct 8, 2002 1:19 am 
Nate LawsonOct 8, 2002 11:25 am 
Don LewisOct 8, 2002 12:15 pm 
Sam LefflerOct 8, 2002 6:25 pm 
JINMEI Tatuya / 神明達哉Oct 10, 2002 7:33 pm 
Sam LefflerOct 11, 2002 11:11 am 
JINMEI Tatuya / 神明達哉Oct 16, 2002 3:03 am 
Luigi RizzoOct 16, 2002 7:45 am 
JINMEI Tatuya / 神明達哉Oct 16, 2002 11:06 am 
Luigi RizzoOct 16, 2002 11:18 am 
Julian ElischerOct 16, 2002 11:24 am 
Sam LefflerOct 16, 2002 11:29 am 
Subject:Re: CFR: m_tag patch
From:Luigi Rizzo (riz@icir.org)
Date:Oct 7, 2002 4:30:39 pm
List:org.freebsd.freebsd-arch

the 16 vs. 32 bit On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote: ...

Sounds to me like the real issue for you is insuring unique m_tag_id values. We're certainly less likely to have collisions with a 32-bit value than a 16-bit value and expanding this way gives you your "field ID" too. I guess the question I have is whether the existing API's that search only by "cookie" are sufficient for your needs. If so then I'm ok with changing things. Otherwise we have an API incompatibility with openbsd that I'd like to avoid.

i wonder what do we gain by moving to 32 bit m_tag_id -- because there is is still no strict guarantee that we have no conflicts if people randomly choose "cookies", and also, using the same reasoning for allocations one could argue that having the cookie chosen as the number of _days_ since the epoch, will still give low conflict probability while still fitting in 16 bits. Also, those modules that require one or a very small number of different annotations (e.g. all the ones currently using m_tags) would just need the "cookie", whereas others with a large set of subfields could as well consider the field_id as part of the opaque data.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message