From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [PATCH RFC net-next 00/19] Devlink health reporting and recovery system Date: Fri, 4 Jan 2019 10:01:11 +0100 Message-ID: <20190104090111.GB21274@nanopsycho.orion> References: <1546266733-9512-1-git-send-email-eranbe@mellanox.com> <20181231174727.6280fc3c@cakuba.hsd1.ca.comcast.net> <6eb2ebe0-40fa-f037-f0f4-d54c907da185@mellanox.com> <20190102144629.525d7dc1@cakuba.hsd1.ca.comcast.net> <44d02f4d-f5c9-a5dd-9392-97e1268f5371@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jakub Kicinski , "netdev@vger.kernel.org" , "David S. Miller" , Jiri Pirko , Moshe Shemesh , Aya Levin , Tal Alon , Ariel Almog To: Eran Ben Elisha Return-path: Received: from mail-wm1-f68.google.com ([209.85.128.68]:53969 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725913AbfADJJX (ORCPT ); Fri, 4 Jan 2019 04:09:23 -0500 Received: by mail-wm1-f68.google.com with SMTP id d15so520637wmb.3 for ; Fri, 04 Jan 2019 01:09:22 -0800 (PST) Content-Disposition: inline In-Reply-To: <44d02f4d-f5c9-a5dd-9392-97e1268f5371@mellanox.com> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Jan 03, 2019 at 02:31:59PM CET, eranbe@mellanox.com wrote: > > >On 1/3/2019 12:46 AM, Jakub Kicinski wrote: >> On Tue, 1 Jan 2019 09:58:30 +0000, Eran Ben Elisha wrote: >>> On 1/1/2019 3:47 AM, Jakub Kicinski wrote: [...] > >> >>>> About the marshalling, I'm not sure it belongs in the kernel. There is >>>> precedent for adding interpretation of FW blobs in user space (ethtool). >>>> IMHO it's a more scalable approach, if we want to avoid having 100 kLoC >>>> drivers. Amount of code you add to print the simple example from last >>>> patch is not inspiring confidence. >>> >>> The idea was to provide the developer the ability to create "tree-like" >>> of information, it is needed when you want to describe complex objects. >>> This caused a longer coding, but I don't think we are even close to the >>> scale you are talking about. >>> We can remove the tree flexibility, and move to array format, it will >>> make the code of storing data by the driver to be shorter, but we will >>> lose the ability to have it in tree-like format. >> >> To be clear I slightly oppose the marshalling in the first place. It >> may be better to just dump the data as is, and have user space know >> what the interpretation is. > >We provides a way to store the data in nested layers. In internal >discussions with Jiri, we decided that this is the correct approach. >However, if one insists, it can fill the buffers with raw binary and >label it as such. Again, the data is generated by driver. Driver knows the objects, it can assemble a tree of values accordingly. To me it seems wrong to squash the info into binary, push to userspace where it has to be parsed and unsquashed back.