On Mon, Oct 6, 2008 at 12:15 PM, Jan Engelhardt wrote: > > On Monday 2008-10-06 14:57, James King wrote: >>update_alloc_size() skips over unregistered extensions, and it's a bug >>to pass (id == NULL) to nf_ct_ext_add() or nf_ct_ext_create(), so >>unused extensions shouldn't really impact memory allocation in terms >>of allocated region size. Under patch #3, nf_cf_ext_types[] has a >>single size increase by sizeof(nf_ct_ext_type), and it increases >>ct->ext->offset by one u8 (so per-conntrack increase). Is this size >>increase alone enough to rule it out, or am I missing something else >>here? > > What I meant is the offset[] array. If we were to add 1000 new ct > extensions, all users of the particular kernel would pay 1000 bytes > for space they will never fully use. > Additionally, NF_CT_EXT_NUM might be too undersized for > *yet more* modules (e.g. out-of-tree) to register their stuff. > It's like tcp port numbers - the number is only finite. > A linked list would "solve" this (allow for infinitely many extensions, > well, as long as your memory holds it), but of course at the cost > of traversing it, etc. as Patrick pointed out. > > I am not against these patches - over time, we only accumulated 2 > modules, and maybe there is not that much of a market for more > than a handul ones. Ah, ok, your first response felt like a NAK, thanks for clarifying. I agree that being able dynamically register unknown extensions in that fashion could be useful in the long run if lots of extensions were to start popping up, but at this point it's an dead even tradeoff between the two approaches, and my immediate goal is to get a module that many people already find very useful supported without an unnecessary patching process. -- 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
