[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130127154332.6b5730f9@stein>
Date: Sun, 27 Jan 2013 15:43:32 +0100
From: Stefan Richter <stefanr@...6.in-berlin.de>
To: stephan.gatzka@...il.com
Cc: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
netdev <netdev@...r.kernel.org>,
linux1394-devel@...ts.sourceforge.net,
David Miller <davem@...emloft.net>
Subject: Re: [RFC:] struct net_device_ops: Add function pointer to fill
device specific ndisc information
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/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists