No subject


Sun Feb 10 20:49:06 EST 2008


useful.
Let's assume you want to save power on turn off WiFi if you are temporarily
not using it.
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
>

------=_Part_7718_12498552.1204921297626
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think there are both driver-specific and &quot;generic&quot; commands.<br>From &quot;Generic&quot; perspective I would say that Start/Stop commands will be useful.<br>Let&#39;s assume you want to save power on turn off WiFi if you are temporarily not using it.<br>
init/deinit are not useful for this purpose.<br><br>I can imagine driver specific commands as well, but the ability to pass any command will solve this issue.<br><br>Thanks,<br><br>Dmitry<br><br><div class="gmail_quote">On Fri, Mar 7, 2008 at 11:41 AM, Jouni Malinen &lt;<a href="mailto:j at w1.fi">j at w1.fi</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Fri, Mar 07, 2008 at 11:26:28AM -0800, Dmitry Shmidt wrote:<br>
<br>
&gt; I need to be able to call driver specific IOCTL (commands) from control<br>
&gt; application.<br>
<br>
</div>Would you be able to describe what kind of functionality this is used<br>
for? Are these truly driver specific or could there be more generic use<br>
for them?<br>
<div class="Ih2E3d"><br>
&gt; It is possible to call IOCTL directly, but I think it will be more<br>
&gt; &quot;architecturally&quot; correct to do this through supplicant interface.<br>
&gt; It was not a big deal to add additional command processing to ctrl_iface.c<br>
&gt; and additional entry to struct wpa_driver_ops, that will<br>
&gt; process command and pass it to the driver.<br>
&gt;<br>
&gt; Does it seem Ok ? Am I missing something ?<br>
<br>
</div>I would assume this depends on what the exact functionality would be. I<br>
could imagine some driver interaction to be perfectly reasonable to do<br>
directly from an external application at least when the operations are<br>
completely independent from the normal supplicant functionality (e.g.,<br>
WMM configuration) while some operations are likely to fit better with<br>
wpa_supplicant talking to the driver in order to avoid conflicts with<br>
other wpa_supplicant-initiated commands.<br>
<br>
As far as the source code change itself is concerned, yes, I would<br>
expect that an additional command in ctrl_iface.c and a handler function<br>
in struct wpa_driver_ops would be the cleanest way of doing this for<br>
driver specific changes.<br>
<font color="#888888"><br>
--<br>
Jouni Malinen &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;PGP id EFC895FA<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP at lists.shmoo.com">HostAP at lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</font></blockquote></div><br>

------=_Part_7718_12498552.1204921297626--


More information about the HostAP mailing list