Date: Mon, 07 Oct 2002 17:32:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Sam Leffler <sam@errno.com>, freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: CFR: m_tag patch Message-ID: <3DA2278A.A1A33A02@mindspring.com> References: <Pine.BSF.4.21.0210071553000.34884-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > 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, I give up. Why is 2^32 possibilities better than 2^16th possibilities? You have > 65536 different chunks of metadata you need to deal with? > > 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. I don't buy this. At this point, you are arguing statistical protection, and you are talking about a difference in collision probability, not collision avoidance. If 16 is bad, and 32 is good, then 64 is better. If 64 is "way too big", then 16 vs. 32 is just a matter of opinion, nothing else. > > 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. That assumes that the numbers people pick are actually random; they won't be. The way to handle this is to ask the kernel for a unique number for use in the registration process. > > Specifically, if you are going to register in new types without an > > assigned numbers authority (e.g. if I have a vendor private extension, > > which I wish to implement, yet not have collide with someone else's > > vendor private extension or a future FreeBSD "standard extension"), > > then you need to implement a registration interface for named > > registration, and use *that*. > > Terry if you like your chances of developing a module within the next > 100 years in exactly the same moment to the second that someone else > does so, and neither of you checks in that module, and your modules > have to co-exist, and you don't TALK to each other, then I have some > used lottery tickets I an sell you.. So it's a timestamp? You didn't say that it was a 32 bit time counter, so that simultaneuity was a requirement for a collision. > > I think it has to. The reason he has this is pretty clear from > > his crypto work, and the reason for the linked list is to, in the > > limit, allow a linear traversal of the list elements to find data > > that's relevent to you. > > Read what he said Terry.. for gods sake. He said that there are usually > < 2 metadata elements each being a few bytes long.. You keep avoiding his reason for the linked list, Julian. > > It's kind of ugly, but "anything that works is better than anything > > that doesn't"... it at least guarantees that it *can* work. > > there is more than one way to skin a cat. the fact that it is a linked > list doesn't mean it has to be a linked list. -- Terry 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?3DA2278A.A1A33A02>