I’ve written an en-en filter layer which is running great. Now I need to
write another en-en layer that sits below the earlier one and above the
Ethernet card drivers. (My layers do different things so I want them as
separate shared objects, and one may not be used in all circumstances)
How do I control the stacking order of two en-en filter layers ?
Is it simply a matter of mounting in the correct order, or are there other
ways ?
It would be wonderful if it didn’t have to done by the mount order, or
failing that if the most recently mounted was stacked directly above the
drivers.
: I’ve written an en-en filter layer which is running great. Now I need to
: write another en-en layer that sits below the earlier one and above the
: Ethernet card drivers. (My layers do different things so I want them as
: separate shared objects, and one may not be used in all circumstances)
: How do I control the stacking order of two en-en filter layers ?
: Is it simply a matter of mounting in the correct order, or are there other
: ways ?
: It would be wonderful if it didn’t have to done by the mount order, or
: failing that if the most recently mounted was stacked directly above the
: drivers.
The most recently mounted _REG_FILTER_ABOVE goes directly above the
_REG_PRODUCER_UP(s) of the same type. So the order does matter but
the outcome is predictable.
: I’ve written an en-en filter layer which is running great. Now I need to
: write another en-en layer that sits below the earlier one and above the
: Ethernet card drivers. (My layers do different things so I want them as
: separate shared objects, and one may not be used in all circumstances)
does the optional (lower) one depend on the higher one? (It will never
be inserted by itself) maybe you could control the loading from the
higher one, by itself -
eth0-en en-en en-ip0
with the optional lower module -
eth0-en en-myif myif-en en-ip0
can filters rename themselves, possibly buffering the data till the
new filter is active ?
The most recently mounted _REG_FILTER_ABOVE goes directly above the
_REG_PRODUCER_UP(s) of the same type. So the order does matter but
the outcome is predictable.