Re: 2.6 must-fix list, v3

Re: 2.6 must-fix list, v3

[Jean Tourrilhes]

Andrew Morton wrote :
> 
> Quite a lot of changes here.  Mostly additions, but some things have been
> crossed off.
> 
> Also at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix

	I don't like making todo list for other people, because it's
up to them to decide, but here is my wishlist for 2.6.X in term of
Wireless stuff.
	I hope those concerned will react and send you their real todo
list.

	o get latest orinoco changes from David. Linus seems timely in
picking David's changes, so I'm not worried about this one.

	o get the latest airo.c fixes from CVS. This will hopefully
fix problems people have reported on the LKML.

	o get HostAP driver in the kernel. No consolidation of the
802.11 management across driver can happen until this one is in (which
is probably 2.7.X material). I think Jouni is mostly ready but didn't
find time for it.

	o get more wireless drivers into the kernel. The most
"integrable" drivers at this point seem the NWN driver, Pavel's
Spectrum driver and the Atmel driver.

	o The last two drivers mentioned above are held up by firmware
issues (see flamewar on LKML a few days ago). So maybe fixing those
firmware issues should be a requirement for 2.6.X, because we can
expect more wireless devices to need firmware upload at startup coming
to market.
	As this firmware business seems to me not a wireless specific
issue (see for example drivers/scsi/qlogicfc_asm.c or
drivers/atm/atmsar11.data), I would prefer a generic solution to that
problem, either saying it's OK to put firmware in the kernel (with
proper licensing) or providing working technical solutions.
	My personal position is that I don't want to hold wireless
drivers in higher standard than other drivers in the kernel, and I
don't want to leave those drivers in the black hole where they
currently are.

	Have fun...

	Jean

airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jeff Garzik]

Jean Tourrilhes wrote:
> 	o get the latest airo.c fixes from CVS. This will hopefully
> fix problems people have reported on the LKML.

please beg Javier to split up his patch.  He sends me a _huge_ patch 
with tons of changes each time.  If I object to one thing, we spin in 
another huge-patch loop... :/

Sending me 20, 50, 100 patches to the same file is ok.  Even encouraged.


> 	o get HostAP driver in the kernel. No consolidation of the
> 802.11 management across driver can happen until this one is in (which
> is probably 2.7.X material). I think Jouni is mostly ready but didn't
> find time for it.

yeah, there are many requests for this one


> 	o The last two drivers mentioned above are held up by firmware
> issues (see flamewar on LKML a few days ago). So maybe fixing those
> firmware issues should be a requirement for 2.6.X, because we can
> expect more wireless devices to need firmware upload at startup coming
> to market.

> 	As this firmware business seems to me not a wireless specific
> issue (see for example drivers/scsi/qlogicfc_asm.c or
> drivers/atm/atmsar11.data), I would prefer a generic solution to that
> problem, either saying it's OK to put firmware in the kernel (with
> proper licensing) or providing working technical solutions.


We need firmware upload, and, firmware _should_ be uploaded from userspace.

All someone needs to do is actually write the code for their driver to 
receive firmware from userspace, and the rest is easy.  A working 
technical solution is obvious, it just needs interested parties to 
implement.

We can upload firmware from initrd, if no boot device is available at 
the time.

	Jeff

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Wed, May 14, 2003 at 06:06:36PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >	o get the latest airo.c fixes from CVS. This will hopefully
> >fix problems people have reported on the LKML.
> 
> please beg Javier to split up his patch.  He sends me a _huge_ patch 
> with tons of changes each time.  If I object to one thing, we spin in 
> another huge-patch loop... :/
> 
> Sending me 20, 50, 100 patches to the same file is ok.  Even encouraged.

	Javier is cc'ed.
	While we are on the subject : a few months ago, Javier added
support for MIC to the airo driver. It's basically crypto based on
AES. You refused to include that part in the kernel because crypto was
not accepted in the kernel.
	Fast forward : today we have crypto in the 2.5.X kernel. Does
this mean that you would have no objection accepting a patch from
Javier including the crypto part ?

