Linux 2.6.16.30-pre1

Linux 2.6.16.30-pre1

[Adrian Bunk]

Patch location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/

git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git

RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss


Changes since 2.6.16.29:

Adrian Bunk:
      V4L/DVB: Saa7134: document that there's also a 220RF from KWorld
      add drivers/media/video/saa7134/saa7134-input.c:flydvb_codes
      Linux 2.6.16.30-pre1

Andrew Burri:
      V4L/DVB: Add support for Kworld ATSC110

Curt Meyers:
      V4L/DVB: KWorld ATSC110: implement set_pll_input
      V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
      V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load

Giampiero Giancipoli:
      V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card

Hartmut Hackmann:
      V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
      V4L/DVB: Added PCI IDs of 2 LifeView Cards
      V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
      V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
      V4L/DVB: TDA10046 Driver update
      V4L/DVB: TDA8290 update

Peter Hartshorn:
      V4L/DVB: Added support for the Tevion DVB-T 220RF card

Henk Vergonet:
      USB: Fix unload oops and memory leak in yealink driver
      USB: add YEALINK phones to the HID_QUIRK_IGNORE blacklist

Jay Cliburn:
      via-velocity: fix speed and link status reported by ethtool

Jose Alberto Reguero:
      V4L/DVB: Add support for the Avermedia 777 DVB-T card

Julien Tous:
      [AGPGART] ATI RS350 support.

Magnus Kessler:
      [AGPGART] VIA PT880 Ultra support.

Mark M. Hoffman:
      I2C: fix 'ignore' module parameter handling

Martin Schwidefsky:
      kernel/kmod.c: fix a race condition in usermodehelper.

maximilian attems:
      V4L/DVB: Saa7134: select FW_LOADER

Michael Krufky:
      V4L/DVB: Kworld ATSC110: cleanups
      V4L/DVB: Saa7134: make unsupported secondary decoder message generic
      V4L/DVB: Medion 7134: Autodetect second bridge chip

Michael Rash:
      [TEXTSEARCH]: Fix Boyer Moore initialization bug

Rickard Osser:
      V4L/DVB: Saa7134: add support for AVerMedia A169 Dual Analog tuner card

Roland Dreier:
      Convert idr's internal locking to _irqsave variant

Roy Marples:
      via-velocity: the link is not correctly detected when the device starts

Tamuki Shoichi:
      V4L/DVB: Add saa713x card: ELSA EX-VISION 700TV (saa7130)
      V4L/DVB: ELSA EX-VISION 700TV: fix incorrect PCI subsystem ID

Tushar Gohad:
      PFKEYV2: Fix inconsistent typing in struct sadb_x_kmprivate.

Re: Linux 2.6.16.30-pre1

[Greg KH]

On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> Andrew Burri:
>       V4L/DVB: Add support for Kworld ATSC110
> 
> Curt Meyers:
>       V4L/DVB: KWorld ATSC110: implement set_pll_input
>       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
>       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> 
> Giampiero Giancipoli:
>       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> 
> Hartmut Hackmann:
>       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
>       V4L/DVB: Added PCI IDs of 2 LifeView Cards
>       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
>       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
>       V4L/DVB: TDA10046 Driver update
>       V4L/DVB: TDA8290 update
> 
> Peter Hartshorn:
>       V4L/DVB: Added support for the Tevion DVB-T 220RF card

Hm, all of these patches seems like these are new features being
backported to the 2.6.16.y kernel, which is not really allowed under the
current -stable rules.

Or are these patches just bugfixes that fix with the current -stable
rules?

thanks,

greg k-h

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > Andrew Burri:
> >       V4L/DVB: Add support for Kworld ATSC110
> > 
> > Curt Meyers:
> >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > 
> > Giampiero Giancipoli:
> >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > 
> > Hartmut Hackmann:
> >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> >       V4L/DVB: TDA10046 Driver update
> >       V4L/DVB: TDA8290 update
> > 
> > Peter Hartshorn:
> >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> 
> Hm, all of these patches seems like these are new features being
> backported to the 2.6.16.y kernel, which is not really allowed under the
> current -stable rules.
> 
> Or are these patches just bugfixes that fix with the current -stable
> rules?

They add support for additional hardware to the saa7134 driver.

If you look at the actual diff there's not much that could cause any 
regression since nearly all of these change don't change anything for 
the already supported cards.

As long as there's not a serious risk of regressions, such additions are 
welcome in 2.6.16.

"is not really allowed under the current -stable rules" is a bit hard to 
answer, but considering that "Missing PCI id update for VIA IDE" was OK 
for 2.6.17.12 I'd say it's consistent with what you are doing.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Greg KH]

On Sat, Sep 23, 2006 at 12:47:35AM +0200, Adrian Bunk wrote:
> On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> > On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > > Andrew Burri:
> > >       V4L/DVB: Add support for Kworld ATSC110
> > > 
> > > Curt Meyers:
> > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > 
> > > Giampiero Giancipoli:
> > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > 
> > > Hartmut Hackmann:
> > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > >       V4L/DVB: TDA10046 Driver update
> > >       V4L/DVB: TDA8290 update
> > > 
> > > Peter Hartshorn:
> > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > 
> > Hm, all of these patches seems like these are new features being
> > backported to the 2.6.16.y kernel, which is not really allowed under the
> > current -stable rules.
> > 
> > Or are these patches just bugfixes that fix with the current -stable
> > rules?
> 
> They add support for additional hardware to the saa7134 driver.

That's not a bugfix.

> If you look at the actual diff there's not much that could cause any 
> regression since nearly all of these change don't change anything for 
> the already supported cards.

I'm not disagreeing about the regression issue.  I'm just concerned
because you are starting down the slope of "backporting new driver
support" to the 2.6.16 tree, and that's something that I thought you did
not want to do.

But if it is, let us know, and we can discuss it.

> As long as there's not a serious risk of regressions, such additions are 
> welcome in 2.6.16.

Are you sure?  That really goes against the -stable rules as we
originally set them out to be.

If you want to accept new drivers and backports like this, I think you
will find it very hard to determine what to say yes or no to in the
future.  It's the main problem that everyone who has tried to maintain a
stable tree has run into, that is why we set up the -stable rules to be
what they are for that very reason.

