login
Search
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 <xiyou.wangcong@gmail.com>
---
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;
}
-
It is safe to give acpi_get_devices() const string, as it should not ACK Thanks, -
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
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 {
-
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, -
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 -
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 ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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!
-
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
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
-
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 *** -
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.
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
-
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: -
+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. -
It is an option to say "gcc >= 4.0 on i386 and >= 3.4 on all other
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
-
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 ======================================================================== -
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." -
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 Huh? 3.4 doesn't work for you, so that's why it should stay a supported compiler? Segher -
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 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." -
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 ] -
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 -
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. 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 -
How many kernel developers use such old gcc versions?
And how many people notice the valid modpost warnings that can indicate
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
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
-
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." -
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 -
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
-
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. -
> 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 -
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
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
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
-
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
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
-
What does "officially supported" mean? Especially the 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 Agreed. Segher -
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. -
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!? -
Yes! Probably that's why they are so darn good! Jarek P. -
ISTR that even Ubuntu overtook Debian... what about Debian 4.x? Jan -- -
Hi, 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/ -
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...) -
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/ -
