Commit graph

4 commits

Author SHA1 Message Date
Inaky Perez-Gonzalez
52a8d96308 wimax: document why wimax_msg_*() operations can be used in any state
Funcion documentation for wimax_msg_alloc() and wimax_msg_send() needs
to clarify that they can be used in the very early stages of a
wimax_dev lifecycle.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:02:04 -07:00
Inaky Perez-Gonzalez
d1a2627a29 wimax: fix oops if netlink fails to add attribute
When sending a message to user space using wimax_msg(), if nla_put()
fails, correctly interpret the return code from wimax_msg_alloc() as
an err ptr and return the error code instead of crashing (as it is
assuming than non-NULL means the pointer is ok).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-06 13:48:36 -07:00
Pablo Neira Ayuso
ff491a7334 netlink: change return-value logic of netlink_broadcast()
Currently, netlink_broadcast() reports errors to the caller if no
messages at all were delivered:

1) If, at least, one message has been delivered correctly, returns 0.
2) Otherwise, if no messages at all were delivered due to skb_clone()
   failure, return -ENOBUFS.
3) Otherwise, if there are no listeners, return -ESRCH.

With this patch, the caller knows if the delivery of any of the
messages to the listeners have failed:

1) If it fails to deliver any message (for whatever reason), return
   -ENOBUFS.
2) Otherwise, if all messages were delivered OK, returns 0.
3) Otherwise, if no listeners, return -ESRCH.

In the current ctnetlink code and in Netfilter in general, we can add
reliable logging and connection tracking event delivery by dropping the
packets whose events were not successfully delivered over Netlink. Of
course, this option would be settable via /proc as this approach reduces
performance (in terms of filtered connections per seconds by a stateful
firewall) but providing reliable logging and event delivery (for
conntrackd) in return.

This patch also changes some clients of netlink_broadcast() that
may report ENOBUFS errors via printk. This error handling is not
of any help. Instead, the userspace daemons that are listening to
those netlink messages should resync themselves with the kernel-side
if they hit ENOBUFS.

BTW, netlink_broadcast() clients include those that call
cn_netlink_send(), nlmsg_multicast() and genlmsg_multicast() since they
internally call netlink_broadcast() and return its error value.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-05 23:56:36 -08:00
Inaky Perez-Gonzalez
3e65646bb1 wimax: basic API: kernel/user messaging, rfkill and reset
Implements the three basic operations provided by the stack's control
interface to WiMAX devices:

- Messaging channel between user space and driver/device

  This implements a direct communication channel between user space
  and the driver/device, by which free form messages can be sent back
  and forth.

  This is intended for device-specific features, vendor quirks, etc.

- RF-kill framework integration

  Provide most of the RF-Kill integration for WiMAX drivers so that
  all device drivers have to do is after wimax_dev_add() is call
  wimax_report_rfkill_{hw,sw}() to update initial state and then every
  time it changes.

  Provides wimax_rfkill() for the kernel to call to set software
  RF-Kill status and/or query current hardware and software switch
  status.

  Exports wimax_rfkill() over generic netlink to user space.

- Reset a WiMAX device

  Provides wimax_reset() for the kernel to reset a wimax device as
  needed and exports it over generic netlink to user space.

This API is clearly limited, as it still provides no way to do the
basic scan, connect and disconnect in a hardware independent way.  The
WiMAX case is more complex than WiFi due to the way networks are
discovered and provisioned.

The next developments are to add the basic operations so they can be
offerent by different drivers. However, we'd like to get more vendors
to jump in and provide feedback of how the user/kernel API/abstraction
layer should be.

The user space code for the i2400m, as of now, uses the messaging
channel, but that will change as the API evolves.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:17 -08:00