Updates in svn

[Kel Modderman]

Loïc Minier wrote:
>         Hi,
>
> On Fri, Apr 14, 2006, Kel Modderman wrote:
>   
>> Pretty cool huh? :-)
>>     
>
>  Indeed, I was lurking at the features for a while, and I already have a
>  couple of projects in mind to take advantage of the new features with
>  embedded hardware.  O:-)
>   

If you don't mind me asking, what kind of embedded stuff interests you?

>   
>> That was provided for convenience of the end user: to compile their own 
>> hostapd/wpa_supplicant binaries against exactly that madwifi source version.
>> If you do not like it, say so, and it will disappear.
>>     
>
>  That might an useful thing for some persons, but I'm not sure it
>  belongs as a Debian package in the archive.  I wouldn't object to it,
>  but -dev package are primarily present to satisfy build-dependencies.
>  IMO, people wanting to build everything themselves can also rebuild
>  madwifi from source to get the headers, but YMMV.
>   

madwifi-dev can safely disappear in the new madwifi, as wext compliance 
is there, and the need for these private ioctl's only exists for hostapd 
and users of older kernels. We can provide some hints about using the 
source tarball to achieve the same result as the -dev package.

>
>   
>> Until the madwifi code is considered complete by ourselves and the 
>> madwifi developers, I'd suggest that it should only be available in the 
>> experimental repo, and the madwifi-ng name should remain intact until 
>> then so that the user must make the conscious decision to install and 
>> use them.
>>     
>
>  Ok, the approach is fine.
>
> [...]
>   
>> I don't really want to introduce the new code until after etch, and I 
>> can't see the outstanding issues in madwifi-ng being fixed completely by 
>> then anyway.
>> Is this reasonable enough?
>>     


I should mention, there may be a time (that could come sooner than I 
think/expected) when madwifi-ng becomes a better choice than madwifi-old 
purely because a critical bug appears in the old code due to lack of 
upstream maintenance. This lack of maintenance is already evident when 
using gcc-4.1, and I've started to hear some strange stories about its 
usage on more recent linux kernels.


Anyway, I'll bring this up in conversation with Michael Renzzman soon, 
there are already other developers who believe that madwifi-ng is stable 
"enough" and should make a first release already.

Thanks, Kel.