On Wed, 2006-03-15 at 10:21 -0500, jamal wrote: > It could - if it can proven to maintain backward compatibility. I > think backward compatibility would probably be fine to be defined as "it > works with one byte". > But you are right. It is a pain. One suggestion Stephen Hemminger had > was to transport the hash on a TLV; I am not a big fan of dynamic > coding.
If you reject utsname, then this is the only way to maintain backward compatibility. > Well, the way we strive to have code working in backwards compatible > format with any netlink derived code such as is the case with iproute2 > is to introduce new TLVs. This way old kernels ignore new ones and new ones > can opt to ignore old TLVs. You will never ever see code which says > "if this is 2.4.x then x" - it is considered close to blasphemy; more > importantly it adds maintainance overhead - imagine if someone changed > the hash in the kernel. Hehe. Thanks for the explanation - it is appreciated. I am a newbie at this kernel coding thing. > > Assuming you are not swayed by the arguments above, I think > > I have lost this one. I presume you have no objections > > to changing "tc" to use the 2.6 hash and leave it at that. > > Yes? > > > > > > indeed. OK, so the next email from me will be the patch. I would like to get the over with, so I can move onto the next set of patches I have for tc. > I dont agree with reverting the 2.6.x change. In the future if you do prove > that the old one is better or a newer one is better then we will revisit > given the definition we have of backwards compatibility above. > Note, you need a lot more data than the simple example you showed. > We can discuss this later etc. I am interested. Yes - later. I have posted data where the 2.4 algorithm fares better. To proceed with the discussion we need your data that shows it is worse. Then we can haggle about which is more likely in real life. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
