confusing comment, explanation of @IFF_RUNNING in if.h

confusing comment, explanation of @IFF_RUNNING in if.h

[Robert P. J. Day]

  more annoying pedantry ... from include/uapi/linux/if.h:

    * @IFF_RUNNING: interface RFC2863 OPER_UP. Volatile.

however, both the code in net/core/dev.c:

/**
 *      netif_oper_up - test if device is operational
 *      @dev: network device
 *
 * Check if carrier is operational
 */
static inline bool netif_oper_up(const struct net_device *dev)
{
        return (dev->operstate == IF_OPER_UP ||
                dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}

and the explanation in operstates.txt:

  ifinfomsg::if_flags & IFF_RUNNING:
    Interface is in RFC2863 operational state UP or UNKNOWN.

suggests IFF_RUNNING represents *either* of the operational states UP
or UNKNOWN, not just UP as the comment in if.h claims. is this
misleading? or is this a deliberate explanation somehow taking into
account that the UNKNOWN state is for backward compatibility (whatever
that means)?

  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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Andrew Lunn]

>   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.

     Andrew

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Robert P. J. Day]

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

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Andrew Lunn]

On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day 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.

I would say proprietary and NDA is causing you all this grief.

There is also the point that if you are not going to contribute the
code to mainline, why should we help you?

The code is GPL after all, so you can post it.

  Andrew

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Robert P. J. Day]

On Sun, 26 Aug 2018, Andrew Lunn wrote:

> On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day 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.
>
> I would say proprietary and NDA is causing you all this grief.
>
> There is also the point that if you are not going to contribute the
> code to mainline, why should we help you?
>
> The code is GPL after all, so you can post it.

  i'm confident that it will *eventually* be GPLed (i can't imagine
there is any other outcome), but for now, there's nothing i can do.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Stephen Hemminger]

On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
"Robert P. J. Day" <rpjday@crashcourse.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.

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Robert P. J. Day]

On Sun, 26 Aug 2018, Stephen Hemminger wrote:

> On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
> "Robert P. J. Day" <rpjday@crashcourse.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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Oliver Hartkopp]

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@crashcourse.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

Re: confusing comment, explanation of @IFF_RUNNING in if.h

[Robert P. J. Day]

On Mon, 27 Aug 2018, Oliver Hartkopp wrote:

> "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.

  i make these arguments on a regular basis with all of my clients
but, as a contractor, i have little influence. but i will continue to
make them.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================