FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-27-2011, 04:05 AM
Grant Edwards
 
Default Slightly OT but interesting nonetheless...

On 2011-09-27, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 09/26/11 16:13, Grant Edwards wrote:
>>
>> That's hilarious.
>>
>> The Linux developers are _constantly_ changing APIs in ways that break
>> existing device driver code. There are repeatedly wholesale
>> re-designs of some APIs that happen between minor versions of a
>> supposedly "stable" kernel.
>>
>> We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4
>> years. Often our Linux drivers have to be updated every 3-4 _months_
>> to keep up with changes in the kernel that break things.
>>
>> I suppose one could try to claim that people who ship Linux drivers
>> for their hardware aren't "users" of the kernel, and therefore our
>> dealing with such breakage isn't a "user experience".
>>
>
> Contribute your drivers upstream. When the devs change an API, they'll
> update your code for you.

That sounds good, but in practice it doesn't work.

1) The kernel developers don't support any existing customers. Bugs
are only fixed for customers who are willing to run the next
kernel verison. I've got customers that are still running 2.4
kernels. 2.6.18 is still widely used. Will the kernel developers
add new features, support for new hardware, or fix bugs for those
customers. Not a chance.

2) The kernel developers only make sure that drivers compile. They
don't have the hardware or knowlege required to actually test
them. One of our drivers _is_ in the kernel. Sure, it builds,
but AFAIK, it hasn't actually worked for at least 10 years.

Trying to maintain two drivers (one in-kernel and one out-of-kernel)
just creates twice as much work for no gain.

--
Grant
 
Old 09-27-2011, 07:45 AM
Mick
 
Default Slightly OT but interesting nonetheless...

On Monday 26 Sep 2011 23:21:56 Peter Humphrey wrote:
> On Monday 26 September 2011 22:45:20 Alan McKinnon wrote:
> > It's unrealistic to support everything you ever did forever
> > like MS tried to do (IE6 is *still* hanging around somehow...)
>
> Tell me about it! IE6 is the nastiest pain in the backside of any
> webmaster. I keep having to abandon pretty enhancements of my site because
> IE6 makes a mess of them.

You can use MSIE6 conditional statements in your html to feed this muppet what
ever stripped down code it will be able to render in terms of CSS and images.
--
Regards,
Mick
 
Old 09-27-2011, 04:52 PM
Volker Armin Hemmann
 
Default Slightly OT but interesting nonetheless...

Am Montag 26 September 2011, 20:13:53 schrieb Grant Edwards:
> On 2011-09-26, Michael Mol <mikemol@gmail.com> wrote:
> > On Mon, Sep 26, 2011 at 3:37 PM, pk <peterk2@coolmail.se> wrote:
> >> Hi,
> >>
> >> Happened upon this interview with Linus Torvalds that some of you
> >> might
> >> find interesting (if you haven't seen it already):
> >>
> >> http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons
> >> -on-Software-Development-Management/ba-p/440>
> > Yeah, I just saw that. Admittedly, when I saw this section:
> >
> > --begin-section--
>
> [...]
>
> > Breaking the user experience in order to ???fix??? something
> > is a totally broken concept; you cannot do it.
>
> That's hilarious.
>
> The Linux developers are _constantly_ changing APIs in ways that break
> existing device driver code. There are repeatedly wholesale
> re-designs of some APIs that happen between minor versions of a
> supposedly "stable" kernel.

which is seriously not a problem and does not matter in the slightest.

They NEVER change user-space APIs and ABIs in incompatible ways. THAT is
important.

>
> We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4
> years.

and look how much devices they drive - because nobody has to send their
drivers upstream, nobody does.

> Often our Linux drivers have to be updated every 3-4 _months_
> to keep up with changes in the kernel that break things.

which is your own fucking fault.

Get your drivers into the kernel. Problem solved.

--
#163933
 
Old 09-27-2011, 04:54 PM
Volker Armin Hemmann
 
Default Slightly OT but interesting nonetheless...

Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards:
> On 2011-09-27, Michael Orlitzky <michael@orlitzky.com> wrote:
> > On 09/26/11 16:13, Grant Edwards wrote:
> >> That's hilarious.
> >>
> >> The Linux developers are _constantly_ changing APIs in ways that break
> >> existing device driver code. There are repeatedly wholesale
> >> re-designs of some APIs that happen between minor versions of a
> >> supposedly "stable" kernel.
> >>
> >> We have to touch our NetBSD and FreeBSD drivers maybe once every 3-4
> >> years. Often our Linux drivers have to be updated every 3-4 _months_
> >> to keep up with changes in the kernel that break things.
> >>
> >> I suppose one could try to claim that people who ship Linux drivers
> >> for their hardware aren't "users" of the kernel, and therefore our
> >> dealing with such breakage isn't a "user experience".
> >
> > Contribute your drivers upstream. When the devs change an API, they'll
> > update your code for you.
>
> That sounds good, but in practice it doesn't work.
>
> 1) The kernel developers don't support any existing customers. Bugs
> are only fixed for customers who are willing to run the next
> kernel verison. I've got customers that are still running 2.4
> kernels. 2.6.18 is still widely used. Will the kernel developers
> add new features, support for new hardware, or fix bugs for those
> customers. Not a chance.