> "is not really allowed under the current -stable rules" is a bit hard to 
> answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> for 2.6.17.12 I'd say it's consistent with what you are doing.

That was a bugfix as the driver could not access that device without
that fix.  Just adding a device id is not something that we normally
will take, as that is what the sysfs "newid" is for.  That patch was
obviously something else.

thanks,

greg k-h

Re: Linux 2.6.16.30-pre1

[Willy Tarreau]

Hi Greg, Hi Adrian,

On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:

> If you want to accept new drivers and backports like this, I think you
> will find it very hard to determine what to say yes or no to in the
> future.  It's the main problem that everyone who has tried to maintain a
> stable tree has run into, that is why we set up the -stable rules to be
> what they are for that very reason.

When I started the 2.4-hotfix tree nearly two years ago, I wanted to
avoid merging drivers changes as much as possible. And particularly,
I avoided to add support for new hardware. The reason is very simple.
I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
does too so that they can blindly upgrade. And if, for any reason,
people suspect that 2.4.X.Y might have brought a bug, then reverting
to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
previous support for any hardware. The problem with new hardware
support is that it can break sensible setups :

  - adding a new network card support will cause existing cards to be
    renumberred (it happened to me on several production systems when
    switching from 2.2 to 2.4)

  - adding support for a new IDE controller can cause hda to become
    hdc, or worse, hda to become sda (problems encountered when adding
    libata support)

  - enabling some devices might lock up memory and/or I/O address ranges
    on a bus leading to other devices not working anymore. I had this
    problem when using dlink 580 quad port nics in some buggy machines
    already equipped with adaptec starfire nics.

  - other core devices might cause system instability without the
    admin being aware they're really used (eg: ACPI, ...)

Since hardware diversity is so high that nobody can know everything, I
think it's better to avoid playing alone with people's hardware, but I
agree it's sometimes very hard to resist.

Adrian, when you have a doubt whether such a fix should go into next
release, simply tell people about the problem and ask them to test
current driver. If nobody encounters the problem, you can safely keep
the patch in your fridge until someone complains. By that time, the
risks associated with this patch will be better known.

> > "is not really allowed under the current -stable rules" is a bit hard to 
> > answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> > for 2.6.17.12 I'd say it's consistent with what you are doing.
> 
> That was a bugfix as the driver could not access that device without
> that fix.

Even this might be dangerous in late -stable releases, unless it was a
recent regression.

Just my 2 cents,
Willy

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> Hi Greg, Hi Adrian,
> 
> On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> 
> > If you want to accept new drivers and backports like this, I think you
> > will find it very hard to determine what to say yes or no to in the
> > future.  It's the main problem that everyone who has tried to maintain a
> > stable tree has run into, that is why we set up the -stable rules to be
> > what they are for that very reason.
> 
> When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> avoid merging drivers changes as much as possible. And particularly,
> I avoided to add support for new hardware. The reason is very simple.
> I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> does too so that they can blindly upgrade.

Bugfixes causing regressions are much more likely than new hardware 
support adding regressions.

> And if, for any reason,
> people suspect that 2.4.X.Y might have brought a bug, then reverting
> to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> previous support for any hardware.

Either you want to use the newly supported hardware or you don't want to 
use it.

In any case, I don't see your point.

> The problem with new hardware
> support is that it can break sensible setups :
> 
>   - adding a new network card support will cause existing cards to be
>     renumberred (it happened to me on several production systems when
>     switching from 2.2 to 2.4)
> 
>   - adding support for a new IDE controller can cause hda to become
>     hdc, or worse, hda to become sda (problems encountered when adding
>     libata support)

I don't consider merging any patches that could cause the sda problem.

People not using the onboard IDE controller but a different controller, 
but OTOH having the driver for their onboard controller enabled in their 
kernel really sounds like a strange case.

>   - enabling some devices might lock up memory and/or I/O address ranges
>     on a bus leading to other devices not working anymore. I had this
>     problem when using dlink 580 quad port nics in some buggy machines
>     already equipped with adaptec starfire nics.
> 
>   - other core devices might cause system instability without the
>     admin being aware they're really used (eg: ACPI, ...)
> 
> Since hardware diversity is so high that nobody can know everything, I
> think it's better to avoid playing alone with people's hardware, but I
> agree it's sometimes very hard to resist.
> 
> Adrian, when you have a doubt whether such a fix should go into next
> release, simply tell people about the problem and ask them to test
> current driver. If nobody encounters the problem, you can safely keep
> the patch in your fridge until someone complains. By that time, the
> risks associated with this patch will be better known.

It's not that I wanted to upgrade ACPI to the latest version.

And my rules are:
- patch must be in Linus' tree
- I'm asking the patch authors and maintainers of the affected subsystem
  whether the patch is OK for 2.6.16

> > > "is not really allowed under the current -stable rules" is a bit hard to 
> > > answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> > > for 2.6.17.12 I'd say it's consistent with what you are doing.
> > 
> > That was a bugfix as the driver could not access that device without
> > that fix.
> 
> Even this might be dangerous in late -stable releases, unless it was a
> recent regression.

It was a case that never worked before.

> Just my 2 cents,
> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Willy Tarreau]

On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > Hi Greg, Hi Adrian,
> > 
> > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > 
> > > If you want to accept new drivers and backports like this, I think you
> > > will find it very hard to determine what to say yes or no to in the
> > > future.  It's the main problem that everyone who has tried to maintain a
> > > stable tree has run into, that is why we set up the -stable rules to be
> > > what they are for that very reason.
> > 
> > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > avoid merging drivers changes as much as possible. And particularly,
> > I avoided to add support for new hardware. The reason is very simple.
> > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > does too so that they can blindly upgrade.
> 
> Bugfixes causing regressions are much more likely than new hardware 
> support adding regressions.
> 
> > And if, for any reason,
> > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > previous support for any hardware.
> 
> Either you want to use the newly supported hardware or you don't want to 
> use it.
> 
> In any case, I don't see your point.

The problem is when some hardware suddenly become detected and assigned
in the middle of a stable release. Do not forget that people need stable
releases to be able to blindly update and get their security vulnerabilities
fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
adding the PCI ID of some new ethernet cards that were not supported may
lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
This causes real trouble to admins, particularly those doing remote
updates. At least, I think that if you manage to inform people clearly
enough, and to separate security fixes and such fixes in distinct releases,
it might work in most situations. But this is a dangerous game anyway.

