On Monday 02 September 2013 22:04:55 Jozsef Kadlecsik wrote: > Hi Oliver, > <snip> > > [Instead of extending "enum ipset_cadt_flags", better rely on the > existing "enum ip_set_extension".] > > The set extensions in their current form (full unique structures defined > in all combinations ) reached their limit from management point of view. > So a cleanup should change it, with the goal of keeping the memory > requirements to the same as present but opening up for more possible > extensions. > > One possible way is to use memory blobs where the first part is the base > structure for a given type (like "struct hash_netnet4_elem"), and the set > structure is extended with the offsets to the extensions in the blob next > to the base structure. That involves a couple of castings and changing > access to all extensions by pointers (that means some reorganizatiom for > the timeout extension). > > What do you think? > > Best regards, > Jozsef I looked again at my simplification and realised that actually it can be made extremely trivial, all the struct combinations and handling of flag combinations can go away and we can just have the for() loop that does setup for each flag. I'm still using cadt_flags because in order to move to using the extensions enum, from what I currently see, that'd require a bit of a redo in userspace to send it across in the netlink message as a separate thing - which, whilst that does strike me as a nice thing to get done, I'd consider it largely separate from just cleaning up that ugly mess. Anyhow, I've completed the cleanup, [PATCH v2] will land shortly, details in cover letter. Kind Regards, Oliver. -- 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
