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.
>
> 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.
|