Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1260323 > unrolled thread

Re: Exporting obscene amounts of data in rtnl_link_ops->fill_info()

Started by"Jason A. Donenfeld" <Jason@zx2c4.com>
First post2015-11-02 04:30 +0100
Last post2015-11-02 04:30 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Exporting obscene amounts of data in rtnl_link_ops->fill_info() "Jason A. Donenfeld" <Jason@zx2c4.com> - 2015-11-02 04:30 +0100

#1260323 — Re: Exporting obscene amounts of data in rtnl_link_ops->fill_info()

From"Jason A. Donenfeld" <Jason@zx2c4.com>
Date2015-11-02 04:30 +0100
SubjectRe: Exporting obscene amounts of data in rtnl_link_ops->fill_info()
Message-ID<qqdYK-cb-3@gated-at.bofh.it>
Hi folks,

Just a follow-up on this thread...

The basic issue is that for a given net device, I want to export to
userspace more data than what can fit in a netlink sk_buff. On first
glance, using RTM_GETLINK with the ops->fill_info() hook seemed
perfect. It provides a simple interface for my rtnetlink driver to
provide additional information back to userspace. Unfortunately, the
size of messages it can export back to userspace is limited, as
mentioned.

So, I see two options from here:

One is registering a new type of netlink message for a new PF, with
rtnl_register(). Inside of this, I'd have a more clean API of sending
back information in chunks, which can fit inside a netlink packet.

The other is to implement ops->ndo_do_ioctl() with a very simple
mechanism of copying structs back to userspace, directly into
userspace-allocated buffers. This would be _much_ simpler and easier
to implement, and probably less prone to race-conditions too.

So I want to add the ioctl. I can practically already see the code in
my head. But everywhere I look, folks are turning to netlink. It's
hard to imagine a new driver passing review on this mailing list if it
adds "yet another" ioctl interface. So, I'm then pushed toward doing
the awkward netlink dance, because "all the cool kids are doing it."

But, before I succumb to what is potentially a false dichotomy, I
thought I'd write in here to get some opinions on the best way
forward. To repeat, the basic idea is - I need to return lots of
per-interface information to userspace from a netdevice. RTM_GETLINK
has a maximum message size, so it won't do. What's the cleanest and
most acceptable way forward?

Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web