> > The problem with new hardware
> > support is that it can break sensible setups :
> > 
> >   - adding a new network card support will cause existing cards to be
> >     renumberred (it happened to me on several production systems when
> >     switching from 2.2 to 2.4)
> > 
> >   - adding support for a new IDE controller can cause hda to become
> >     hdc, or worse, hda to become sda (problems encountered when adding
> >     libata support)
> 
> I don't consider merging any patches that could cause the sda problem.
> 
> People not using the onboard IDE controller but a different controller, 
> but OTOH having the driver for their onboard controller enabled in their 
> kernel really sounds like a strange case.

No, this one is common, it's the reverse which is uncommon. Think about it.
You buy a mobo, you discover that the onboard SATA is not supported, you add
a new controller but do not disable the old one in case you have time to
perform more tests.

Anyway, the case above was even not that. It was simply that if the shiny
new sata_piix driver detected the sata controller, it would then steal the
resources first, preventing ata_piix from registering.

Cheers,
Willy

Re: Linux 2.6.16.30-pre1

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

On Sun, 24 Sep 2006 01:53:15 +0200 Willy Tarreau wrote:

> The problem is when some hardware suddenly become detected and assigned
> in the middle of a stable release. Do not forget that people need stable
> releases to be able to blindly update and get their security vulnerabilities
> fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
> adding the PCI ID of some new ethernet cards that were not supported may
> lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
> This causes real trouble to admins, particularly those doing remote
> updates. At least, I think that if you manage to inform people clearly
> enough, and to separate security fixes and such fixes in distinct releases,
> it might work in most situations. But this is a dangerous game anyway.

Seems that the V4L/DVB patches in question are safe in this regard.
These patches add PCI table entries matching the specific subsystem ids;
without these entries the device will still match the default entry for
the chip, and the user will get the same /dev/videoN, but most likely it
won't work correctly.

The only problem which might arise is with additional IR input devices,
but no one should expect any stable ordering there - with USB the order
of input devices is already random.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sun, Sep 24, 2006 at 01:53:15AM +0200, Willy Tarreau wrote:
> On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> > On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > > Hi Greg, Hi Adrian,
> > > 
> > > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > > 
> > > > If you want to accept new drivers and backports like this, I think you
> > > > will find it very hard to determine what to say yes or no to in the
> > > > future.  It's the main problem that everyone who has tried to maintain a
> > > > stable tree has run into, that is why we set up the -stable rules to be
> > > > what they are for that very reason.
> > > 
> > > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > > avoid merging drivers changes as much as possible. And particularly,
> > > I avoided to add support for new hardware. The reason is very simple.
> > > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > > does too so that they can blindly upgrade.
> > 
> > Bugfixes causing regressions are much more likely than new hardware 
> > support adding regressions.
> > 
> > > And if, for any reason,
> > > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > > previous support for any hardware.
> > 
> > Either you want to use the newly supported hardware or you don't want to 
> > use it.
> > 
> > In any case, I don't see your point.
> 
> The problem is when some hardware suddenly become detected and assigned
> in the middle of a stable release. Do not forget that people need stable
> releases to be able to blindly update and get their security vulnerabilities
> fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
> adding the PCI ID of some new ethernet cards that were not supported may
> lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
> This causes real trouble to admins, particularly those doing remote
> updates. At least, I think that if you manage to inform people clearly
> enough, and to separate security fixes and such fixes in distinct releases,
> it might work in most situations. But this is a dangerous game anyway.

It seems we do not always agree.  ;-)

I did consider gcc 4 support in kernel 2.4 more dangerous and you do 
consider this more dangerous than I do.

I can always be proved wrong by getting reports from people that I broke 
their setups. If you know someone whose setup I broke, please tell him 
to inform me about this fact.

That zero feedback is good feedback is my experience since the times 
when I offered packages to run kernel 2.4 on Debian 2.2, and later 
packages to run kernel 2.6 on Debian 3.0 - I got almost zero feedback 
except for the one time when an update removed /etc/services ...

> > > The problem with new hardware
> > > support is that it can break sensible setups :
> > > 
> > >   - adding a new network card support will cause existing cards to be
> > >     renumberred (it happened to me on several production systems when
> > >     switching from 2.2 to 2.4)
> > > 
> > >   - adding support for a new IDE controller can cause hda to become
> > >     hdc, or worse, hda to become sda (problems encountered when adding
> > >     libata support)
> > 
> > I don't consider merging any patches that could cause the sda problem.
> > 
> > People not using the onboard IDE controller but a different controller, 
> > but OTOH having the driver for their onboard controller enabled in their 
> > kernel really sounds like a strange case.
> 
> No, this one is common, it's the reverse which is uncommon. Think about it.
> You buy a mobo, you discover that the onboard SATA is not supported, you add
> a new controller but do not disable the old one in case you have time to
> perform more tests.
> 
> Anyway, the case above was even not that. It was simply that if the shiny
> new sata_piix driver detected the sata controller, it would then steal the
> resources first, preventing ata_piix from registering.

I know that ATA is an area that requires extra care (and I don't plan 
any big updates in this area).

But having:
- two saa7134 cards in your computer and
- one of them formerly not supported and
- depending on one of them being the first one
is a case you can theoretically construct, but then there's the point 
that this is highly unlikely, and OTOH the value of the added support is 
more realistic.

If I was as extremely regarding regressions as you describe regarding 
hardware updates, I would also have to reject any bugfixes that are not 
security fixes since they might cause regressions.

I do know that the only value of the 2.6.16 tree lies in a lack of 
regressions and act accordingly, but I'm trying to do this in a 
pragmatic way.

> Cheers,
> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Stefan Richter]

Adrian Bunk wrote:
> But having:
> - two saa7134 cards in your computer and
> - one of them formerly not supported and
> - depending on one of them being the first one
> is a case you can theoretically construct, but then there's the point 
> that this is highly unlikely,

Yes, this is an unlikely scenario.

> and OTOH the value of the added support is more realistic.

But then I think people don't really expect additional hardware support
from a stable kernel series.

