Options depending on STANDALONE

Options depending on STANDALONE

[Adrian Bunk]

On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 12:36:00PM -0700, Greg Kroah-Hartman wrote:
> 
>  > > That is good to know.  But there is a kernel option which doesn't make 
>  > > much sense in that case:
>  > > 
>  > > [*] Select only drivers that don't need compile-time external firmware
>  > 
>  > No, that is very different.  That option is present if you don't want to
>  > build some firmware images from the source that is present in the kernel
>  > tree, and instead, use the pre-built stuff that is also present in the
>  > kernel tree.
> 
> You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> STANDALONE, which is something else completely.  That allows us to not
> build drivers that pull in things from /etc and the like during compile.
> (Whoever thought that was a good idea?)

We should also look at what drivers do depend on STANDALONE:
- some OSS drivers
- one DVB driver option (DVB_AV7110_FIRMWARE)
- ACPI_CUSTOM_DSDT

The OSS drivers are more or less RIP, so let's ignore them.

Is DVB_AV7110_FIRMWARE really still required?
ALL other drivers work without such an option.

ACPI_CUSTOM_DSDT seems to be the most interesting case.
It's anyway not usable for distribution kernels, and AFAIR the ACPI 
people prefer to get the kernel working with all original DSDTs
(which usually work with at least one other OS) than letting the people 
workaround the problem by using a custom DSDT.

It might therefore be possile simply getting rid of CONFIG_STANDALONE?

> 		Dave

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: Options depending on STANDALONE

[Greg KH]

On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
> people prefer to get the kernel working with all original DSDTs
> (which usually work with at least one other OS) than letting the people 
> workaround the problem by using a custom DSDT.

Not true at all.  For SuSE kernels, we have a patch that lets people
load a new DSDT from initramfs due to broken machines requiring a
replacement in order to work properly.

thanks,

greg k-h

Re: Options depending on STANDALONE

[Dave Jones]

On Thu, Aug 03, 2006 at 01:28:07PM -0700, Greg Kroah-Hartman wrote:
 > On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
 > > ACPI_CUSTOM_DSDT seems to be the most interesting case.
 > > It's anyway not usable for distribution kernels, and AFAIR the ACPI 
 > > people prefer to get the kernel working with all original DSDTs
 > > (which usually work with at least one other OS) than letting the people 
 > > workaround the problem by using a custom DSDT.
 > 
 > Not true at all.  For SuSE kernels, we have a patch that lets people
 > load a new DSDT from initramfs due to broken machines requiring a
 > replacement in order to work properly.

Whilst this is a quick fix for users who either know how to hack DSDTs
themselves, or know where to get a fixed one, it doesn't solve the bigger
problem, that the interpretor doesn't get fixed.
And by 'fixed', I mean we aren't bug for bug compatible with that
other OS.  We need to be adding workarounds to the ACPI interpretor
so this stuff 'just works', not hiding from the problem and creating
"but it works in $otherdistro when I do this" scenarios.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Trent Piepho]

On Thu, 3 Aug 2006, Adrian Bunk wrote:
> On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > STANDALONE, which is something else completely.  That allows us to not
> > build drivers that pull in things from /etc and the like during compile.
> > (Whoever thought that was a good idea?)
>
>
> Is DVB_AV7110_FIRMWARE really still required?
> ALL other drivers work without such an option.

The other DVB drivers that need firmware load it when the device is opened
or used (ie.  a channel is tuned).  At least for the ones I'm familiar
with.  If they are compiled directly into the kernel, they can still use
FW_LOADER since the loading won't happen until utill well after booting is
done.

For AV7110, it looks like the firmware loading is done when the driver is
first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
not be used.  The filesystem with the firmware won't be mounted yet.

So AV7110 has an option to compile a firmware file into the driver.

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Adrian Bunk]

On Thu, Aug 03, 2006 at 04:40:25PM -0700, Trent Piepho wrote:
> On Thu, 3 Aug 2006, Adrian Bunk wrote:
> > On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > > STANDALONE, which is something else completely.  That allows us to not
> > > build drivers that pull in things from /etc and the like during compile.
> > > (Whoever thought that was a good idea?)
> >
> >
> > Is DVB_AV7110_FIRMWARE really still required?
> > ALL other drivers work without such an option.
> 
> The other DVB drivers that need firmware load it when the device is opened
> or used (ie.  a channel is tuned).  At least for the ones I'm familiar
> with.  If they are compiled directly into the kernel, they can still use
> FW_LOADER since the loading won't happen until utill well after booting is
> done.
> 
> For AV7110, it looks like the firmware loading is done when the driver is
> first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
> not be used.  The filesystem with the firmware won't be mounted yet.
> 
> So AV7110 has an option to compile a firmware file into the driver.

