All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: stephan.gatzka@gmail.com
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
	linux1394-devel@lists.sourceforge.net, netdev@vger.kernel.org
Subject: Re: IPv6 over firewire
Date: Sat, 12 Jan 2013 09:27:30 +0100	[thread overview]
Message-ID: <20130112092730.2cd18294@stein> (raw)
In-Reply-To: <50F10C53.4000803@gmail.com>

On Jan 12 Stephan Gatzka wrote:
> 
> > And, last but big issue is, well, packet inspection at
> > driver level.  For example, you use ndisc_parse_options()
> > and code depends on CONFIG_IPV6=y.
> 
> Good point. Of course I can make firewire-net dependent from IPv6.
> 
> The other option is to build a separate firewire_ipv6 module. 
> Implementing that looks easy enough. From the original firewire net 
> driver I just need a hook to register a function that investigates 
> incoming packets for IPv6 link layer option. In addition, 
> fwnet_peer_find_by_guid must be exported.
> 
> Stefan, what is your opinion on that?

>From your previous patch it looks like that the RFC 3146 related parts in
drivers/firewire/net.c are just a few places that can be enclosed into
#if/#endif blocks.  That way, firewire-net will be built according to the
same Kconfig switches as before, and gets RFC 3146 capability if
CONFIG_IPV6=y or =m.

#if/#endif are generally not very nice, but in this case I think they can
be kept localized and thus are more beneficial than hurtful.

There is a catch:  Since both net/ipv6/Kconfig::IPV6 and
drivers/firewire/Kconfig::FIREWIRE_NET are tristate variables, we need to
prevent CONFIG_FIREWIRE_NET=y while CONFIG_IPV6=m.  One way to do that
would be like it was done for the infrared remote control support in the
firedtv driver which depends on the CONFIG_INPUT tristate variable.  This
was solved like this:
  - The helper variable drivers/media/firewire/Kconfig::DVB_FIREDTV_INPUT
    was added.
  - This variable is true if CONFIG_INPUT=y,
    or if CONFIG_DVB_FIREDTV=m and CONFIG_INPUT=m.
    In other words, if CONFIG_INPUT=m and CONFIG_DVB_FIREDTV=y, firedtv
    silently loses support for remote control input.
  - The respective firedtv parts are of course made dependent on
    CONFIG_DVB_FIREDTV.  In this case, only
    drivers/media/firewire/firedtv.h and drivers/media/firewire/Makefile
    are minimally affected.

So, if implemented like that, the special case of CONFIG_FIREWIRE_NET=y &&
CONFIG_IPV6=m would mean that firewire-net would be built but would lack
RFC 3146 support.

With a little bit more Kconfig related effort one could solve it such that
CONFIG_FIREWIRE_NET=y && CONFIG_IPV6=m would actually put RFC 3146 support
into firewire-net but would force it to be built modular instead of
statically.

Not sure which way is preferrable.  Cc'ing netdev.

In case of CONFIG_IPV6=n however, people should still be able to build
firewire-net with its current RFC 2734-only feature set.
-- 
Stefan Richter
-=====-===-= ---= -==--
http://arcgraph.de/sr/

       reply	other threads:[~2013-01-12  8:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <50EF1AEB.1080704@gmail.com>
     [not found] ` <50EFE095.2040505@linux-ipv6.org>
     [not found]   ` <50F10C53.4000803@gmail.com>
2013-01-12  8:27     ` Stefan Richter [this message]
     [not found] ` <20130110210912.09c62d38@stein>
     [not found]   ` <50F10E94.9090302@gmail.com>
2013-01-12  9:24     ` IPv6 over firewire Stefan Richter
2013-01-12 10:54       ` Stephan Gatzka
2013-01-12 13:57         ` Stefan Richter
2013-01-12 14:37         ` Stefan Richter
2013-01-12 14:42           ` Stephan Gatzka
2012-12-21 17:03 IPv6 over Firewire Stephan Gatzka
2012-12-21 17:53 ` YOSHIFUJI Hideaki
2012-12-21 18:39   ` Stephan Gatzka
2012-12-21 19:49     ` YOSHIFUJI Hideaki
2012-12-21 23:12       ` Stefan Richter
2012-12-22  6:03         ` Stephan Gatzka
2012-12-22  6:10       ` Stephan Gatzka
2012-12-22  9:15         ` Stefan Richter
2012-12-22 18:33           ` Stephan Gatzka
2012-12-23  8:23         ` YOSHIFUJI Hideaki
2012-12-23 11:13           ` Stephan Gatzka
2012-12-23 12:09             ` YOSHIFUJI Hideaki
2012-12-23 13:25               ` Stephan Gatzka
2012-12-23 17:09                 ` YOSHIFUJI Hideaki
2012-12-23 18:25                   ` Stephan Gatzka
2012-12-23 19:38                     ` YOSHIFUJI Hideaki
2012-12-23 23:52                     ` Stefan Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130112092730.2cd18294@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=stephan.gatzka@gmail.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.