On Tue, Aug 11, 2009 at 10:39:58PM +0200, Johannes Berg wrote:
quoted text
> On Wed, 2009-08-12 at 00:23 +0400, Dmitry Eremin-Solenikov wrote:
> 
> > > That return value is strange.
> > 
> > The idea is that tx function can return info about errors during
> > transmit (busy channel, no ACK, etc).
> 
> Well, TX functions don't usually wait for anything so busy channel or no
> ack wouldn't be possible to return there but more like a TX status, and
> I think people are more used to NETDEV_TX_OK etc. return values. But
> it's your choice to make, obviously. If you want to return specific
> information like that though I would recommend making an enum so you get
> at least some type checking (and things like 'return -1' are more
> obviously wrong).

Currently we do all the work from special worker threads, so it's
possible for this callback to sleep. The error isn't yet propagated to
upper layers (there is a huge TODO there), anyway.

quoted text
> 
> > > We've had no end to trouble with the master netdev, I suggest you look
> > > into the current mac80211 code and see if you can get rid of it.
> > 
> > What troubles w/ master netdev did you have had? I do still see the
> > master devices in mac80211. IIUC, it's planned to replace (from
> > management point of view) the mdev with wiphy instance, isn't it?
> 
> Mostly the userspace API was a mess, and you can't actually _do_
> anything with the master netdev. It also doesn't see all the frames,
> only outgoing. It's very strange.

We were using master netdevices for several purposes:
1) ip link add link mwpanX type wpan, so that we have out-of-box support
   for radio additions. That's really nice thing to have.

2) for SOCK_RAW implementation that can be used to send raw packets
   over-the-air/receive raw packets. I think we can use af_packet for
   this, but I'm still not sure about packet injection.

3) On the RX, we did send a clone of skb to the mdev and clones to slave
   interfaces, thus overcoming your last argument.

quoted text
> The biggest problem is that it really clutters up the userspace API
> since you can't do any netdev things with it, it's just a placeholder.
> 
> In addition to that, you can't put anything into skb->cb, then push the
> frame to the master netdev, and expect things in skb->cb to still be
> there when the frame arrives at the master netdev. Not sure you do that
> (I hope not because that would be very buggy), but eventually you'll
> probably find that you do want that, etc.

Hmm. It works for us. Could you please tell me more about the problems
with skb->cb ?

quoted text
> IMHO it's just better practise to not use it in situations like this
> where it can't be really used as a netdev.

We did use it as a netdev, however we can probably live without it.
I'll rethink this interface.

-- 
With best wishes
Dmitry

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html