ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Len Brown]

Yes, the ACPI part to enable MMconfig was pretty small.
We parse a table in the standard way and set a global variable --
that's about it.

I submitted it to 2.4 for the sole purpose
to enable Greg to enable native PCIExpress.

I expect demand for this in 2.4 as the major distros'
enterprise releases are still 2.4 based and the hardware has
arrived...  Your call, Marcelo, if this is something to
solve in upstream 2.4 or something the distros need
to solve for themselves.  I recommend leaving the
small ACPI piece of the puzzle intact in either case.

On Tue, 2004-05-25 at 08:54, Marcelo Tosatti wrote:
> I've humbly asked Len to stop doing big updates
> whenever possible on the 
> v2.4 ACPI code, and do bugfixes only instead. Is that a pain in the
> ass for you, Len?    
> 
> I asked that because it is common to see new bugs introduced by an
> ACPI update, and you know that more than I do.

At one point I released to 2.4 first because that is where
the useful testing feedback was; and then released to 2.5
to make sure it didn't fall behind.

Then I released to 2.4 and 2.6 simultaneously b/c
I got quick feeback from both camps.

Now we're into the era where the release-early
release-often matra applies to 26 only (or maybe more 2.6-mm)
and 2.4 is in maintenance mode.

I would still like to send some significant ACPI patches to 24.
Yes, they're 100% bugfixes -- sometimes bugfixes touch
lots of files too...  But I'll do so only after the same
fix has been proven in 2.6 for a spell.

With some parts of ACPI, such as the ACPICA core interpreter
this is actually pretty low risk, because that part of
the kernel is identical between 2.4 and 2.6.  So if 2.6 works,
so will 2.4.

Of course this also depends on if 2.4 will be accepting anything.
I recall talk back about 2.4.25 about the end of the 2.4 line.
I generally only have time to read LKML messages directed to me
or if the word "ACPI" appears in the message, so I may have missed
the word 2.4.  What is the word?

thanks,
-Len

Re: ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Arjan van de Ven]

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

On Wed, May 26, 2004 at 03:35:34AM -0400, Len Brown wrote:
> Yes, the ACPI part to enable MMconfig was pretty small.
> We parse a table in the standard way and set a global variable --
> that's about it.
> 
> I submitted it to 2.4 for the sole purpose
> to enable Greg to enable native PCIExpress.
> 
> I expect demand for this in 2.4 as the major distros'
> enterprise releases are still 2.4 based and the hardware has
> arrived... 

yet those enterprise releases won't go to newer 2.4 upstream releases....


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

Re: ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Jeff Garzik]

Arjan van de Ven wrote:
> On Wed, May 26, 2004 at 03:35:34AM -0400, Len Brown wrote:
> 
>>Yes, the ACPI part to enable MMconfig was pretty small.
>>We parse a table in the standard way and set a global variable --
>>that's about it.
>>
>>I submitted it to 2.4 for the sole purpose
>>to enable Greg to enable native PCIExpress.
>>
>>I expect demand for this in 2.4 as the major distros'
>>enterprise releases are still 2.4 based and the hardware has
>>arrived... 
> 
> 
> yet those enterprise releases won't go to newer 2.4 upstream releases....


Len is right in guessing enterprise releases want PCI Express support 
though :)

	Jeff

Re: ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Marcelo Tosatti]

On Wed, May 26, 2004 at 03:35:34AM -0400, Len Brown wrote:
> Yes, the ACPI part to enable MMconfig was pretty small.
> We parse a table in the standard way and set a global variable --
> that's about it.
> 
> I submitted it to 2.4 for the sole purpose
> to enable Greg to enable native PCIExpress.
> 
> I expect demand for this in 2.4 as the major distros'
> enterprise releases are still 2.4 based and the hardware has
> arrived...  Your call, Marcelo, if this is something to
> solve in upstream 2.4 or something the distros need
> to solve for themselves.  I recommend leaving the
> small ACPI piece of the puzzle intact in either case.
> 
> On Tue, 2004-05-25 at 08:54, Marcelo Tosatti wrote:
> > I've humbly asked Len to stop doing big updates
> > whenever possible on the 
> > v2.4 ACPI code, and do bugfixes only instead. Is that a pain in the
> > ass for you, Len?    
> > 
> > I asked that because it is common to see new bugs introduced by an
> > ACPI update, and you know that more than I do.
> 
> At one point I released to 2.4 first because that is where
> the useful testing feedback was; and then released to 2.5
> to make sure it didn't fall behind.
> 
> Then I released to 2.4 and 2.6 simultaneously b/c
> I got quick feeback from both camps.
> 
> Now we're into the era where the release-early
> release-often matra applies to 26 only (or maybe more 2.6-mm)
> and 2.4 is in maintenance mode.
> 
> I would still like to send some significant ACPI patches to 24.
> Yes, they're 100% bugfixes -- sometimes bugfixes touch
> lots of files too...  But I'll do so only after the same
> fix has been proven in 2.6 for a spell.
> 
> With some parts of ACPI, such as the ACPICA core interpreter
> this is actually pretty low risk, because that part of
> the kernel is identical between 2.4 and 2.6.  So if 2.6 works,
> so will 2.4.
> 
> Of course this also depends on if 2.4 will be accepting anything.
> I recall talk back about 2.4.25 about the end of the 2.4 line.

