Re: [Madwifi-devel] Problem: auto scan
Status: Beta
Brought to you by:
otaku
From: Mathieu L. <Mat...@so...> - 2003-10-07 05:56:15
|
On Mon, 2003-10-06 at 18:09, Sam Leffler wrote: > On Monday 06 October 2003 07:28 am, Mathieu Lacage wrote: > > On Mon, 2003-10-06 at 09:31, Mathieu Lacage wrote: > > > Do you want to take the BSD code and port it again to the linux driver ? > > > > I assume this is what you want to do. I have started reading this code > > and while I can imagine many ways to port the code, I would like to know > > what your ultimate goal is: do you want to really make the BSD code > > shared out-of-the-box between the linux and BSD versions of the driver ? > > Or do you want to simply minimize the porting effort once in a while of > > the BSD code to the linux codebase ? > > > > At present I diff the madwifi driver against the bsd version to find changes > that should be backported. This despite not having any kind of portability > layer of shims. I want to be able do the same for the wlan code but because > the code has changed so much it's simply not feasible. Hrm, I am not sure I understand: do you mean there are some changes to the madwifi wlan code you would like to apply to the BSD tree ? The way I am planning to do it is to take the BSD code and port it by looking at the Linux wlan code to figure out how to do it. > > > I personally would feel a bit uneasy with the latter so, the question > > becomes, what amount of patches can be integrated in the BSD version ? > > I maintain the BSD code and can introduce portability shims where it makes > sense. I have some uncommitted ones to hide things like locking operations > to improve portability between FreeBSD and NetBSD; these would also help with > Linux portability. But otherwise I am not a great fan of portability layers > that hide too many details of the underlying implementation; they often turn yes, but here, the use-case is pretty clearly defined and limited which should make it difficult for us to use an A-bomb to blast a tiny bug. > code into swiss cheese and make it difficult to maintain. > > > Should I try to: > > > > - make as little modifications to the BSD version: this means either > > patching heavily the code coming from BSD or using as many magic linux > > macros to re-create some sort of BSD environment (the latter might be > > impossible: _some_ things will require patching the code coming from > > BSD. For example, the LIST_HEAD macro _must_ not be used as-is since its > > definition in the Linux headers and in the BSD headers is different). > > > > Yeah, the queue.h thing is annoying. We've hacked around the issue for the > moment by resolving the one important name conflict manually. At one point I > promised David Miller I'd convert the code wholesale to the Linux conventions > but decided it wasn't worth doing before moving to this new code base. Once > that's done we can consider switching over entirely. I see. > Atomic ops and locking calls are pretty easy to shim w/o obscuring too much > code. FreeBSD uses upper case macros by convention for locking operations > and I have these changes in my private branch. I'm not sure whether it's > worth wacking the atomic ops in a similar way. In that specific case, the refcount object is a u_int on BSD and an atomic_t on Linux which means we _have_ at least to introduce either a typedef or a macro to declare the structure member (or patch the Linux version, just like for the LIST_HEAD macro). The Linux code could then be hidden by magic macros hiding the functions atomic_{dec|inc} but this feels really evil to me. This scheme would make it mandatory to use the evil non-atomic dec/read operation on Linux while we have the atomic atomic_dec_and_read function (see the XXX in ieee80211_free_node). I'd rather make the interface explicit in that case. > > In general I am not looking to have zero code differences because Linux is so > different from BSD systems and trying to mask these differences can introduce > subtle bugs. Instead I'd like to see the code ported over, fully modified, > then we can try to reduce diffs through careful addition of portability > shims. I can't do this work myself right now but am willing to help you and > anyone else that's willing to give it a go by explaining things and/or > providing code out of my p4 repository to look at (not sure that any of it is > worth taking just yet--othewise I'd have committed it to the master FreeBSD I think I have enough code to look over for now :) regards, Mathieu -- Mathieu Lacage <mat...@so...> |