Re: confusing comment, explanation of @IFF_RUNNING in if.h
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
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" 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
On Sun, 26 Aug 2018, Stephen Hemminger wrote: > On Sun, 26 Aug 2018 15:20:24 -0400 (EDT) > "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. > > > > 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
On Sun, 26 Aug 2018 15:20:24 -0400 (EDT) "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. > > 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
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
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
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
> 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