> If I was as extremely regarding regressions as you describe regarding 
> hardware updates, I would also have to reject any bugfixes that are not 
> security fixes since they might cause regressions.
> 
> I do know that the only value of the 2.6.16 tree lies in a lack of 
> regressions and act accordingly, but I'm trying to do this in a 
> pragmatic way.

If there was more manpower, driver updates could be maintained as extra
patchkits separately to the kernel. I know that some people would like
to have exactly this: A minimally updated base plus a choice of specific
driver updates as add-ons.

In fact that's what I do with the IEEE 1394 drivers --- although not
primarily to support this kind of user base but rather to make it easier
to get bugfixes tested by bug reporters. However I can only afford to do
this by an all-or-nothing approach: I put almost _all_ driver changes
into these patchkits. That means full risk of regressions but also
complete feature updates and minimal divergence from mainline. This was
trivial to do so far.
-- 
Stefan Richter
-=====-=-==- =--= ==---
http://arcgraph.de/sr/

Re: Linux 2.6.16.30-pre1

[Willy Tarreau]

On Sun, Sep 24, 2006 at 09:46:17PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > But having:
> > - two saa7134 cards in your computer and
> > - one of them formerly not supported and
> > - depending on one of them being the first one
> > is a case you can theoretically construct, but then there's the point 
> > that this is highly unlikely,
> 
> Yes, this is an unlikely scenario.
> 
> > and OTOH the value of the added support is more realistic.
> 
> But then I think people don't really expect additional hardware support
> from a stable kernel series.
> 
> > If I was as extremely regarding regressions as you describe regarding 
> > hardware updates, I would also have to reject any bugfixes that are not 
> > security fixes since they might cause regressions.
> > 
> > I do know that the only value of the 2.6.16 tree lies in a lack of 
> > regressions and act accordingly, but I'm trying to do this in a 
> > pragmatic way.
> 
> If there was more manpower, driver updates could be maintained as extra
> patchkits separately to the kernel. I know that some people would like
> to have exactly this: A minimally updated base plus a choice of specific
> driver updates as add-ons.

If there was more manpower, the same principle as I adopted for the
2.4-hotfix series would be applicable :

  - maintain multiple older versions in parallel
  - only apply critical fixes.

=> That way, people choose the version they will work with based on a
   feature set, and they benefit from fixes only. But this is an ideal
   world, and as Greg told us (and demonstrated), 2.6 is moving too fast
   to permit the maintenance of multiple branches in parallel. We won't
   clone Adrian for every new 2.6 which comes out :-)

However, I noticed (in 2.4) that raising the patch acceptance threshold
for a hotfix reduces the conflicts between versions and reduces the
amount of work needed to maintain multiple versions in parallel. I have
only 192 patches to cover all identified fixes between 2.4.28 and 2.4.33
and only one or two of them did require manual merging for old versions.
Anyway, this is still boring work.

> In fact that's what I do with the IEEE 1394 drivers --- although not
> primarily to support this kind of user base but rather to make it easier
> to get bugfixes tested by bug reporters. However I can only afford to do
> this by an all-or-nothing approach: I put almost _all_ driver changes
> into these patchkits. That means full risk of regressions but also
> complete feature updates and minimal divergence from mainline. This was
> trivial to do so far.
> -- 
> Stefan Richter
> -=====-=-==- =--= ==---
> http://arcgraph.de/sr/

Regards,
Willy

Re: Linux 2.6.16.30-pre1

[Willy Tarreau]

On Sun, Sep 24, 2006 at 08:16:41PM +0200, Adrian Bunk wrote:
> On Sun, Sep 24, 2006 at 01:53:15AM +0200, Willy Tarreau wrote:
> > On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> > > On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > > > Hi Greg, Hi Adrian,
> > > > 
> > > > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > > > 
> > > > > If you want to accept new drivers and backports like this, I think you
> > > > > will find it very hard to determine what to say yes or no to in the
> > > > > future.  It's the main problem that everyone who has tried to maintain a
> > > > > stable tree has run into, that is why we set up the -stable rules to be
> > > > > what they are for that very reason.
> > > > 
> > > > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > > > avoid merging drivers changes as much as possible. And particularly,
> > > > I avoided to add support for new hardware. The reason is very simple.
> > > > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > > > does too so that they can blindly upgrade.
> > > 
> > > Bugfixes causing regressions are much more likely than new hardware 
> > > support adding regressions.
> > > 
> > > > And if, for any reason,
> > > > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > > > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > > > previous support for any hardware.
> > > 
> > > Either you want to use the newly supported hardware or you don't want to 
> > > use it.
> > > 
> > > In any case, I don't see your point.
> > 
> > The problem is when some hardware suddenly become detected and assigned
> > in the middle of a stable release. Do not forget that people need stable
> > releases to be able to blindly update and get their security vulnerabilities
> > fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
> > adding the PCI ID of some new ethernet cards that were not supported may
> > lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
> > This causes real trouble to admins, particularly those doing remote
> > updates. At least, I think that if you manage to inform people clearly
> > enough, and to separate security fixes and such fixes in distinct releases,
> > it might work in most situations. But this is a dangerous game anyway.
> 
> It seems we do not always agree.  ;-)

:-)

> I did consider gcc 4 support in kernel 2.4 more dangerous and you do 
> consider this more dangerous than I do.

I initially did too (gcc4), but reviewing the fixes one at a time
reassured me.

> I can always be proved wrong by getting reports from people that I broke 
> their setups. If you know someone whose setup I broke, please tell him 
> to inform me about this fact.

Don't worry, at this game, we *all* get proved wrong once in a while, and
this does not imply that a bad decision was taken, but rather that it is
a complicated job and we're all humans.

> That zero feedback is good feedback is my experience since the times 
> when I offered packages to run kernel 2.4 on Debian 2.2, and later 
> packages to run kernel 2.6 on Debian 3.0 - I got almost zero feedback 
> except for the one time when an update removed /etc/services ...

cf above ;-)

[...]
> > Anyway, the case above was even not that. It was simply that if the shiny
> > new sata_piix driver detected the sata controller, it would then steal the
> > resources first, preventing ata_piix from registering.
> 
> I know that ATA is an area that requires extra care (and I don't plan 
> any big updates in this area).
> 
> But having:
> - two saa7134 cards in your computer and
> - one of them formerly not supported and
> - depending on one of them being the first one
> is a case you can theoretically construct, but then there's the point 
> that this is highly unlikely, and OTOH the value of the added support is 
> more realistic.

