Re: linux-wireless mailing list

[Jean Tourrilhes <jt@bougret.hpl.hp.com>]

On Wed, Mar 10, 2004 at 12:46:09PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >+static inline int rtnetlink_standard_call(struct net_device *	dev,
> >+					  struct iw_event *	request,
> >+					  int			request_len,
> >+					  iw_handler		handler)
> >+{
> >+	const struct iw_ioctl_description *	descr = NULL;
> >+	unsigned int				cmd;
> >+	union iwreq_data *			wrqu;
> >+	int					hdr_len;
> >+	struct iw_request_info			info;
> >+	int					ret = -EINVAL;
> >+
> >+	/* Get the description of the IOCTL */
> >+	cmd = request->cmd;
> >+	if((cmd - SIOCIWFIRST) >= standard_ioctl_num)
> >+		return -EOPNOTSUPP;
> >+	descr = &(standard_ioctl[cmd - SIOCIWFIRST]);
> 
> 
> OK, this patch looks good to me.

	Jeff (and others),

	I'm hitting a problem with migrating Wireless Extensions to
RtNetlink.

	The basic model of Wireless Extensions is Query/Reply. I ask
for the ESSID, the card returns the ESSID, I ask for a scan, the card
returns the scan results.
	This doesn't work well with RtNetlink. RtNetlink supports only
Set and Dump. Set doesn't allow to return data, and Dump doesn't take
any input arguments, so always return everything. Using Dump doesn't
make sense, I don't want the card to perform a Wireless Scan every
time I want to check the ESSID (each Wireless Scan takes a few
seconds).
	The RtNetlink interface was clearly not designed for hardware
devices where the retrieval of each piece of information has a
significant cost/overhead.

	I'm also suspicious of the interaction with the device
notifiers and link flag setting. But that may not be as bad.

	The option I'm leaning toward is to define a new Netlink
socket type for Wireless Extensions, which would allow me to use the
Query/Reply model.

	Thanks...

	Jean