But is there a technical reason why this has to be done this way?

This is the onle (non-OSS) driver doing it this way, and Zach has a 
point that this is legally questionable.

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Oliver Endriss]

Adrian Bunk wrote:
> On Thu, Aug 03, 2006 at 04:40:25PM -0700, Trent Piepho wrote:
> > On Thu, 3 Aug 2006, Adrian Bunk wrote:
> > > On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > > > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > > > STANDALONE, which is something else completely.  That allows us to not
> > > > build drivers that pull in things from /etc and the like during compile.
> > > > (Whoever thought that was a good idea?)
> > >
> > > Is DVB_AV7110_FIRMWARE really still required?
> > > ALL other drivers work without such an option.
> > 
> > The other DVB drivers that need firmware load it when the device is opened
> > or used (ie.  a channel is tuned).  At least for the ones I'm familiar
> > with.  If they are compiled directly into the kernel, they can still use
> > FW_LOADER since the loading won't happen until utill well after booting is
> > done.
> > 
> > For AV7110, it looks like the firmware loading is done when the driver is
> > first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
> > not be used.  The filesystem with the firmware won't be mounted yet.
> > 
> > So AV7110 has an option to compile a firmware file into the driver.
> 
> But is there a technical reason why this has to be done this way?
> 
> This is the onle (non-OSS) driver doing it this way, and Zach has a 
> point that this is legally questionable.

This option _is_ useful because it allows allows a user to build an
av7110 driver without hotplug etc. I NAK any attempt to remove it.

Sorry, a kernel option cannot cause a legal issue. Only the user does.
For non-distribution kernels there is no difference whether firmware is
loaded at run-time or compiled-in.

Obviously, there might be a difference for distribution kernels if you
are not allowed to distribute the firmware (imho not a problem in this
case, but IANAL). Simple solution: Do not enable the option.

I have no problem if you want to remove STANDALONE: Simply remove the
dependency to STANDALONE, but keep DVB_AV7110_FIRMWARE with default 'n'.

CU
Oliver

-- 
--------------------------------------------------------
VDR Remote Plugin available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Adrian Bunk]

On Sun, Aug 06, 2006 at 01:18:59PM +0200, Oliver Endriss wrote:
> Adrian Bunk wrote:
> > On Thu, Aug 03, 2006 at 04:40:25PM -0700, Trent Piepho wrote:
> > > On Thu, 3 Aug 2006, Adrian Bunk wrote:
> > > > On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > > > > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > > > > STANDALONE, which is something else completely.  That allows us to not
> > > > > build drivers that pull in things from /etc and the like during compile.
> > > > > (Whoever thought that was a good idea?)
> > > >
> > > > Is DVB_AV7110_FIRMWARE really still required?
> > > > ALL other drivers work without such an option.
> > > 
> > > The other DVB drivers that need firmware load it when the device is opened
> > > or used (ie.  a channel is tuned).  At least for the ones I'm familiar
> > > with.  If they are compiled directly into the kernel, they can still use
> > > FW_LOADER since the loading won't happen until utill well after booting is
> > > done.
> > > 
> > > For AV7110, it looks like the firmware loading is done when the driver is
> > > first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
> > > not be used.  The filesystem with the firmware won't be mounted yet.
> > > 
> > > So AV7110 has an option to compile a firmware file into the driver.
> > 
> > But is there a technical reason why this has to be done this way?
> > 
> > This is the onle (non-OSS) driver doing it this way, and Zach has a 
> > point that this is legally questionable.
> 
> This option _is_ useful because it allows allows a user to build an
> av7110 driver without hotplug etc. I NAK any attempt to remove it.

If you look at the dependencies of DVB_AV7110 and the code in av7110.c 
you'll note that your statement "it allows allows a user to build an 
av7110 driver without hotplug" is not true.

