Date: Wed, 01 Sep 2004 00:33:18 +0200 From: Andre Oppermann <andre@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE Message-ID: <4134FCAE.7374599A@freebsd.org> References: <Pine.LNX.4.60.0408311611550.7530@athena> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-) -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4134FCAE.7374599A>