Custom driver specific commands

[Dan Williams]

On Fri, 2008-03-07 at 14:54 -0800, Dmitry Shmidt wrote:
> 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.

Is it a kernel net device driver?  If so, you must have the open() and
close() methods, and thus ifconfig up/down will work for you.

If it's not, then obviously ifconfig up/down won't work, yeah.

Dan

> 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
>         
>         
>