Thread: [Madwifi-devel] DFS status
Status: Beta
Brought to you by:
otaku
From: Pavel R. <pr...@gn...> - 2008-07-17 07:10:41
|
Hello! I'd like to see the DFS branch finally merged into the trunk. The longer we wait, the more differences appear between the branches, the harder it becomes to merge the changes. I tried to reduce the differences today, but I only touched trivial differences. All non-trivial changes should be merged by those who wrote the code, or it's likely that something will be mismerged. Are there any problems with the DFS branch? It there any reason why we don't want to merge it to the trunk? Are there any parts that can be merged now? I'm concerned that the differences keep growing. There are changes on the DFS branch that should not be there, such as improvements to debug macros or changes to rate control algorithms. In one case, conflicting changes were made to the ONOE rate control algorithm. I'd like to see changes in topic branches limited to their topics. All other changes should be applied to the trunk first, so that they are done in a synchronized manner. Those changes could then be merged to the topic branches. We could create a git mirror for those who wants personal branches, but topic branches are not personal branches. As it stands now, I'm afraid we are well beyond the point where we can trust merging the remaining differences to any version control software. It has to be manual. But let's try to avoid it in the future. -- Regards, Pavel Roskin |
From: Scott R. <sco...@gm...> - 2008-07-17 11:43:39
|
Hi all, Let's get -dfs merged ASAP. As Pavel points out it's been used for non- DFS changes which makes it very hard to keep track of. My main concern with the -dfs branch is that I don't really know what it gives us. Am I right in the assumption that ad-hoc mode fixes went into -dfs? Cheers, On 17/07/2008, at 7:10 PM, Pavel Roskin wrote: > Hello! > > ... > > I'd like to see changes in topic branches limited to their topics. > All other changes should be applied to the trunk first, so that they > are done in a synchronized manner. Those changes could then be merged > to the topic branches. > Agreed. This should be a basic commit requirement. > We could create a git mirror for those who wants personal branches, > but topic branches are not personal branches. Good idea - a read-only git-svn mirror that we can git-clone off for personal local working branches would be great. Have the git-svn mirror fetch changes from svn every hour or so. I already have a similar set up locally and it works a treat. Cheers, -- Scott Raynel WAND Network Research Group Department of Computer Science University of Waikato New Zealand |
From: Benoit P. <ben...@fr...> - 2008-07-17 19:31:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Raynel a écrit : | Hi all, | | Let's get -dfs merged ASAP. As Pavel points out it's been used for non- | DFS changes which makes it very hard to keep track of. My main concern | with the -dfs branch is that I don't really know what it gives us. Am | I right in the assumption that ad-hoc mode fixes went into -dfs? | | Cheers, My fault really, mainly due to lack of time. -dfs branch is pretty much working. It can still be improved (radar detection filtering is far from being perfect) and some optimizations could be done to reduce CAC. The only bug I'm aware is that due to fact I'm mainly working on adhoc mode, ~ STA mode is broken (sympton is that association is not possible at all on DFS channels). I hope to fix it quite soon since it /*should*/ be fairly easy, but it should not prevent merging. It also includes adhoc fixes that I've been testing since I'm mainly working on Adhoc. In order to help, I ask mentor some times ago to do an initial merge that I could review. I've seen a major change in r3774, which I'm currently reviewing. Feel free to continue merging. I would be more than happy to discuss some specific points on this list since I don't want to be (with Mike Taylor), the only person knowing about DFS :-). I'm really open to any way to move forward if compatible with my time schedule. The only point I see is that I would need to double-check the end results anyway. Regards, Benoit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIf54AOR6EySwP7oIRAlEqAJ9LcuRQejLaMiw6JF7uve2OkKxC0QCgmib2 HgzTp+lXIH9AX4mfulgvcKY= =bb5F -----END PGP SIGNATURE----- |
From: Georg L. <ge...@bo...> - 2008-07-17 13:04:01
|
Hello, * Scott Raynel <sco...@gm...> [2008-07-17 13:45]: > Let's get -dfs merged ASAP. As Pavel points out it's been used for non- > DFS changes which makes it very hard to keep track of. My main concern > with the -dfs branch is that I don't really know what it gives us. Am > I right in the assumption that ad-hoc mode fixes went into -dfs? Yes, at least 3662 comes to my mind, but also other changes related to SWBA calculation. > > I'd like to see changes in topic branches limited to their topics. > > All other changes should be applied to the trunk first, so that they > > are done in a synchronized manner. Those changes could then be merged > > to the topic branches. ACK. I think the motivation behind the non-topic changes was to have a branch where things can be tested before putting them into trunk. This could be mitigated by using personal repositories and letting other people fetch from them. > > We could create a git mirror for those who wants personal branches, > > but topic branches are not personal branches. > Good idea - a read-only git-svn mirror that we can git-clone off for > personal local working branches would be great. Have the git-svn > mirror fetch changes from svn every hour or so. I already have a > similar set up locally and it works a treat. I'm also using git-svn for madwifi, and I love it. However, I do not see too much use in creating a read-only git clone of the repository, besides of providing an option to accelerate the initial checkout and encourage users/developers to get familiar with git (which is an important point). I am also not sure if it is possible to dcommit from such a cloned git into the main svn. I would like to see the main madwifi repo converted to git in a reasonable time frame, but it requires several things to be done first. If there is consensus about changing the repository, we should make a list (on the wiki or as a task in trac?) of things which have to be completed for such a heavy change: * merge -dfs back into trunk (will not be easier with git due to the already done untracked merges) * set up the read-only git clone (it probably could be auto-updated using a hook in svn) * make sure all madwifi developers with commit rights are familiar with git * deploy trac 0.11 and test if it cooperates well with git (might be tested on the read-only git clone of the current svn) * see if we can port the ticket history from trac-svn to trac-git. Other contributions to this list are welcome. Kind regards, Georg -- || http://op-co.de ++ GCS/CM d? s: a-- C+++ UL+++ !P L+++ E--- W++ ++ || gpg: 0x962FD2DE || N++ o? K- w---() O M V? PS+ PE-- Y+ PGP++ t* || || Ge0rG: euIRCnet || 5 X+ R tv b+(+++) DI+(+++) D+ G e* h! r* !y+ || ++ IRCnet OFTC OPN ||________________________________________________|| |
From: Felix F. <nb...@op...> - 2008-07-17 13:15:24
Attachments:
gsc.sh
|
Georg Lukas wrote: > I'm also using git-svn for madwifi, and I love it. However, I do not see > too much use in creating a read-only git clone of the repository, > besides of providing an option to accelerate the initial checkout and > encourage users/developers to get familiar with git (which is an > important point). > > I am also not sure if it is possible to dcommit from such a cloned git > into the main svn. I use the attached script to fetch a git clone of an svn repository and fix up the git-svn metadata, so that git-svn dcommit works. On average my checkouts with this script take about half the time of a single svn revision checkout, yet include the whole history. - Felix |
From: Chr <chu...@we...> - 2008-07-17 17:59:53
|
On Thursday 17 July 2008 15:03:50 Georg Lukas wrote: > Hello, > > * Scott Raynel <sco...@gm...> [2008-07-17 13:45]: > > Let's get -dfs merged ASAP. As Pavel points out it's been used for non- > > DFS changes which makes it very hard to keep track of. My main concern > > with the -dfs branch is that I don't really know what it gives us. Am > > I right in the assumption that ad-hoc mode fixes went into -dfs? > > Yes, at least 3662 comes to my mind, but also other changes related to > SWBA calculation. > Has anyone tried the SWBA changes on a AR5008? Because it doesn't work... no beacons at all, maybe the register-adresses are different. (BTW: replace the ath_hw_beaconinit call with ath_hal_beaconinit and the beacons are back.) Regards, Chr. |
From: Scott R. <sco...@gm...> - 2008-07-17 23:15:59
|
Hi, On 18/07/2008, at 1:03 AM, Georg Lukas wrote: > > ACK. I think the motivation behind the non-topic changes was to have a > branch where things can be tested before putting them into trunk. This > could be mitigated by using personal repositories and letting other > people fetch from them. I'd like to see this route taken - it's pretty much the whole point of decentralised version control :) > > >>> We could create a git mirror for those who wants personal branches, >>> but topic branches are not personal branches. >> Good idea - a read-only git-svn mirror that we can git-clone off for >> personal local working branches would be great. Have the git-svn >> mirror fetch changes from svn every hour or so. I already have a >> similar set up locally and it works a treat. > > I'm also using git-svn for madwifi, and I love it. However, I do not > see > too much use in creating a read-only git clone of the repository, > besides of providing an option to accelerate the initial checkout and > encourage users/developers to get familiar with git (which is an > important point). > The reason for a read-only git repository would be, as you say, to get everybody used to using git tools. It's pretty hard to go back to using straight SVN once you've got a real feel for what git can do. Making dcommit work would be nice though, and if it's possible, which it seems to be thanks to Felix's script, that would be a nice touch. Migration to a native git repo would be nice, but we'd have to agree on a workflow: 1) Completely decentralised, there is no "official" source 2) Centralised CVS-style development with personal branches maintained as local branches by developers. Developers end up pushing their results directly into the "official" tree. 3) Linux kernel style development. Option 1 doesn't really help. Option 3 introduces a huge amount of administrative overhead, but it also results in the least amount of on- going breakage in the official tree. Option 2 seems like a nice middle ground, as long as we can agree on the use of topic and personal branches. > I am also not sure if it is possible to dcommit from such a cloned git > into the main svn. > > I would like to see the main madwifi repo converted to git in a > reasonable time frame, but it requires several things to be done > first. > > If there is consensus about changing the repository, we should make a > list (on the wiki or as a task in trac?) of things which have to be > completed for such a heavy change: > > * merge -dfs back into trunk (will not be easier with git due to the > already done untracked merges) > > * set up the read-only git clone (it probably could be auto-updated > using a hook in svn) > > * make sure all madwifi developers with commit rights are familiar > with > git > > * deploy trac 0.11 and test if it cooperates well with git (might be > tested on the read-only git clone of the current svn) > > * see if we can port the ticket history from trac-svn to trac-git. > > Other contributions to this list are welcome. > A point to keep in mind: We use svn externals for ath_info which git doesn't support. Cheers, -- Scott Raynel WAND Network Research Group Department of Computer Science University of Waikato New Zealand |
From: Michael R. <mre...@ma...> - 2008-07-21 06:12:02
|
Hi. Pavel Roskin wrote: > We could create a git mirror for those who wants personal branches, I guess it would help if team members had space on our servers where they could publish their git stuff, patches and thelike? Apart from that: I have no experience with git yet. What changes would be required on the server to make it work? Anyone available for some sparring? Bye, Mike |
From: Pavel R. <pr...@gn...> - 2008-07-21 06:25:29
|
Quoting Michael Renzmann <mre...@ma...>: > Hi. > > Pavel Roskin wrote: >> We could create a git mirror for those who wants personal branches, > > I guess it would help if team members had space on our servers where they > could publish their git stuff, patches and thelike? > > Apart from that: I have no experience with git yet. What changes would be > required on the server to make it work? Anyone available for some > sparring? I'm already maintaining 2 mirrors on http://repo.or.cz/ and once of them is mirroring a subversion repository. The only problem is that I need a reliable machine to run the import process once in a while (I'm going it twice every hour). It can be behind firewall, it just needs to be powered on and connected. The mirroring process takes very little time and resources, especially if there are no changes. We could run the git repository on the madwifi server instead, and that would give it a more official status. Still, we can require that the git repository remains strictly a mirror. I don't know if anyone needs a public personal repository. Such repositories could be hosted elsewhere, including repo.or.cz. -- Regards, Pavel Roskin |
From: Michael R. <mre...@ma...> - 2008-07-21 11:10:47
|
Hi Pavel. Pavel Roskin wrote: > We could run the git repository on the madwifi server instead, and > that would give it a more official status. Still, we can require that > the git repository remains strictly a mirror. I tend to keeping everything that's related to MadWifi on madwifi.org, if possible, so that people don't need to look around at different places. Thus I'd vote for run the git repository on madwifi.org. Is there any special requirement that must be met on the server for this? Or any "nice to have" things that would make life of those working with the repository easier? > I don't know if anyone needs a public personal repository. Such > repositories could be hosted elsewhere, including repo.or.cz. Same here, just tell me what is required to allow hosting such personal repositories and I'll try to make it happen. As long as the repository is related to the madwifi.org project, at least :) Bye, Mike |
From: Pavel R. <pr...@gn...> - 2008-07-22 05:33:19
|
Quoting Michael Renzmann <mre...@ma...>: > Pavel Roskin wrote: >> We could run the git repository on the madwifi server instead, and >> that would give it a more official status. Still, we can require that >> the git repository remains strictly a mirror. > > I tend to keeping everything that's related to MadWifi on madwifi.org, if > possible, so that people don't need to look around at different places. > Thus I'd vote for run the git repository on madwifi.org. > > Is there any special requirement that must be met on the server for this? > Or any "nice to have" things that would make life of those working with > the repository easier? It would be nice to have http access to the repository. Please see this file in the git sources: Documentation/howto/setup-git-server-over-http.txt Of course, the native git protocol should be enabled too. It would be nice to have the latest released version of git, just to avoid known problems. The last version is currently 1.5.6.4 and can be downloaded from http://git.or.cz/ >> I don't know if anyone needs a public personal repository. Such >> repositories could be hosted elsewhere, including repo.or.cz. > > Same here, just tell me what is required to allow hosting such personal > repositories and I'll try to make it happen. As long as the repository is > related to the madwifi.org project, at least :) I believe ssh access with be required to run git over ssh. My biggest concern is whether we can import svn branches as git branches. We changed the repository structure in the past, so it may interfere with the import. If it doesn't work, I'm not even sure we want an official git repository, as it will either miss the branches or is will force users to download all branches. And the worst thing is that git won't be able to merge anything. We could use an intermediate svn repository that would use the current layout for historic revisions (svk may help to speed it up). We could patch git-svn to guess branch locations. We could interpret old and new paths as different branches. Or we could start the git history from the point where the layout changed, but that would lose useful history. I see that git-svn has an option --follow-parent, which could help. But I'm afraid we'll still need to patch git-svn to have the complete history. Or we'll need an svn mirror with straightened history. That's the real issue. Once we deal with it, we can set up the repository anywhere. I don't think anyone has a git mirror with the full history and correct branches. I'd like to be proven wrong. -- Regards, Pavel Roskin |
From: Lrj <ren...@gm...> - 2008-07-23 14:49:20
|
Hi David , The problem is that you do the OS_REG_WRITE too early, exactly as Steve said. This does the opposite - it causes *sent* frames not to wait for an ACK. You > may also need to set the tx count (try0) to "1". > While it's not necessary to set the try0, because that value will not work with the ACK disabled. On Wed, Jul 23, 2008 at 10:49 PM, <lr...@ss...> wrote: > Hi, > > I apologize about bringing up an old thread again but I am still having > problems disabling Layer 2 acknowledgments in ad hoc mode. Using Lrj's > instructions: > > In if_ath.c > >> First, in the ath_attach(), add the codes "OS_REG_WRITE(ah, 0x8048, >> 0x00000002);", which writes register to disable the hardware auto ACK; >> And in the ath_reset(), do the same thing. >> > > Then, in the ath_tx_start(), before the call of ath_hal_setuptxdesc(), add >> the codes "flags |= HAL_TXDESC_NOACK;", which sets the flags to stop the hw >> ACK waiting. >> Done. >> > > Note: I have used a * before the sections of code to make it easier to read > this email. The first reg write went here (starting line 452): > > * if (ah->ah_abi != HAL_ABI_VERSION) { > * printk(KERN_ERR "%s: HAL ABI mismatch; " > * "driver expects 0x%x, HAL reports 0x%x\n", > * dev->name, HAL_ABI_VERSION, ah->ah_abi); > * error = ENXIO; /* XXX */ > * goto bad; > * } > * sc->sc_ah = ah; > * OS_REG_WRITE(ah, 0x8048, 0x00000002); > * > * /* > * * Check if the MAC has multi-rate retry support. > > The second reg write (approx line 2180): > > *static int > *ath_reset(struct net_device *dev) > *{ > * struct ath_softc *sc = dev->priv; > * struct ieee80211com *ic = &sc->sc_ic; > * struct ath_hal *ah = sc->sc_ah; > * struct ieee80211_channel *c; > * HAL_STATUS status; > * OS_REG_WRITE(ah, 0x8048, 0x00000002); > * > * /* > * * Convert to a HAL channel description with the flags > > The final flags to prevent nodes waiting for an ack (approx line 7135): > > *flags |= HAL_TXDESC_NOACK; > * > * /* > * * Formulate first tx descriptor with tx controls. > * */ > * /* XXX check return value? */ > * ath_hal_setuptxdesc(ah, ds > * , pktlen /* packet length */ > * , hdrlen /* header length */ > > > If anyone who has been successful in disabling L2 ACKs could take a look at > where I may have gone wrong I would be very grateful. > > Thanks > Dave > > > > -------------------------------------- Welcome to Beijing~ ^_^ -------------------------------------- Best wishes, Lrj, NCI, China |
From: David M. <301...@st...> - 2008-07-24 18:13:30
|
Hi, I just wanted to confirm that Lrj's method to disable layer 2 ACKs works well. Many thanks to Lrj and Stevie for their help. For anyone else interested in doing this, the instructions are below Cheers Dave > In if_ath.c > > First, in the ath_attach(), add the codes "OS_REG_WRITE(ah, > 0x8048, 0x00000002);", which writes register to disable the > hardware auto ACK; > And in the ath_reset(), do the same thing. > > > Then, in the ath_tx_start(), before the call of > ath_hal_setuptxdesc(), add the codes "flags |= > HAL_TXDESC_NOACK;", which sets the flags to stop the hw ACK > waiting. > Done. > |
From: David M. <301...@st...> - 2008-07-22 10:33:01
|
Hi, I apologize about bringing up an old thread again but I am still having problems disabling Layer 2 acknowledgments in ad hoc mode. Using Lrj's instructions: In if_ath.c > First, in the ath_attach(), add the codes "OS_REG_WRITE(ah, 0x8048, > 0x00000002);", which writes register to disable the hardware auto ACK; > And in the ath_reset(), do the same thing. > Then, in the ath_tx_start(), before the call of > ath_hal_setuptxdesc(), add the codes "flags |= HAL_TXDESC_NOACK;", > which sets the flags to stop the hw ACK waiting. > Done. Note: I have used a * before the sections of code to make it easier to read this email. The first reg write went here (starting line 452): * if (ah->ah_abi != HAL_ABI_VERSION) { * printk(KERN_ERR "%s: HAL ABI mismatch; " * "driver expects 0x%x, HAL reports 0x%x\n", * dev->name, HAL_ABI_VERSION, ah->ah_abi); * error = ENXIO; /* XXX */ * goto bad; * } * sc->sc_ah = ah; * OS_REG_WRITE(ah, 0x8048, 0x00000002); * * /* * * Check if the MAC has multi-rate retry support. The second reg write (approx line 2180): *static int *ath_reset(struct net_device *dev) *{ * struct ath_softc *sc = dev->priv; * struct ieee80211com *ic = &sc->sc_ic; * struct ath_hal *ah = sc->sc_ah; * struct ieee80211_channel *c; * HAL_STATUS status; * OS_REG_WRITE(ah, 0x8048, 0x00000002); * * /* * * Convert to a HAL channel description with the flags The final flags to prevent nodes waiting for an ack (approx line 7135): *flags |= HAL_TXDESC_NOACK; * * /* * * Formulate first tx descriptor with tx controls. * */ * /* XXX check return value? */ * ath_hal_setuptxdesc(ah, ds * , pktlen /* packet length */ * , hdrlen /* header length */ If anyone who has been successful in disabling L2 ACKs could take a look at where I may have gone wrong I would be very grateful. Thanks Dave |
From: Steve G. <ste...@gm...> - 2008-07-22 11:01:25
|
Hi Dave, I've been using exactly the approach you describe and it works in ad hoc and infrastructure modes. In if_ath.c > > First, in the ath_attach(), add the codes "OS_REG_WRITE(ah, 0x8048, > > 0x00000002);", which writes register to disable the hardware auto ACK; > > And in the ath_reset(), do the same thing. > I do this and it works nicely. This disables the auto-ACK usually done by the WNIC for *received* frames. > Then, in the ath_tx_start(), before the call of > > ath_hal_setuptxdesc(), add the codes "flags |= HAL_TXDESC_NOACK;", > > which sets the flags to stop the hw ACK waiting. > > Done. > This does the opposite - it causes *sent* frames not to wait for an ACK. You may also need to set the tx count (try0) to "1". * if (ah->ah_abi != HAL_ABI_VERSION) { > * printk(KERN_ERR "%s: HAL ABI mismatch; " > * "driver expects 0x%x, HAL reports 0x%x\n", > * dev->name, HAL_ABI_VERSION, ah->ah_abi); > * error = ENXIO; /* XXX */ > * goto bad; > * } > * sc->sc_ah = ah; > * OS_REG_WRITE(ah, 0x8048, 0x00000002); > * > * /* > * * Check if the MAC has multi-rate retry support. > > The second reg write (approx line 2180): > > *static int > *ath_reset(struct net_device *dev) > *{ > * struct ath_softc *sc = dev->priv; > * struct ieee80211com *ic = &sc->sc_ic; > * struct ath_hal *ah = sc->sc_ah; > * struct ieee80211_channel *c; > * HAL_STATUS status; > * OS_REG_WRITE(ah, 0x8048, 0x00000002); > * > * /* > * * Convert to a HAL channel description with the flags > > The final flags to prevent nodes waiting for an ack (approx line 7135): > > *flags |= HAL_TXDESC_NOACK; > * > * /* > * * Formulate first tx descriptor with tx controls. > * */ > * /* XXX check return value? */ > * ath_hal_setuptxdesc(ah, ds > * , pktlen /* packet length */ > * , hdrlen /* header length */ > > > If anyone who has been successful in disabling L2 ACKs could take a > look at where I may have gone wrong I would be very grateful. > > Thanks > Dave These look pretty good but... you are doing the register write too early (i.e. before the ath_hal_reset). Move it to the end of the function or else you risk the HAL resetting the register back to the default (hw-generated ACK) value. At a guess that is what is happening in your patched version. Steve |