> >	o get HostAP driver in the kernel. No consolidation of the
> >802.11 management across driver can happen until this one is in (which
> >is probably 2.7.X material). I think Jouni is mostly ready but didn't
> >find time for it.
> 
> yeah, there are many requests for this one

	By the way, the HostAP driver include crypto (currently only
RC4 for WEP). Same question, I hope you would not refuse the crypto
part of HostAP (which is mandatory because most PrismII firmwares are
broken and can't do basic WEP properly).

> >	o The last two drivers mentioned above are held up by firmware
> >issues (see flamewar on LKML a few days ago). So maybe fixing those
> >firmware issues should be a requirement for 2.6.X, because we can
> >expect more wireless devices to need firmware upload at startup coming
> >to market.
> 
> >	As this firmware business seems to me not a wireless specific
> >issue (see for example drivers/scsi/qlogicfc_asm.c or
> >drivers/atm/atmsar11.data), I would prefer a generic solution to that
> >problem, either saying it's OK to put firmware in the kernel (with
> >proper licensing) or providing working technical solutions.
> 
> 
> We need firmware upload, and, firmware _should_ be uploaded from userspace.

	Ok, so I ask it this way : currently the kernel include some
drivers containing some binary firmwares blobs which are linked
directly into the kernel/module (including networking). Does this mean
that you are going to remove those driver from the kernel ASAP ? Or
does this mean that the rule above only apply to wireless drivers ?
	Let's be logical and coherent here...

> All someone needs to do is actually write the code for their driver to 
> receive firmware from userspace, and the rest is easy.  A working 
> technical solution is obvious, it just needs interested parties to 
> implement.
> 
> We can upload firmware from initrd, if no boot device is available at 
> the time.

	Currently, it looks like every driver will use its own method,
which I guess is ok.

> 	Jeff

	Thanks !

	Jean

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Andrew Morton]

Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
>
> firmwares blobs 

well for the purposes of tracking 2.6 activities I'll separate this issue
of firmware access policy out from drivers/net/wireless/. 

yeah, it would be nice if the core kernel provided a "give me my firmware"
API or something.

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Dave Jones]

On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:

 > 	While we are on the subject : a few months ago, Javier added
 > support for MIC to the airo driver. It's basically crypto based on
 > AES. You refused to include that part in the kernel because crypto was
 > not accepted in the kernel.
 > 	Fast forward : today we have crypto in the 2.5.X kernel. Does
 > this mean that you would have no objection accepting a patch from
 > Javier including the crypto part ?

Sounds like it would be better to get it using the in-kernel crypto
stuff rather than reimplementing its own routines. Same for the HostAP
driver.
 
		Dave

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jeff Garzik]

Dave Jones wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> 
>  > 	While we are on the subject : a few months ago, Javier added
>  > support for MIC to the airo driver. It's basically crypto based on
>  > AES. You refused to include that part in the kernel because crypto was
>  > not accepted in the kernel.
>  > 	Fast forward : today we have crypto in the 2.5.X kernel. Does
>  > this mean that you would have no objection accepting a patch from
>  > Javier including the crypto part ?
> 
> Sounds like it would be better to get it using the in-kernel crypto
> stuff rather than reimplementing its own routines. Same for the HostAP
> driver.


Correct.

_I_ didn't refuse the crypto, Linus did.  But that was a positive step, 
that kicked off inclusion of crypto into the kernel.

airo and HostAP do indeed need to use CryptoAPI not reimplement their 
own crypto, though...

	Jeff

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Thu, May 15, 2003 at 12:43:59AM +0100, Dave Jones wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> 
>  > 	While we are on the subject : a few months ago, Javier added
>  > support for MIC to the airo driver. It's basically crypto based on
>  > AES. You refused to include that part in the kernel because crypto was
>  > not accepted in the kernel.
>  > 	Fast forward : today we have crypto in the 2.5.X kernel. Does
>  > this mean that you would have no objection accepting a patch from
>  > Javier including the crypto part ?
> 
> Sounds like it would be better to get it using the in-kernel crypto
> stuff rather than reimplementing its own routines. Same for the HostAP
> driver.
>  
> 		Dave

	For HostAP, the kernel crypto doesn't include any RC4 support,
so it can't use kernel crypto as it is.
	For airo, crypto was added before kernel crypto was available
in the kernel, and I don't know how easy it will be to refactor the
code.
	I just wanted to know the position of Jeff on this issue. I'll
let the technical decision to the respective authors.

	Thanks...

	Jean

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jouni Malinen]

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:

> airo and HostAP do indeed need to use CryptoAPI not reimplement their 
> own crypto, though...

Host AP driver has a dynamic crypto implementation that allows one to
load new algorithms as a separate kernel modules. One of such modules
was an interface to use CryptoAPI. However, I don't think there is a
public release of it.

Do you think WEP should be implemented as a CryptoAPI algorithm? It is a
combination of CRC-32 and RC4 and the crypto module in Host AP does
these together in one pass of the packet payload to minimize host CPU
load. I'm not keen on using RC4 separately with CryptoAPI (I don't think
it is even included yet) if that means making the WEP encryption use
more CPU.. However, I could consider taking CryptoAPI into use it would
support WEP as an algorithm (i.e., I could consider porting the current
Host AP WEP code to CryptoAPI).

