RFC: madwifi-ng patch rationalisation and version update

RFC: madwifi-ng patch rationalisation and version update

[Rod Whitby]

There are currently some slugos-specific patches in madwifi-ng
(specifically to enable the Atheros wifi cards in devices like the
DSM-G600 and the Iomega NAS100d.

There are also some previous arm xscale patches which are almost identical.

>   -rw-r--r-- 1 rwhitby rwhitby  619 2007-01-26 04:12 10-xscale-be-elf-copts.patch
>   -rw-r--r-- 1 rwhitby rwhitby  553 2007-01-26 04:12 10-xscale-le-elf-copts.patch
>   -rw-r--r-- 1 rwhitby rwhitby  677 2007-01-06 14:32 slugos-VFP-wackelf.patch
>   -rw-r--r-- 1 rwhitby rwhitby  433 2007-01-06 14:32 slugos-xscale-be-elf-copts.patch
>   -rw-r--r-- 1 rwhitby rwhitby  367 2007-01-06 14:32 slugos-xscale-le-elf-copts.patch

We intend updating the 10-xscale patches with the contents of the
corresponding slugos-xscale patches, and unconditionally applying the
slugos-VFP-wackelf patch (after renaming it appropriately).

We also intend updating madwifi-ng to a later snapshot (e.g.
r2100-20070210), cause the current version won't build against 2.6.20
due to changes in the INIT_WORK kernel macro.

The difference between the 10-xscale patches and the slugos-xscale
patches is the removal of the "-msoft-float -mfp=2" compiler options.
This is required to match the binary HAL objects which come from madwifi.

The "wackelf" patch then edits the ELF headers on the proprietary HAL
stuff to match the floating point used in the kernel -- it can do that
because there's no actual FP performed.  It just needs to match to make
the linker happy.

If there are no objections in the next 24 hours, we will do this in the
next 48 hours.

If there are other people using the madwifi package, please contact me
so we can get this change tested by you before applying it.  Note that
we're referring to madwifi-ng (which I couldn't find any other reference
to in OE other than slugos and openprotium), not madwifi-modules (which
is used directly by a number of distros).

-- Rod

Re: RFC: madwifi-ng patch rationalisation and version update

[Jamie Lenehan]

On Tue, Feb 13, 2007 at 04:44:36PM +1030, Rod Whitby wrote:
[...]
> We also intend updating madwifi-ng to a later snapshot (e.g.
> r2100-20070210), cause the current version won't build against 2.6.20
> due to changes in the INIT_WORK kernel macro.

I've been waiting for them to fix this for a while now so I can move
forward to newer kernels - so I definitely want the newer verison.

I think it'd would be a good idea to remove all the older versions as
well, apart from perhaps r1844 which corrosponds to the last actual
madwifi release (0.9.2.1). This should help get us back to one set of
patches as well since in version r1844 they changed the file that arm
is patching, requiring different patches for r1844 and newer.

Actually looking at it now it appears as if someone patched the
version in the files directory for a newer version so the older
versions (prior to r1844) won't build anymore anyway (patching will
fail). So the older versions of madwifi-ng and all the version
specific subdirs can all go as well.

[...]
> If there are other people using the madwifi package, please contact me
> so we can get this change tested by you before applying it.  Note that

I only use it on wrap (i486) and titan (sh4). They won't be effected
by your changes (and I'll test and fix up any issues for these
targers anyway.) I currently use r1844 but will move to a later
version as soon as there's one that works with 2.6.20.

> we're referring to madwifi-ng (which I couldn't find any other reference
> to in OE other than slugos and openprotium), not madwifi-modules (which
> is used directly by a number of distros).

Is anyone actually using madwifi-modules? It looks like a really old
version and looks to be hacked to only work on mips targets.

-- 
 Jamie Lenehan <lenehan@twibble.org>

Re: RFC: madwifi-ng patch rationalisation and version update

[Rod Whitby]

