Thu, Jan 03, 2019 at 02:31:59PM CET, era...@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.
