Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Aug 2004 16:45:08 -0600
From:      Scott Long <scottl@freebsd.org>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: option directive and turning on AOE
Message-ID:  <4134FF74.4010105@freebsd.org>
In-Reply-To: <4134FCAE.7374599A@freebsd.org>
References:  <Pine.LNX.4.60.0408311611550.7530@athena> <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4134FF74.4010105>