Since I'm not that interested in maintaining multiple source trees of
the driver, own WEP implementation is going to remain in the Host AP
driver for 2.2 and 2.4 kernels. Anyway, this could probably be
automatically stripped from the code if backward compatibility in
drivers must be removed from 2.5/2.6 kernel tree.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:
> Dave Jones wrote:
> >On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> >
> > > 	While we are on the subject : a few months ago, Javier added
> > > support for MIC to the airo driver. It's basically crypto based on
> > > AES. You refused to include that part in the kernel because crypto was
> > > not accepted in the kernel.
> > > 	Fast forward : today we have crypto in the 2.5.X kernel. Does
> > > this mean that you would have no objection accepting a patch from
> > > Javier including the crypto part ?
> >
> >Sounds like it would be better to get it using the in-kernel crypto
> >stuff rather than reimplementing its own routines. Same for the HostAP
> >driver.
> 
> 
> Correct.
> 
> _I_ didn't refuse the crypto, Linus did.  But that was a positive step, 
> that kicked off inclusion of crypto into the kernel.
> 
> airo and HostAP do indeed need to use CryptoAPI not reimplement their 
> own crypto, though...
> 
> 	Jeff

	Ok, this point is clarified as well. I'll communicate
downstream.
	Thanks.

	Jean

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[David Gibson]

On Wed, May 14, 2003 at 04:38:26PM -0700, Andrew Morton wrote:
> Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
> >
> > firmwares blobs 
> 
> well for the purposes of tracking 2.6 activities I'll separate this issue
> of firmware access policy out from drivers/net/wireless/. 
> 
> yeah, it would be nice if the core kernel provided a "give me my firmware"
> API or something.

Well, Manuel Estrada (also author of the orinoco USB patches) has
proposed one on lkml.  Doesn't look like people were happy with that
version, but I think he's still working on revising it based on
feedback.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Wed, May 14, 2003 at 05:59:04PM -0700, Jouni Malinen wrote:
> On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:
> 
> > airo and HostAP do indeed need to use CryptoAPI not reimplement their 
> > own crypto, though...
> 
> Host AP driver has a dynamic crypto implementation that allows one to
> load new algorithms as a separate kernel modules. One of such modules
> was an interface to use CryptoAPI. However, I don't think there is a
> public release of it.
> 
> Do you think WEP should be implemented as a CryptoAPI algorithm? It is a
> combination of CRC-32 and RC4 and the crypto module in Host AP does
> these together in one pass of the packet payload to minimize host CPU
> load. I'm not keen on using RC4 separately with CryptoAPI (I don't think
> it is even included yet) if that means making the WEP encryption use
> more CPU.. However, I could consider taking CryptoAPI into use it would
> support WEP as an algorithm (i.e., I could consider porting the current
> Host AP WEP code to CryptoAPI).

	There is no RC4 currently in the crypto API (guess why), and I
believe that most wireless driver would be interested in the RC4+CRC,
so I would advocate for doing "WEP".

> Since I'm not that interested in maintaining multiple source trees of
> the driver, own WEP implementation is going to remain in the Host AP
> driver for 2.2 and 2.4 kernels. Anyway, this could probably be
> automatically stripped from the code if backward compatibility in
> drivers must be removed from 2.5/2.6 kernel tree.

	If you define the WEP in the kernel crypto, it could even be
the exact same file.

> Jouni Malinen

	Thanks...

	Jean

Re: CryptoAPI and WEP/stream ciphers (was: airo and firmware upload)

[Jouni Malinen]

On Wed, May 14, 2003 at 07:53:31PM -0400, Jeff Garzik wrote:

> airo and HostAP do indeed need to use CryptoAPI not reimplement their 
> own crypto, though...

I tried to change my WEP implementation to use CryptoAPI, but that ended
up in problems.. If I understood correctly, current CryptoAPI supports
only block ciphers(?). However, WEP uses RC4 as a stream cipher. This
does not seem to fit the cipher definition in CryptoAPI. One might be
able to implement it as an compression algorithm (encrypt as decompress,
since it adds IV and ICV; and decrypt as compress). However, this
certainly does not sound very reasonable.. Another alternative would be
to add support for stream ciphers into CryptoAPI.

Do you think that it would still be required to get rid of the own WEP
implementation in the Host AP driver before including it into the kernel
tree? Would this mean that someone would first need to add support for
stream ciphers into CryptoAPI? Any change of that happening for Linux
2.6.x?

And one more question before using more time with WEP implementation..
Is someone already working with stream cipher support for CryptoAPI?

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: CryptoAPI and WEP/stream ciphers (was: airo and firmware upload)