> Sorry, a kernel option cannot cause a legal issue. Only the user does.
> For non-distribution kernels there is no difference whether firmware is
> loaded at run-time or compiled-in.
> 
> Obviously, there might be a difference for distribution kernels if you
> are not allowed to distribute the firmware (imho not a problem in this
> case, but IANAL). Simple solution: Do not enable the option.

The general direction in Linux kernel development is to load the 
firmware at runtime.

> I have no problem if you want to remove STANDALONE: Simply remove the
> dependency to STANDALONE, but keep DVB_AV7110_FIRMWARE with default 'n'.

The point of STANDALONE are working allmodconfig/allyesconfig compiles.

Removing the dependency on STANDALONE therefore implies that it compiles.

> CU
> Oliver

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Trent Piepho]

On Sun, 13 Aug 2006, Adrian Bunk wrote:
> On Sun, Aug 06, 2006 at 01:18:59PM +0200, Oliver Endriss wrote:
> > Adrian Bunk wrote:
> > > On Thu, Aug 03, 2006 at 04:40:25PM -0700, Trent Piepho wrote:
> > > > On Thu, 3 Aug 2006, Adrian Bunk wrote:
> > > > > On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > > > > > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > > > > > STANDALONE, which is something else completely.  That allows us to not
> > > > > > build drivers that pull in things from /etc and the like during compile.
> > > > > > (Whoever thought that was a good idea?)
> > > > >
> > > > > Is DVB_AV7110_FIRMWARE really still required?
> > > > > ALL other drivers work without such an option.
> > > >
> > > > The other DVB drivers that need firmware load it when the device is opened
> > > > or used (ie.  a channel is tuned).  At least for the ones I'm familiar
> > > > with.  If they are compiled directly into the kernel, they can still use
> > > > FW_LOADER since the loading won't happen until utill well after booting is
> > > > done.
> > > >
> > > > For AV7110, it looks like the firmware loading is done when the driver is
> > > > first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
> > > > not be used.  The filesystem with the firmware won't be mounted yet.
> > > >
> > > > So AV7110 has an option to compile a firmware file into the driver.
> > >
> > > But is there a technical reason why this has to be done this way?

Is there another way to load firmware in a driver compiled into the kernel?

> > > This is the onle (non-OSS) driver doing it this way, and Zach has a
> > > point that this is legally questionable.

I know there are other DVB drivers that can have firmware compiled in
instead of using FW_LOADER.  They just don't show that ability in Kconfig,
you have to edit the driver to enable compiled in firmware.

> > This option _is_ useful because it allows allows a user to build an
> > av7110 driver without hotplug etc. I NAK any attempt to remove it.
>
> If you look at the dependencies of DVB_AV7110 and the code in av7110.c
> you'll note that your statement "it allows allows a user to build an
> av7110 driver without hotplug" is not true.

Looks like a mistake in the Kconfig file:
-	select FW_LOADER
+	select FW_LOADER if DVB_AV7110_FIRMWARE=n

Re: [v4l-dvb-maintainer] Options depending on STANDALONE

[Adrian Bunk]

On Mon, Aug 14, 2006 at 02:15:26PM -0700, Trent Piepho wrote:
> On Sun, 13 Aug 2006, Adrian Bunk wrote:
> > On Sun, Aug 06, 2006 at 01:18:59PM +0200, Oliver Endriss wrote:
> > > Adrian Bunk wrote:
> > > > On Thu, Aug 03, 2006 at 04:40:25PM -0700, Trent Piepho wrote:
> > > > > On Thu, 3 Aug 2006, Adrian Bunk wrote:
> > > > > > On Thu, Aug 03, 2006 at 03:56:17PM -0400, Dave Jones wrote:
> > > > > > > You're describing PREVENT_FIRMWARE_BUILD.  The text Zach quoted is from
> > > > > > > STANDALONE, which is something else completely.  That allows us to not
> > > > > > > build drivers that pull in things from /etc and the like during compile.
> > > > > > > (Whoever thought that was a good idea?)
> > > > > >
> > > > > > Is DVB_AV7110_FIRMWARE really still required?
> > > > > > ALL other drivers work without such an option.
> > > > >
> > > > > The other DVB drivers that need firmware load it when the device is opened
> > > > > or used (ie.  a channel is tuned).  At least for the ones I'm familiar
> > > > > with.  If they are compiled directly into the kernel, they can still use
> > > > > FW_LOADER since the loading won't happen until utill well after booting is
> > > > > done.
> > > > >
> > > > > For AV7110, it looks like the firmware loading is done when the driver is
> > > > > first initialized.  If AV7110 is compiled into the kernel, FW_LOADER can
> > > > > not be used.  The filesystem with the firmware won't be mounted yet.
> > > > >
> > > > > So AV7110 has an option to compile a firmware file into the driver.
> > > >
> > > > But is there a technical reason why this has to be done this way?
> 
> Is there another way to load firmware in a driver compiled into the kernel?

