On Mon, Oct 6, 2008 at 12:48 PM, James King <t.james.king@xxxxxxxxx> wrote: > 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. Patrick, do you have any objections to these patches (specifically adding NF_CT_EXT_LAYER7), or were you just against Jan's suggestion to make ct_extend to use a linked list for all extensions? If not, would you like me to send a proper patch series? -- 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