[James Morris]

On Wed, 14 May 2003, Jouni Malinen wrote:

> I tried to change my WEP implementation to use CryptoAPI, but that ended
> up in problems.. If I understood correctly, current CryptoAPI supports
> only block ciphers(?).

Block ciphers and digests.

> certainly does not sound very reasonable.. Another alternative would be
> to add support for stream ciphers into CryptoAPI.

Yes, it would be good to have API support for stream encryption in 
general, e.g. also for OFB and Counter Mode.

> Do you think that it would still be required to get rid of the own WEP
> implementation in the Host AP driver before including it into the kernel
> tree? Would this mean that someone would first need to add support for
> stream ciphers into CryptoAPI? Any change of that happening for Linux
> 2.6.x?

I'd like to see it go in if the code is available.

> And one more question before using more time with WEP implementation..
> Is someone already working with stream cipher support for CryptoAPI?

Not that I know of.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[James Morris]

On Wed, 14 May 2003, Jean Tourrilhes wrote:

> 	There is no RC4 currently in the crypto API (guess why), and I

If you mean because of IP issues, that's not the reason.  As far as I 
know, we can use 'arcfour', which is compatible.

Arcfour is also needed potentially for MPPE support (check for recent 
thread).

- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Greg KH]

On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> 	Ok, so I ask it this way : currently the kernel include some
> drivers containing some binary firmwares blobs which are linked
> directly into the kernel/module (including networking). Does this mean
> that you are going to remove those driver from the kernel ASAP ? Or
> does this mean that the rule above only apply to wireless drivers ?
> 	Let's be logical and coherent here...

I've stated this for _years_ now, I'm very glad to take patches to move
the firmware blobs out of the usb drivers that currently have them, and
move it to userspace, if people send me those patches.  For all the
whining on debian-legal about them over the _years_, no one has sent me
such a patch.

Ok, yes, I did get the start of some patches in the early 2.4 series, I
said I would accept them in 2.5 as it was too radical of a change to
take during a stable kernel series (the developer agreed with me.)  They
were never resubmitted to me during the entire 2.5 development time.

thanks,

greg k-h

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Thu, May 15, 2003 at 12:13:18AM -0700, Greg KH wrote:
> On Wed, May 14, 2003 at 04:32:35PM -0700, Jean Tourrilhes wrote:
> > 	Ok, so I ask it this way : currently the kernel include some
> > drivers containing some binary firmwares blobs which are linked
> > directly into the kernel/module (including networking). Does this mean
> > that you are going to remove those driver from the kernel ASAP ? Or
> > does this mean that the rule above only apply to wireless drivers ?
> > 	Let's be logical and coherent here...
> 
> I've stated this for _years_ now, I'm very glad to take patches to move
> the firmware blobs out of the usb drivers that currently have them, and
> move it to userspace, if people send me those patches.  For all the
> whining on debian-legal about them over the _years_, no one has sent me
> such a patch.
> 
> Ok, yes, I did get the start of some patches in the early 2.4 series, I
> said I would accept them in 2.5 as it was too radical of a change to
> take during a stable kernel series (the developer agreed with me.)  They
> were never resubmitted to me during the entire 2.5 development time.
> 
> thanks,
> 
> greg k-h

	At this point, we must get something ASAP in the kernel,
otherwise the various drivers waiting for it will just implement their
own proprietary solutions and be done with it. And it doesn't need to
be perfect at this stage, as long as it can evolve in the right
direction.
	Manuel Estrada sent me a proposal for that. As it seems it's
the only one we have on the table right now, I will spend some time
looking at it and convincing other wireless driver authors to adopt
it. I hope you will help us getting that integrated and adopted.
	Thanks...

	Jean

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Greg KH]

On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> 	Manuel Estrada sent me a proposal for that.

I provided some feedback to him that I think will make his proposal work
for almost everyone.  Hopefully he has the time to implement it :)

thanks,

greg k-h

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Jean Tourrilhes]

On Thu, May 15, 2003 at 10:46:48AM -0700, Greg KH wrote:
> On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> > 	Manuel Estrada sent me a proposal for that.
> 
> I provided some feedback to him that I think will make his proposal work
> for almost everyone.  Hopefully he has the time to implement it :)
> 
> thanks,
> 
> greg k-h

	I read that thread and I don't agree with some of your
unrealistic requirements.
	As long as kernel 2.6.X is not standard in most major
