All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gatzka <stephan.gatzka@gmail.com>
To: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>,
	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, 21 Jan 2013 22:16:41 +0100	[thread overview]
Message-ID: <50FDB039.2070604@gmail.com> (raw)
In-Reply-To: <50FD9DB7.60802@linux-ipv6.org>


>> 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.

Regards,

Stephan

  reply	other threads:[~2013-01-21 21:16 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 [this message]
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
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=50FDB039.2070604@gmail.com \
    --to=stephan.gatzka@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --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.