On Dec 15 2007 17:42, Pablo Neira Ayuso wrote: >Jan Engelhardt wrote: >> On Dec 15 2007 16:55, Pablo Neira Ayuso wrote: >>> The revision thing was a hack that I introduced myself to let us add >>> several improvements that we really needed at that time, actually it is >>> not something we should abuse IMO. >>> >> But it looks like the cleanest way to do things. If you think it is abuse, >> do you have a better way? > >Indeed, it is the best way to do things as for now but I don't think >that we should pollute the code with tons of revisions unless that it is >necessary. > Pollution is the result of not throwing away old things. Windows is probably best example of that. Granted that old revisions need some time to go away, but that does not mean we should really wait for the next linux 2.x.0 for all old revisions to purge, _should_ the revision number be very big. And they are not very big right now. Taking all floating patches into account, 1 module is at revision 2 (MARK), 6 modules at revision 1 (TOS, tos, multiport, owner, CONNMARK, connmark) and all others at 0. >>>> Old revisions should be purged after a "reasonable time" (whatever >>>> that means for everyone), or perhaps whenever there is a Linux kernel >>>> version with a trailing .0 (2.7.0, 2.8.0), or when great new things >>>> appear (pkttables, or whatever is in the works). >>>> >>>> I think the step should better be made now than later, or this cruft >>>> will be carried for the next 10 instead of 5 years. >>> I hope that we'll get that long-awaited netlink interface for iptables >>> before those 10 years goes by and we all become museum pieces :) >>> >> What will netlink bring us, with respect to the two states: >> - old iptables, new kernel >> - new iptables, old kernel >> so matching some UUIDs (and .revision is one, more or less) seems like the way >> to go. > >Netlink doesn't stick us to fixed structure layouts as it happens to the >current interface since we represent the messages kernel <-> userspace >in TLV (type-length-value) format. Thus, userspace and kernel won't >share structures and new features just require a new type. For that >reason, the netlink interface won't require such revision infrastructure. > Please explain the TLV thing. How would something like struct ipt_tos_target_info (revision 0, in net-2.6.25/xt_DSCP.c) and struct xt_tos_target_info (revision 1, in net-2.6.25/xt_DSCP.c) be encoded? Does the mere presence of a TLV block (sending it over netlink) indicate a certain revision? >Not that I'm against your patches, I'm just stating the right direction >to go for those 5-10 years that you have mentioned. And of course, we >don't have a single line of such interface at the moment :) > Which is why you can't be against the patches by definition and they should go in. :p - To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
