option directive and turning on AOE

[Scott Long]

Andre Oppermann wrote:

> Julian Elischer wrote:
> 
>>Brooks Davis wrote:
>>
>>
>>>On Tue, Aug 31, 2004 at 02:27:33PM -0600, Scott Long wrote:
>>>
>>>
>>>
>>>>Sam wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I've added code to if_ethersubr.c:/ether_demux/
>>>>>to queue up AoE frames as they appear.  I followed
>>>>>suit with other protocols and included my addition
>>>>>inside of an #ifdef AOE.  Where do I turn this on?
>>>>>I thought perhaps just adding an 'option AOE' to
>>>>>the config would do it, but it doesn't -- so clearly
>>>>>I don't understand how the option directive works.
>>>>>The config man page doesn't talk about option/device
>>>>>directives ...
>>>>>
>>>>>I'm still looking, but a clue would be well received.
>>>>>
>>>>>
>>>>
>>>>Did you modify /sys/conf/options to tell it about your
>>>>AOE option?  If so, then you should have specified the name
>>>>of a header file that the option would be #define'd into.
>>>>Include that header file in if_ethersubr.c and you should
>>>>have no problems.
>>>>
>>>>Incidentally, this might be an area when netgraph would be
>>>>useful.  Instead of having an AoE specific hook in the
>>>>stack, you could have an AoE netgraph module that uses the
>>>>existing netgraph hooks.  It's just an idea, though.
>>>>
>>>>
>>>
>>>Another option might be a PFIL hook.  There isn't one there now, but I
>>>think I've seen talk of adding one.  Actually, if we did that, we could
>>>get most of the netgraph specific hooks out of the ethernet code.
>>>
>>
>>or visa versa..
>>make pfil have a netgraph hook. then you could use it to filter all
>>kinds of things in netgraph graphs.
> 
> 
> Yea, a ng_pfilhook module should be fairly easy to write.  I don't like
> it the other way around.  PFIL_HOOKS is a hooking mechanism, so something
> should hook itself in there.
> 
> PS: I'm thinking about moving all the IPSec cruft in IPv4 into a pfil
> hook.  Thus IPSecKAME and FastIPSec could be loadable modules and it
> would relieve ip_input/output.c by some more 1000's of lines.  Haven't
> looked fully into it yet though.  I'm sure there are some difficulties
> hidden somewhere. ;-)
> 

Having a single common interface is definitely attractive, but there are
performance and locking issues with the Netgraph framework that should
probably be resolved first.

Scott