From: Robert P. J. Day <hidden> Date: 2018-08-26 11:57:42
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
========================================================================
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-08-26 23:03:28
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
From: Robert P. J. Day <hidden> Date: 2018-08-26 23:06:18
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
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
========================================================================
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-08-26 23:12:22
On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day wrote:
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
quoted
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
From: Robert P. J. Day <hidden> Date: 2018-08-26 23:16:41
On Sun, 26 Aug 2018, Andrew Lunn wrote:
On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day wrote:
quoted
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
quoted
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
========================================================================
From: Stephen Hemminger <stephen@networkplumber.org> Date: 2018-08-27 00:35:26
On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
"Robert P. J. Day" [off-list ref] wrote:
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
quoted
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.
From: Robert P. J. Day <hidden> Date: 2018-08-27 10:08:31
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
"Robert P. J. Day" [off-list ref] wrote:
quoted
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
quoted
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
========================================================================
From: Oliver Hartkopp <socketcan@hartkopp.net> Date: 2018-08-27 11:04:23
On 08/27/2018 08:20 AM, Robert P. J. Day wrote:
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
quoted
On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
"Robert P. J. Day" [off-list ref] wrote:
quoted
On Sun, 26 Aug 2018, Andrew Lunn wrote:
quoted
quoted
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
From: Robert P. J. Day <hidden> Date: 2018-08-27 11:52:51
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
========================================================================