On Mon, 11 Jun 2007 10:57:32 +0800, Zhu Yi wrote: > > Actually, now > > that I understand it, don't you think it'd be easier to understand if > > you had two write-only (!) files > > * dls/teardown > > * dls/request > > and writing a mac address to each one would trigger the operation for > > that mac address? I like this idea. It should be also used for send_addts and similar - would be better than the "write anything here to trigger the event" concept. > > That way, you have it atomically and no problem with > > two processes stomping each other (since now you write the mac address > > and then the operation). That would be much closer to the nl80211 > > interface where I'd probably just have two commands NL80211_REQUEST_DLS > > and NL80211_TEARDOWN_DLS that both take an ATTR_MAC_ADDRESS (in addition > > to the virtual interface). > > > > Same for tspec, even though I haven't seen where it's used, why not have > > a single file that accepts the whole tspec information element that > > userspace has pieced together, > > When I sent the patch the first time which used sysfs, the comment was > one value per file (Is this still true for debugfs?). So I split them > up. The drawback for all values in one file is the user has to remember > all the values and their orders. Johannes probably meant a binary blob prepared by user space. That still complies to the one value per file rule. > The DLS is easier because it only has one parameter (peer mac address) > now. I programed it the same way as tspec. So when we find to need more > parameters for DLS setup, we can add another debugfs file for the new > parameter instead of combining multiple parameters in one file. > > I'd agree I didn't pay a lot of attentions to the debugfs interface > design since I thought it was used for occasional debug only. Please > tell me what which do you prefer: one value per file or multiple values > per file so that we can do one shot parameter passing? So I don't need > to switch them back and forth. Depends on how long you want to keep this debugfs interface. If it's just a few months matter and it's never going to hit vanilla, it's probably not worth the effort to rewrite it. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
