Date: Mon, 7 Oct 2002 16:11:12 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: 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.0210071553000.34884-100000@InterJet.elischer.org> In-Reply-To: <3DA20C1C.A4B863B7@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Oct 2002, Terry Lambert 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. > > 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. > 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. > > 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.. > The easiest way to do this would be to ensure that you use the > *runtime* kernel address as your identifier, which guarantees that > it will be unique in any given system. Terry I am NOT going to do that.. end of argument. > 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.. > > 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. 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.0210071553000.34884-100000>