netdev - Re: [RFC PATCH 6/6] ipv6: IPv6 over IEEE1394 (RFC3146) support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Jan 2013 17:37:32 +0100
From:	Stephan Gatzka <stephan.gatzka@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	netdev@...r.kernel.org, linux1394-devel@...ts.sourceforge.net
Subject: Re: [RFC PATCH 6/6] ipv6: IPv6 over IEEE1394 (RFC3146) support.


> Dito, please do not solve this with an EXPORT from drivers/firewire/net.c.
Again, I totally agree from the architectural point of view.

>
> Either a new driver callback is required, and the function pointer to this
> callback needs to be reachable indirectly via the skb pointer.

How I understand the whole ndisc code, ndisc just copes with struct 
net_devices. So to break the dependency to the firewire net driver an 
optional callback routine in struct net_device might be the easiest way.

> Or drivers/firewire/net.c needs to be aware that it just received an NDP
> packet, and then call a parser function in net/ipv6/ndisc.c which returns
> the data that drivers/firewire/net.c wants to know.

I think that is definitely to late. All cryptographic stuff (IPSEC) will 
be done and I don't think we want to recalculate that afterwards.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html