so what? There are long term stable kernels with no api changes. Hmm...

>
> 2) The kernel developers only make sure that drivers compile. They
> don't have the hardware or knowlege required to actually test
> them. One of our drivers _is_ in the kernel. Sure, it builds,
> but AFAIK, it hasn't actually worked for at least 10 years.

and nobody complains on lkml about it - seems that nobody uses your hardware.

If something stops working (called a 'regression' btw) it has to be fixed.
Linus is very clear about that.

>
> Trying to maintain two drivers (one in-kernel and one out-of-kernel)
> just creates twice as much work for no gain.

then don't be outside the kernel.

--
#163933
 
Old 09-27-2011, 05:03 PM
Michael Orlitzky
 
Default Slightly OT but interesting nonetheless...

On 09/27/11 00:05, Grant Edwards wrote:
>>
>> Contribute your drivers upstream. When the devs change an API, they'll
>> update your code for you.
>
> That sounds good, but in practice it doesn't work.
>
> 1) The kernel developers don't support any existing customers. Bugs
> are only fixed for customers who are willing to run the next
> kernel verison. I've got customers that are still running 2.4
> kernels. 2.6.18 is still widely used. Will the kernel developers
> add new features, support for new hardware, or fix bugs for those
> customers. Not a chance.

If your users don't upgrade their kernel, then the API doesn't change,
and there's no problem for these customers, right?


> 2) The kernel developers only make sure that drivers compile. They
> don't have the hardware or knowlege required to actually test
> them. One of our drivers _is_ in the kernel. Sure, it builds,
> but AFAIK, it hasn't actually worked for at least 10 years.
>
> Trying to maintain two drivers (one in-kernel and one out-of-kernel)
> just creates twice as much work for no gain.
>

So (assuming the devs do break your stuff occasionally) you have to test
and possibly fix at least one driver whenever the API changes. I see a
few options:

1) Test/fix one driver, in-kernel (less work)
2) Test/fix one driver, out-of-kernel (more work)
3) Test/fix two drivers, one in- and one out-of-kernel (most work)

In any case, even if I'm wrong about the amount of work involved, it
would be nicer for your customers if they didn't have to ask your
permission to upgrade the kernel.
 
Old 09-27-2011, 05:07 PM
Michael Mol
 
Default Slightly OT but interesting nonetheless...

On Tue, Sep 27, 2011 at 12:54 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards:
>> That sounds good, but in practice it doesn't work.
>>
>> *1) The kernel developers don't support any existing customers. *Bugs
>> * * are only fixed for customers who are willing to run the next
>> * * kernel verison. *I've got customers that are still running 2.4
>> * * kernels. 2.6.18 is still widely used. *Will the kernel developers
>> * * add new features, support for new hardware, or fix bugs for those
>> * * customers. *Not a chance.
>
> so what? There are long term stable kernels with no api changes. Hmm...

Except they have drivers which are buggy and require backported fixes.

>> *2) The kernel developers only make sure that drivers compile. *They
>> * * don't have the hardware or knowlege required to actually test
>> * * them. *One of our drivers _is_ in the kernel. *Sure, it builds,
>> * * but AFAIK, it hasn't actually worked for at least 10 years.
>
> and nobody complains on lkml about it - seems that nobody uses your hardware.

Except his customers. Who are going directly to him for support.

> If something stops working (called a 'regression' btw) it has to be fixed.
> Linus is very clear about that.