distributions (including Debian), whatever scheme we decide on must be
easy to implement on 2.4.X. Let be realistic : all of us still
continue to update 2.4.X on a regular basis. Those 3 drivers are ready
today (one of them has been waiting on this issue for already 6
months), and I want them in 2.4.X not long after they go in 2.5.X.
	Therefore, unless you plan to port sysfs to 2.4.X real soon,
the scheme can't depend exclusively on sysfs. I would even say,
because sysfs change on a weekly basis, it might even be wise to take
a two phase approach, with sysfs used only in the second phase and
based on the feedback and the results from the first phase (I
personally don't believe we will get it perfect at the first try). The
hotplug facility is flexible enough to migrate to sysfs smoothly.
	I'm pragmatic : I prefer to have something imperfect now
rather than something perfect later. I think Manuel's solution is a
good stepping stone to where we want to go. If you make it too
difficult, this will never happen (and each driver will use a
proprietary solution or be kept in a black hole).

	So, my question for you is :
	o how do you plan to make it work with 2.4.X.

	Have fun...

	Jean

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Greg KH]

On Thu, May 15, 2003 at 12:55:16PM -0700, Jean Tourrilhes wrote:
> On Thu, May 15, 2003 at 10:46:48AM -0700, Greg KH wrote:
> > On Thu, May 15, 2003 at 10:24:46AM -0700, Jean Tourrilhes wrote:
> > > 	Manuel Estrada sent me a proposal for that.
> > 
> > I provided some feedback to him that I think will make his proposal work
> > for almost everyone.  Hopefully he has the time to implement it :)
> > 
> > thanks,
> > 
> > greg k-h
> 
> 	I read that thread and I don't agree with some of your
> unrealistic requirements.

If you think that having a common firmware interface for any kind of
device for 2.5 is unrealistic, then this is going to be a very short
discussion.

<2.4 is here for a long time ramble snipped>

> 	So, my question for you is :
> 	o how do you plan to make it work with 2.4.X.

In short, I don't care how you do it for 2.4.x.  Do it like the
bluetooth usb drivers do it, that's a good place to start with.  Or do
it like the usb drivers that do firmware download from userspace, that's
also a good way to do this for 2.4.  So for 2.4 you have a lot of
different options on how to do this, _because_ we don't have the
goodness of sysfs and the driver model there.

For 2.5 do it the way I proposed, that way _all_ devices in the kernel
have a single way to have firmware downloaded to them, which will result
in peace and harmony for many years to come, during which we will gaze
thoughtfully back on the anarchistic ways of 2.4 and laugh at how
foolish we were then.

thanks,

greg k-h

Re: airo and firmware upload (was Re: 2.6 must-fix list, v3)

[Manuel Estrada Sainz]

On Thu, May 15, 2003 at 11:04:59AM +1000, David Gibson wrote:
> On Wed, May 14, 2003 at 04:38:26PM -0700, Andrew Morton wrote:
> > Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
> > >
> > > firmwares blobs 
> > 
> > well for the purposes of tracking 2.6 activities I'll separate this issue
> > of firmware access policy out from drivers/net/wireless/. 
> > 
> > yeah, it would be nice if the core kernel provided a "give me my firmware"
> > API or something.
> 
> Well, Manuel Estrada (also author of the orinoco USB patches) has
> proposed one on lkml.  Doesn't look like people were happy with that
> version, but I think he's still working on revising it based on
> feedback.

 Yep, I posted it yesterday. Please provide feedback so I can get it
 "right (TM)" and it gets in the kernel for all to enjoy.

 Thanks

 	Manuel
-- 
--- Manuel Estrada Sainz <ranty@debian.org>
                         <ranty@bigfoot.com>
			 <ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

Re: 2.6 must-fix list, v3

[Pavel Machek]

Hi!

> > Quite a lot of changes here.  Mostly additions, but some things have been
> > crossed off.
> > 
> > Also at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix
> 
> 	I don't like making todo list for other people, because it's
> up to them to decide, but here is my wishlist for 2.6.X in term of
> Wireless stuff.
> 	I hope those concerned will react and send you their real todo
> list.
> 
> 	o get latest orinoco changes from David. Linus seems timely in
> picking David's changes, so I'm not worried about this one.
> 
> 	o get the latest airo.c fixes from CVS. This will hopefully
> fix problems people have reported on the LKML.
> 
> 	o get HostAP driver in the kernel. No consolidation of the
> 802.11 management across driver can happen until this one is in (which
> is probably 2.7.X material). I think Jouni is mostly ready but didn't
> find time for it.
> 
> 	o get more wireless drivers into the kernel. The most
> "integrable" drivers at this point seem the NWN driver, Pavel's
> Spectrum driver and the Atmel driver.

Is that Pavel Roskin or is there another Pavel around here? 

							Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]