The CONFIG_DVB_AV7110_FIRMWARE=n code should work fine.

> > > > This is the onle (non-OSS) driver doing it this way, and Zach has a
> > > > point that this is legally questionable.
> 
> I know there are other DVB drivers that can have firmware compiled in
> instead of using FW_LOADER.  They just don't show that ability in Kconfig,
> you have to edit the driver to enable compiled in firmware.
> 
> > > This option _is_ useful because it allows allows a user to build an
> > > av7110 driver without hotplug etc. I NAK any attempt to remove it.
> >
> > If you look at the dependencies of DVB_AV7110 and the code in av7110.c
> > you'll note that your statement "it allows allows a user to build an
> > av7110 driver without hotplug" is not true.
> 
> Looks like a mistake in the Kconfig file:
> -	select FW_LOADER
> +	select FW_LOADER if DVB_AV7110_FIRMWARE=n

Sure, it could be fixed.

But the fact that it didn't work doesn't create a strong reason for 
keeping it.

And the whole "kernel without hotplug" is anyway no longer possible in 
the usual CONFIG_EMBEDDED=n case.

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: Options depending on STANDALONE

[Brown, Len]

>On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
>> ACPI_CUSTOM_DSDT seems to be the most interesting case.
>> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
>> people prefer to get the kernel working with all original DSDTs
>> (which usually work with at least one other OS) than letting 
>> the people workaround the problem by using a custom DSDT.
>
>Not true at all.  For SuSE kernels, we have a patch that lets people
>load a new DSDT from initramfs due to broken machines requiring a
>replacement in order to work properly.

CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
by building a modified DSDT into the kernel to over-ride what
came with the system.  It would make no sense for a distro
to use it, unless the distro were shipping only on 1 model machine.
This technique is necessary for debugging, but makes no
sense for production.

The initramfs method shipped by SuSE is more flexible, allowing
the hacker to stick the DSDT image in the initrd and use it
without re-compiling the kernel.

I have refused to accept the initrd patch into Linux many times,
and always will.

I've advised SuSE many times that they should not be shipping it,
as it means that their supported OS is running on modified firmware --
which, by definition, they can not support.  Indeed, one could view
this method as couter-productive to the evolution of Linux --
since it is our stated goal to run on the same machines that Windows
runs on -- without requiring customers to modify those machines
to run Linux.

-Len

Re: Options depending on STANDALONE

[Greg KH]

On Thu, Aug 03, 2006 at 04:49:08PM -0400, Brown, Len wrote:
> I've advised SuSE many times that they should not be shipping it,
> as it means that their supported OS is running on modified firmware --
> which, by definition, they can not support.  Indeed, one could view
> this method as couter-productive to the evolution of Linux --
> since it is our stated goal to run on the same machines that Windows
> runs on -- without requiring customers to modify those machines
> to run Linux.

Ok, if it's your position that we should not support this, I'll see what
I can do to remove it from our kernel tree...

If there are any other patches that we are carrying that you (or anyone
else) feel we should not be, please let me know.

thanks,

greg k-h

Re: Options depending on STANDALONE

[Dave Jones]

On Thu, Aug 03, 2006 at 01:51:27PM -0700, Greg Kroah-Hartman wrote:
 > On Thu, Aug 03, 2006 at 04:49:08PM -0400, Brown, Len wrote:
 > > I've advised SuSE many times that they should not be shipping it,
 > > as it means that their supported OS is running on modified firmware --
 > > which, by definition, they can not support.  Indeed, one could view
 > > this method as couter-productive to the evolution of Linux --
 > > since it is our stated goal to run on the same machines that Windows
 > > runs on -- without requiring customers to modify those machines
 > > to run Linux.
 > 
 > Ok, if it's your position that we should not support this, I'll see what
 > I can do to remove it from our kernel tree...
 > 
 > If there are any other patches that we are carrying that you (or anyone
 > else) feel we should not be, please let me know.