I don't personaly have problems with those cards (I don't use them at all),
I was just arguing general principles in response to Greg's comments. I
think you're already taking extreme care in what you accept, but I think
that what you're currently doing is middle way between Greg's stable policy
and what yourself would really like to do. I hope that in the end, you will
not get frustrated by refraining from merging patches you would have liked
to get, while being criticized for having merged too many.

Probably that later you will have to either maintain several other versions
(let's say 2.6.16+2.6.18) or have sort of an "enhanced" branch with more
fixes (which is easy to do with GIT).

> If I was as extremely regarding regressions as you describe regarding 
> hardware updates, I would also have to reject any bugfixes that are not 
> security fixes since they might cause regressions.

Hmm, don't say this publicly, you'll get people saying that it is what
they expect !

> I do know that the only value of the 2.6.16 tree lies in a lack of 
> regressions and act accordingly, but I'm trying to do this in a 
> pragmatic way.

That's what I observed till now. I just wanted to warn you about the risks
of getting hit.

Cheers,
Willy

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sun, Sep 24, 2006 at 10:02:04PM +0200, Willy Tarreau wrote:
> On Sun, Sep 24, 2006 at 08:16:41PM +0200, Adrian Bunk wrote:
>...
> > > Anyway, the case above was even not that. It was simply that if the shiny
> > > new sata_piix driver detected the sata controller, it would then steal the
> > > resources first, preventing ata_piix from registering.
> > 
> > I know that ATA is an area that requires extra care (and I don't plan 
> > any big updates in this area).
> > 
> > But having:
> > - two saa7134 cards in your computer and
> > - one of them formerly not supported and
> > - depending on one of them being the first one
> > is a case you can theoretically construct, but then there's the point 
> > that this is highly unlikely, and OTOH the value of the added support is 
> > more realistic.
> 
> I don't personaly have problems with those cards (I don't use them at all),
> I was just arguing general principles in response to Greg's comments. I
> think you're already taking extreme care in what you accept, but I think
> that what you're currently doing is middle way between Greg's stable policy
> and what yourself would really like to do. I hope that in the end, you will
> not get frustrated by refraining from merging patches you would have liked
> to get, while being criticized for having merged too many.
> 
> Probably that later you will have to either maintain several other versions
> (let's say 2.6.16+2.6.18) or have sort of an "enhanced" branch with more
> fixes (which is easy to do with GIT).

Instead of 2.6.16+2.6.18, it would be easier to simply use 2.6.18.

And this is what I have in mind as a possible solution:

Start a similar stable series based on e.g. 2.6.22 or 2.6.24, and 
announce an EOL date for 2.6.16 half a year or one year after this 
branch starts.

Well, that's all very far in the future (even 2.6.22 + half a year will 
most likely be in 2008), but it's better than backporting huge updates.

> > If I was as extremely regarding regressions as you describe regarding 
> > hardware updates, I would also have to reject any bugfixes that are not 
> > security fixes since they might cause regressions.
> 
> Hmm, don't say this publicly, you'll get people saying that it is what
> they expect !

I say what I want to do, and I did say the same before I started 
maintaining the 2.6.16 branch.

> > I do know that the only value of the 2.6.16 tree lies in a lack of 
> > regressions and act accordingly, but I'm trying to do this in a 
> > pragmatic way.
> 
> That's what I observed till now. I just wanted to warn you about the risks
> of getting hit.

Is someone wants to prove me wrong, he should send me the reports of 
regressions my changes have caused...

> Cheers,
> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Pavel Machek]

Hi!

> > Adrian, when you have a doubt whether such a fix should go into next
> > release, simply tell people about the problem and ask them to test
> > current driver. If nobody encounters the problem, you can safely keep
> > the patch in your fridge until someone complains. By that time, the
> > risks associated with this patch will be better known.
> 
> It's not that I wanted to upgrade ACPI to the latest version.
> 
> And my rules are:
> - patch must be in Linus' tree
> - I'm asking the patch authors and maintainers of the affected subsystem
>   whether the patch is OK for 2.6.16

I thought stable rules were longer than this... including 'patch must
be < 100 lines' and 'must be bugfix for serious bug'. Changing rules
for -stable series in the middle of it seems like a bad idea...

Maybe you can keep -ab with relaxed rules and -stable with original
rules?

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sun, Sep 24, 2006 at 10:17:53AM +0000, Pavel Machek wrote:
> Hi!
> 
> > > Adrian, when you have a doubt whether such a fix should go into next
> > > release, simply tell people about the problem and ask them to test
> > > current driver. If nobody encounters the problem, you can safely keep
> > > the patch in your fridge until someone complains. By that time, the
> > > risks associated with this patch will be better known.
> > 
> > It's not that I wanted to upgrade ACPI to the latest version.
> > 
> > And my rules are:
> > - patch must be in Linus' tree
> > - I'm asking the patch authors and maintainers of the affected subsystem
> >   whether the patch is OK for 2.6.16
> 
> I thought stable rules were longer than this... including 'patch must
> be < 100 lines' and 'must be bugfix for serious bug'. Changing rules
> for -stable series in the middle of it seems like a bad idea...

I stated what I'd do with 2.6.16 before I took over maintainance.

> Maybe you can keep -ab with relaxed rules and -stable with original
> rules?

Much would be possible under the assumption I had unlimited time...

> 							Pavel

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Pavel Machek]

Hi!

> > > And my rules are:
> > > - patch must be in Linus' tree
> > > - I'm asking the patch authors and maintainers of the affected subsystem
> > >   whether the patch is OK for 2.6.16
> > 
> > I thought stable rules were longer than this... including 'patch must
> > be < 100 lines' and 'must be bugfix for serious bug'. Changing rules
> > for -stable series in the middle of it seems like a bad idea...
> 
> I stated what I'd do with 2.6.16 before I took over maintainance.

I do not remember you stating that
Documentation/stable_kernel_rules.txt is obsolete, and that you'll
have your own version. Heh, I'm not sure greg understood that.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.16.30-pre1

[Greg KH]

On Mon, Sep 25, 2006 at 03:23:22AM +0200, Adrian Bunk wrote:
> On Sun, Sep 24, 2006 at 10:17:53AM +0000, Pavel Machek wrote:
> > Hi!
> > 
> > > > Adrian, when you have a doubt whether such a fix should go into next
> > > > release, simply tell people about the problem and ask them to test
> > > > current driver. If nobody encounters the problem, you can safely keep
> > > > the patch in your fridge until someone complains. By that time, the
> > > > risks associated with this patch will be better known.
> > > 
> > > It's not that I wanted to upgrade ACPI to the latest version.
> > > 
> > > And my rules are:
> > > - patch must be in Linus' tree
> > > - I'm asking the patch authors and maintainers of the affected subsystem
> > >   whether the patch is OK for 2.6.16
> > 
> > I thought stable rules were longer than this... including 'patch must
> > be < 100 lines' and 'must be bugfix for serious bug'. Changing rules
> > for -stable series in the middle of it seems like a bad idea...
> 
> I stated what I'd do with 2.6.16 before I took over maintainance.

No you did not...

{dig, dig, dig}  Ah, here we go:

I stated in the original announcement with message id
<20060803204921.GA10935@kroah.com>:

	He will still be following the same -stable rules that are
	documented in the Documentation/stable_kernel_rules.txt file,
	but just doing this for the 2.6.16 kernel tree for a much longer
	time than the current stable team is willing to do (we have
	moved on to the 2.6.17 kernel now.)


And I said that based on a message you wrote to stable@kernel.org where
you stated:
	My primary goal is to follow these rules.

	But there will also be cases like "adding a PCI id to a driver"
	that wouldn't fit the wording of the your -stable release rules.

	OTOH, I remember e.g. releases/2.6.12.3/smp-fix-for-6pack.patch
	being added despite me disagreeing with this - and this did
	equally not match the -stable rules.

	Especially if the tree will be accepted and used for a long
	time, there will be a need for moderate hardware updates. But
	2.4 and 2.6 have different rules, people quickly learned that
	-rc is Linus' newspeak for -pre ;-) and similar things, so I
	doubt the confusion will be that big (people will either use the
	current stable kernel or the 2.6.16 branch - and people using
	the latter will know the difference (otherwise they wouldn't use
	an older branch instead of the latest stable kernel)).

Hm, ok, I guess you did say this in the beginning, but only to a small
subset of us.  And I misinterpreted it too in my original announcement.

Ok, I withdraw my objection, only to note that this is going to cause
your tree to diverge even more than expected, which might cause bigger
problems in the end.

good luck,

greg k-h

Re: Linux 2.6.16.30-pre1

[Jean Delvare]

Hi Adrian, Greg,

> On Sat, Sep 23, 2006 at 12:47:35AM +0200, Adrian Bunk wrote:
> > On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> > > On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > > > Andrew Burri:
> > > >       V4L/DVB: Add support for Kworld ATSC110
> > > > 
> > > > Curt Meyers:
> > > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > > 
> > > > Giampiero Giancipoli:
> > > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > > 
> > > > Hartmut Hackmann:
> > > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > > >       V4L/DVB: TDA10046 Driver update
> > > >       V4L/DVB: TDA8290 update
> > > > 
> > > > Peter Hartshorn:
> > > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > > 
> > > Hm, all of these patches seems like these are new features being
> > > backported to the 2.6.16.y kernel, which is not really allowed under the
> > > current -stable rules.
> > > 
> > > Or are these patches just bugfixes that fix with the current -stable
> > > rules?
> > 
> > They add support for additional hardware to the saa7134 driver.
> 
> That's not a bugfix.
> 
> > If you look at the actual diff there's not much that could cause any 
> > regression since nearly all of these change don't change anything for 
> > the already supported cards.
> 
> I'm not disagreeing about the regression issue.  I'm just concerned
> because you are starting down the slope of "backporting new driver
> support" to the 2.6.16 tree, and that's something that I thought you did
> not want to do.
> 
> But if it is, let us know, and we can discuss it.

I second Greg's objection, and share his worries. "No possible
regression" is something extremely hard to evaluate in general.
Besides, the goal of -stable as I remember it is not "no regression"
but rather "only bugfixes", i.e. patches don't go in without a good
reason (default policy = reject), rather than patches are rejected if
they may cause problem (default policy = accept.)

Adding support for new devices, even if it's only adding an ID in a
list, is not always safe. I am not happy about new IDs being considered
as OK for late RCs, I am even less so for -stable.

The sole fact that Adrian felt the need to release a -pre1 for
2.6.16.30 betrays his lack of confidence IMHO. And the size of
ChangeLog-2.6.16.29 speaks for itself.

Given that 2.6.16.y follows the naming convention of -stable and is
released in the official v2.6 directory on ftp.kernel.org, I'd like to
see it follow the same rules we have for "real" -stable trees. Adrian,
if you are going to diverge from the original intent of -stable, this
is your own right, but then please change the name of your tree to
2.6.16-ab or something similar, to clear the confusion.

I will not use 2.6.16.y with its current rules, for sure, and I doubt
any distribution will. Wasn't the whole point of 2.6.16.y to serve as a
common base between several distributions?

Thanks,
-- 
Jean Delvare

Re: Linux 2.6.16.30-pre1

[Lee Revell]

On Sat, 2006-09-23 at 22:49 +0200, Jean Delvare wrote:
> I will not use 2.6.16.y with its current rules, for sure, and I doubt
> any distribution will. Wasn't the whole point of 2.6.16.y to serve as
> a common base between several distributions? 

I would not expect distros to be interested in a 2.6 tree that does not
add support for new devices.  Isn't new hardware support one of the main
areas where distros routinely get ahead of mainline?

Lee

Re: Linux 2.6.16.30-pre1

[Jean Delvare]

Hi Lee,

> On Sat, 2006-09-23 at 22:49 +0200, Jean Delvare wrote:
> > I will not use 2.6.16.y with its current rules, for sure, and I doubt
> > any distribution will. Wasn't the whole point of 2.6.16.y to serve as
> > a common base between several distributions? 
> 
> I would not expect distros to be interested in a 2.6 tree that does not
> add support for new devices.  Isn't new hardware support one of the main
> areas where distros routinely get ahead of mainline?

