[Prism54-devel] Re: Just several thoughts & suggestions

[Jean Tourrilhes]

kaleda wrote :
> 
> Currently there are 14 private ioctl's used. Total there are only 16
> private ioctls available. If we'll continue this way - soon we'll have
> no private ioctls.

	When it concern Wireless Extensions, if you want me to get
involved, I would advise to cc me directly (I read mailing list
archive only ocasionally).
	This is not exactly correct. As Aurelien point out, for WE-12
and later you have 32 ioctls.

> What I suggest is to group similar functionality ioctls. E.g. group to
> one ioctl all acl related ioctls, to other group all WPA related ioctls.
> And so on. The card firmware has much more functionality, to fit each
> function to separate ioctl. I can suggest two ways:
>  1.a) still use iwpriv. But first byte (or several first bytes) shows
> what kind of action to do: e.g. 1 - add new mac, 2 - delete mac, 3 -
> list macs, and so on.
>  1.b) write our own prism54 private ioctl tool. It should use private
> ioctls, but in such a way we can use our private structures, and we can
> much more extend functionality. We can give much more control to
> userspace.

	Solution 1c) : Use sub-ioctl support provided by WE-15 and
later. This is what HostAP is doing (well, this support was
explicitely created for the HostAP driver).
	For more info on that, check :
		o iwpriv source code (comments at the top)
		o sample_priv_addr.c
		o HostAP source code

	Solution 1d) : Use token-index support provided by WE-15 and
later. Nobody is using that but it should work.
	For more info on that, check :
		o iwpriv source code (comments at the top)

> Everybody sees, that current wireless extentions & iwconfig
> functionality is more than not enougth. And many wireless related things
> are comming up (like wpa or acl - these are common things, but they have
> no standard). I hope, that in near future wireless extentions will have
> new features.

	That's exactly the way it works. Updates are slow because I
want to get them right. The HostAP driver is usually where I do my
experimentations.
	For new features, I would like to look into WPA.

> 3. Interface name. I'd like to have posibbility to set interface name
> via module parameters. Some proprietary software are dumb enougth, that
> they expect only specifin network interface names (like ixp0, ixp1 on
> intel arm IXP architecture).

	I'm currently enhancing nameif/SIOCSIFNAME support. This is
IMHO the way to go, as it is more flexible and can apply to any driver
without hacks in the driver themselves. More on this later.

> In this way it's easy for me to extend some drivers ioctl's
> functionality (just add a new case in switch in this ioctl nad
> cpu_to_lexx conversion), and a simple way to extend private ioctl
> utility - just add specific structure to union and add relates scanfs
> (or whatsever).

	Sub-ioctl is definitely the way to go. Just use the OIDs
numbers as the sub-ioctl index, provide a generic converter between
OIDs data and WE data, and you are done. You should be able to do that
with iwpriv out of the box.

> So much comments and so few core
> (quote from wireless tools header ;-).

	"code".

Herbert Valerio Riedel wrote :
> it seems to be, that the whole wlan-business in linux could benefit from
> some better framework to help minimize code; when I look through stuff
> like isl_ioctl.[ch] I see much code that either repetitive (causing me
> to be tempted to factorize this away by ugly macros -- causing others to
> puke at them due to the unclear control flow)

	In case you did not realised, WE-13 (new driver API), WE-15
(enhanced iwpriv) and WE-16 (factored iwspy support) are doing exactly
that. And without breaking backward compatibility.
	Suggestions are always welcomed, but remember that upgrading a
dozen driver (with maintainers not always responsive) is a royal
pain.

> or maybe I'm overlooking that there's something like what I'm dreaming
> of available already?

	Let's get down to particular. Please point out which code is
problematic.

> The comments around those #define are a bit confusing because the
> first says 16 ioctl. Whereas the second : "We now have 32 commands,
> so a bit more space ;-)."

	That's called a "bug", and I will need to fix it ;-)

> BTW, I'm currently rewriting some ioctl stuff and the oid thing, and
> it will be a bit more coherent...

	Cool. You are doing an amazing work ;-)

	Jean