On 02/24/2016 01:49 PM, Jamal Hadi Salim wrote:
On 16-02-23 10:34 AM, Daniel Borkmann wrote:
[...]
My concern is we add 20 new modules like this that only do trivial things,
where instead they could have been consolidated and reduce maintenance. Or
is this hard module requirement related to the IFE_META_* module parameter?
Yes, a bit of that ++.
I am between two worlds: There are people who do user space packet
processing that claim they do so because they can quickly prototype
without compiling the kernel. My goal is to make it easy for people
adding new metadata without having to deal with kernel recompile.
Seems like a case for cls_bpf? ;)
I do expect for there to be many variations of what that metadata
will be. For that reason I have them as standalone modules and they
serve the purpose to illustrate how someone would write such a module.
The IFE_META_XXX is part of saying i dont need to have people
changing the header file either. But i want them to use static
META_IDS. So the IFE module parameter is supposed to allow them to
change the upper bound of modules when insmoding ife_act so that
proper validation can happen. I cant make it as large as 32-bit
or not check if it is correct. If i take it out - then i would have to
do that or introduce some complex mechanism for registration.
Ok, sure, given the assumption that this is only to be used in your own
fully _controlled_ environment anyway. But in that case, you don't even
need to define any fixed IDs. Currently it seems like you could have
different kernel versions with different IFE_META_MAX from the kernel
headers and external modules define part of the ID space differently?
Thanks,
Daniel
