From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: netdev <netdev@vger.kernel.org>,
linux1394-devel@lists.sourceforge.net,
David Miller <davem@davemloft.net>
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information
Date: Mon, 28 Jan 2013 00:26:33 +0100 [thread overview]
Message-ID: <20130128002633.0eac1d6c@stein> (raw)
In-Reply-To: <51057FEF.9090006@linux-ipv6.org>
On Jan 28 YOSHIFUJI Hideaki wrote:
> Stephan Gatzka wrote:
>
> >> I am not a contributor to net/, hence don't have a say over how the
> >> networking APIs should evolve.
> >>
> >> Any solution is fine with me, as long as net/ does not use any definitions
> >> or declarations from <linux/firewire.h>.
> >
> > O.k. then I will go for Yoshifujis "extended hwaddress" approch.
> >
> > I think I will divide all the stuff into two major pieces:
> >
> > First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
> >
> > Then I'll implement the IPv6 stuff based on that IPv4 solution.
>
> I even think that we do not need to have event notification if we
> can just use max_rec, sspd and fifo embedded in the destination
> "MAC address" in the sending packet.
Yes and no. After a bus topology change, it takes a brief period for
firewire-core to have the new node(s) scanned and tell firewire-net about
them, so that firewire-net can add (or remove) items in the list for the
mapping between GUID on one hand and card:generation:nodeID on the other
hand.
So, right after a bus reset, we may already receive IP packets from nodes
which firewire-core didn't process yet. But I guess this short period
isn't really a problem.
By the way, I wouldn't trust max_rec and sspd from 1394-ARP or 1394-NDP
packets. These should rather be taken from firewire-core's bus analysis
as soon as this is complete. Only unicast_FIFO can alas not be obtained
by bus analysis. (IEEE 1394 addendum B:2002 made things more complicated
with regard to maximum payload and maximum transmission speed then they
were until addendum A:2000, in ways that the authors of RFC 2374 and 3146
surely could not anticipate.)
--
Stefan Richter
-=====-===-= ---= ===--
http://arcgraph.de/sr/
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
next prev parent reply other threads:[~2013-01-27 23:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 17:52 [RFC:] struct net_device_ops: Add function pointer to fill device specific ndisc information Stephan Gatzka
2013-01-20 18:47 ` YOSHIFUJI Hideaki
2013-01-20 21:23 ` Stephan Gatzka
2013-01-21 2:29 ` YOSHIFUJI Hideaki
2013-01-21 6:25 ` Stephan Gatzka
2013-01-21 7:39 ` Stefan Richter
2013-01-21 11:50 ` YOSHIFUJI Hideaki
2013-01-21 19:25 ` Stephan Gatzka
2013-01-21 19:57 ` YOSHIFUJI Hideaki
2013-01-21 21:16 ` Stephan Gatzka
2013-01-27 14:43 ` Stefan Richter
2013-01-27 17:21 ` Stephan Gatzka
2013-01-27 18:20 ` Stephan Gatzka
2013-01-27 18:25 ` YOSHIFUJI Hideaki
2013-01-27 19:28 ` YOSHIFUJI Hideaki
2013-01-27 23:26 ` Stefan Richter [this message]
2013-01-21 11:50 ` YOSHIFUJI Hideaki
2013-01-21 8:09 ` Stefan Richter
2013-01-21 12:04 ` YOSHIFUJI Hideaki
2013-01-21 13:15 ` Stefan Richter
2013-01-21 6:37 ` Stephan Gatzka
2013-01-21 12:16 ` YOSHIFUJI Hideaki
2013-01-20 21:22 ` Waskiewicz Jr, Peter P
2013-01-21 6:17 ` Stephan Gatzka
2013-01-21 8:28 ` Stefan Richter
2013-01-21 12:32 ` YOSHIFUJI Hideaki
2013-01-21 14:15 ` YOSHIFUJI Hideaki
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=20130128002633.0eac1d6c@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=davem@davemloft.net \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=netdev@vger.kernel.org \
--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.