Here are some more of, probably well-known, warnings with attached
testing-only .config.
Regards,
Jarek P.
sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
drivers/pci/search.c: In function `pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
Root device is (8, 1)
Setup is 11036 bytes (padded to 11264 bytes).
System is 2428 kB
Fix this warning:
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
(I don't know whether this fix hits the real problem.)
Signed-off-by: WANG Cong <[email protected]>
---
drivers/acpi/ec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc3-git3/drivers/acpi/ec.c
===================================================================
--- linux-2.6.23-rc3-git3.orig/drivers/acpi/ec.c
+++ linux-2.6.23-rc3-git3/drivers/acpi/ec.c
@@ -869,8 +869,8 @@ int __init acpi_ec_ecdt_probe(void)
boot_ec->handle = ACPI_ROOT_OBJECT;
} else {
printk(KERN_DEBUG PREFIX "Look up EC in DSDT\n");
- status = acpi_get_devices(ec_device_ids[0].id, ec_parse_device,
- boot_ec, NULL);
+ status = acpi_get_devices((char *)ec_device_ids[0].id,
+ ec_parse_device, boot_ec, NULL);
if (ACPI_FAILURE(status))
goto error;
}
WANG Cong wrote:
> Fix this warning:
>
> drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
>
> (I don't know whether this fix hits the real problem.)
>
It is safe to give acpi_get_devices() const string, as it should not
modify it in any condition.
> Signed-off-by: WANG Cong <[email protected]>
>
>
ACK
Thanks,
Alex
> ---
> drivers/acpi/ec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.23-rc3-git3/drivers/acpi/ec.c
> ===================================================================
> --- linux-2.6.23-rc3-git3.orig/drivers/acpi/ec.c
> +++ linux-2.6.23-rc3-git3/drivers/acpi/ec.c
> @@ -869,8 +869,8 @@ int __init acpi_ec_ecdt_probe(void)
> boot_ec->handle = ACPI_ROOT_OBJECT;
> } else {
> printk(KERN_DEBUG PREFIX "Look up EC in DSDT\n");
> - status = acpi_get_devices(ec_device_ids[0].id, ec_parse_device,
> - boot_ec, NULL);
> + status = acpi_get_devices((char *)ec_device_ids[0].id,
> + ec_parse_device, boot_ec, NULL);
> if (ACPI_FAILURE(status))
> goto error;
> }
>
On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
> WANG Cong wrote:
> > Fix this warning:
> >
> > drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> > drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
> >
> > (I don't know whether this fix hits the real problem.)
> >
> It is safe to give acpi_get_devices() const string, as it should not
> modify it in any condition.
Signed-off-by: Al Viro <[email protected]>
---
diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
index ab65b2c..f39fbc6 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -540,7 +540,7 @@ acpi_ns_get_device_callback(acpi_handle obj_handle,
******************************************************************************/
acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
acpi_walk_callback user_function,
void *context, void **return_value)
{
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index b5cca5d..3d7ab9e 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -130,7 +130,7 @@ acpi_walk_namespace(acpi_object_type type,
void *context, void **return_value);
acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
acpi_walk_callback user_function,
void *context, void **return_value);
diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
index aeb4498..8848265 100644
--- a/include/acpi/acstruct.h
+++ b/include/acpi/acstruct.h
@@ -146,7 +146,7 @@ struct acpi_init_walk_info {
struct acpi_get_devices_info {
acpi_walk_callback user_function;
void *context;
- char *hid;
+ const char *hid;
};
union acpi_aml_operands {
Al Viro wrote:
> On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
>
>> WANG Cong wrote:
>>
>>> Fix this warning:
>>>
>>> drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
>>> drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
>>>
>>> (I don't know whether this fix hits the real problem.)
>>>
>>>
>> It is safe to give acpi_get_devices() const string, as it should not
>> modify it in any condition.
>>
>
>
Yes, that is the proper solution with a single drawback:
it touches ACPICA dual-licensed code and would take ages to commit,
and Len would probably ask you to give permission to re-license it under
BSD.
Regards,
Alex.
> Signed-off-by: Al Viro <[email protected]>
> ---
> diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
> index ab65b2c..f39fbc6 100644
> --- a/drivers/acpi/namespace/nsxfeval.c
> +++ b/drivers/acpi/namespace/nsxfeval.c
> @@ -540,7 +540,7 @@ acpi_ns_get_device_callback(acpi_handle obj_handle,
> ******************************************************************************/
>
> acpi_status
> -acpi_get_devices(char *HID,
> +acpi_get_devices(const char *HID,
> acpi_walk_callback user_function,
> void *context, void **return_value)
> {
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index b5cca5d..3d7ab9e 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -130,7 +130,7 @@ acpi_walk_namespace(acpi_object_type type,
> void *context, void **return_value);
>
> acpi_status
> -acpi_get_devices(char *HID,
> +acpi_get_devices(const char *HID,
> acpi_walk_callback user_function,
> void *context, void **return_value);
>
> diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
> index aeb4498..8848265 100644
> --- a/include/acpi/acstruct.h
> +++ b/include/acpi/acstruct.h
> @@ -146,7 +146,7 @@ struct acpi_init_walk_info {
> struct acpi_get_devices_info {
> acpi_walk_callback user_function;
> void *context;
> - char *hid;
> + const char *hid;
> };
>
> union acpi_aml_operands {
>
On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote:
> Yes, that is the proper solution with a single drawback:
> it touches ACPICA dual-licensed code and would take ages to commit,
> and Len would probably ask you to give permission to re-license it under
> BSD.
The latter is certainly not a problem (assuming that it's non-trivial
enough to be copyrightable, in the first place).
On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
>Here are some more of, probably well-known, warnings with attached
>testing-only .config.
>
>Regards,
>Jarek P.
>
>
>sed: -e expression #1, char 154: Unknown option to 's'
>drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
>drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
>drivers/pci/search.c: In function `pci_find_slot':
>drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
>drivers/pci/search.c: At top level:
>drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
>drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
>drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
>drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
>drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
>drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
>drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
>In file included from drivers/usb/host/ohci-hcd.c:859:
>drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
>drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined.
See the following:
<snip>
if (device_may_wakeup(&pdev->dev))
ohci->hc_control |= OHCI_CTRL_RWC;
<snip>
Or a bug of gcc?
--
_ /|
\'o.O'
=(___)=
U ack!
On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> Here are some more of, probably well-known, warnings with attached
> testing-only .config.
>
> Regards,
> Jarek P.
>
>
> sed: -e expression #1, char 154: Unknown option to 's'
> drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
> drivers/pci/search.c: In function `pci_find_slot':
> drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
> drivers/pci/search.c: At top level:
> drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> In file included from drivers/usb/host/ohci-hcd.c:859:
> drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
> drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
> Root device is (8, 1)
> Setup is 11036 bytes (padded to 11264 bytes).
> System is 2428 kB
What gcc version? I don't get the arch_ warnings in drivers/pci/msi.c.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Wed, Aug 22, 2007 at 12:17:23AM +0800, WANG Cong wrote:
> On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
> >Here are some more of, probably well-known, warnings with attached
> >testing-only .config.
> >
> >Regards,
> >Jarek P.
> >
> >
> >sed: -e expression #1, char 154: Unknown option to 's'
> >drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> >drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
> >drivers/pci/search.c: In function `pci_find_slot':
> >drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
> >drivers/pci/search.c: At top level:
> >drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> >drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> >drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> >drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> >drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> >drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> >drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> >In file included from drivers/usb/host/ohci-hcd.c:859:
> >drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
> >drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined.
> See the following:
>
> <snip>
> if (device_may_wakeup(&pdev->dev))
> ohci->hc_control |= OHCI_CTRL_RWC;
> <snip>
>
> Or a bug of gcc?
gcc bug, I have a patch for this queued up.
thanks,
greg k-h
On Tue, Aug 21, 2007 at 09:44:29AM -0700, Greg KH wrote:
> On Wed, Aug 22, 2007 at 12:17:23AM +0800, WANG Cong wrote:
> > On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
> > >Here are some more of, probably well-known, warnings with attached
> > >testing-only .config.
> > >
> > >Regards,
> > >Jarek P.
> > >
> > >
> > >sed: -e expression #1, char 154: Unknown option to 's'
> > >drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> > >drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
> > >drivers/pci/search.c: In function `pci_find_slot':
> > >drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
> > >drivers/pci/search.c: At top level:
> > >drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> > >drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
> > >drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> > >drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
> > >drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > >drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > >drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> > >In file included from drivers/usb/host/ohci-hcd.c:859:
> > >drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
> > >drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined.
> > See the following:
> >
> > <snip>
> > if (device_may_wakeup(&pdev->dev))
> > ohci->hc_control |= OHCI_CTRL_RWC;
> > <snip>
> >
> > Or a bug of gcc?
>
> gcc bug, I have a patch for this queued up.
No, gcc is all right.
The problem is that with CONFIG_PM=y, CONFIG_PM_SLEEP=n
device_may_wakeup() is an empty macro, and the pdev usage is in this
case removed by the preprocessor and therefore invisible to the
compiler.
> 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
On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
>
> > Here are some more of, probably well-known, warnings with attached
> > testing-only .config.
> >...
> > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> >...
>
> What gcc version? I don't get the arch_ warnings in drivers/pci/msi.c.
Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
You can reproduce it with a more recent gcc when adding
-fno-unit-at-a-time to the CFLAGS.
And it's becoming a real maintainance problem that not only this problem
but also other problems like some section mismatches [2] are only
present without unit-at-a-time.
Currently we support 6 different stable gcc release series, and it might
be the right time to consider dropping support for the older ones.
Are there any architectures still requiring a gcc < 4.0 ?
> ~Randy
cu
Adrian
[1] unit-at-a-time was added in gcc 3.4, but on gcc 3.4 we disable it on
i386 due to stack usage problems
[2] example: static __init function with exactly one caller, and this
caller is non-__init
--
"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
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> > On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> >
> > > Here are some more of, probably well-known, warnings with attached
> > > testing-only .config.
> > >...
> > > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> > >...
> >
> > What gcc version? I don't get the arch_ warnings in drivers/pci/msi.c.
>
> Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
>
> You can reproduce it with a more recent gcc when adding
> -fno-unit-at-a-time to the CFLAGS.
>
> And it's becoming a real maintainance problem that not only this problem
> but also other problems like some section mismatches [2] are only
> present without unit-at-a-time.
>
> Currently we support 6 different stable gcc release series, and it might
> be the right time to consider dropping support for the older ones.
>
> Are there any architectures still requiring a gcc < 4.0 ?
I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
>From my point of view, gcc 4 compilers have been something of a development
thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and
significantly less noisy than gcc 4.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
Actually there are widely used 3.3 variants that support unit-at-a-time
(e.g. 3.3-hammer which was shipped by several distributions for some time)
There are still a lot of systems around which use gcc 3.3 (less so with
3.4). Unless there's a major bug that is hard to work around I would
prefer to keep it supported.
Bogus warnings should be relatively harmless.
> And it's becoming a real maintainance problem that not only this problem
> but also other problems like some section mismatches [2] are only
> present without unit-at-a-time.
The unit-at-a-time output order is not defined, so even if it works
with the current compiler a compiler change might still trigger
that problem. So it would be better to fix those anyways.
-Andi
On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
> I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
> From my point of view, gcc 4 compilers have been something of a development
> thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and
> significantly less noisy than gcc 4.
>
+1, similar reasons, for parisc. Not that gcc4 doesn't work, but there's
some cases where gcc 3.4 still generates better code...
Regards,
Kyle M.
On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> > On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> > > On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> > >
> > > > Here are some more of, probably well-known, warnings with attached
> > > > testing-only .config.
> > > >...
> > > > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > > > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > > > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> > > >...
> > >
> > > What gcc version? I don't get the arch_ warnings in drivers/pci/msi.c.
> >
> > Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
> >
> > You can reproduce it with a more recent gcc when adding
> > -fno-unit-at-a-time to the CFLAGS.
> >
> > And it's becoming a real maintainance problem that not only this problem
> > but also other problems like some section mismatches [2] are only
> > present without unit-at-a-time.
> >
> > Currently we support 6 different stable gcc release series, and it might
> > be the right time to consider dropping support for the older ones.
> >
> > Are there any architectures still requiring a gcc < 4.0 ?
>
> I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
> >From my point of view, gcc 4 compilers have been something of a development
> thing as far as the ARM architecture goes.
>...
It is an option to say "gcc >= 4.0 on i386 and >= 3.4 on all other
architectures is required".
> Russell King
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
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> Are there any architectures still requiring a gcc < 4.0 ?
Yes, sadly in some places (embedded) there are people with older
compiler who want newer kernels.
On Tue, Aug 21, 2007 at 09:19:59PM +0200, Andi Kleen wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> > Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
>
> Actually there are widely used 3.3 variants that support unit-at-a-time
> (e.g. 3.3-hammer which was shipped by several distributions for some time)
>
> There are still a lot of systems around which use gcc 3.3 (less so with
> 3.4). Unless there's a major bug that is hard to work around I would
> prefer to keep it supported.
>
> Bogus warnings should be relatively harmless.
How many kernel developers use such old gcc versions?
And how many people notice the valid modpost warnings that can indicate
a runtime Oops?
> > And it's becoming a real maintainance problem that not only this problem
> > but also other problems like some section mismatches [2] are only
> > present without unit-at-a-time.
>
> The unit-at-a-time output order is not defined, so even if it works
> with the current compiler a compiler change might still trigger
> that problem. So it would be better to fix those anyways.
The example [2] from my email is guaranteed to not be a problem with
unit-at-a-time (as long as unit-at-a-time implies
inline-functions-called-once - and that's although theoretically
possible quite unlikely to change in practice).
This example is for a bug that should be fixed, but my point is the
maintainability, IOW: issues with older compilers might not be
discovered and fixed before they go into a stable kernel.
We currently support 6 different stable gcc release series plus heavily
modified vendor branches like 3.3-hammer. We can discuss whether it is
now already the right time, and where to make the cut, but medium-term
we must reduce the number of supported compilers.
> -Andi
cu
Adrian
[2] example: static __init function with exactly one caller, and this
caller is non-__init
--
"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
On Tue, Aug 21, 2007 at 09:54:33PM +0200, Adrian Bunk wrote:
> We currently support 6 different stable gcc release series plus heavily
> modified vendor branches like 3.3-hammer. We can discuss whether it is
> now already the right time, and where to make the cut, but medium-term
> we must reduce the number of supported compilers.
I don't think that's feasible. We're dealing with a situation where:
- GCC aim to release a new compiler series every 6 months.
Fortunately, they don't achieve this goal, but they do release every
12 months or thereabouts [1].
- Enterprise distros are supported for seven years
- We still care about people being able to compile kernels on
enterprise distros that are still supported by their vendor.
Yes, it causes us some pain to support all these different compilers,
but it's not *that* big a pain.
[1] Release dates, according to the GCC website
2007-05-17 4.2.0 (14 months)
2006-02-28 4.1.0 (10 months)
2005-04-20 4.0.0 (12 months)
2004-04-20 3.4.0 (11 months)
2003-05-20 3.3 (12 months, ignoring gcc 3.2 which was really 3.1.2)
2002-05-15 3.1 (11 months)
2001-06-18 3.0
--
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Tue, 21 Aug 2007, Adrian Bunk wrote:
> >
> > Bogus warnings should be relatively harmless.
>
> How many kernel developers use such old gcc versions?
It's NOT about "kernel developers".
It's about random people testing kernels.
If we make it harder for people to test kernels, we're going to lose. So
no, I vote for *not* cutting off old gcc versions unless it's absolutely
fatal.
Linus
On Tue, Aug 21, 2007 at 01:08:25PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 21 Aug 2007, Adrian Bunk wrote:
> > >
> > > Bogus warnings should be relatively harmless.
> >
> > How many kernel developers use such old gcc versions?
>
> It's NOT about "kernel developers".
>
> It's about random people testing kernels.
>
> If we make it harder for people to test kernels, we're going to lose. So
> no, I vote for *not* cutting off old gcc versions unless it's absolutely
> fatal.
How many people e.g. test -rc kernels compiled with gcc 3.2?
> Linus
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
On Tue, 21 Aug 2007, Adrian Bunk wrote:
>
> How many people e.g. test -rc kernels compiled with gcc 3.2?
How could anybody know?
Linus
On 8/21/07, Chris Wedgwood <[email protected]> wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
>
> > Are there any architectures still requiring a gcc < 4.0 ?
>
> Yes, sadly in some places (embedded) there are people with older
> compiler who want newer kernels.
Last time I tried a mips build, it would fail the compile unless I was
using _exactly_ 3.4.4 (I didn't tried older versions, but did try
3.4.6, for ex.). So I also think the 3.4 series will still have to be
around for a while.
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
> How many people e.g. test -rc kernels compiled with gcc 3.2?
Why would that matter? It either works or not. If it doesn't
work, it can either be fixed, or support for that old compiler
version can be removed.
The only other policy than "only remove support if things are
badly broken" would be "only support what the GCC team supports",
which would be >= 4.1 now; and there are very good arguments for
supporting more than that with the Linux kernel.
Segher
> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.).
If 3.4.4 works where 3.4.6 doesn't, you should report this as a
bug; either here, or to the GCC team (but please be aware that the
3.4 series isn't supported anymore), or to whoever built that
compiler for you.
> So I also think the 3.4 series will still have to be
> around for a while.
Huh? 3.4 doesn't work for you, so that's why it should stay
a supported compiler?
Segher
On 8/21/07, Segher Boessenkool <[email protected]> wrote:
> > Last time I tried a mips build, it would fail the compile unless I was
> > using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> > 3.4.6, for ex.).
>
> If 3.4.4 works where 3.4.6 doesn't, you should report this as a
> bug; either here, or to the GCC team (but please be aware that the
> 3.4 series isn't supported anymore), or to whoever built that
> compiler for you.
I didn't bothered reporting it here because linux-mips website quotes
explicitly the dependency on 3.4.4. So at least, I imagined they are
aware of it. (And as you said, no point in reporting it to gcc...)
> > So I also think the 3.4 series will still have to be
> > around for a while.
>
> Huh? 3.4 doesn't work for you, so that's why it should stay
> a supported compiler?
3.4.4 does. anyway, by this phrase, I only meant: "Dropping support
for 3.4 series won't help in this case"
--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
>> How many people e.g. test -rc kernels compiled with gcc 3.2?
>
> Why would that matter? It either works or not. If it doesn't
> work, it can either be fixed, or support for that old compiler
> version can be removed.
One bug report "kernel doesn't work / crash / ... when compiled with
gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost
in the big pile of unhandled bugs, not cause the removal of gcc 3.2
support...
> The only other policy than "only remove support if things are
> badly broken" would be "only support what the GCC team supports",
> which would be >= 4.1 now; and there are very good arguments for
> supporting more than that with the Linux kernel.
No, it's not about bugs in gcc, it's about kernel+gcc combinations that
are mostly untested but officially supported.
E.g. how many kernel developers use kernels compiled without
unit-at-a-time? And unit-at-a-time does paper over some bugs,
e.g. at about half a dozen section mismatch bugs I've fixed
recently are not present with it.
But as the discussions have shown gcc 4.0 is currently too high for
making a cut, and it is not yet the right time for raising the minimum
required gcc version.
> Segher
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
Hi all!
I think it's bad idea, when removing support for gcc3.x, while some
people using debian 3.1 at now and under debian 3.1 the default
comiler is 3.3.5, when I good know or not!?
On Tue, 2007-08-21 at 23:21 +0200, Adrian Bunk wrote:
> On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
> >> How many people e.g. test -rc kernels compiled with gcc 3.2?
> >
> > Why would that matter? It either works or not. If it doesn't
> > work, it can either be fixed, or support for that old compiler
> > version can be removed.
>
> One bug report "kernel doesn't work / crash / ... when compiled with
> gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost
> in the big pile of unhandled bugs, not cause the removal of gcc 3.2
> support...
What's the bugzilla or pointer to this report please? Those of us who
use gcc-3 as the default kernel compiler will take it seriously (if it
looks to have an impact to our kernel builds) otherwise we can tell you
it's unreproducible/not a problem etc.
James
> > The only other policy than "only remove support if things are
> > badly broken" would be "only support what the GCC team supports",
> > which would be >= 4.1 now; and there are very good arguments for
> > supporting more than that with the Linux kernel.
>
> No, it's not about bugs in gcc, it's about kernel+gcc combinations that
> are mostly untested but officially supported.
>
> E.g. how many kernel developers use kernels compiled without
> unit-at-a-time? And unit-at-a-time does paper over some bugs,
> e.g. at about half a dozen section mismatch bugs I've fixed
> recently are not present with it.
>
> But as the discussions have shown gcc 4.0 is currently too high for
> making a cut, and it is not yet the right time for raising the minimum
> required gcc version.
>
> > Segher
>
> cu
> Adrian
>
On Tue, Aug 21, 2007 at 04:49:38PM -0500, James Bottomley wrote:
> On Tue, 2007-08-21 at 23:21 +0200, Adrian Bunk wrote:
> > On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
> > >> How many people e.g. test -rc kernels compiled with gcc 3.2?
> > >
> > > Why would that matter? It either works or not. If it doesn't
> > > work, it can either be fixed, or support for that old compiler
> > > version can be removed.
> >
> > One bug report "kernel doesn't work / crash / ... when compiled with
> > gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost
> > in the big pile of unhandled bugs, not cause the removal of gcc 3.2
> > support...
>
> What's the bugzilla or pointer to this report please? Those of us who
> use gcc-3 as the default kernel compiler will take it seriously (if it
> looks to have an impact to our kernel builds) otherwise we can tell you
> it's unreproducible/not a problem etc.
This was an example in response to Segher's point we would remove
support for a gcc version in such a case.
I remember we had such issues, but I don't find any pointer to a
specific one at the moment.
I'll keep you informed when bug reports come in that only occur with
older gcc versions and that aren't easily fixable.
> James
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
>>> How many people e.g. test -rc kernels compiled with gcc 3.2?
>>
>> Why would that matter? It either works or not. If it doesn't
>> work, it can either be fixed, or support for that old compiler
>> version can be removed.
>
> One bug report "kernel doesn't work / crash / ... when compiled with
> gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost
> in the big pile of unhandled bugs, not cause the removal of gcc 3.2
> support...
While that might be true, it's a separate problem.
>> The only other policy than "only remove support if things are
>> badly broken" would be "only support what the GCC team supports",
>> which would be >= 4.1 now; and there are very good arguments for
>> supporting more than that with the Linux kernel.
>
> No, it's not about bugs in gcc, it's about kernel+gcc combinations that
> are mostly untested but officially supported.
What does "officially supported" mean? Especially the
"officially" part. Is this documented somewhere?
> E.g. how many kernel developers use kernels compiled without
> unit-at-a-time? And unit-at-a-time does paper over some bugs,
> e.g. at about half a dozen section mismatch bugs I've fixed
> recently are not present with it.
If any developer is interested in supporting some certain old
compiler version, he should be testing regularly with it. Sounds
like that's you ;-)
If no developer is interested, we shouldn't claim to support
using that compiler version.
> But as the discussions have shown gcc 4.0 is currently too high for
> making a cut, and it is not yet the right time for raising the minimum
> required gcc version.
Agreed.
Segher
On Tue, 21 Aug 2007, Adrian Bunk wrote:
> It is an option to say "gcc >= 4.0 on i386 and >= 3.4 on all other
> architectures is required".
if you're going to do something like that, you might as well take
the extra step and start keeping track of which versions of gcc work
with which architectures, along the lines of what dan kegel did with
the results matrix of crosstool:
http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/
i'm being only moderately facetious, of course but, on the other
hand, if there's all this anecdotal information regarding which
combinations work and which don't, maybe it's worth codifying that
into a compilation check somewhere in the build process.
after all, at the moment in init/main.c, any gcc < 3.2 is rejected
outright, while gcc-4.1.0 generates a warning. that's incredibly ad
hoc and certainly incomplete. might as well just write a script for
the scripts/ directory which accepts an architecture and a version of
gcc and tells you what the current situation is and what you can do
about it.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Wed, Aug 22, 2007 at 02:08:33AM +0200, Segher Boessenkool wrote:
> >>>How many people e.g. test -rc kernels compiled with gcc 3.2?
I confirm gcc version:
~/src/linux-2.6.23-rc3$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.2.3/specs
Configured with: ../gcc-3.2.3/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checkingi
--with-gnu-ld --verbose --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 3.2.3
glibc-2.3.2
Sorry, you have to guess this, but, after reporting long time ago some
acpi make warnings, I didn't even suspect anybody would be interested
more this time...
It's an old box with Slackware 9.1, and this make is the last stage
of testing such a hot kernel version... But, according to README gcc
3.2 seems to be legal. (I hope there would be some warning about gcc
too old, anyway.)
Cheers,
Jarek P.
On Tue, Aug 21, 2007 at 01:32:50PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 21 Aug 2007, Adrian Bunk wrote:
> >
> > How many people e.g. test -rc kernels compiled with gcc 3.2?
>
> How could anybody know?
It shouldn't be so hard:
a) statistically: by doing some random math with:
int number_of_seemingly_gcc3.2_reports_eg_per_rc;
int number_of_all_such_reports_eg_per_rc;
int estimated_number_of_all_users_or_developers;
(or maybe some more...)
b) precisely (or even more): by adding proper and often updated
announcements, e.g:
"drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
(BTW, Angelina and Brad will be very suprised this warning is
yet possible!!!)"
Regards,
Jarek P.
On Tue, Aug 21, 2007 at 04:18:20PM +0100, Al Viro wrote:
> On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
> > WANG Cong wrote:
> > > Fix this warning:
> > >
> > > drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
> > > drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type
> > >
> > > (I don't know whether this fix hits the real problem.)
> > >
> > It is safe to give acpi_get_devices() const string, as it should not
> > modify it in any condition.
>
> Signed-off-by: Al Viro <[email protected]>
> ---
> diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
> index ab65b2c..f39fbc6 100644
> --- a/drivers/acpi/namespace/nsxfeval.c
> +++ b/drivers/acpi/namespace/nsxfeval.c
> @@ -540,7 +540,7 @@ acpi_ns_get_device_callback(acpi_handle obj_handle,
> ******************************************************************************/
>
> acpi_status
> -acpi_get_devices(char *HID,
> +acpi_get_devices(const char *HID,
> acpi_walk_callback user_function,
> void *context, void **return_value)
> {
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index b5cca5d..3d7ab9e 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -130,7 +130,7 @@ acpi_walk_namespace(acpi_object_type type,
> void *context, void **return_value);
>
> acpi_status
> -acpi_get_devices(char *HID,
> +acpi_get_devices(const char *HID,
> acpi_walk_callback user_function,
> void *context, void **return_value);
>
> diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
> index aeb4498..8848265 100644
> --- a/include/acpi/acstruct.h
> +++ b/include/acpi/acstruct.h
> @@ -146,7 +146,7 @@ struct acpi_init_walk_info {
> struct acpi_get_devices_info {
> acpi_walk_callback user_function;
> void *context;
> - char *hid;
> + const char *hid;
> };
>
> union acpi_aml_operands {
>
So, it looks like this patch (or at least its -mm version) is working.
Now there is 'only' like this (there could be something new, because
I've forgotten to mention this yesterday's log was the second make,
after removing some small testing patch; here it's after make clean;
.config is the same; gcc 3.2.3):
sed: -e expression #1, char 154: Unknown option to 's'
kernel/power/pm.c:205: warning: `pm_register' is deprecated (declared at kernel/power/pm.c:64)
kernel/power/pm.c:205: warning: `pm_register' is deprecated (declared at kernel/power/pm.c:64)
kernel/power/pm.c:206: warning: `pm_send_all' is deprecated (declared at kernel/power/pm.c:180)
kernel/power/pm.c:206: warning: `pm_send_all' is deprecated (declared at kernel/power/pm.c:180)
drivers/pci/search.c: In function `pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480)
drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
drivers/pci/search.c:437: warning: `pci_find_device' is deprecated (declared at drivers/pci/search.c:244)
drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
drivers/pci/search.c:438: warning: `pci_find_slot' is deprecated (declared at drivers/pci/search.c:96)
drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
include/asm/processor.h: In function `native_get_debugreg':
include/asm/processor.h:524: warning: asm operand 0 probably doesn't match constraints
include/asm/processor.h: In function `native_set_debugreg':
include/asm/processor.h:551: warning: asm operand 0 probably doesn't match constraints
Root device is (8, 1)
Setup is 11036 bytes (padded to 11264 bytes).
System is 2428 kB
Cheers,
Jarek P.
PS: does somebody here remember these old good times:
real 56m19.454s
user 53m38.580s
sys 2m7.610s
On Aug 21 2007 23:41, Oliver Pinter wrote:
>I think it's bad idea, when removing support for gcc3.x, while some
>people using debian 3.1 at now and under debian 3.1 the default
>comiler is 3.3.5, when I good know or not!?
They always lag behind.
Jan
--
On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
>
> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >I think it's bad idea, when removing support for gcc3.x, while some
> >people using debian 3.1 at now and under debian 3.1 the default
> >comiler is 3.3.5, when I good know or not!?
>
> They always lag behind.
Yes! Probably that's why they are so darn good!
Jarek P.
On Aug 22 2007 10:08, Jarek Poplawski wrote:
>On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
>>
>> On Aug 21 2007 23:41, Oliver Pinter wrote:
>> >I think it's bad idea, when removing support for gcc3.x, while some
>> >people using debian 3.1 at now and under debian 3.1 the default
>> >comiler is 3.3.5, when I good know or not!?
>>
>> They always lag behind.
>
>Yes! Probably that's why they are so darn good!
ISTR that even Ubuntu overtook Debian... what about Debian 4.x?
Jan
--
On Tue, Aug 21, 2007 at 05:41:04PM -0300, Glauber de Oliveira Costa wrote:
> On 8/21/07, Chris Wedgwood <[email protected]> wrote:
> > On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> >
> > > Are there any architectures still requiring a gcc < 4.0 ?
> >
> > Yes, sadly in some places (embedded) there are people with older
> > compiler who want newer kernels.
>
> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.). So I also think the 3.4 series will still have to be
> around for a while.
that's fixed and I'm happiliy building the MIPS tree with gcc 3.3.3.
And I would be very unhappy to upgrade all my crosscompiler just because
someone thinks nobody build -rc kernel with older compilers. I do.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
Hi,
On 22/08/07, Jan Engelhardt <[email protected]> wrote:
>
> On Aug 22 2007 10:08, Jarek Poplawski wrote:
> >On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
> >>
> >> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >> >I think it's bad idea, when removing support for gcc3.x, while some
> >> >people using debian 3.1 at now and under debian 3.1 the default
> >> >comiler is 3.3.5, when I good know or not!?
> >>
> >> They always lag behind.
> >
> >Yes! Probably that's why they are so darn good!
>
> ISTR that even Ubuntu overtook Debian... what about Debian 4.x?
They are using gcc 4.1.1 as default
http://packages.debian.org/stable/devel/gcc
Anyway, IMO dropping support for a compiler just because of warnings
it is a bad thing.
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
* Jan Engelhardt <[email protected]> [2007-08-22 09:57]:
> >I think it's bad idea, when removing support for gcc3.x, while some
> >people using debian 3.1 at now and under debian 3.1 the default
> >comiler is 3.3.5, when I good know or not!?
> They always lag behind.
Debian 4.0 has GCC 4.1 as the default compiler, and we use 4.1 to
compile our kernels on all architectures except of m68k.
--
Martin Michlmayr
http://www.cyrius.com/
On Wed, Aug 22, 2007 at 10:10:16AM +0200, Jan Engelhardt wrote:
>
> On Aug 22 2007 10:08, Jarek Poplawski wrote:
> >On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
> >>
> >> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >> >I think it's bad idea, when removing support for gcc3.x, while some
> >> >people using debian 3.1 at now and under debian 3.1 the default
> >> >comiler is 3.3.5, when I good know or not!?
> >>
> >> They always lag behind.
> >
> >Yes! Probably that's why they are so darn good!
>
> ISTR that even Ubuntu overtook Debian... what about Debian 4.x?
I'm glad with KNOPPIX 4.0 too. But, I hope we don't think about Debian
3.1 etc. for a new box & new installation!
Since I've found lynx or links plus some html tool is not enough (too
dangerous) to configure locally cups or samba (don't remember now,
it was around the beginning of Ubuntu), and there is X and probably
gnome necessary for this, and it wasn't like this with other distros,
I think Ubuntu's way of thinking is definitely too good for me...
Jarek P.
PS: this could look like some flame war, or something, so let's say
all (GPL2) Linux distros and all gcc versions are extremely nice!
(...at least not less nice than BSDs...)
On Tue, Aug 21, 2007 at 05:41:04PM -0300, Glauber de Oliveira Costa wrote:
> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.). So I also think the 3.4 series will still have to be
> around for a while.
I don't know what broken MIPS platform you've tried. I keep changing
between compiler versions all the time just so I can ensure builds with
older compilers keep working until we officially deciede to drop support
for them. So the minimum compiler version for 32-bit MIPS kernels is
gcc 3.2 and for 64-bit kernel gcc 3.3.
But for sake of sanity and productivity I definately don't mind dumping
support for gcc < 4.0 or maybe even 4.1. And while we're at it, let's
deprecate ancient binutils version as well. A minimum version of 2.17
would be nice as I could get rid of lads of .word sillyness which is
needed to support older binutils.
Ralf
>On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote:
>> Yes, that is the proper solution with a single drawback:
>> it touches ACPICA dual-licensed code and would take ages to commit,
>> and Len would probably ask you to give permission to
>re-license it under
>> BSD.
>
>The latter is certainly not a problem (assuming that it's non-trivial
>enough to be copyrightable, in the first place).
The dual license is at the top of the file.
I just need to know when you touch one of these dual-license files
that Intel has your permission to ship your change to folks we
send the same file to under the BSD-style non-GPL license.
eg. BSD, Solaris and HPUX uses this same ACPICA files -- though in a
different format.
I've actually never had anybody say no when I asked.
And I've had some people who play laywers on TV tell me
this is not strictly necessary, but other people who play laywers
on TV tell me it is best to ask, so I do.
thanks,
-Len
On Wed, Aug 22, 2007 at 08:59:48PM -0400, Brown, Len wrote:
> The dual license is at the top of the file.
> I just need to know when you touch one of these dual-license files
> that Intel has your permission to ship your change to folks we
> send the same file to under the BSD-style non-GPL license.
> eg. BSD, Solaris and HPUX uses this same ACPICA files -- though in a
> different format.
You have it.