Jean Tourrilhes [EMAIL PROTECTED] wrote:
We have the message interface (through a Wireless Events,
since WE-14). However, netlink is highly undesirable in embedded space
for bloat reason.
Why is that? I've seen many embedded applications using netlink
for either routing or IPsec. It
On Tue, 11 Apr 2006 10:58:06 +0200, [EMAIL PROTECTED] wrote:
Below patch was developed after discussion with Daniel Drake who
mentioned to me that wireless tools expect an EAGAIN return from getscan
so that they can wait for the scan to finish before printing out the
results.
This sounds
On Thu, 2006-04-13 at 02:00 -0700, Pete Zaitcev wrote:
This sounds completely wrong. Do you guys remember the Subject: string
of this discussion by any chance?
Discussed offline at the wireless summit, sorry.
It's very likely that tools do indeed loop when they see EAGAIN, but
this is a
On Thu, 2006-04-13 at 11:06 +0200, Johannes Berg wrote:
It's very likely that tools do indeed loop when they see EAGAIN, but
this is a workaround, not the main mode of operation. It seems obvious
to me that the get method should wait until the scan results are
available. Perhaps the
On Thu, 2006-04-13 at 02:00 -0700, Pete Zaitcev wrote:
On Tue, 11 Apr 2006 10:58:06 +0200, [EMAIL PROTECTED] wrote:
Below patch was developed after discussion with Daniel Drake who
mentioned to me that wireless tools expect an EAGAIN return from getscan
so that they can wait for the scan
On Thu, 2006-04-13 at 11:34 +0200, Johannes Berg wrote:
On Thu, 2006-04-13 at 11:06 +0200, Johannes Berg wrote:
It's very likely that tools do indeed loop when they see EAGAIN, but
this is a workaround, not the main mode of operation. It seems obvious
to me that the get method should
On Thu, 2006-04-13 at 08:12 -0400, Dan Williams wrote:
Maybe it's wrong now, but it's how the CLI tools have operated for quite
a while AFAIK.
Yes, and they don't seem to care about the netlink messages.
But the question is rather -- should we block the program inside the
kernel and only
On Thu, Apr 13, 2006 at 02:19:26PM +0200, Johannes Berg wrote:
But the question is rather -- should we block the program inside the
kernel and only return from get scan after the scan is actually done,
rather than returning we can't give you anything now, try later. We
could do that too, but
On Thu, 13 Apr 2006 08:12:55 -0400, Dan Williams [EMAIL PROTECTED] wrote:
This sounds completely wrong. Do you guys remember the Subject: string
of this discussion by any chance?
There are two options for tools: (a) request scan and block on GIWSCAN
until it doesn't return EAGAIN, or (b)
On Thu, 13 Apr 2006 09:00:51 -0700, Jouni Malinen [EMAIL PROTECTED] wrote:
That could be blocking an ioctl call for couple of seconds
and would be quite horrible for single threaded programs.
I would say that waiting for couple of seconds in the kernel would
be quite wonderful for single
On Thu, Apr 13, 2006 at 03:28:53PM -0700, Pete Zaitcev wrote:
On Thu, 13 Apr 2006 09:00:51 -0700, Jouni Malinen [EMAIL PROTECTED] wrote:
That could be blocking an ioctl call for couple of seconds
and would be quite horrible for single threaded programs.
I would say that waiting for
On Thu, 13 Apr 2006 15:45:22 -0700
Jouni Malinen [EMAIL PROTECTED] wrote:
On Thu, Apr 13, 2006 at 03:28:53PM -0700, Pete Zaitcev wrote:
On Thu, 13 Apr 2006 09:00:51 -0700, Jouni Malinen [EMAIL PROTECTED]
wrote:
That could be blocking an ioctl call for couple of seconds
and would be
Pete Zaitcev wrote :
Do you realize that block means enterering the kernel and calling
schedule(), which is exactly what is NOT happening in the patch?
I would not mind if the tools blocked in GIWSCAN, only until
it returns success and not EGAIN.
Do you realise that block means
Stephen Hemminger wrote :
Sounds like you want a message interface like netlink, not ioctl's.
We have the message interface (through a Wireless Events,
since WE-14). However, netlink is highly undesirable in embedded space
for bloat reason.
Jean
-
To unsubscribe from this
Below patch was developed after discussion with Daniel Drake who
mentioned to me that wireless tools expect an EAGAIN return from getscan
so that they can wait for the scan to finish before printing out the
results.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
15 matches
Mail list logo