It's somewhat hard to tell when the source rpm's don't match the binaries.
See ftp://ftp.suse.com/pub/projects/kernel/kotd/x86_64/HEAD for example,
and notice the lack of 2.6.18rc3 source, just 2.6.16.  Or am I looking
in the wrong place ? (The other arch's all seem to suffer this curious problem).

		Dave




-- 
http://www.codemonkey.org.uk

Re: Options depending on STANDALONE

[Greg KH]

On Thu, Aug 03, 2006 at 05:01:30PM -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 01:51:27PM -0700, Greg Kroah-Hartman wrote:
>  > On Thu, Aug 03, 2006 at 04:49:08PM -0400, Brown, Len wrote:
>  > > I've advised SuSE many times that they should not be shipping it,
>  > > as it means that their supported OS is running on modified firmware --
>  > > which, by definition, they can not support.  Indeed, one could view
>  > > this method as couter-productive to the evolution of Linux --
>  > > since it is our stated goal to run on the same machines that Windows
>  > > runs on -- without requiring customers to modify those machines
>  > > to run Linux.
>  > 
>  > Ok, if it's your position that we should not support this, I'll see what
>  > I can do to remove it from our kernel tree...
>  > 
>  > If there are any other patches that we are carrying that you (or anyone
>  > else) feel we should not be, please let me know.
> 
> It's somewhat hard to tell when the source rpm's don't match the binaries.
> See ftp://ftp.suse.com/pub/projects/kernel/kotd/x86_64/HEAD for example,
> and notice the lack of 2.6.18rc3 source, just 2.6.16.  Or am I looking
> in the wrong place ? (The other arch's all seem to suffer this curious problem).

Bleah, our KOTD build is still broken...

We do have a 2.6.18rc3 kernel, and everything rebased on that, but it's
not getting out to the world just yet for some odd reason.  It will show
up in the next Opensuse 10.2 Alpha release some time next week, but it
should be mirroring nightly too.

/me goes off to kick the build system

thanks,

greg k-h

RE: Options depending on STANDALONE

[Thomas Renninger]

On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote:
> >On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> >> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> >> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
> >> people prefer to get the kernel working with all original DSDTs
> >> (which usually work with at least one other OS) than letting 
> >> the people workaround the problem by using a custom DSDT.
> >
> >Not true at all.  For SuSE kernels, we have a patch that lets people
> >load a new DSDT from initramfs due to broken machines requiring a
> >replacement in order to work properly.
> 
> CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
> by building a modified DSDT into the kernel to over-ride what
> came with the system.  It would make no sense for a distro
> to use it, unless the distro were shipping only on 1 model machine.
> This technique is necessary for debugging, but makes no
> sense for production.
> 
> The initramfs method shipped by SuSE is more flexible, allowing
> the hacker to stick the DSDT image in the initrd and use it
> without re-compiling the kernel.
> 
> I have refused to accept the initrd patch into Linux many times,
> and always will.
> 
> I've advised SuSE many times that they should not be shipping it,
> as it means that their supported OS is running on modified firmware --
> which, by definition, they can not support.  
Tainting the kernel if done so should be sufficient.
> Indeed, one could view
> this method as couter-productive to the evolution of Linux --
> since it is our stated goal to run on the same machines that Windows
> runs on -- without requiring customers to modify those machines
> to run Linux.

There are three reasons for the initrd patch (last one also applies for
the compile in functionality):

1)
There might be "BIOS bugs" that will never get fixed:
https://bugzilla.novell.com/show_bug.cgi?id=160671
(Because it's an obvious BIOS bug, "compatibility" fixing it could make
things worse).

2)
There might be "ACPICA/kernel bugs" that take a while until they get
fixed:

This happens often. There comes out a new machine, using AML in a
slightly other way, we need to fix it in kernel/ACPICA. Until the patch
appears mainline may take a month or two. Until the distro of your
choice that makes use of the fix comes out might take half a year or
more...
And backporting ACPICA fixes to older kernels is currently not possible
as ACPICA patches appear in a big bunch of some thousand lines patches.
But this hopefully changes soon.

In my mind come:
- alias broken in certain cases
   https://bugziall.novell.com/show_bug.cgi?id=113099
- recon amount of elements in packages
   https://bugzilla.novell.com/show_bug.cgi?id=189488
- wrong offsets at Field and Operation Region declarations
   -> should be compatible for quite a while now
