Re: [PATCH] printk-formats.txt documentation update
On Sun, Feb 06, 2011 at 04:23:09PM +, Andrew Murray wrote: On 6 February 2011 16:14, Andrew Murray amur...@mpcdata.com wrote: From: Andrew Murray amur...@mpc-data.co.uk This patch updates the incomplete documentation concerning the printk extended format specifiers. Good one, thanks! +Kernel Pointers: + + %pK 0x0 + + For printing kernel pointers which should be hidden from unprivileged + users. The behaviour of %pK depends on the kptr_resrict sysctl - see Typo: Should be kptr_restrict. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] PM: Hide CONFIG_PM from users
* Mark Brown broo...@opensource.wolfsonmicro.com wrote: It is very rare to find a current system which is both sufficiently resource constrained to want to compile out power management support and sufficiently power insensitive to be able to tolerate doing so. Since having the configuration option requires non-zero effort to maintain, with ifdefery in most drivers, but it is used with vanishing rarity it is simpler to just remove the option. Well, either make it dependent on CONFIG_EXPERT or remove the option altogether. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 01:48:46PM +0100, Ingo Molnar wrote: * Mark Brown broo...@opensource.wolfsonmicro.com wrote: Since having the configuration option requires non-zero effort to maintain, with ifdefery in most drivers, but it is used with vanishing rarity it is simpler to just remove the option. Well, either make it dependent on CONFIG_EXPERT or remove the option altogether. The goal is the latter but when I saw the IA64 emulator there I didn't want to make it instabuggy. The current patch means we get the UI effect of the change (especially in terms of avoiding it turning up in randconfigs or whatever). -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
Hi Mark, On Mon, 7 Feb 2011 12:22:15 + Mark Brown broo...@opensource.wolfsonmicro.com wrote: diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig index 2657299..99e3c52 100644 --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -1,23 +1,6 @@ config PM - bool Power Management support - depends on !IA64_HP_SIM - ---help--- - Power Management means that parts of your computer are shut - off or put into a power conserving sleep mode if they are not - being used. There are two competing standards for doing this: APM - and ACPI. If you want to use either one, say Y here and then also - to the requisite support below. - - Power Management is most important for battery powered laptop - computers; if you have a laptop, check out the Linux Laptop home - page on the WWW at http://www.linux-on-laptops.com/ or - Tuxmobil - Linux on Mobile Computers at http://www.tuxmobil.org/ - and the Battery Powered Linux mini-HOWTO, available from - http://www.tldp.org/docs.html#howto. - - Note that, even if you say N here, Linux on the x86 architecture - will issue the hlt instruction if nothing is to be done, thereby - sending the processor to sleep and saving power. + bool + default y if !IA64_HP_SIM Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the server configs), so this will unexpectedly turn it on for them. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpkFS5I6VqwG.pgp Description: PGP signature
Re: [PATCH] PM: Hide CONFIG_PM from users
Hi Mark, On Mon, 7 Feb 2011 14:18:29 + Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote: On Mon, 7 Feb 2011 12:22:15 + Mark Brown broo...@opensource.wolfsonmicro.com wrote: + bool + default y if !IA64_HP_SIM Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the server configs), so this will unexpectedly turn it on for them. Do you mean that these systems require CONFIG_PM be turned off, or just that people tend not to turn it on? If the latter would you expect any ill effects from doing so? I don't know the answer to either question without testing. All I am saying is that currently the default for CONFIG_PM is off and you are changing it to be on and there may not have been any testing done of that in some situations. We don't know where it was explicitly turned off any more since we shrank our defconfig files (which was done automatically) ... since it is off by default, it doesn't need to be mentioned in a defconfig unless it needs to be turned on. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpGzafpyYxuI.pgp Description: PGP signature
Re: [PATCH] PM: Hide CONFIG_PM from users
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote: On Mon, 7 Feb 2011 14:18:29 + Mark Brown broo...@opensource.wolfsonmicro.com wrote: Do you mean that these systems require CONFIG_PM be turned off, or just that people tend not to turn it on? If the latter would you expect any ill effects from doing so? I don't know the answer to either question without testing. All I am saying is that currently the default for CONFIG_PM is off and you are changing it to be on and there may not have been any testing done of that in some situations. We don't know where it was explicitly turned off any more since we shrank our defconfig files (which was done automatically) ... since it is off by default, it doesn't need to be mentioned in a defconfig unless it needs to be turned on. My suspicion would be that it'll have been turned off by someone hitting return through a config upgrade rather than through deliberate effort. On the other hand if it is essential for some machines to have it disabled they probably want to have somethnig in Kconfig. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 7, 2011 at 15:50, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
On Mon, 7 Feb 2011 14:18:29 + Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on? If the latter would you expect any
ill effects from doing so?
I don't know the answer to either question without testing. All I am
saying is that currently the default for CONFIG_PM is off and you are
changing it to be on and there may not have been any testing done of
that in some situations. We don't know where it was explicitly
turned off any more since we shrank our defconfig files (which was done
automatically) ... since it is off by default, it doesn't need to be
mentioned in a defconfig unless it needs to be turned on.
My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.
$ git grep CONFIG_PM is not set
7cf3d73b4360e91b14326632ab1aeda4cb26308d^ -- arch/ | wc -l
256
$
7cf3d73b4360e91b14326632ab1aeda4cb26308d is the commit that introduced
savedefconfig, so that's a safe revision with untrimmed defconfigs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote: At least some of the powerpc defconfigs were added with CONFIG_PM disabled. I assume that was on purpose (though it may not have been). I'd not be so sure - since it's a bool without an explicit default set Kconfig will default to disabling it and if anything enabling it is the option that requires special effort. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote: On Mon, 7 Feb 2011, Mark Brown wrote: I'd not be so sure - since it's a bool without an explicit default set Kconfig will default to disabling it and if anything enabling it is the option that requires special effort. This may be a naive suggestion, but have you considered simply _asking_ the people who added those defconfigs? I'm rather hoping that they'll notice the mailing list thread or that someone else who knows what's going on with them does - as Geert pointed out there's a considerable number of defconfigs that have this turned off. It seems more sensible to get some idea if this seems sane to people in the general case before going trying to identify and contact so many individuals. If there are systems that really require disabling CONFIG_PM we probably need to add stuff to Kconfig to make sure it can't be enabled anyway; this shouldn't enable any new configurations. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Monday, February 07, 2011, Mark Brown wrote: It is very rare to find a current system which is both sufficiently resource constrained to want to compile out power management support and sufficiently power insensitive to be able to tolerate doing so. Since having the configuration option requires non-zero effort to maintain, with ifdefery in most drivers, but it is used with vanishing rarity it is simpler to just remove the option. Begin doing so by hiding it from users - this should attract complaints from any active users. The option is left disabled for the IA64 Ski simulator which is a partial simulator for IA64 systems mostly missing device support. This is a very limited use case which is unlikely to ever want to enable most drivers. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- kernel/power/Kconfig | 21 ++--- 1 files changed, 2 insertions(+), 19 deletions(-) diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig index 2657299..99e3c52 100644 --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -1,23 +1,6 @@ config PM - bool Power Management support - depends on !IA64_HP_SIM - ---help--- - Power Management means that parts of your computer are shut - off or put into a power conserving sleep mode if they are not - being used. There are two competing standards for doing this: APM - and ACPI. If you want to use either one, say Y here and then also - to the requisite support below. - - Power Management is most important for battery powered laptop - computers; if you have a laptop, check out the Linux Laptop home - page on the WWW at http://www.linux-on-laptops.com/ or - Tuxmobil - Linux on Mobile Computers at http://www.tuxmobil.org/ - and the Battery Powered Linux mini-HOWTO, available from - http://www.tldp.org/docs.html#howto. - - Note that, even if you say N here, Linux on the x86 architecture - will issue the hlt instruction if nothing is to be done, thereby - sending the processor to sleep and saving power. + bool + default y if !IA64_HP_SIM config PM_DEBUG bool Power Management Debug Support I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM. However, there's a number of things that I'm afraid wouldn't build correctly if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case. Anyway, I'll try to prepare a patch doing that and see what happens. Stay tuned. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Mark Brown wrote: config PM_DEBUG bool Power Management Debug Support I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM. That still leaves the IA64 emulator to worry about but I'm not fundamentally opposed to that, it achieves a similar effect. The main thing I'm looking for here is to cut down on the configuration options we have to maintain. However, there's a number of things that I'm afraid wouldn't build correctly if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case. Actually CONFIG_PM_OPS probably also wants to be on independantly of those two sometimes for .poweroff() which I'd expect to run even if we can't suspend. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] printk-formats.txt documentation update
On Mon, 2011-02-07 at 18:12 +, Andrew Murray wrote:
On 7 February 2011 09:29, Wolfram Sang w.s...@pengutronix.de wrote:
On Sun, Feb 06, 2011 at 04:23:09PM +, Andrew Murray wrote:
+
+ For printing kernel pointers which should be hidden from unprivileged
+ users. The behaviour of %pK depends on the kptr_resrict sysctl - see
Typo: Should be kptr_restrict.
Updated patch:
trivia:
diff --git a/Documentation/printk-formats.txt
b/Documentation/printk-formats.txt
[]
+Kernel Pointers:
+
+ %pK 0x0
Bad example, leading zeros are emitted.
%pK 0x01234567 or 0x01234567890abcdef
depending on 32/64 bit. For 2.6.38, output should be 0x
for a 0 if kptr_restrict is set, (null) or value otherwise.
+ For printing kernel pointers which should be hidden from unprivileged
+ users. The behaviour of %pK depends on the kptr_restrict sysctl - see
+ Documentation/sysctl/kernel.txt for more details.
+
+Struct Resources:
+
+ %pr [mem 0x6000-0x6fff flags 0x2200]
+ %pR [mem 0x6000-0x6fff pref]
+
+ For printing struct resources. The 'R' and 'r' specifiers result in a
+ printed resource with ('R') or without ('r') a decoded flags member.
Same issue, mem resources are printed using sizeof(resource_size_t) * 2
+IPv6 addresses:
+
+ %pI60001:0002:0003:0004:0005:0006:0007:0008
+ %pi600010002000300040005000600070008
+ %pI6c 1:2:3:4:5:6:7:8
+
+ For printing IPv6 network-order 16 bit hex addresses. The 'I6' and 'i6'
+ specifiers result in a printed address with ('I6') or without ('i6')
+ colon-separators. Leading zeros are always used.
+
+ The additional 'c' specifier can be used with the 'I' specifier to
+ print a compressed IPv6 address as described by
+ http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00.
It's probably better to use:
http://tools.ietf.org/html/rfc5952
+
+UUID/GUID addresses:
+
+ %pU 00010203-0506-0708-090a-0b0c0d0e0fff
What happened to 04?
It's probably easier/simpler to just show all possible
output styles. Assuming an in memory incrementing
16 byte array, output is:
%pU 00010203-0405-0607-08090a0b0c0d0e0f
+ %pU[bBlL]
%pUb00010203-0405-0607-08090a0b0c0d0e0f
%pUB00010203-0405-0607-08090A0B0C0D0E0F
%pUl03020100-0504-0706-08090a0b0c0d0e0f
%pUL03020100-0504-0706-08090A0B0E0D0E0F
+ For printing 16 byte UUID/GUIDs addresses. The additional 'l', 'L',
+ 'b' and 'B' specifiers are used to specify a little endian order in
+ lower ('l') or upper case ('L') hex characters - and big endian order
+ in lower ('b') or upper case ('B') hex characters.
+
+ Where no additional specifiers are used the default little endian
+ order with lower case hex characters will be printed.
+
+struct va_format:
+
+ %pV
+
+ For printing struct va_format structures. These contain a format string
+ and va_list as follows:
+
+ struct va_format {
+ const char *fmt;
+ va_lost *va;
va_list
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 08:46:48PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Mark Brown wrote: On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote: I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM. That still leaves the IA64 emulator to worry about Why exactly? Actually not so much the IA64 emulator (which does have the !PM dependency declared already - I expect that'd just be moved) as any other platforms with an undeclared dependency on !PM. but I'm not fundamentally opposed to that, it achieves a similar effect. The main thing I'm looking for here is to cut down on the configuration options we have to maintain. But I must say you chose a particularly bad time for that from my point of view. This doesn't seem like it's a worse time than any other? However, there's a number of things that I'm afraid wouldn't build correctly if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case. Actually CONFIG_PM_OPS probably also wants to be on independantly of those two sometimes for .poweroff() which I'd expect to run even if we can't suspend. If you worry about that, then add CONFIG_PM_POWEROFF and make CONFIG_PM(_OPS) depend on it, but I don't think it really is worth it, because people generally don't make the poweroff code depend on CONFIG_PM. Yeah, but some people seem very keen on removing the pointers to the PM ops entirely when CONFIG_PM is disabled which means that you end up with varying idioms for what you do with the PM ops as stuff gets ifdefed out. Then again I'm not sure anything would make those people any happier. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Mon, Feb 07, 2011 at 11:00:03PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Dmitry Torokhov wrote: On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Mark Brown wrote: Yeah, but some people seem very keen on removing the pointers to the PM ops entirely when CONFIG_PM is disabled which means that you end up with varying idioms for what you do with the PM ops as stuff gets ifdefed out. Then again I'm not sure anything would make those people any happier. I really think we should do things that makes sense rather that worry about who's going to like or dislike it (except for Linus maybe, but he tends to like things that make sense anyway). At this point I think the change I suggested makes sense, because it (a) simplifies things and (b) follows the quite common practice which is to make PM callbacks depend on CONFIG_PM. Many people make these callback dependent on PM not because it makes much sense but because it is possible to do so. However, aside of randconfig compile testing, nobody really tests drivers that implement PM in the !CONFIG_PM setting. That I can agree with, but I'm not sure whether it is an argument against the patch I've just posted or for it? More of an observation for your (b) justification. I'd probably force CONFIG_PM to always 'y'w while we weeding references to it from drivers... -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
On Monday, February 07, 2011, Dmitry Torokhov wrote: On Mon, Feb 07, 2011 at 11:00:03PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Dmitry Torokhov wrote: On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote: On Monday, February 07, 2011, Mark Brown wrote: Yeah, but some people seem very keen on removing the pointers to the PM ops entirely when CONFIG_PM is disabled which means that you end up with varying idioms for what you do with the PM ops as stuff gets ifdefed out. Then again I'm not sure anything would make those people any happier. I really think we should do things that makes sense rather that worry about who's going to like or dislike it (except for Linus maybe, but he tends to like things that make sense anyway). At this point I think the change I suggested makes sense, because it (a) simplifies things and (b) follows the quite common practice which is to make PM callbacks depend on CONFIG_PM. Many people make these callback dependent on PM not because it makes much sense but because it is possible to do so. However, aside of randconfig compile testing, nobody really tests drivers that implement PM in the !CONFIG_PM setting. That I can agree with, but I'm not sure whether it is an argument against the patch I've just posted or for it? More of an observation for your (b) justification. I'd probably force CONFIG_PM to always 'y'w while we weeding references to it from drivers... We simply can't force CONFIG_PM to 'y', because some platforms want it to be 'n'. OTOH, if CONFIG_PM = CONFIG_PM_SLEEP||CONFIG_PM_RUNTIME, we can just leave the #ifdefs as they are and simply avoid adding new ones, or use CONFIG_PM for all PM callbacks. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
