wlan-ng in kernel staging

[Richard Kennedy]

hi all,
I don't know if you saw this :-
http://marc.info/?l=linux-kernel&m=122367876126577&w=2

Greg Kroah-Hartman has taken a version of the usb driver into the kernel
staging tree.
I haven't tried it yet, so I don't know if it works, but it's
interesting anyway :)

I don't know what should be done about firmware loading, any
suggestions?
regards
Richard

[Solomon Peachy]

Post by Richard Kennedy
Greg Kroah-Hartman has taken a version of the usb driver into the
kernel staging tree. I haven't tried it yet, so I don't know if it
works, but it's interesting anyway :)

It is interesting, but I hope it never gets merged (as it is, anyway).
I still think it would take less work to write a new driver from scratch
(or adapt the hostap driver to work with USB) than it would take to make
linux-wlan-ng a proper kernel denizen.

That said, good first step would be to strip everything out that the
current WEXT frontend code doesn't use. Then eliminate everything
relating to (tertiary firmware) AP operation.

Post by Richard Kennedy
I don't know what should be done about firmware loading, any
suggestions?

The whole firmware upload path basically needs to be rewritten to exist
purely in kernelspace, especially the firmware plugging steps. (The
hotplug/udev 'request_firmware' only supports reading in a dumb file,
and prism2dl+scripts do a lot of work..)

- Solomon

[Richard Kennedy]

Post by Solomon Peachy

Post by Richard Kennedy
Greg Kroah-Hartman has taken a version of the usb driver into the
kernel staging tree. I haven't tried it yet, so I don't know if it
works, but it's interesting anyway :)

It is interesting, but I hope it never gets merged (as it is, anyway).
I still think it would take less work to write a new driver from scratch
(or adapt the hostap driver to work with USB) than it would take to make
linux-wlan-ng a proper kernel denizen.

Some time ago, when you suggested it last I think ;), I did look at
building on the hostap code but it got quite ugly to get usb to work
within it's existing structure - so I abandoned it.

I'm not sure if it's possible to use the kernel's 802.11 code, and just
write the usb/prism2 parts. Last time I looked at the kernel wireless
stack there wasn't too much documentation,and it only seemed to work
with softmac cards. But maybe that's changed?

Post by Solomon Peachy
That said, good first step would be to strip everything out that the
current WEXT frontend code doesn't use. Then eliminate everything
relating to (tertiary firmware) AP operation.

good idea.

Post by Solomon Peachy

Post by Richard Kennedy
I don't know what should be done about firmware loading, any
suggestions?

The whole firmware upload path basically needs to be rewritten to exist
purely in kernelspace, especially the firmware plugging steps. (The
hotplug/udev 'request_firmware' only supports reading in a dumb file,
and prism2dl+scripts do a lot of work..)
- Solomon

I was thinking about a simple user space utility to convert the firmware
to a binary representation that matches the kernel.( this would only
need doing once at build time)
and use request_firmware to upload that, then the kernel would only
have to do the plugging & upload to the card.

regards
Richard

[Solomon Peachy]

Post by Richard Kennedy
I'm not sure if it's possible to use the kernel's 802.11 code, and just
write the usb/prism2 parts. Last time I looked at the kernel wireless
stack there wasn't too much documentation,and it only seemed to work
with softmac cards. But maybe that's changed?

Last time I checked, the kernel's (newest) 802.11 stack wasn't suitable
for thickmac cards. And should stay that way. Proper support for the
prism2's quirks would mean a lot of uglification.

Fortunately, wlan-ng's guts can be cut down considerably. (I've been
sending patches in to do just that)

Post by Richard Kennedy
I was thinking about a simple user space utility to convert the firmware
to a binary representation that matches the kernel.( this would only
need doing once at build time)

I don't see the point -- what would be gained vs doing it all in
the kernel?

- Solomon

[Richard Kennedy]

Post by Solomon Peachy

Post by Richard Kennedy
I'm not sure if it's possible to use the kernel's 802.11 code, and just
write the usb/prism2 parts. Last time I looked at the kernel wireless
stack there wasn't too much documentation,and it only seemed to work
with softmac cards. But maybe that's changed?

Last time I checked, the kernel's (newest) 802.11 stack wasn't suitable
for thickmac cards. And should stay that way. Proper support for the
prism2's quirks would mean a lot of uglification.
Fortunately, wlan-ng's guts can be cut down considerably. (I've been
sending patches in to do just that)

I see Greg has just posted your patches , nice.

Post by Solomon Peachy

Post by Richard Kennedy
I was thinking about a simple user space utility to convert the firmware
to a binary representation that matches the kernel.( this would only
need doing once at build time)

I don't see the point -- what would be gained vs doing it all in
the kernel?

Just because it's trivial in perl to convert the S-records to a
simplified binary format, therefore reducing the amount of code in the
kernel that needs debugging & maintaining.
Also we only need to perform the conversion once rather than every time
the firmware is loaded. Looking at the prism download utility is seems a
bit of a tedious job to do in C whereas it is simple in perl.
regards
Richard