Yes, wish it was. Unfortunately there still a lot of activitity from 
people sending me patches, which are usually fixing bugs. Not major core
bugs, more "outside of the core" things (drivers and filesystems).

> I generally only have time to read LKML messages directed to me
> or if the word "ACPI" appears in the message, so I may have missed
> the word 2.4.  What is the word?

I dont get you? What you mean? (sorry)

Re: ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Len Brown]

On Fri, 2004-05-28 at 08:09, Marcelo Tosatti wrote:
> On Wed, May 26, 2004 at 03:35:34AM -0400, Len Brown wrote:

> > I generally only have time to read LKML messages directed to me
> > or if the word "ACPI" appears in the message, so I may have missed
> > the word 2.4.  What is the word?
> 
> I dont get you? What you mean? (sorry)

If you announced a change in policy for accepting 2.4 patches,
then I missed it.  So I'm assuming that since people are still
complaining to me about bugs in 2.4, and we're all still fixing
those bugs, that I should continue to submit those patches to you.

I understand that we should not add any new features to 2.4,
and that we should not undertake any significant code cleanups
because the tolerance for risk is low.

For these reasons, the ACPI code in 2.6 is starting to diverge
from 2.4.  However, large parts of the ACPI sub-system, such
as the core intepreter and most of the configuration code,
are very much the same betwen 2.4 and 2.6.  For this reason
I think the risk is low to integrate some relatively large
ACPI patches into 2.4 -- as long as the same code has already
been tested and released in 2.6.

So I can delay sending 2.4 patches until it is clear that they
were successful in 2.6.  The question I have is how long there
will be a 2.4 release available for accepting those patches.

-Len

Re: ACPI & 2.4 (Re: [BK PATCH] PCI Express patches for 2.4.27-pre3)

[Marcelo Tosatti]

On Fri, May 28, 2004 at 10:56:50AM -0400, Len Brown wrote:
> On Fri, 2004-05-28 at 08:09, Marcelo Tosatti wrote:
> > On Wed, May 26, 2004 at 03:35:34AM -0400, Len Brown wrote:
> 
> > > I generally only have time to read LKML messages directed to me
> > > or if the word "ACPI" appears in the message, so I may have missed
> > > the word 2.4.  What is the word?
> > 
> > I dont get you? What you mean? (sorry)
> 
> If you announced a change in policy for accepting 2.4 patches,
> then I missed it.  So I'm assuming that since people are still
> complaining to me about bugs in 2.4, and we're all still fixing
> those bugs, that I should continue to submit those patches to you.

Perfect. 

> I understand that we should not add any new features to 2.4,
> and that we should not undertake any significant code cleanups
> because the tolerance for risk is low.

Right.

> For these reasons, the ACPI code in 2.6 is starting to diverge
> from 2.4.  However, large parts of the ACPI sub-system, such
> as the core intepreter and most of the configuration code,
> are very much the same betwen 2.4 and 2.6.  For this reason
> I think the risk is low to integrate some relatively large
> ACPI patches into 2.4 -- as long as the same code has already
> been tested and released in 2.6.

Hum, fine. That sounds more conservative.

> So I can delay sending 2.4 patches until it is clear that they
> were successful in 2.6.  The question I have is how long there
> will be a 2.4 release available for accepting those patches.

The policy now is to accept only bugfixes and support for new
hardware (eg new PCI ID's, new drivers). There will still be
a few v2.4 releases, just not with the same frequency as they have
been released in the past.

Does that answer your question?