Search Linux Wireless

Re: [RFC] Add new regulatory framework for Linux wireless

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Its just a random number we use as a receipt. I was thinking of
> having it to provide uniqueness on requests and to provide a cookie
> to ensure it comes from the kernel but now that I think about this
> a bit more its really unnecessary. 

> If we keep UUID we can remove the alpha2, you're right. But it seems
> we may rather keep the alpha2 and just nuke the UUID.

ok, makes sense to me, yes.

> > > +	reg_rule_policy[NL80211_REG_RULE_ATTR_MAX + 1] = {
> > > +	[NL80211_ATTR_REG_RULE_FLAGS]		= { .type = NLA_U32 },
> > 
> > I thought we agreed to use actual NLA flags for the flags, in a nested
> > attribute, instead of using bitmaps.
> 
> I forgot if we did. If we keep them as they are we can actually end
> up using them to replace the channel flags themselves with these
> though. What do you think? Also if we do use a nested attribut for
> the flags what would be the benefit?

Mostly we wouldn't need to care about any space concerns like adding a
"FLAGS2" attribute if we run out of the 32 bits we have there. I don't
feel strongly, but it seems to me that using NLA flags is more natural
in netlink and makes the separation clearer. Maybe.

> > > +/**
> > > + * regulatory_hint - hint to wireless core a regulatory domain
> > > + * @alpha2: the ISO-3166 alpha2 the driver thinks we're on
> > > + * @wiphy: the driver's very own &struct wiphy
> > > + *
> > > + * Wireles drivers can use this function to hint to the wireles core
> > 
> > type in both instances :)
> 
> Hm? I don't get it.

Sorry, made a typo myself. typ_o_, not typ_e_. you wrote "wireles".

> > > +static int is_an_alpha2(char *alpha2)
> > > +{
> > > +	if (is_alpha_upper(alpha2[0]) && is_alpha_upper(alpha2[1]))
> > > +		return 1;
> > > +	return 0;
> > 
> > Why's that so important?
> 
> Its not, but we should want to pick one or the other to use. I
> picked alpha_upper. Have some other ideas?

I'm just wondering whether we care at all. If userspace wants to call it
"de" when we requested "DE", what do we care? OTOH, since we match this
against 11d info I guess we do have to pick one or the other.

johannes

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux