Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751991AbbKBDZn (ORCPT ); Sun, 1 Nov 2015 22:25:43 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:57997 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750903AbbKBDZl (ORCPT ); Sun, 1 Nov 2015 22:25:41 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 2 Nov 2015 04:25:36 +0100 Message-ID: Subject: Re: Exporting obscene amounts of data in rtnl_link_ops->fill_info() From: "Jason A. Donenfeld" To: Netdev , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1926 Lines: 43 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/