Hi David, > The entire iw tool is really just a hack btw... doesn't look too bad to me, unlike my python tool... :) > > iw phy set [ phy ] DEVICE [ CHANSPEC ] [ name NEWNAME ] > > > > and we discussed on IRC that it might make sense to have the same for > > nl80211. On the surface, that makes sense, however, it does add a > > complication in that we need to either specify that you cannot combine > > some attributes (which doesn't really make sense), > Hmm, I can't come up with any example other than using some 11n attribute > with a 11abg phymode... care to hit me with a hint? I was thinking of the name vs. phy parameters. > if (err < 0 && modified && net_ratelimit()) > printk(KERN_WARNING "A link change request failed with " > "some changes comitted already. Interface %s may " > "have been left with an inconsistent configuration, " > "please check.\n", dev->name); > > So, if rtnetlink doesn't bother too much about "transaction safety" either, > why should we? Heh, dunno, I just like to think that one thing posted to the kernel is done atomically. We can drop that requirement and document it, but that won't be easy since we'd have to document exactly what is done atomically. > If an app wants to know what failed, it can still send SET > requests broken down into pieces, so they will know which piece failed. > Obviously they need to leave some stuff grouped (e.g. PHYMODE and CHANNEL), > but I don't think it's useful to force them do so by breaking stuff into > multiple commands... > > (There is no difference really between > CMD_SET_PHY name=myphy > CMD_SET_PHY phymode=a channel=1 > and > CMD_SET_PHYNAME name=myphy > CMD_SET_CHANNEL phymode=a channel=1 > but the former allows, if we don't care, to just batch it.) True. I guess we can leave it as-is and see if we run into problems with some software or something and if we do document it better ;) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