That's all well and good, but it doesn't fix things that weren't
working correctly in the first place. Upstream kernel doesn't backport
fixes, that's what distros and people like Grant, for their customers.

And Linus's statement as quoted in that article (and my snippet)
doesn't include one important caveat: Sometimes, they drop support for
things that either have no maintainer, or are obsolete and difficult
to keep.

>> Trying to maintain two drivers (one in-kernel and one out-of-kernel)
>> just creates twice as much work for no gain.
>
> then don't be outside the kernel.

If we take your position, in this context, to its logical outcome, it
sounds like you're saying that distributions like Gentoo, Red Hat and
Debian shouldn't maintain older kernels with backported fixes.

There exist systems which cannot be upgraded with financial sanity;
the existing install works well enough that it would cost more to
upgrade. The reasons might be that they're using an old software
package which was abandoned, and taking ownership of the code isn't
always sane. I was actually approached by someone in my area a couple
weeks ago who was in just this kind of scenario.

--
:wq
 
Old 09-27-2011, 05:10 PM
Mark Knecht
 
Default Slightly OT but interesting nonetheless...

On Mon, Sep 26, 2011 at 9:05 PM, Grant Edwards
<grant.b.edwards@gmail.com> wrote:
<SNIP>
>> Contribute your drivers upstream. When the devs change an API, they'll
>> update your code for you.
>
> That sounds good, but in practice it doesn't work.
>
> *1) The kernel developers don't support any existing customers. *Bugs
> * *are only fixed for customers who are willing to run the next
> * *kernel verison. *I've got customers that are still running 2.4
> * *kernels. 2.6.18 is still widely used. *Will the kernel developers
> * *add new features, support for new hardware, or fix bugs for those
> * *customers. *Not a chance.
>

Grant,
Check out the Long Term Stable family of kernels. It's a bit hard
right now due to the status of the kernel web site being
down/changing. However you can see here at Andi Kleen's blog that he's
interested in participation:

http://halobates.de/blog/p/38

I know from watching the lkml list over the years that updates to long
term stable kernels come out periodically and do include fixes. I
don't know about new drivers, but reading Andi's blog it seems he's
potentially open to receiving driver updates from folks interested in
having the driver included.

Hope this helps,
Mark
 
Old 09-27-2011, 05:22 PM
Volker Armin Hemmann
 
Default Slightly OT but interesting nonetheless...

Am Dienstag 27 September 2011, 13:07:02 schrieb Michael Mol:
> On Tue, Sep 27, 2011 at 12:54 PM, Volker Armin Hemmann
>
> <volkerarmin@googlemail.com> wrote:
> > Am Dienstag 27 September 2011, 04:05:31 schrieb Grant Edwards:
> >> That sounds good, but in practice it doesn't work.
> >>
> >> 1) The kernel developers don't support any existing customers. Bugs
> >> are only fixed for customers who are willing to run the next
> >> kernel verison. I've got customers that are still running 2.4
> >> kernels. 2.6.18 is still widely used. Will the kernel developers
> >> add new features, support for new hardware, or fix bugs for those
> >> customers. Not a chance.
> >
> > so what? There are long term stable kernels with no api changes. Hmm...
>
> Except they have drivers which are buggy and require backported fixes.

and that is the reason stable series exist. They are stable and they backport
fixes. Exclusively.

>
> >> 2) The kernel developers only make sure that drivers compile. They
> >> don't have the hardware or knowlege required to actually test
> >> them. One of our drivers _is_ in the kernel. Sure, it builds,
> >> but AFAIK, it hasn't actually worked for at least 10 years.
> >
> > and nobody complains on lkml about it - seems that nobody uses your
> > hardware.
> Except his customers. Who are going directly to him for support.
>
> > If something stops working (called a 'regression' btw) it has to be
> > fixed. Linus is very clear about that.
>
> That's all well and good, but it doesn't fix things that weren't
> working correctly in the first place. Upstream kernel doesn't backport
> fixes, that's what distros and people like Grant, for their customers.

wrong, long time stable series do backport fixes. That is the reason they
exist in the first place.

>
> And Linus's statement as quoted in that article (and my snippet)
> doesn't include one important caveat: Sometimes, they drop support for
> things that either have no maintainer, or are obsolete and difficult
> to keep.

