lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dddb1a17-991a-30b6-a1ad-b7c5bc05348a@pensando.io>
Date:   Wed, 10 Jul 2019 10:06:05 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface

On 7/9/19 11:48 PM, Jiri Pirko wrote:
> Tue, Jul 09, 2019 at 09:13:53PM CEST, snelson@...sando.io wrote:
>> On 7/8/19 11:56 PM, Jiri Pirko wrote:
>>> Tue, Jul 09, 2019 at 12:58:00AM CEST, snelson@...sando.io wrote:
>>>> On 7/8/19 1:03 PM, Jiri Pirko wrote:
>>>>> Mon, Jul 08, 2019 at 09:58:09PM CEST, snelson@...sando.io wrote:

>>>>>> If I'm not mistaken, the alloc is only allocating enough for a pointer, not
>>>>>> the whole per device struct, and a few lines down from here the pointer to
>>>>>> the new devlink struct is assigned to ionic->dl.  This was based on what I
>>>>>> found in the qed driver's qed_devlink_register(), and it all seems to work.
>>>>> I'm not saying your code won't work. What I say is that you should have
>>>>> a struct for device that would be allocated by devlink_alloc()
>>>> Is there a particular reason why?  I appreciate that devlink_alloc() can give
>>>> you this device specific space, just as alloc_etherdev_mq() can, but is there
>>> Yes. Devlink manipulates with the whole device. However,
>>> alloc_etherdev_mq() allocates only net_device. These are 2 different
>>> things. devlink port relates 1:1 to net_device. However, devlink
>>> instance can have multiple ports. What I say is do it correctly.
>> So what you are saying is that anyone who wants to add even the smallest
>> devlink feature to their driver needs to rework their basic device memory
>> setup to do it the devlink way.  I can see where some folks may have a
>> problem with this.
> It's just about having a structure to hold device data. You don't have
> to rework anything, just add this small one.

Well, there's a bit of logic rework to and a little data twiddling - not 
too bad in our case.  Others may not be thrilled depending on how 
they've already implemented their drivers.

>>>>> The ionic struct should be associated with devlink_port. That you are
>>>>> missing too.
>>>> We don't support any of devlink_port features at this point, just the simple
>>>> device information.
>>> No problem, you can still register devlink_port. You don't have to do
>>> much in order to do so.
>> Is there any write-up to help guide developers new to devlink in using the
>> interface correctly?  I haven't found much yet, but perhaps I've missed
>> something.  The manpages are somewhat useful in showing what the user might
>> do, but they really don't help much in guiding the developer through these
>> details.
> That is not job of a manpage. See the rest of the code to get inspired.
>

Sure, we should all be able to poke through the code and figure out the 
basics - "use the Force, read the source" - but as software engineers we 
should be including some bits of documentation to help those new to the 
feature to steer away from pitfalls and use the feature correctly.  
We're all busy with our own projects and only have limited time to dig 
into and understand someone else's code; if there's not a guide, we'll 
do what we can to get it working and then move on, with no guarantee 
that we followed the original intent.

There's a Documentation page on the devlink-health feature, and a brief 
bit on devlink-params, but I haven't seen anything yet that spells out 
the "proper" way to use the devlink framework.  Of course, the 
open-source spirit is for me to scratch my own itch and take care of the 
need myself: I'd be happy to get a brief doc started, but if the 
original developers can take a few minutes to at least sketch some notes 
down about important bits like "the device struct should be associated 
with devlink_port" and why it should, then we have a chance at saving a 
lot of other people's time, and perhaps we can fill out the details 
correctly and not miss something important.

sln


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