Re: [PATCH 1/2] mac802154: add a software MAC 802.15.4 implementation

On Wed, 2009-08-12 at 00:23 +0400, Dmitry Eremin-Solenikov wrote:

quoted

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

quoted

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.

Yes, you still see it in the current tree, but it's gone in our -next
tree.

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.

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

Hmm. I thought that one may be able to rmmod the module w/ ops while the
device is still hanging in the system. On the other hand, ops are
provided by the driver, so if one rmmods the driver and the device is
still there, it's a bug...

Exactly. You _want_ to be able to rmmod the module and have it
unregister itself.

johannes