and when they do that they warn everybody for years (just look up binary
sysctl support as a prime example).

>
> >> Trying to maintain two drivers (one in-kernel and one out-of-kernel)
> >> just creates twice as much work for no gain.
> >
> > then don't be outside the kernel.
>
> If we take your position, in this context, to its logical outcome, it
> sounds like you're saying that distributions like Gentoo, Red Hat and
> Debian shouldn't maintain older kernels with backported fixes.

no, but if you decide on one kernel you should use one of the long term
supported one. Not 2.6.something-because-I-like-the-number.

>
> There exist systems which cannot be upgraded with financial sanity;
> the existing install works well enough that it would cost more to
> upgrade.

so don't touch the kernel. Wow, that was hard. I think I need something to eat
now. Hmmm... noodles....

> The reasons might be that they're using an old software
> package which was abandoned, and taking ownership of the code isn't
> always sane. I was actually approached by someone in my area a couple
> weeks ago who was in just this kind of scenario.

and if the system just works - why touch it at all?

--
#163933
 
Old 09-27-2011, 05:43 PM
Michael Mol
 
Default Slightly OT but interesting nonetheless...

On Tue, Sep 27, 2011 at 1:22 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am Dienstag 27 September 2011, 13:07:02 schrieb Michael Mol:
>> Except they have drivers which are buggy and require backported fixes.
>
> and that is the reason stable series exist. They are stable and they backport
> fixes. Exclusively.

I hadn't even heard of these until Mark's email 20 minutes ago. It's
useful information. You might have saved us some arguing if you'd
presented it more specific and in an explanatory fashion, rather than
dropping a noun and assuming it was specifically known. I assumed you
meant the kernels maintained by distributions. Obviously, I was wrong,
but Mark's email cleared that up for me.

>
>> The reasons might be that they're using an old software
>> package which was abandoned, and taking ownership of the code isn't
>> always sane. I was actually approached by someone in my area a couple
>> weeks ago who was in just this kind of scenario.
>
> and if the system just works - why touch it at all?

Because, in this case, the hardware, which is unreplaceable, went tits
up. Meaning it no longer works. It can't be replaced, and they're SOL
until they get the software ported forward. Their remaining hardware
of the same vintage had already died on them, and they didn't have any
migration path or hedge set up.

Other reasons--and this is why I *loathe* unnuanced "if it works,
don't touch it" mentalities--include security updates and migration
difficulty in the event of *necessity* of upgrades.

I know someone who's running Ubuntu 7.10 on a server that accepts
incoming, public connections--because they got it working, and didn't
even want to update to the Ubuntu 8.04 LTS, because of a "if it just
works, why touch it at all?" mentality. Eventually, they _will_ be
hacked as a consequence, even if it's just from someone scanning the
public IPv4 space with tools looking for vulnerable versions of
software.

The other general class of cases is something Gentoo users should be
able to understand in the abstract; the longer you go without
updating, the more difficult and expensive (in terms of time fixing
incompatibilities from un{tested,supported} version jumps, at the very
least) it becomes when you no longer have a choice.

--
:wq
 
Old 09-27-2011, 06:24 PM
Mark Knecht
 
Default Slightly OT but interesting nonetheless...

On Tue, Sep 27, 2011 at 10:43 AM, Michael Mol <mikemol@gmail.com> wrote:
<SNIP>
>
> Because, in this case, the hardware, which is unreplaceable, went tits
> up. Meaning it no longer works. It can't be replaced, and they're SOL
> until they get the software ported forward. Their remaining hardware
> of the same vintage had already died on them, and they didn't have any
> migration path or hedge set up.
>
> Other reasons--and this is why I *loathe* unnuanced "if it works,
> don't touch it" mentalities--include security updates and migration
> difficulty in the event of *necessity* of upgrades.
>

I sympathize with the hardware dieing, but one could argue (IMHO
anyway) that that is as much a management problem on their part, or
those supporting them, as it is an issue with the kernel. If someone
is running a system which is critical and isn't planing for how to get
new copies of the system or move forward to new hardware over time,
then they are painted into a corner.

I can pretty much promise you that one area likely to get LOTS of
attention in this kernel series IS security updates, at least if they
are kernel based security issues. That a major reason, if not the #1
reason, that this series of kernels exists.

HTH,
Mark
 

Thread Tools




All times are GMT. The time now is 09:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org