Thread: [zd1211-devs] Status of WPA in the driver (and reformatting CVS code)
Status: Beta
Brought to you by:
mayne
From: Mike P. <mp...@re...> - 2005-03-22 18:53:55
|
Hi all, Has anyone got WPA working using the zd1211 driver? My company is planning to make this happen at some point soon, but if anyone else has made any progress on this already we'd be interested to know, and to help out. Also, a minor gripe wrt activity on CVS. I know this project is just getting started with this driver and that the coding style isn't what it might be, but I've just trawled through 9000 lines of your latest changes to CVS looking for useful things, and very nearly all of it is code reformatting, which I could easily do without. To quote from http://dotat.at/writing/cvs-guidelines.html > Never, ever reformat code. This is a really bad thing to do because it > makes diffs hard to understand and apply. Upstream authors won't > accept patches against reformatted code. Bugfixes and patches against > the upstream code won't apply. New versions of the upstream code can't > be imported. Real changes get hidden in the mass of reformatting. > > No-one's favourite coding style is significantly better or worse than > anyone else's so reformatting code provides no advantage to oppose the > disadvantages. It's not for me to try and impose my will on the people contributing to this project so I'll just offer that as an opinion (and note that dealing with your changes to this code would be a lot easier for me if such reformatting were avoided) to see if other people have anything to add. I'm not sure if you have had any discussions about coding style on the list yet but I'm deliberately not saying anything about that because I don't think the details of it are as important an issue. Mike |
From: Mike P. <mp...@re...> - 2005-03-23 14:32:47
|
(I guess rik's reply to me was meant to go to the list as well - am quoting it in full) On Wed, Mar 23, 2005 at 04:42:48PM +0300, Roman K wrote: > To solve your CVS problem I suggest you to use diff -ub key. I already use both of those, plus the -w option which deals with some whitespace changes, but that doesn't help with changes such as the following, to pick an example at random (from zdpmfilter.c) @@ -894,12 +867,10 @@ TimMapSet(TimBitMap, aid, TRUE); return FALSE; } - } - else{ + } else { goto direct_send; } - } - else{ //group address + } else { //group address if ((orderBit(frame) == 0) && (mPsStaCnt > 0)){ if ((zd_CheckTotalQueCnt() > TXQ_THRESHOLD) || (pPsQ[0]->cnt > MCQ_THRESHOLD)){ PSDEBUG("*****Drop MC packet*****"); I managed to eliminate changes like this by running the old version and the latest version through GNU indent before doing the diff, but that is a lot of hassle, and doesn't help if I want to apply the improvements from this project to my cvs repository. > This is to fix that is already done. For the future I'd like to > propose: > 1. List to track CVS commits. > 2. Strict commit policy that will contain a rule to commit style > changes separate. Those sound like good suggestions to me (I would join such a list), though in themselves don't deal with the general problem of trying to spot changes in functionality across weeks or months of CVS activity. Mike |
From: Roman K <rom...@ma...> - 2005-03-23 16:12:59
|
> (I guess rik's reply to me was meant to go to the list as well - am > quoting it in full) Yea, I just forgot to cc. > On Wed, Mar 23, 2005 at 04:42:48PM +0300, Roman K wrote: > > To solve your CVS problem I suggest you to use diff -ub key. > > I already use both of those, plus the -w option which deals with some > whitespace changes, but that doesn't help with changes such as the > following, to pick an example at random (from zdpmfilter.c) > > @@ -894,12 +867,10 @@ > TimMapSet(TimBitMap, aid, TRUE); > return FALSE; > } > - } > - else{ > + } else { > goto direct_send; > } > - } > - else{ //group address > + } else { //group address > if ((orderBit(frame) == 0) && (mPsStaCnt > 0)){ > if ((zd_CheckTotalQueCnt() > TXQ_THRESHOLD) || (pPsQ[0]->cnt > MCQ_THRESHOLD)){ > PSDEBUG("*****Drop MC packet*****"); > > > I managed to eliminate changes like this by running the old version and > the latest version through GNU indent before doing the diff, but that is > a lot of hassle, and doesn't help if I want to apply the improvements > from this project to my cvs repository. The choice between two options to do indent before diff or do indent before reading the text. May be better choice is to style all source once. > > This is to fix that is already done. For the future I'd like to > > propose: > > 1. List to track CVS commits. > > 2. Strict commit policy that will contain a rule to commit style > > changes separate. > > Those sound like good suggestions to me (I would join such a list), > though in themselves don't deal with the general problem of trying to > spot changes in functionality across weeks or months of CVS activity. Keeping bad style wouldn't solve it anyway if we are talking about long period of time. rik > Mike > > > ------------------------------------------------------- > This SF.net email is sponsored by: 2005 Windows Mobile Application Contest > Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones > for the chance to win $25,000 and application distribution. Enter today at > http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click > _______________________________________________ > Zd1211-devs mailing list > Zd1...@li... > https://lists.sourceforge.net/lists/listinfo/zd1211-devs > |