From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: stephan.gatzka@gmail.com
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
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: Sun, 27 Jan 2013 15:43:32 +0100 [thread overview]
Message-ID: <20130127154332.6b5730f9@stein> (raw)
In-Reply-To: <50FDB039.2070604@gmail.com>
On Jan 21 Stephan Gatzka wrote:
>
> >> Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
> >>
> >> This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
> >
> > I do not understand what "that" and "this" mean here.
> > Do you want to have different FIFO on single net_device? If yes, for what?
> >
>
> Oh, I'm sorry for being mixed-up. I meant that your proposal for
> enhancing the hardware address seems to be a feasible solution, if we
> _never_ want to have distinct fifo addresses for IPv4 and IPv6. This
> will be just impossible with a single netdevice.
>
> But I have to admit that I have no good use case for different fifo
> addresses...
>
> So overall, your proposal seems to be a possible solution. Nevertheless,
> I can't help that I find it a bit awkward to have speed, max_rec and
> fifo address in the hardware address of the network device. For me,
> that's just the GUID.
>
> I want to have an ack from Stefan Richter before I'm going to implement
> your solution.
Sorry for my delayed response.
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>.
--
Stefan Richter
-=====-===-= ---= ==-==
http://arcgraph.de/sr/
next prev parent reply other threads:[~2013-01-27 14:43 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 [this message]
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
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=20130127154332.6b5730f9@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=davem@davemloft.net \
--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.