Multiple definitions. Code issue
ahuguet at cttc.es
Mon Apr 23 03:18:40 PDT 2007
>> I don't understand what you mean here, and it's something I'd like to.
>> modifications I'm trying to do are for lab testing purposes, but,
>> I don't see why declaring a global variable would make it card
> Because the global variable would be shared by all instances of the
> driver (i.e., one per wlan card).
Yes, I understood that, and tried to post a reply to my own message, where
I stated my conclusions. That it was meant to refer to more than one card
used in the same computer. Unfortunately I'm not used to mailing list,
more to forums where you can edit your own posts, and it seems I even made
a new thread with my reply, rather than keep with the started one.
My confusion, this time, had its origin in a language misunderstanding, as
I took as meaning "vendor" or even the specific card that I had plugged at
that very moment.
> Are you sure you need a _global_ sk_buff structure? I would assume you
> need per-interface data, not global..
No, it wouldn't be necessary for it to be global. I would simply need that
each interface (typically wlan0) has one sk_buff where it keeps the last
received socket buffer that is of type data.
>> So maybe it would be better if I had declared a struct sk_buff
>> on the header, rather than the pointer, and then at the code,
>> do the struct sk_buff *pointer_to_skb=skb_copy(skb,GFP_KERNEL);
>> and then:
>> Would this be correct?
> I'm not sure what you are trying to do with this, but this looks very
> odd. There is not much point doing something like this and you would
> like end up in major problems with functions that try to free the skbs.
It doesn't add any functionality for the normal use of the driver, that's
for sure. Currently, there is no point in keeping a copy of the last
But, I'm trying to introduce some modifications to the driver, to do
certain tests on a lab.
So far, I've not imagined any other way of keeping a copy of the received
data frame through the driver code. It seems to me that having that copy,
with skb_copy will keep a copy of the skb.
As for the problems with functions trying to free the skb, while not an
expert, I'll try to describe what I intend to do:
The original skb, will remain unaffected, and make its way through the
driver receiver code.
As for the skb copy (last_data_rx) this would be overwritten everytime
(with the memcopy) a new data arrives so I hope that no issues would
I've tried to search for documentation regarding the code, especially the
part of interfaces, to know what has to be put and where, at each moment,
as I think it's what is causing me some issues. My search has not provided
the desired results, and the search functionality for the mailing list
seems to be still broken.
I'll probably make a new thread, where I paste there some code, together
with an explanation of what I'm trying to do, so things are more clear.
>> If I added that sk_buff structure to the local_info one, as you suggest
>> order to avoid declaration of global variables, would that structure
>> remain unchanged, from one void hostap_80211_rx execution until the
>> and so on, until I decided to explicitly modify its value?
> Yes and since local_info_t is already used in hostap_80211_rx(), this
> would be very easy thing to do and should resolve all the issues with
> use of global variables.
I'll surely try putting the sk_buff inside the local_info_t structure, now
that I know that there is the proper way to have it. It suits the needs.
And, to properly use it, is why I need to understand properly what each
thing is pointing at.
For example, in hostap_80211_rx
it has a parameter, net_device *dev.
Then we've, code:
struct hostap_interface *iface;
iface = netdev_priv(dev);
local = iface->local;
/* dev is the master radio device; change this to be the default
* virtual interface (this may be changed to WDS device below) */
dev = local->ddev;
iface = netdev_priv(dev);
More information about the Hostap