- ...

3)
Debugging.
This is why at least compile in or via initrd must be provided in
mainline kernel IMHO. Intel people themselves ask the bug reporter to
override ACPI tables with a patched table to debug the system.
Do you really think ripping out all overriding functionality from the
kernel is a good idea?

     Thomas

It is true that some users are happy with a fixed DSDT, even you tell
them to find the root cause..., but sooner or later they always come
back.

Re: Options depending on STANDALONE

[Greg KH]

On Mon, Aug 07, 2006 at 07:33:31PM +0200, Thomas Renninger wrote:
> On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote:
> > >On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> > >> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> > >> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
> > >> people prefer to get the kernel working with all original DSDTs
> > >> (which usually work with at least one other OS) than letting 
> > >> the people workaround the problem by using a custom DSDT.
> > >
> > >Not true at all.  For SuSE kernels, we have a patch that lets people
> > >load a new DSDT from initramfs due to broken machines requiring a
> > >replacement in order to work properly.
> > 
> > CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
> > by building a modified DSDT into the kernel to over-ride what
> > came with the system.  It would make no sense for a distro
> > to use it, unless the distro were shipping only on 1 model machine.
> > This technique is necessary for debugging, but makes no
> > sense for production.
> > 
> > The initramfs method shipped by SuSE is more flexible, allowing
> > the hacker to stick the DSDT image in the initrd and use it
> > without re-compiling the kernel.
> > 
> > I have refused to accept the initrd patch into Linux many times,
> > and always will.
> > 
> > I've advised SuSE many times that they should not be shipping it,
> > as it means that their supported OS is running on modified firmware --
> > which, by definition, they can not support.  
> Tainting the kernel if done so should be sufficient.
> > Indeed, one could view
> > this method as couter-productive to the evolution of Linux --
> > since it is our stated goal to run on the same machines that Windows
> > runs on -- without requiring customers to modify those machines
> > to run Linux.
> 
> There are three reasons for the initrd patch (last one also applies for
> the compile in functionality):

<snip>

Yeah, you and others within SuSE have convinced me to not drop this
patch from our kernel tree.

Sorry Len.

thanks,

greg k-h

Re: Options depending on STANDALONE

[Eric Piel]

08/07/2006 07:33 PM, Thomas Renninger wrote/a écrit:
> 
> There are three reasons for the initrd patch (last one also applies for
> the compile in functionality):
Hi, I just happen to be the maintainer "this initrd patch" ;-) I agree 
with you Thomas. IMHO, this patch is really useful in our "not so 
perfect" world. Few more comments below:

> 
> 1)
> There might be "BIOS bugs" that will never get fixed:
> https://bugzilla.novell.com/show_bug.cgi?id=160671
> (Because it's an obvious BIOS bug, "compatibility" fixing it could make
> things worse).
This is really feature #1, PC manufacturers come to sometimes extremely 
ugly things when they code their ACPI tables. You can find lots of BIOS 
containing in their ACPI tables tests like "do this if OS name is 13 
letters long, and that if OS name is 11 letters long..." Obviously 
Linux is most of the time not within those tests!

1.5) Feature adding. Some (crazy?) people are working on new 
implementation of their ACPI table to add features (cf the "Smart 
Battery System for Linux" project).

In those two cases, you really can't expect every user to recompile it's 
Linux kernel to get an new DSDT table :-)

> 2)
> There might be "ACPICA/kernel bugs" that take a while until they get
> fixed:
> 
> This happens often. There comes out a new machine, using AML in a
> slightly other way, we need to fix it in kernel/ACPICA. Until the patch
> appears mainline may take a month or two. Until the distro of your
> choice that makes use of the fix comes out might take half a year or
> more...
> And backporting ACPICA fixes to older kernels is currently not possible
> as ACPICA patches appear in a big bunch of some thousand lines patches.
> But this hopefully changes soon.
> 
> In my mind come:
> - alias broken in certain cases
>    https://bugziall.novell.com/show_bug.cgi?id=113099
> - recon amount of elements in packages
>    https://bugzilla.novell.com/show_bug.cgi?id=189488
> - wrong offsets at Field and Operation Region declarations
>    -> should be compatible for quite a while now
> - ...
Agree, although I  believe of this as more an excuse than a reason. 
Linux is still full of bugs, lots of which cannot be fixed by ACPI table 
swapping anyway...

