Re: IPv6 over firewire

[Stephan Gatzka <stephan.gatzka@gmail.com>]

> But if a new callback is needed, it doesn't have to burden the kernel much:
>
>    - In the linux-kernel OOP model, there are mandatory methods as well
>      as optional methods.  A new method for RFC 3146 Neighbor Discovery
>      should of course be an optional one.
>
>    - There is a downside to optional methods:  The core code which may
>      have to use the method first needs to do a NULL check of the
>      method's function pointer or needs to check a correlated
>      capabilities flag or something like that.  Such additional checks
>      are undesirable in hot paths, but I suppose IPv6 Neighbor Discovery
>      is not a particularly hot path.

Yes, that should be true.

>
>    - There is another downside:  Each new driver method increases the
>      memory footprint of instances of respective function pointer tables
>      by 4 or 8 bytes.

I can't imagine that this is a show stopper. How many instances of 
struct netdev do we have o a typical system? I guess not the much.

>
> Both downsides can be countered somewhat by enclosing the respective
> code into #ifdef CONFIG_RFC3146_NDISC...#endif and have something like
>      select RFC3146_NDISC if IPV6 = y || (IPV6 = m && FIREWIRE_NET = m)
> in the "config FIREWIRE_NET" section.
>
> But the new callback (if one is really needed) doesn't have to be a driver
> method.  It could also look about like this:
>
>      include/net/ndisc.h:
>      -extern struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
>      -		struct ndisc_options *ndopts);
>      +extern struct ndisc_options *__ndisc_parse_options(u8 *opt,
>      +		int opt_len, struct ndisc_options *ndopts,
>      +		whatever_type *callback);
>      +
>      +static inline struct ndisc_options *ndisc_parse_options(u8 *opt,
>      +		int opt_len, struct ndisc_options *ndopts)
>      +{
>      +	return __ndisc_parse_options(opt, len, ndopts, NULL);
>      +}
>
>      net/ipv6/ndisc.c:
>      -struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
>      -		struct ndisc_options *ndopts)
>      +struct ndisc_options *__ndisc_parse_options(u8 *opt, int opt_len,
>      +		struct ndisc_options *ndopts, whatever_type *callback)
>       {
>
> Or the (optional!) callback could be a new member of struct ndisc_options.

Hm, right now I have no opinion on that. Where does
whatever_type *callback comes from? Is it an exported method of the 
firewire net driver or the new function pointer in struct netdevice?

> However, does net/ipv6/ndisc.c really need to be aware of the RFC 3146
> Neighbor Discovery related packet header layouts?  Isn't it possible to
> rewrite these headers in-place in drivers/firewire/net.c?


Yes, it it possible, but yoshfuji strongly voted against rewriting ndisc 
packets in firewire net driver to maintain extensibility to protocols. 
Especially IPSEC can just not work if I rewrite the packets in the driver.

Regards,

Stephan


-- 
Welchen Unterschied gibt es zwischen einem toten Hund auf der
Straße und einer überfahrenen Bratsche auf der Straße? Vor dem
toten Hund gibt es Bremsspuren.