Custom driver specific commands

[Dan Williams]

On Fri, 2008-03-07 at 12:21 -0800, Dmitry Shmidt wrote:
> I think there are both driver-specific and "generic" commands.
> From "Generic" perspective I would say that Start/Stop commands will
> be useful.

Describe start/stop more please...  start and stop are "ifconfig xxx up"
and "ifconfig xxx down".  No more, no less.

> Let's assume you want to save power on turn off WiFi if you are
> temporarily not using it.

If you're not using the wifi, either flip the killswitch, or "ifconfig
xxx down", and the driver should automatically turn off the RF power.
Not all drivers work this way, but that's a bug.

Custom commands really, really need to be on a case-by-case basis, if at
all.  I realize that WEXT doesn't handle them very well, but if we just
allow any old custom commands we get right back into the horrible,
horrible situation of 2 years ago where every single driver had a
different command set and you had to have special cases for every single
one.

Dan

> init/deinit are not useful for this purpose.
> 
> I can imagine driver specific commands as well, but the ability to
> pass any command will solve this issue.
> 
> Thanks,
> 
> Dmitry
> 
> On Fri, Mar 7, 2008 at 11:41 AM, Jouni Malinen <j at w1.fi> wrote:
>         On Fri, Mar 07, 2008 at 11:26:28AM -0800, Dmitry Shmidt wrote:
>         
>         > I need to be able to call driver specific IOCTL (commands)
>         from control
>         > application.
>         
>         
>         Would you be able to describe what kind of functionality this
>         is used
>         for? Are these truly driver specific or could there be more
>         generic use
>         for them?
>         
>         > It is possible to call IOCTL directly, but I think it will
>         be more
>         > "architecturally" correct to do this through supplicant
>         interface.
>         > It was not a big deal to add additional command processing
>         to ctrl_iface.c
>         > and additional entry to struct wpa_driver_ops, that will
>         > process command and pass it to the driver.
>         >
>         > Does it seem Ok ? Am I missing something ?
>         
>         
>         I would assume this depends on what the exact functionality
>         would be. I
>         could imagine some driver interaction to be perfectly
>         reasonable to do
>         directly from an external application at least when the
>         operations are
>         completely independent from the normal supplicant
>         functionality (e.g.,
>         WMM configuration) while some operations are likely to fit
>         better with
>         wpa_supplicant talking to the driver in order to avoid
>         conflicts with
>         other wpa_supplicant-initiated commands.
>         
>         As far as the source code change itself is concerned, yes, I
>         would
>         expect that an additional command in ctrl_iface.c and a
>         handler function
>         in struct wpa_driver_ops would be the cleanest way of doing
>         this for
>         driver specific changes.
>         
>         --
>         Jouni Malinen                                            PGP
>         id EFC895FA
>         _______________________________________________
>         HostAP mailing list
>         HostAP at lists.shmoo.com
>         http://lists.shmoo.com/mailman/listinfo/hostap
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap