netdev - Re: confusing comment, explanation of @IFF

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]

Date:   Mon, 27 Aug 2018 09:11:58 +0200
From:   Oliver Hartkopp <socketcan@...tkopp.net>
To:     "Robert P. J. Day" <rpjday@...shcourse.ca>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Linux kernel netdev mailing list <netdev@...r.kernel.org>
Subject: Re: confusing comment, explanation of @IFF_RUNNING in if.h

On 08/27/2018 08:20 AM, Robert P. J. Day wrote:
> On Sun, 26 Aug 2018, Stephen Hemminger wrote:
> 
>> On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
>> "Robert P. J. Day" <rpjday@...shcourse.ca> wrote:
>>
>>> On Sun, 26 Aug 2018, Andrew Lunn wrote:
>>>
>>>>>    i ask since, in my testing, when the interface should have been
>>>>> up, the attribute file "operstate" for that interface showed
>>>>> "unknown", and i wondered how worried i should be about that.
>>>>
>>>> Hi Robert
>>>>
>>>> You should probably post the driver for review. A well written
>>>> driver should not even need to care about any of this. phylib and
>>>> the netdev driver code does all the work. It only gets interesting
>>>> when you don't have a PHY, e.g. a stacked device, like bonding, or a
>>>> virtual device like tun/tap.
>>>
>>>    i wish, but i'm on contract, and proprietary, and NDA and all that.
>>> so i am reduced to crawling through the code, trying to figure out
>>> what is misconfigured that is causing all this grief.
>>>
>>> rday
>>>
>>
>> So you expect FOSS developers to help you with proprietary licensed
>> driver. Good Luck with that.
> 
>    sorry, i'm sure this will all be released upon production, just not
> while it's in the midst of development.

"released upon production" means usually:
Oh, we put that driver in a tar-ball on a CD that's shipped with the 
product and which will get no further visibility nor (security) maintenance.

Robert, please tell your manager that creating a driver is no rocket 
science and also brings no "costumer differentiation" which needs to be 
covered under NDA.

Posting drivers and bring it into mainline Linux heavily increases the 
quality due to the review process and all the people that are willing to 
help you to get better. At the end your driver gets long-term 
maintenance and other people can benefit from it - as your boss is 
getting benefit from using Linux right now.

When something is "released upon production" it will not be in a quality 
that it could go into the kernel - and no one will have the 
time/money/ambition to spend effort on it then. You have just produced 
one of the numerous dead out-of-tree drivers. That would be just sad.

Best regards,
Oliver