On Sat, Feb 28, 2015 at 11:00 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: Eyal Birger <eyal.birger@xxxxxxxxx> > Date: Sat, 28 Feb 2015 22:38:04 +0200 > >> My concern is that any value I pick based on the existing implementations >> would need to be adjusted come a protocol with a larger address length. > > Then we need a method that requires protocols to register their > address length in a manner that will allow us to validate that > limit at compile time. > Sorry to reiterate this, but such validation will inherently become the actual limit for hardware addresses. So, it would be equivalent to changing the in-kernel definition of MAX_ADDR_SIZE. Is this something to be considered? > This is not rocket science. > > Right now we're proposing to do utterly stupid shit like encoding > integers in device pointers in the sk_buff, when that is absolutely > not necessary at all. Ok. Another suggestion I received was to delay the preparation of the full sockaddr_ll until it is needed, and store the skb original length in the first two fields (sll_protocol and sll_family) as they can be derived later on from the skb. IMHO, It would still be somewhat of a hack though. Would that approach be considered? Regards, Eyal. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