It really depends on the distribution, and even more of the specific
product. I know for a fact that Suse has no interest in supporting
additional hardware in the saa7134 driver for SLES10, for example. I
suspect that distributions only backport hardware support when a
customer asks for it, and they have some in-house knowledge to do it
safely.

My original understanding was that 2.6.16.y was meant to be a common
tree between different distributions and products, containing only the
unquestionable fixes - i.e. security, data corruption and other oopses,
in the -stable spirit - and then different distributions would add their
own patches on top of it as they see fit.

-- 
Jean Delvare

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sat, Sep 23, 2006 at 11:20:54PM +0200, Jean Delvare wrote:
> Hi Lee,
> 
> > On Sat, 2006-09-23 at 22:49 +0200, Jean Delvare wrote:
> > > I will not use 2.6.16.y with its current rules, for sure, and I doubt
> > > any distribution will. Wasn't the whole point of 2.6.16.y to serve as
> > > a common base between several distributions? 
> > 
> > I would not expect distros to be interested in a 2.6 tree that does not
> > add support for new devices.  Isn't new hardware support one of the main
> > areas where distros routinely get ahead of mainline?
> 
> It really depends on the distribution, and even more of the specific
> product. I know for a fact that Suse has no interest in supporting
> additional hardware in the saa7134 driver for SLES10, for example. I
> suspect that distributions only backport hardware support when a
> customer asks for it, and they have some in-house knowledge to do it
> safely.

[ see my comment about distributions in the other email ]

And I'd expect distributions with some in-house knowledge to do at most 
cherry picking from my tree.

> My original understanding was that 2.6.16.y was meant to be a common
> tree between different distributions and products, containing only the
> unquestionable fixes - i.e. security, data corruption and other oopses,
> in the -stable spirit - and then different distributions would add their
> own patches on top of it as they see fit.

How do you define "unquestionable fixes"?

E.g. what if a distribution supports an external module, and a fix 
requires changing the kernel ABI this module uses?

The users of my trees are mostly people using self-compiled kernels that 
want security fixes but no regressions.

> Jean Delvare

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sat, Sep 23, 2006 at 10:49:09PM +0200, Jean Delvare wrote:

> Hi Adrian, Greg,

Hi Jean,

> I second Greg's objection, and share his worries. "No possible
> regression" is something extremely hard to evaluate in general.
> Besides, the goal of -stable as I remember it is not "no regression"
> but rather "only bugfixes", i.e. patches don't go in without a good
> reason (default policy = reject), rather than patches are rejected if
> they may cause problem (default policy = accept.)
> 
> Adding support for new devices, even if it's only adding an ID in a
> list, is not always safe. I am not happy about new IDs being considered
> as OK for late RCs, I am even less so for -stable.

the main goals for 2.6.16 are:
- no regressions
- security fixes

And I did always say that things like adding new PCI IDs are considered 
OK for 2.6.16.

> The sole fact that Adrian felt the need to release a -pre1 for
> 2.6.16.30 betrays his lack of confidence IMHO.

No, all it says is:
- there was no reason for releasing 2.6.16.30 very soon
- my TODO list still contains reviewing 65 of the patches the -stable
  team added to 2.6.17

> And the size of ChangeLog-2.6.16.29 speaks for itself.

Except for 2 bug fixes, all of them were patches the -stable team added 
to 2.6.17.

> Given that 2.6.16.y follows the naming convention of -stable and is
> released in the official v2.6 directory on ftp.kernel.org, I'd like to
> see it follow the same rules we have for "real" -stable trees. Adrian,
> if you are going to diverge from the original intent of -stable, this
> is your own right, but then please change the name of your tree to
> 2.6.16-ab or something similar, to clear the confusion.
> 
> I will not use 2.6.16.y with its current rules, for sure, and I doubt
> any distribution will. Wasn't the whole point of 2.6.16.y to serve as a
> common base between several distributions?

No, see [1]:

<--  snip  -->

Q:
What is the target audience for this 2.6.16 series?

A:
The target audience are users still using 2.4 (or who'd still use kernel 
2.4 if they weren't forced to upgrade to 2.6 for some reason) who want a 
stable kernel series including security fixes but excluding many 
regressions.
It might also be interesting for distributions that prefer stability 
over always using the latest stuff.

<--  snip  -->


The 2.6.16 series is an offer.

If you don't want to use it it's OK.

Distributions can use it, cherry pick from it, or ignore it.

Whether a distribution uses 2.6.16 or a more recent kernel (that will 
anyway support more hardware than 2.6.16 ever will), and if a 
distribution that uses 2.6.16 will ever follow the 2.6.16 series depends 
on the goals of the distribution.


> Thanks,
> Jean Delvare

cu
Adrian

[1] http://article.gmane.org/gmane.linux.kernel/354360

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Lee Revell]

On Sun, 2006-09-24 at 00:33 +0200, Adrian Bunk wrote:
> the main goals for 2.6.16 are:
> - no regressions
> - security fixes
> 
> And I did always say that things like adding new PCI IDs are
> considered 
> OK for 2.6.16. 

I think the point that people are trying to make is that adding new PCI
IDs carries an inherent risk of regression.  Unless you have access to
every device with that ID for regression testing it could be the
difference between a machine where one device doesn't work and a machine
that locks up hard.

Lee

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sat, Sep 23, 2006 at 06:47:54PM -0400, Lee Revell wrote:
> On Sun, 2006-09-24 at 00:33 +0200, Adrian Bunk wrote:
> > the main goals for 2.6.16 are:
> > - no regressions
> > - security fixes
> > 
> > And I did always say that things like adding new PCI IDs are
> > considered 
> > OK for 2.6.16. 
> 
> I think the point that people are trying to make is that adding new PCI
> IDs carries an inherent risk of regression.  Unless you have access to
> every device with that ID for regression testing it could be the
> difference between a machine where one device doesn't work and a machine
> that locks up hard.

"a machine that locks up hard" is a pretty uncommon case, and it should 
be ruled out by the following two factors:
- patch must be in Linus' tree
- I'm asking the patch authors and maintainers of the affected subsystem
  whether the patch is OK for 2.6.16

You never achieve 0% risk, but many bug fixes have a much higher risk of 
regression.

