Andi Kleen wrote:
On Thu, Jan 24, 2002 at 09:16:07AM -0700, Ben Greear wrote:
From a quick glance at the man page, it seems netlink would be pretty
heavy-weight for just wanting to get the counters from a device. I
especially do not want to have to deal with the unreliable
(according to the man page) nature of netlink when reading kernel
counters. To me, an IOCTL seems best.
When the ioctl allocates memory for example it is not in any way more
reliable than a netlink request. The only special case is when you
get an netlink notification from an softirq/irq, in this case there
is the possibility that the netlink packet cannot get allocated when
you're out of GFP_ATOMIC memory.
In this case the application needs to be notified in a failsafe way
to request a resync.
There are various ways to do that, e.g. set a flag and wake it all waiters
up or use a preallocated error skb for this case.
Note this cannot happen for a simple request, only for a async
threshold exceeded message. Simple request happens completely
in process context and are mostly equivalent to ioctls.
Ok, that sounds better. An IOCTL in this case should not have to allocate
any memory (other than perhaps something on the stack). It also wouldn't
involve having to parse any netlink headers, but could just pass back a packed
structure of 64bit numbers.
By the way, how do you change a 64-bit counter to/from network-byte-order
on a 32bit machine? (Perhaps you would need to do it in this case..but I'm
curious :))
netlink packets are in host order.
-Andi
P.S.: people will of course not use netlink, but instead do popen("eth-tool")
It's therefore important that the output of eth-tool is table and easy
to parse too. In the end it'll have the same issues as /proc.
--
Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
|