Jamie Lenehan wrote:
> On Tue, Feb 13, 2007 at 04:44:36PM +1030, Rod Whitby wrote:
> [...]
>> We also intend updating madwifi-ng to a later snapshot (e.g.
>> r2100-20070210), cause the current version won't build against 2.6.20
>> due to changes in the INIT_WORK kernel macro.
> 
> I've been waiting for them to fix this for a while now so I can move
> forward to newer kernels - so I definitely want the newer verison.
> 
> I think it'd would be a good idea to remove all the older versions as
> well, apart from perhaps r1844 which corrosponds to the last actual
> madwifi release (0.9.2.1). This should help get us back to one set of
> patches as well since in version r1844 they changed the file that arm
> is patching, requiring different patches for r1844 and newer.
> 
> Actually looking at it now it appears as if someone patched the
> version in the files directory for a newer version so the older
> versions (prior to r1844) won't build anymore anyway (patching will
> fail). So the older versions of madwifi-ng and all the version
> specific subdirs can all go as well.

OK, I'll do this too.

So the only madwifi-ng versions remaining will be
madwifi-ng_r1844-20061208.bb and madwifi-ng_r2100-20070210.bb and they
will use common patches from the files directory.

I'll let someone else deal with madwifi-modules ...

-- Rod

Re: RFC: madwifi-ng patch rationalisation and version update

[Andrew Paulsen]

On 2/13/07, Rod Whitby <rod@whitby.id.au> wrote:
> Jamie Lenehan wrote:
> > On Tue, Feb 13, 2007 at 04:44:36PM +1030, Rod Whitby wrote:
> > [...]
> >> We also intend updating madwifi-ng to a later snapshot (e.g.
> >> r2100-20070210), cause the current version won't build against 2.6.20
> >> due to changes in the INIT_WORK kernel macro.
> >
> > I've been waiting for them to fix this for a while now so I can move
> > forward to newer kernels - so I definitely want the newer verison.
> >
> > I think it'd would be a good idea to remove all the older versions as
> > well, apart from perhaps r1844 which corrosponds to the last actual
> > madwifi release (0.9.2.1). This should help get us back to one set of
> > patches as well since in version r1844 they changed the file that arm
> > is patching, requiring different patches for r1844 and newer.
> >
> > Actually looking at it now it appears as if someone patched the
> > version in the files directory for a newer version so the older
> > versions (prior to r1844) won't build anymore anyway (patching will
> > fail). So the older versions of madwifi-ng and all the version
> > specific subdirs can all go as well.
>
> OK, I'll do this too.
>
> So the only madwifi-ng versions remaining will be
> madwifi-ng_r1844-20061208.bb and madwifi-ng_r2100-20070210.bb and they
> will use common patches from the files directory.
>
> I'll let someone else deal with madwifi-modules ...
>
> -- Rod

This cleanup appears to have been repealed.  Is there a reason for the change?

Re: RFC: madwifi-ng patch rationalisation and version update

[Stelios Koroneos]

The problem originally was created as i used an older version of
madwifi-ng_r.inc to make the updates.
We managed to resolve it thanks to the help of rwhitby.

One the the things that came out of this,was that several packages contain
arch specific definitions and patches that get applied by default, whether
the package gets build for that specific architecture/machine or not.
In many circumstances this is not noticable, in others (like this) is.
Since support for more architectures/machines is happing we need to have a
more close look on this or we will end up with a lot unhappy situations.

Stelios

Add soft-float support for powerpc targets without fpu

[Stelios Koroneos]

I have posted 2 patches on the bugtracker that provide soft-float support
for powerpc targets
http://bugs.openembedded.org/show_bug.cgi?id=1918

I have been testing the patches for a couple of weeks now, both on powerpc
targets and others (x86 variants mainly) without problems,but as these can
be
considered "system wide changes" (although the patches will be only applied
to
powerpc targets) i decided to post them to the bug tracker first for peer
review.

Please do test if they effect your distro/build in any way and post any
comments findings on the bugtracker.
If there are no major problems i plan to push them into OE during the next
"bug hunting weekend"

Stelios