Custom driver specific commands

[Dmitry Shmidt]

Hi Dan,

In my specific customer driver Start() starts the Radio and Stop() stops it
saving power.
Unfortunately the driver itself is not written in the way when Start() /
Stop() will be called through "standard" IOCTL, so neither ifconfig nor
iwconfig will be able to call it.

I can add wifi_ioctl utility that will call IOCTLs but then I'll have 3
utilities:
wpa_cli (kind of), wpa_supplicant, wifi_ioctl - and I think to have only 2
is a reasonable will...

Thanks,

Dmitry

On Fri, Mar 7, 2008 at 2:33 PM, Dan Williams <dcbw at redhat.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20080307/ba2ea2a1/attachment.htm