> 3)
> Debugging.
> This is why at least compile in or via initrd must be provided in
> mainline kernel IMHO. Intel people themselves ask the bug reporter to
> override ACPI tables with a patched table to debug the system.
> Do you really think ripping out all overriding functionality from the
> kernel is a good idea?
Well, I think even Len agree with this usage :-)

All in all, I'm really _not_ asking for inclusion of the patch in the 
main tree. Just asking you not to think too much bad of the distros 
which use this patch ;-) (IIRC, at least Mandriva and Ubuntu include it 
in addition to SuSE)

See you,
Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Options depending on STANDALONE

[Thomas Renninger]

On Mon, 2006-08-07 at 19:33 +0200, Thomas Renninger wrote:
> On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote:
> > >On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> > >> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> > >> It's anyway not usable for distribution kernels, and AFAIR the ACPI 
> > >> people prefer to get the kernel working with all original DSDTs
> > >> (which usually work with at least one other OS) than letting 
> > >> the people workaround the problem by using a custom DSDT.
> > >
> > >Not true at all.  For SuSE kernels, we have a patch that lets people
> > >load a new DSDT from initramfs due to broken machines requiring a
> > >replacement in order to work properly.
> > 
> > CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
> > by building a modified DSDT into the kernel to over-ride what
> > came with the system.  It would make no sense for a distro
> > to use it, unless the distro were shipping only on 1 model machine.
> > This technique is necessary for debugging, but makes no
> > sense for production.
> > 
> > The initramfs method shipped by SuSE is more flexible, allowing
> > the hacker to stick the DSDT image in the initrd and use it
> > without re-compiling the kernel.
> > 
> > I have refused to accept the initrd patch into Linux many times,
> > and always will.
> > 
> > I've advised SuSE many times that they should not be shipping it,
> > as it means that their supported OS is running on modified firmware --
> > which, by definition, they can not support.  
> Tainting the kernel if done so should be sufficient.
> > Indeed, one could view
> > this method as couter-productive to the evolution of Linux --
> > since it is our stated goal to run on the same machines that Windows
> > runs on -- without requiring customers to modify those machines
> > to run Linux.
> 
> There are three reasons for the initrd patch (last one also applies for
> the compile in functionality):
> 
> 1)
> There might be "BIOS bugs" that will never get fixed:
> https://bugzilla.novell.com/show_bug.cgi?id=160671
> (Because it's an obvious BIOS bug, "compatibility" fixing it could make
> things worse).
> 
> 2)
> There might be "ACPICA/kernel bugs" that take a while until they get
> fixed:
> 
> This happens often. There comes out a new machine, using AML in a
> slightly other way, we need to fix it in kernel/ACPICA. Until the patch
> appears mainline may take a month or two. Until the distro of your
> choice that makes use of the fix comes out might take half a year or
> more...
> And backporting ACPICA fixes to older kernels is currently not possible
> as ACPICA patches appear in a big bunch of some thousand lines patches.
> But this hopefully changes soon.
> 
> In my mind come:
> - alias broken in certain cases
>    https://bugziall.novell.com/show_bug.cgi?id=113099
> - recon amount of elements in packages
>    https://bugzilla.novell.com/show_bug.cgi?id=189488
> - wrong offsets at Field and Operation Region declarations
>    -> should be compatible for quite a while now
> - ...
> 
> 3)
> Debugging.
> This is why at least compile in or via initrd must be provided in
> mainline kernel IMHO. Intel people themselves ask the bug reporter to
> override ACPI tables with a patched table to debug the system.
> Do you really think ripping out all overriding functionality from the
> kernel is a good idea?

A last sentence...
I forgot the most important point that could make all others obsolete:
4)
Vendors don't care about Linux yet.
For laptops I know two vendors who eventually would fix their BIOS (for
special models, HP and Lenovo) and provide a BIOS update for customers.
If we could convince those to at least validate their BIOSes with Intel
ACPICA in some way, most stuff described in point 2 would not happen.
Hopefully Novell has more influence here than SUSE had to make at least
the big players take more care about Linux support. I think it's getting
better...

I hope those who never used ACPICA and ignored any "Could you please
switch this byte for us in AML code" cries from Linux customers will get
punished with incompatibility with newer M$ ACPI interpreters at some
time and will be forced to provide last minute updates and I hope it
hurts.

   Thomas