I do know that the only value of the 2.6.16 tree lies in a lack of 
regressions and act accordingly, and as soon as people will report 
regressions compared to earlier 2.6.16 kernels I'll know that I'll have 
done something wrong (but I haven't yet gotten such bug reports).

> Lee

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> On Sat, Sep 23, 2006 at 12:47:35AM +0200, Adrian Bunk wrote:
> > On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> > > On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > > > Andrew Burri:
> > > >       V4L/DVB: Add support for Kworld ATSC110
> > > > 
> > > > Curt Meyers:
> > > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > > 
> > > > Giampiero Giancipoli:
> > > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > > 
> > > > Hartmut Hackmann:
> > > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > > >       V4L/DVB: TDA10046 Driver update
> > > >       V4L/DVB: TDA8290 update
> > > > 
> > > > Peter Hartshorn:
> > > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > > 
> > > Hm, all of these patches seems like these are new features being
> > > backported to the 2.6.16.y kernel, which is not really allowed under the
> > > current -stable rules.
> > > 
> > > Or are these patches just bugfixes that fix with the current -stable
> > > rules?
> > 
> > They add support for additional hardware to the saa7134 driver.
> 
> That's not a bugfix.

See below.

> > If you look at the actual diff there's not much that could cause any 
> > regression since nearly all of these change don't change anything for 
> > the already supported cards.
> 
> I'm not disagreeing about the regression issue.  I'm just concerned
> because you are starting down the slope of "backporting new driver
> support" to the 2.6.16 tree, and that's something that I thought you did
> not want to do.
> 
> But if it is, let us know, and we can discuss it.

I always said that things like adding new PCI IDs are OK for 2.6.16.

> > As long as there's not a serious risk of regressions, such additions are 
> > welcome in 2.6.16.
> 
> Are you sure?  That really goes against the -stable rules as we
> originally set them out to be.
> 
> If you want to accept new drivers and backports like this, I think you
> will find it very hard to determine what to say yes or no to in the
> future.  It's the main problem that everyone who has tried to maintain a
> stable tree has run into, that is why we set up the -stable rules to be
> what they are for that very reason.

My primary priorities are:
- no regressions
- security fixes

If adding support for hardware without a very low regression risk is 
possible (bugfixes usually have a much higher risk), I don't see the 
point against doing it.

If adding support for hardware would have a regression risk I'll always 
say no - no matter how important the hardware is (I'd expect this e.g. 
in the near future for SATA).

I do know that the only value of the 2.6.16 tree lies in a lack of 
regressions and act accordingly, and as soon as people will report 
regressions compared to earlier 2.6.16 kernels I'll know that I'll have 
done something wrong (but I haven't yet gotten such bug reports).

> > "is not really allowed under the current -stable rules" is a bit hard to 
> > answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> > for 2.6.17.12 I'd say it's consistent with what you are doing.
> 
> That was a bugfix as the driver could not access that device without
> that fix.  Just adding a device id is not something that we normally
> will take, as that is what the sysfs "newid" is for.  That patch was
> obviously something else.

I read the changelog differently.

Anyway, I'm not really seeing any non-academical difference between "as 
the driver could not access that device without that fix" and "adding 
support for a device to a driver" - it's all about a device that tdidn't 
work before and does work after the patch.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Pavel Machek]

Hi!

> > > Andrew Burri:
> > >       V4L/DVB: Add support for Kworld ATSC110
> > > 
> > > Curt Meyers:
> > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > 
> > > Giampiero Giancipoli:
> > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > 
> > > Hartmut Hackmann:
> > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > >       V4L/DVB: TDA10046 Driver update
> > >       V4L/DVB: TDA8290 update
> > > 
> > > Peter Hartshorn:
> > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > 
> > Hm, all of these patches seems like these are new features being
> > backported to the 2.6.16.y kernel, which is not really allowed under the
> > current -stable rules.
> > 
> > Or are these patches just bugfixes that fix with the current -stable
> > rules?
> 
> They add support for additional hardware to the saa7134 driver.
> 
> If you look at the actual diff there's not much that could cause any 
> regression since nearly all of these change don't change anything for 
> the already supported cards.
> 
> As long as there's not a serious risk of regressions, such additions are 
> welcome in 2.6.16.

I believe you should not do that. Maybe risk of regression is small,
but risk of adding non-working driver is not, and goal of -stable is
to be stable, not to have feature-of-the-day.

						Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: Linux 2.6.16.30-pre1

[Adrian Bunk]

On Sun, Sep 24, 2006 at 10:12:55AM +0000, Pavel Machek wrote:
> Hi!
> 
> > > > Andrew Burri:
> > > >       V4L/DVB: Add support for Kworld ATSC110
> > > > 
> > > > Curt Meyers:
> > > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > > 
> > > > Giampiero Giancipoli:
> > > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > > 
> > > > Hartmut Hackmann:
> > > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > > >       V4L/DVB: TDA10046 Driver update
> > > >       V4L/DVB: TDA8290 update
> > > > 
> > > > Peter Hartshorn:
> > > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > > 
> > > Hm, all of these patches seems like these are new features being
> > > backported to the 2.6.16.y kernel, which is not really allowed under the
> > > current -stable rules.
> > > 
> > > Or are these patches just bugfixes that fix with the current -stable
> > > rules?
> > 
> > They add support for additional hardware to the saa7134 driver.
> > 
> > If you look at the actual diff there's not much that could cause any 
> > regression since nearly all of these change don't change anything for 
> > the already supported cards.
> > 
> > As long as there's not a serious risk of regressions, such additions are 
> > welcome in 2.6.16.
> 
> I believe you should not do that. Maybe risk of regression is small,
> but risk of adding non-working driver is not,

If it didn't work before and doesn't work after, nothing changed.

> and goal of -stable is
> to be stable, not to have feature-of-the-day.

No disagreement.

> 						Pavel

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16.30-pre1

[Grant Coady]

On Sat, 23 Sep 2006 00:23:00 +0200, Adrian Bunk <bunk@stusta.de> wrote:

>Patch location:
>ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/

Works on 6 of 7 boxen here, the seventh box is new install (2.4.33.3), it 
booted but needs configuration work to run 2.6.anything properly ;)

Cheers,
Grant.