* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 13:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, linux-arch
In-Reply-To: <AANLkTimxpRHW2TPwSnufpoeOHoEtkz1iaR3-VsC1qM4j@mail.gmail.com>
On Mon, Feb 07, 2011 at 01:40:28PM +0100, Geert Uytterhoeven wrote:
> Which means that (for now) I don't have to care that CONFIG_PM becomes
> unclearable. Other people may care, though...
The whole point of the patch is that (other than the IA64 emulator which
explicitly requires that CONFIG_PM be disabled) I strongly suspect that
nobody is actually using this configuration except as a result of
randconfig type testing.
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 13:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded
In-Reply-To: <20110207124846.GA10442@elte.hu>
On Mon, Feb 07, 2011 at 01:48:46PM +0100, Ingo Molnar wrote:
> * Mark Brown <broonie@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).
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Ingo Molnar @ 2011-02-07 12:48 UTC (permalink / raw)
To: Mark Brown
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded
In-Reply-To: <1297081335-13631-1-git-send-email-broonie@opensource.wolfsonmicro.com>
* Mark Brown <broonie@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
^ permalink raw reply
* Re: [PATCH] PM: Hide CONFIG_PM from users
From: Geert Uytterhoeven @ 2011-02-07 12:40 UTC (permalink / raw)
To: Mark Brown
Cc: Rafael J. Wysocki, Len Brown, Alan Stern, linux-pm, linux-kernel,
Andrew Morton, Dmitry Torokhov, linux-embedded, linux-arch
In-Reply-To: <1297081335-13631-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Mon, Feb 7, 2011 at 13:22, Mark Brown
<broonie@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.
Hmmm...
> --- 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.
Good to see the PC-centric comments are going away :-)
> -
> - 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
The following architectures do not source "kernel/power/Kconfig":
alpha
cris
h8300
Kconfig
m32r
m68k
m68knommu
microblaze
parisc
score
sparc
tile
um
xtensa
Which means that (for now) I don't have to care that CONFIG_PM becomes
unclearable. Other people may care, though...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* [PATCH] PM: Hide CONFIG_PM from users
From: Mark Brown @ 2011-02-07 12:22 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Alan Stern
Cc: linux-pm, linux-kernel, Andrew Morton, Dmitry Torokhov,
linux-embedded, Mark Brown
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 <broonie@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"
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] printk-formats.txt documentation update
From: Wolfram Sang @ 2011-02-07 9:29 UTC (permalink / raw)
To: Andrew Murray
Cc: Geert Uytterhoeven, linux-embedded, linux kernel, trivial,
rdunlap
In-Reply-To: <AANLkTi=bHe_h1F6Lh=rv6BXmVzkyPSW9u5EKXxpYGuL_@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
On Sun, Feb 06, 2011 at 04:23:09PM +0000, Andrew Murray wrote:
> On 6 February 2011 16:14, Andrew Murray <amurray@mpcdata.com> wrote:
> From: Andrew Murray <amurray@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/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Kconfig: XIP doesn't depend on block
From: Marco Stornelli @ 2011-02-07 7:52 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Linux Kernel, Linux FS Devel, Linux Embedded, Andrew Morton
In-Reply-To: <20110206084440.a6c2df3b.rdunlap@xenotime.net>
2011/2/6 Randy Dunlap <rdunlap@xenotime.net>:
> On Sun, 06 Feb 2011 16:15:00 +0100 Marco Stornelli wrote:
>
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> XIP doesn't depend on block symbol, then we can reorder the Kconfig.
>> For ext2 doesn't change the Kconfig behavior but if other fs will use
>> FS_XIP it won't need to include block support if not needed.
>
> Hi Marco,
>
> Do you know of a filesystem where this matters?
>
Yes, for example mine (pramfs) :)
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
>>
>> --- Kconfig.orig 2011-01-19 00:14:02.000000000 +0100
>> +++ Kconfig 2011-02-06 16:04:51.000000000 +0100
>
> This filename should include path, like
> --- fs/Kconfig.orig
> +++ fs/Kconfig
>
>> @@ -9,13 +9,6 @@ if BLOCK
>> source "fs/ext2/Kconfig"
>> source "fs/ext3/Kconfig"
>> source "fs/ext4/Kconfig"
>> -
>
> The 3 filesystems above are immediately under:
>
> if BLOCK
>
> so ext[234] depend on BLOCK. Why would it matter about FS_XIP?
>
I don't know but for example even POSIX ACL was under "if BLOCK",
maybe there is only an historical refuse.
Marco
^ permalink raw reply
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Tony Ibbs @ 2011-02-06 21:07 UTC (permalink / raw)
To: Grant Likely; +Cc: Tony Ibbs, linux-embedded, rrw
In-Reply-To: <AANLkTin+uw=y8kver3M-9OFOS-z=RvSHvFf_EBVOB71u@mail.gmail.com>
On 3 Feb 2011, at 17:32, Grant Likely wrote:
> The big issue that comes into play when implementing a new protocol in
> Linux is that once it is implemented, we need to support it until the
> end of time.
Indeed.
> That means it needs to be well thought out and there is
> a lot of resistance to implementing something new without first seeing
> that it is a measurable benefit that is worth supporting to the end of
> time.
And I believe this is a good thing. If KBUS doesn't get in, hopefully it
will be because it has been demonstrated why it should not.
> In your case, you'll need to show (or attract) a wider range of
> users who can say, "yes, this is better than the alternatives".
This is one of the reasons I wanted to start by talking to the embedded
linux mailing list, where we can get the attention of people working
with small systems.
> I suggest looking at working with dbus for that exact reason. If dbus
> can be made faster/better/more reliable by using a kbus backend, then
> you've got a big userbase saying that it is a valuable addition.
Well, that's presumably true, but does DBUS *need* to be those
things (i.e., is it doing well enough already), and is that enough
reason to put something into the kernel (previous attempts, e.g.,
http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster,
seem to have foundered).
> It also gives you a broad use-case that will stretch your assumptions
That *is* a good motivation, and is one of the reasons for the CELF
proposals. But I don't think it is sufficient to be KBUS's reason for
existence.
> and improve the implementation before it gets set in stone when
> merged.
and I'm not so convinced on this one, since it seems to present a bit of
a chiken-and-egg problem. We believe KBUS is ready for merging because
we've been using it to good effect. If we don't try to merge it, then we
won't find out if we're right (!). If it should be in the kernel, then
it's better to get it there sooner, so that it can be moulded/grown
in-tree.
> If kbus turns out to only be applicable to your corner of the universe
> then it becomes a lot harder to justify it as a generic Linux
> communication implementation.
On the other hand, that depends on how big the corner is. We've seen
many projects trying to hand construct new socket based systems for lack
of a KBUS, and these generally reinvent the same problems each time. The
idea of KBUS is to get away from that.
If you're working on a large-ish system, needing to interact with the
many high-level components that already interact using DBUS, then
clearly you should be using DBUS for that purpose.
However, if you're building a system from scratch, if you have Linux,
busybox, and a set of programs that need to communicate with each other,
and limited resources, then DBUS is not going to be chosen. But those
systems still need a reliable, already written messaging mechanism,
rather than another ad-hoc approach.
Personally, I don't see KBUS competing with DBUS. DBUS already has its
place, and I assume it is good at what it does. KBUS wants to come in
at a lower level, and satisfy different customers.
Tibs
^ permalink raw reply
* Re: [PATCH] Kconfig: XIP doesn't depend on block
From: Randy Dunlap @ 2011-02-06 16:44 UTC (permalink / raw)
To: Marco Stornelli
Cc: Linux Kernel, Linux FS Devel, Linux Embedded, Andrew Morton
In-Reply-To: <4D4EBAF4.9070403@gmail.com>
On Sun, 06 Feb 2011 16:15:00 +0100 Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> XIP doesn't depend on block symbol, then we can reorder the Kconfig.
> For ext2 doesn't change the Kconfig behavior but if other fs will use
> FS_XIP it won't need to include block support if not needed.
Hi Marco,
Do you know of a filesystem where this matters?
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
>
> --- Kconfig.orig 2011-01-19 00:14:02.000000000 +0100
> +++ Kconfig 2011-02-06 16:04:51.000000000 +0100
This filename should include path, like
--- fs/Kconfig.orig
+++ fs/Kconfig
> @@ -9,13 +9,6 @@ if BLOCK
> source "fs/ext2/Kconfig"
> source "fs/ext3/Kconfig"
> source "fs/ext4/Kconfig"
> -
The 3 filesystems above are immediately under:
if BLOCK
so ext[234] depend on BLOCK. Why would it matter about FS_XIP?
I don't object to the patch if FS_XIP builds/works without BLOCK being
enabled.
> -config FS_XIP
> -# execute in place
> - bool
> - depends on EXT2_FS_XIP
> - default y
> -
> source "fs/jbd/Kconfig"
> source "fs/jbd2/Kconfig"
>
> @@ -38,6 +31,12 @@ source "fs/nilfs2/Kconfig"
>
> endif # BLOCK
>
> +config FS_XIP
> +# execute in place
> + bool
> + depends on EXT2_FS_XIP
> + default y
> +
> # Posix ACL utility routines
> #
> # Note: Posix ACLs can be implemented without these helpers. Never use
>
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-02-06 16:23 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-embedded, linux kernel, trivial, rdunlap
In-Reply-To: <AANLkTimsTJ4smnJUfkvYEkJixKQoZNfq6RHU4moLhT0o@mail.gmail.com>
On 6 February 2011 16:14, Andrew Murray <amurray@mpcdata.com> wrote:
> On 6 February 2011 10:16, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> In the mean time, we also got %pV and %pK. Can you please add them as well? Thx!
>
> Ok how about this revised patch?
>
I've just noticed a zillion spelling mistakes - find below another
revised patch.
From: Andrew Murray <amurray@mpc-data.co.uk>
This patch updates the incomplete documentation concerning the printk
extended format specifiers.
Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
---
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..cad0dda 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -1,4 +1,4 @@
-If variable is of Type, use printk format specifier:
+f variable is of Type, use printk format specifier:
---------------------------------------------------------
int %d or %x
unsigned int %u or %x
@@ -9,7 +9,111 @@ If variable is of Type, use printk format specifier:
size_t %zu or %zx
ssize_t %zd or %zx
-Raw pointer value SHOULD be printed with %p.
+Raw pointer value SHOULD be printed with %p. The kernel supports
+the following extended format specifiers for pointer types:
+
+Symbols/Function Pointers:
+
+ %pF versatile_init+0x0/0x110
+ %pf versatile_init
+ %pS versatile_init+0x0/0x110
+ %ps versatile_init
+
+ For printing symbols and function pointers. The 'S' and 's' specifiers
+ result in the symbol name with ('S') or without ('s') offsets. Where
+ this is used on a kernel without KALLSYMS - the symbol address is
+ printed instead.
+
+ On ia64, ppc64 and parisc64 architectures function pointers are
+ actually function descriptors which must first be resolved. The 'F' and
+ 'f' specifiers perform this resolution and then provide the same
+ functionality as the 'S' and 's' specifiers.
+
+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
+ Documentation/sysctl/kernel.txt for more details.
+
+Struct Resources:
+
+ %pr [mem 0x60000000-0x6fffffff flags 0x2200]
+ %pR [mem 0x60000000-0x6fffffff pref]
+
+ For printing struct resources. The 'R' and 'r' specifiers result in a
+ printed resource with ('R') or without ('r') a decoded flags member.
+
+MAC/FDDI addresses:
+
+ %pM 00:01:02:03:04:05
+ %pMF 00-01-02-03-04-05
+ %pm 000102030405
+
+ For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
+ specifiers result in a printed address with ('M') or without ('m') byte
+ separators. The default byte separator is the colon (':').
+
+ Where FDDI addresses are concerned the 'F' specifier can be used after
+ the 'M' specifier to use dash ('-') separators instead of the default
+ separator.
+
+IPv4 addresses:
+
+ %pI4 1.2.3.4
+ %pi4 001.002.003.004
+ %p[Ii][hnbl]
+
+ For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
+ specifiers result in a printed address with ('i4') or without ('I4')
+ leading zeros.
+
+ The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
+ host, network, big or little endian order addresses respectively. Where
+ no specifier is provided the default network/big endian order is used.
+
+IPv6 addresses:
+
+ %pI6 0001:0002:0003:0004:0005:0006:0007:0008
+ %pi6 00010002000300040005000600070008
+ %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.
+
+UUID/GUID addresses:
+
+ %pU 00010203-0506-0708-090a-0b0c0d0e0fff
+ %pU[bBlL]
+
+ 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;
+ };
+
+ Do not use this feature without some mechanism to verify the
+ correctness of the format string and va_list arguments.
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
@@ -32,4 +136,5 @@ Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
-By Randy Dunlap <rdunlap@xenotime.net>
+By Randy Dunlap <rdunlap@xenotime.net> and
+Andrew Murray <amurray@mpc-data.co.uk>
^ permalink raw reply related
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-02-06 16:14 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-embedded, linux kernel, trivial, rdunlap
In-Reply-To: <AANLkTimcFvq-cSpain--STuVVg3dUJeTCDrykQ=24egg@mail.gmail.com>
On 6 February 2011 10:16, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> In the mean time, we also got %pV and %pK. Can you please add them as well? Thx!
Ok how about this revised patch?
From: Andrew Murray <amurray@mpc-data.co.uk>
This patch updates the incomplete documentation concerning the printk
extended format specifiers.
Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
---
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..cad0dda 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -1,4 +1,4 @@
-If variable is of Type, use printk format specifier:
+f variable is of Type, use printk format specifier:
---------------------------------------------------------
int %d or %x
unsigned int %u or %x
@@ -9,7 +9,111 @@ If variable is of Type, use printk format specifier:
size_t %zu or %zx
ssize_t %zd or %zx
-Raw pointer value SHOULD be printed with %p.
+Raw pointer value SHOULD be printed with %p. The kernel supports
+the following extended format specifiers for pointer types:
+
+Symbols/Function Pointers:
+
+ %pF versatile_init+0x0/0x110
+ %pf versatile_init
+ %pS versatile_init+0x0/0x110
+ %ps versatile_init
+
+ For printing symbols and function pointers. The 'S' and 's' specifiers
+ result in the symbol name with ('S') or without ('s') offsets. Where
+ this is used on a kernel without KALLSYMS - the symbol address is
+ printed instead.
+
+ On ia64, ppc64 and parisc64 architectures function pointers are
+ actually function descriptors which must first be resolved. The 'F' and
+ 'f' specifiers perform this resolution and then provide the same
+ functionality as the 'S' and 's' specifiers.
+
+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
+ Documentation/sysctl/kernel.txt for more details.
+
+Struct Resources:
+
+ %pr [mem 0x60000000-0x6fffffff flags 0x2200]
+ %pR [mem 0x60000000-0x6fffffff pref]
+
+ For printing struct resources. The 'R' and 'r' specifiers result in a
+ printed resource with ('R') or without ('r') a decoded flags member.
+
+MAC/FDDI addresses:
+
+ %pM 00:01:02:03:04:05
+ %pMF 00-01-02-03-04-05
+ %pm 000102030405
+
+ For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
+ specifiers result in a printed address with ('M') or without ('m') byte
+ seperators. The default byte seperator is the colon (':').
+
+ Where FDDI addresses are concerned the 'F' specifier can be used after
+ the 'M' specifier to use dash ('-') seperators instead of the default
+ seperator.
+
+IPv4 addresses:
+
+ %pI4 1.2.3.4
+ %pi4 001.002.003.004
+ %p[Ii][hnbl]
+
+ For printing IPv4 dot-seperated decminal addresses. The 'I4' and 'i4'
+ specifiers result in a printed address with ('i4') or without ('I4')
+ leading zeros.
+
+ The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
+ host, network, big or little endian order addresses respectively. Where
+ no specifier is provided the default network/big endian order is used.
+
+IPv6 addresses:
+
+ %pI6 0001:0002:0003:0004:0005:0006:0007:0008
+ %pi6 00010002000300040005000600070008
+ %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-seperaters. 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.
+
+UUID/GUID addresses:
+
+ %pU 00010203-0506-0708-090a-0b0c0d0e0fff
+ %pU[bBlL]
+
+ For printing 16 byte UUID/GUIDs addresses. The additional 'l', 'L',
+ 'b' and 'B' specifiers are used to specifiy 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;
+ };
+
+ Do not use this feature without some mechanism to verify the
+ correctness of the format string and va_list arguments.
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
@@ -32,4 +136,5 @@ Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
-By Randy Dunlap <rdunlap@xenotime.net>
+By Randy Dunlap <rdunlap@xenotime.net> and
+Andrew Murray <amurray@mpc-data.co.uk>
^ permalink raw reply related
* [PATCH] Kconfig: XIP doesn't depend on block
From: Marco Stornelli @ 2011-02-06 15:15 UTC (permalink / raw)
To: Linux Kernel; +Cc: Linux FS Devel, Linux Embedded, Andrew Morton, rdunlap
From: Marco Stornelli <marco.stornelli@gmail.com>
XIP doesn't depend on block symbol, then we can reorder the Kconfig.
For ext2 doesn't change the Kconfig behavior but if other fs will use
FS_XIP it won't need to include block support if not needed.
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
---
--- Kconfig.orig 2011-01-19 00:14:02.000000000 +0100
+++ Kconfig 2011-02-06 16:04:51.000000000 +0100
@@ -9,13 +9,6 @@ if BLOCK
source "fs/ext2/Kconfig"
source "fs/ext3/Kconfig"
source "fs/ext4/Kconfig"
-
-config FS_XIP
-# execute in place
- bool
- depends on EXT2_FS_XIP
- default y
-
source "fs/jbd/Kconfig"
source "fs/jbd2/Kconfig"
@@ -38,6 +31,12 @@ source "fs/nilfs2/Kconfig"
endif # BLOCK
+config FS_XIP
+# execute in place
+ bool
+ depends on EXT2_FS_XIP
+ default y
+
# Posix ACL utility routines
#
# Note: Posix ACLs can be implemented without these helpers. Never use
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Geert Uytterhoeven @ 2011-02-06 10:16 UTC (permalink / raw)
To: Andrew Murray; +Cc: linux-embedded, linux kernel, trivial, rdunlap
In-Reply-To: <AANLkTikj+FU8OF_-KFr2hmTSWqTHMK5JnrnTVyn-XtxQ@mail.gmail.com>
On Sun, Feb 6, 2011 at 01:15, Andrew Murray <amurray@mpcdata.com> wrote:
> From: Andrew Murray <amurray@mpc-data.co.uk>
>
> This patch updates the incomplete documentation concerning the printk
> extended format specifiers.
>
> Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
> ---
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..df14336 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,42 @@ If variable is of Type, use printk format specifier:
> size_t %zu or %zx
> ssize_t %zd or %zx
>
> -Raw pointer value SHOULD be printed with %p.
> +Raw pointer value SHOULD be printed with %p. The kernel supports
> +the following extended format specifiers for pointer types:
> +
> + General:
> +
> + %pF function pointer with offset, e.g. module_start
> + %pf function pointer without offset, e.g. module_start+0x0/0x62 [hello]
> + %pS text symbol with offset
> + %ps text symbol without offset
> + %pR struct resource with decoded flags, e.g. [mem 0x0-0x1f 64 bit pref]
> + %pr struct resource with raw flags, e.g. [mem 0x0-0x1f flags 0x201]
> +
> + MAC/FDDI addresses:
> +
> + %pM colon-seperated 6-byte MAC address in hex notation, e.g. 00:01:02:03:04:05
> + %pm non-colon-seperated 6-byte MAC address is hex notation, e.g. 000102030405
> + %pMF 6-byte dash-separated FDDI hex notation
> +
> + IPv4 addresses:
> +
> + %pI4 IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4
> + %pi4 IPv4 dot-seperated decimal with leading 0's, 001.002.003.004
> + %p[Ii]4[hl] IPv4 dot-seperated decimal with/without leading 0's for
> + host (h), little (l) or network/big (default) endian order
> +
> + IPv6 addresses:
> + %pI6 IPv6 colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 0001:0203:...:0708
> + %pi6 IPv6 non-colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 000102...0f
> + %pI6c IPv6 address as described by
> + http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00,
> + e.g. 1::708
> +
> + %pU[bBlL] 16 byte UUID/GUID in big or little endian using lower or upper case
> +
In the mean time, we also got %pV and %pK. Can you please add them as well? Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-02-06 10:07 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-embedded, linux kernel, Jiri Kosina
In-Reply-To: <1296952626.4133.77.camel@Joe-Laptop>
Thanks for the feedback - I will truncate to 80 characters and
implement Joe's advice.
Thanks,
Andrew Murray
On 6 February 2011 00:37, Joe Perches <joe@perches.com> wrote:
> On Sun, 2011-02-06 at 00:15 +0000, Andrew Murray wrote:
>> From: Andrew Murray <amurray@mpc-data.co.uk>
>> This patch updates the incomplete documentation concerning the printk
>> extended format specifiers.
>> Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
>> ---
>> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> []
>> @@ -9,7 +9,42 @@ If variable is of Type, use printk format specifier:
>> size_t %zu or %zx
>> ssize_t %zd or %zx
>>
>> -Raw pointer value SHOULD be printed with %p.
>> +Raw pointer value SHOULD be printed with %p. The kernel supports
>> +the following extended format specifiers for pointer types:
>
> I think it'd be better if each extension were individually described
> with an example output.
>
>> +
>> + General:
>> +
>> + %pF function pointer with offset, e.g. module_start
>> + %pf function pointer without offset, e.g. module_start+0x0/0x62 [hello]
>
> with/without inversion?
>
>> + %pS text symbol with offset
>> + %ps text symbol without offset
>> + %pR struct resource with decoded flags, e.g. [mem 0x0-0x1f 64 bit pref]
>> + %pr struct resource with raw flags, e.g. [mem 0x0-0x1f flags 0x201]
>> +
>> + MAC/FDDI addresses:
>> +
>> + %pM colon-seperated 6-byte MAC address in hex notation, e.g. 00:01:02:03:04:05
>
> spelling: separated
>
>> + %pm non-colon-seperated 6-byte MAC address is hex notation, e.g. 000102030405
>> + %pMF 6-byte dash-separated FDDI hex notation
>> +
>> + IPv4 addresses:
>> +
>> + %pI4 IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4
>> + %pi4 IPv4 dot-seperated decimal with leading 0's, 001.002.003.004
>> + %p[Ii]4[hl] IPv4 dot-seperated decimal with/without leading 0's for
>> + host (h), little (l) or network/big (default) endian order
>> +
>> + IPv6 addresses:
>> + %pI6 IPv6 colon-seperated network-order 16 bit hex with leading 0's,
>> + e.g. 0001:0203:...:0708
>> + %pi6 IPv6 non-colon-seperated network-order 16 bit hex with leading 0's,
>> + e.g. 000102...0f
>> + %pI6c IPv6 address as described by
>> + http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00,
>> + e.g. 1::708
>> +
>> + %pU[bBlL] 16 byte UUID/GUID in big or little endian using lower or upper case
>
> Maybe a simple 2 line table without the e.g.:
>
> %p<extension1> sample output1
> description1
> %p<extension2> sample output2
> description2
>
>
>
--
Andrew Murray, Embedded Linux Group
MPC Data Limited
e-mail: amurray@mpc-data.co.uk web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710665
MPC Data Limited is a company registered in England and Wales with
company number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14 7FJ
VAT no: 850625238
The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the
addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the
original message. When
addressed to our clients any opinions or advice contained in this
email is subject to
the terms and conditions expressed in the governing contract.
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Joe Perches @ 2011-02-06 0:37 UTC (permalink / raw)
To: Andrew Murray; +Cc: linux-embedded, linux kernel, Jiri Kosina
In-Reply-To: <AANLkTikj+FU8OF_-KFr2hmTSWqTHMK5JnrnTVyn-XtxQ@mail.gmail.com>
On Sun, 2011-02-06 at 00:15 +0000, Andrew Murray wrote:
> From: Andrew Murray <amurray@mpc-data.co.uk>
> This patch updates the incomplete documentation concerning the printk
> extended format specifiers.
> Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
> ---
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
[]
> @@ -9,7 +9,42 @@ If variable is of Type, use printk format specifier:
> size_t %zu or %zx
> ssize_t %zd or %zx
>
> -Raw pointer value SHOULD be printed with %p.
> +Raw pointer value SHOULD be printed with %p. The kernel supports
> +the following extended format specifiers for pointer types:
I think it'd be better if each extension were individually described
with an example output.
> +
> + General:
> +
> + %pF function pointer with offset, e.g. module_start
> + %pf function pointer without offset, e.g. module_start+0x0/0x62 [hello]
with/without inversion?
> + %pS text symbol with offset
> + %ps text symbol without offset
> + %pR struct resource with decoded flags, e.g. [mem 0x0-0x1f 64 bit pref]
> + %pr struct resource with raw flags, e.g. [mem 0x0-0x1f flags 0x201]
> +
> + MAC/FDDI addresses:
> +
> + %pM colon-seperated 6-byte MAC address in hex notation, e.g. 00:01:02:03:04:05
spelling: separated
> + %pm non-colon-seperated 6-byte MAC address is hex notation, e.g. 000102030405
> + %pMF 6-byte dash-separated FDDI hex notation
> +
> + IPv4 addresses:
> +
> + %pI4 IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4
> + %pi4 IPv4 dot-seperated decimal with leading 0's, 001.002.003.004
> + %p[Ii]4[hl] IPv4 dot-seperated decimal with/without leading 0's for
> + host (h), little (l) or network/big (default) endian order
> +
> + IPv6 addresses:
> + %pI6 IPv6 colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 0001:0203:...:0708
> + %pi6 IPv6 non-colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 000102...0f
> + %pI6c IPv6 address as described by
> + http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00,
> + e.g. 1::708
> +
> + %pU[bBlL] 16 byte UUID/GUID in big or little endian using lower or upper case
Maybe a simple 2 line table without the e.g.:
%p<extension1> sample output1
description1
%p<extension2> sample output2
description2
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Tim Bird @ 2011-02-06 0:27 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-embedded@vger.kernel.org, linux kernel, trivial@kernel.org
In-Reply-To: <AANLkTikj+FU8OF_-KFr2hmTSWqTHMK5JnrnTVyn-XtxQ@mail.gmail.com>
On 02/05/2011 04:15 PM, Andrew Murray wrote:
> From: Andrew Murray <amurray@mpc-data.co.uk>
>
> This patch updates the incomplete documentation concerning the printk
> extended format specifiers.
>
> Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
> ---
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..df14336 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,42 @@ If variable is of Type, use printk format specifier:
> size_t %zu or %zx
> ssize_t %zd or %zx
>
> -Raw pointer value SHOULD be printed with %p.
> +Raw pointer value SHOULD be printed with %p. The kernel supports
> +the following extended format specifiers for pointer types:
> +
> + General:
> +
> + %pF function pointer with offset, e.g. module_start
> + %pf function pointer without offset, e.g. module_start+0x0/0x62 [hello]
> + %pS text symbol with offset
> + %ps text symbol without offset
> + %pR struct resource with decoded flags, e.g. [mem 0x0-0x1f 64 bit pref]
> + %pr struct resource with raw flags, e.g. [mem 0x0-0x1f flags 0x201]
> +
> + MAC/FDDI addresses:
> +
> + %pM colon-seperated 6-byte MAC address in hex notation, e.g. 00:01:02:03:04:05
> + %pm non-colon-seperated 6-byte MAC address is hex notation, e.g. 000102030405
> + %pMF 6-byte dash-separated FDDI hex notation
> +
> + IPv4 addresses:
> +
> + %pI4 IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4
> + %pi4 IPv4 dot-seperated decimal with leading 0's, 001.002.003.004
> + %p[Ii]4[hl] IPv4 dot-seperated decimal with/without leading 0's for
> + host (h), little (l) or network/big (default) endian order
> +
> + IPv6 addresses:
> + %pI6 IPv6 colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 0001:0203:...:0708
> + %pi6 IPv6 non-colon-seperated network-order 16 bit hex with leading 0's,
> + e.g. 000102...0f
> + %pI6c IPv6 address as described by
> + http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00,
> + e.g. 1::708
> +
> + %pU[bBlL] 16 byte UUID/GUID in big or little endian using lower or upper case
> +
>
> u64 SHOULD be printed with %llu/%llx, (unsigned long long):
I like this, as it has information that is not documented elsewhere.
Some feedback on the patch:
Some of these lines are longer than 80 chars. Can you please truncate
things to fit in an 80-column terminal window?
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-02-06 0:15 UTC (permalink / raw)
To: linux-embedded; +Cc: linux kernel, trivial
From: Andrew Murray <amurray@mpc-data.co.uk>
This patch updates the incomplete documentation concerning the printk
extended format specifiers.
Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
---
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..df14336 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -9,7 +9,42 @@ If variable is of Type, use printk format specifier:
size_t %zu or %zx
ssize_t %zd or %zx
-Raw pointer value SHOULD be printed with %p.
+Raw pointer value SHOULD be printed with %p. The kernel supports
+the following extended format specifiers for pointer types:
+
+ General:
+
+ %pF function pointer with offset, e.g. module_start
+ %pf function pointer without offset, e.g. module_start+0x0/0x62 [hello]
+ %pS text symbol with offset
+ %ps text symbol without offset
+ %pR struct resource with decoded flags, e.g. [mem 0x0-0x1f 64 bit pref]
+ %pr struct resource with raw flags, e.g. [mem 0x0-0x1f flags 0x201]
+
+ MAC/FDDI addresses:
+
+ %pM colon-seperated 6-byte MAC address in hex notation, e.g. 00:01:02:03:04:05
+ %pm non-colon-seperated 6-byte MAC address is hex notation, e.g. 000102030405
+ %pMF 6-byte dash-separated FDDI hex notation
+
+ IPv4 addresses:
+
+ %pI4 IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4
+ %pi4 IPv4 dot-seperated decimal with leading 0's, 001.002.003.004
+ %p[Ii]4[hl] IPv4 dot-seperated decimal with/without leading 0's for
+ host (h), little (l) or network/big (default) endian order
+
+ IPv6 addresses:
+ %pI6 IPv6 colon-seperated network-order 16 bit hex with leading 0's,
+ e.g. 0001:0203:...:0708
+ %pi6 IPv6 non-colon-seperated network-order 16 bit hex with leading 0's,
+ e.g. 000102...0f
+ %pI6c IPv6 address as described by
+ http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00,
+ e.g. 1::708
+
+ %pU[bBlL] 16 byte UUID/GUID in big or little endian using lower or upper case
+
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
^ permalink raw reply related
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Grant Likely @ 2011-02-03 17:32 UTC (permalink / raw)
To: Tony Ibbs; +Cc: linux-embedded, tibs, rrw
In-Reply-To: <20110203170457.0a1640cf@spoon>
On Thu, Feb 3, 2011 at 10:04 AM, Tony Ibbs <tibs@kynesim.co.uk> wrote:
> Apologies again for getting Grant's email address wrong on my initial
> email.
>
> On Tue, 1 Feb 2011 20:40:08 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> There are already a large number of communication channels available
>> to Linux, with DBUS gatting the most attention at the moment. What
>> niche is KBUS filling that DBUS and others misses? Secondarily, does
>> KBUS implement a new API instead of extending an existing mechanism to
>> meet your needs? I suspect you'll get a lot more traction if KBUS can
>> make DBUS work better/faster/more efficiently.
>
> Hmm. I'm not sure what make up that large number, but I'll try to
> address your specific concerns.
>
> I've got four real reasons for why KBUS and not something else:
>
> 1. Simple to use and understand. You should be able to get started
> using KBUS without needing to feel you've had to learn anything much.
It can be argued that this is an interface issue; but that's a
tangential point to my main point below....
[...]
> As a side issue, DBUS also mixes together message and content. KBUS
> deliberately does not address the description of message content. We do
> not believe there is a one-size-fits-all solution to this, not even for
> request/reply used as RPC. Whilst not named in the big 4 above, I
> regard this as a serious problem with DBUS for our domain.
>
> Elsewhere, 0mq (zeromq) looks very attractive, not least because it
> appears to be very well documented (although I think a lot of that is
> fairly recent). I really want to find a project where I need to use it.
> However, it is written in C++, so fails (4). Also, I think it is too
> complete a solution - it is meant to be a general networking solution,
> and I think that makes it wrong for this application - it is over
> powerful. Also, I assume it cannot provide (3).
>
> I'm not sure what other mechanisms we should consider. The kernel
> itself doesn't provide anything that addresses our problem space,
> without a lot of support work.
>
> As to API. The basic API is just the file API (open/read/write/
> ioctl/close), and KBUS is perfectly usable at that level.
The big issue that comes into play when implementing a new protocol in
Linux is that once it is implemented, we need to support it until the
end of time. That means it needs to be well thought out and there is
a lot of resistance to implementing something new without first seeing
that it is a measurable benefit that is worth supporting to the end of
time. In your case, you'll need to show (or attract) a wider range of
users who can say, "yes, this is better than the alternatives". I
suggest looking at working with dbus for that exact reason. If dbus
can be made faster/better/more reliable by using a kbus backend, then
you've got a big userbase saying that it is a valuable addition. It
also gives you a broad use-case that will stretch your assumptions and
improve the implementation before it gets set in stone when merged.
If kbus turns out to only be applicable to your corner of the universe
then it becomes a lot harder to justify it as a generic Linux
communication implementation.
g.
^ permalink raw reply
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Tony Ibbs @ 2011-02-03 17:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded, tibs, rrw
In-Reply-To: <20110202034008.GC29148@angua.secretlab.ca>
Apologies again for getting Grant's email address wrong on my initial
email.
On Tue, 1 Feb 2011 20:40:08 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> There are already a large number of communication channels available
> to Linux, with DBUS gatting the most attention at the moment. What
> niche is KBUS filling that DBUS and others misses? Secondarily, does
> KBUS implement a new API instead of extending an existing mechanism to
> meet your needs? I suspect you'll get a lot more traction if KBUS can
> make DBUS work better/faster/more efficiently.
Hmm. I'm not sure what make up that large number, but I'll try to
address your specific concerns.
I've got four real reasons for why KBUS and not something else:
1. Simple to use and understand. You should be able to get started
using KBUS without needing to feel you've had to learn anything much.
1.5 This also means it mustn't try to do too much - it needs
to aim for the simplest solution that will do.
2. We require deterministic message ordering. All listeners (on the
same bus) to a particular message name must receive those messages
in the same order. And that must be the same as the order they
were sent in.
3. In a request/reply situation, the requester must be guaranteed a
reply, even if the reply is to indicate that the replier has gone away,
and including the case that the replier has crashed.
4. The system has to be written in C, since we can't guarantee the
availability of other language libraries (specifically, we are quite
likely not to have C++ on a board).
I believe DBUS is ruled out because of (1) alone - it is not easy to use
or understand. Someone writing embedded code does not normally want to
invest much time in learning yet another technology, so quick to learn
is very important here. Learning about protocol layers is not
appropriate in this context. My EuroPython talk explained almost the
entirety of KBUS (and all the important bits) with examples, in about
20 minutes.
I don't know if DBUS provides (2) - I've not been able to tell from its
documentation. And I assume it doesn't provide (3).
Also, KBUS is perfectly usable with just the kernel module. DBUS is
quite large, and we don't necessarily have the space to spare for it on
many of our systems.
As a side issue, DBUS also mixes together message and content. KBUS
deliberately does not address the description of message content. We do
not believe there is a one-size-fits-all solution to this, not even for
request/reply used as RPC. Whilst not named in the big 4 above, I
regard this as a serious problem with DBUS for our domain.
Elsewhere, 0mq (zeromq) looks very attractive, not least because it
appears to be very well documented (although I think a lot of that is
fairly recent). I really want to find a project where I need to use it.
However, it is written in C++, so fails (4). Also, I think it is too
complete a solution - it is meant to be a general networking solution,
and I think that makes it wrong for this application - it is over
powerful. Also, I assume it cannot provide (3).
I'm not sure what other mechanisms we should consider. The kernel
itself doesn't provide anything that addresses our problem space,
without a lot of support work.
As to API. The basic API is just the file API (open/read/write/
ioctl/close), and KBUS is perfectly usable at that level.
For those who want to have simpler code, there's a C library to wrap
stuff up neatly, but you don't have to use it. We wanted a set of
useful routines for ourselves, so it happened anyway. It's also a
useful step to (for instance) the Java API, rather than going the
low-level route (obviously not needed when writing the C++ or Python
bindings).
Finally, I have actually submitted a CELF Open Project proposal for
KBUS, and one of the work items is to look at using KBUS as a bottom
end for DBUS.
> > Date: Fri, 28 Jan 2011 17:50:40 +0000
> > From: Tony Ibbs <tibs@kynesim.co.uk>
> > To: Linux-embedded <linux-embedded@vger.kernel.org>
[...]
> > Should I just submit the patch to this list?
[...]
> Yes. If you want review, then posting a URLs doesn't help. :-) Send
> it as an email so that I can just hit 'reply' and start typing.
> Post and then I'll comment.
I shall attempt to sort out the issues following on from Sam Ravnborg's
comments, and then submit as several inline patches, then.
Tibs
^ permalink raw reply
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Tony Ibbs @ 2011-02-03 16:59 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux-embedded, Richard Watts, Tibs at home
In-Reply-To: <20110128191837.GA6781@merkur.ravnborg.org>
On Fri, 28 Jan 2011 20:20:42 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:
> [Edited cc: list as my smtp server refused to send the original reply]
Apologies - I had copied down Grant Likely's email address wrong at ELCE.
> > Should I just submit the patch to this list?
>
> You will get more feedback on lkml...
Indeed. I hoped to start small.
> - use __u32 (and friends) in exported headers - not uint32_t.
OK. I'd missed that. Presumably I should also be using u32 and friends
inside the kernel module itself, instead of uint32_t...
> - do not invent our own logging system. Use one of the standard
> methods.
I vaguely remember having a reason for that. Doubtless it was a bad
one. I shall attend to it.
> If you post for review try to divide it up a little.
> Maybe kbus.c in one patch, Makefile + Kconfig in last patch.
> It is a large file to review already.
That's useful guidance. I shall amend the code as suggested above and
resubmit as smaller, inline patches.
Tibs
^ permalink raw reply
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Grant Likely @ 2011-02-02 3:40 UTC (permalink / raw)
To: Tony Ibbs; +Cc: linux-embedded, tibs, rrw
In-Reply-To: <20110128180158.6f670a51@spoon>
On Fri, Jan 28, 2011 at 06:01:58PM +0000, Tony Ibbs wrote:
> We talked briefly at ELCE 2010 in Cambridge, after the "keeping
> kernel maintainers happy" talk, and you offered that I could
> CC you when I got round to submitting our kernel module.
Hi Tony,
Yes, I remember talking to you. I'll take a look through and see if I
see any glaring problems. However, my major critique still stands.
There are already a large number of communication channels available
to Linux, with DBUS gatting the most attention at the moment. What
niche is KBUS filling that DBUS and others misses? Secondarily, does
KBUS implement a new API instead of extending an existing mechanism to
meet your needs? I suspect you'll get a lot more traction if KBUS can
make DBUS work better/faster/more efficiently.
> I've just emailed the embedded linux mailing list with an initial
> question about it, and attempted to CC you as
> grant.likely@secretlab.com, which appears to have bounced. I'm
> hoping that I just wrote the address down wrong, and the .ca
> version is correct.
Yes, the correct domain is secretlab.ca
>
> Apologies for any confusion,
> Tibs
>
> Begin forwarded message:
>
> Date: Fri, 28 Jan 2011 17:50:40 +0000
> From: Tony Ibbs <tibs@kynesim.co.uk>
> To: Linux-embedded <linux-embedded@vger.kernel.org>
> Cc: Grant Likely <grant.likely@secretlab.com>, Tibs at home <tibs@tonyibbs.co.uk>, Richard Watts <rrw@kynesim.co.uk>
> Subject: [RFC][PATCH] KBUS messaging subsystem
>
>
[...]
> We've got a working repository with Linux 2.6.37 patched for KBUS,
> available via:
>
> git pull git://github.com/crazyscot/linux-2.6-kbus.git kbus-2.6.37
>
> Our tentative patch is at
> http://kbus.googlecode.com/files/0001-KBUS-messaging-subsystem.patch
>
> The diffstat for the patch is:
>
> Documentation/Kbus.txt | 1189 ++++++++++
> include/linux/kbus_defns.h | 666 ++++++
> init/Kconfig | 3 +
> ipc/Kconfig | 99 +
> ipc/Makefile | 1 +
> ipc/kbus.c | 5120 ++++++++++++++++++++++++++++++++++++++++++++
> ipc/kbus_internal.h | 773 +++++++
> 7 files changed, 7851 insertions(+), 0 deletions(-)
>
> Should I just submit the patch to this list?
Yes. If you want review, then posting a URLs doesn't help. :-) Send
it as an email so that I can just hit 'reply' and start typing.
Post and then I'll comment.
g.
^ permalink raw reply
* Re: [RFC][PATCH] KBUS messaging subsystem
From: Sam Ravnborg @ 2011-01-28 19:20 UTC (permalink / raw)
To: Tony Ibbs; +Cc: Linux-embedded
In-Reply-To: <20110128175040.72cf332a@spoon>
[Edited cc: list as my smtp server refused to send the original reply]
>
> Our tentative patch is at
> http://kbus.googlecode.com/files/0001-KBUS-messaging-subsystem.patch
>
> The diffstat for the patch is:
>
> Documentation/Kbus.txt | 1189 ++++++++++
> include/linux/kbus_defns.h | 666 ++++++
> init/Kconfig | 3 +
> ipc/Kconfig | 99 +
> ipc/Makefile | 1 +
> ipc/kbus.c | 5120 ++++++++++++++++++++++++++++++++++++++++++++
> ipc/kbus_internal.h | 773 +++++++
> 7 files changed, 7851 insertions(+), 0 deletions(-)
>
> Should I just submit the patch to this list?
You will get more feedback on lkml...
Looks like comprehensive descriptions - good!
Took a quick peek at the patch.
- use __u32 (and friends) in exported headers - not uint32_t.
- do not invent our own logging system. Use one of the standard methods.
If you post for review try to divide it up a little.
Maybe kbus.c in one patch, Makefile + Kconfig in last patch.
It is a large file to review already.
Sam
^ permalink raw reply
* [RFC][PATCH] KBUS messaging subsystem
From: Tony Ibbs @ 2011-01-28 17:50 UTC (permalink / raw)
To: Linux-embedded; +Cc: Grant Likely, Tibs at home, Richard Watts
KBUS is a lightweight Linux-kernel mediated message system,
particularly intended for use in embedded environments.
It is meant to be simple to use and understand. It is particularly
designed to provide predictable message delivery, deterministic
message ordering, and a guaranteed reply for each request.
We have various customers using KBUS in real life, and believe it to
be useful. I had a showcase table for KBUS at the ELCE in Cambridge,
October last year, and there seemed to be interest.
We'd like some advice on how to submit this - I assume that submitting
patches to the Embedded Linux mailing list first would be sensible,
since we believe this to be an area that will find KBUS interesting.
The KBUS project home page is at http://kbus-messaging.org/
The KBUS specification can be found at
http://html.kbus.googlecode.com/hg/docs/html/specification.html
Userland support, plus unit tests for the kernel module, are in the
Google code repositories. There's a GettingStarted page linked from
the KBUS home page.
We've got a working repository with Linux 2.6.37 patched for KBUS,
available via:
git pull git://github.com/crazyscot/linux-2.6-kbus.git kbus-2.6.37
Our tentative patch is at
http://kbus.googlecode.com/files/0001-KBUS-messaging-subsystem.patch
The diffstat for the patch is:
Documentation/Kbus.txt | 1189 ++++++++++
include/linux/kbus_defns.h | 666 ++++++
init/Kconfig | 3 +
ipc/Kconfig | 99 +
ipc/Makefile | 1 +
ipc/kbus.c | 5120 ++++++++++++++++++++++++++++++++++++++++++++
ipc/kbus_internal.h | 773 +++++++
7 files changed, 7851 insertions(+), 0 deletions(-)
Should I just submit the patch to this list?
Tibs
^ permalink raw reply
* RE: Generic PWM git tree rebased; please resend me your patches
From: Natarajan, Sugumar @ 2011-01-27 13:10 UTC (permalink / raw)
To: Bill Gatliff, sugumar
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <AANLkTin=BvOXfQcrUvjmRzJ416TbJ1KsMVtZSrh0TFy=@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5159 bytes --]
Hi Bill,
I am working on the driver for eHRPWM module. I have completed the initial implementation and looking forward for your support to make it as complete driver. There are few design issues that needs to be addressed. Block diagram of the eHRPWM module is presented below for clear understanding.
[cid:image001.png-0+Gm3E7YfSJjdIJ4uHzgADRmByFHzeGd@public.gmane.org]
Fig 1 eHRPWM Module
[cid:image002.png@01CBBE4C.C2818090]
Fig 2 Dead Band (Sub Module)
The major difference between Atmel controller and eHRPWM controller is that though eHRPWM module has two channels, they are not independent. There are no separate hardware registers for each channel as in the case of Atmel. Independent control of two channels is achieved in the driver only by means of software. eHRPWM is registered as a character device and for the reason that the channels are not independent, the system calls, open and IOCTL are written in such as way that they operate on the device and not the channels. Initially, the IOCTL interface was designed to be based on the channel request. But, there are features such as Trip zone and Dead Band which can source any of the channel output from the previous stage. For Eg. Let say, channel A is stopped and channel B is running or in other words the output of A at the Action Qualifier stage(Fig 1)is 0. Using the Dead Band feature, output of B from the previous stage can be sourced to override both outputs A and B of the next and subsequent stages(As seen from Fig 2 Dead Band). Hence, the design was modified to be based on the device request. To be more specific, there is no concept of channels. There are two independent outputs which can be overriden by any eHRPWM feature.
Considering the above, I am facing the below design issue.
1. IOCTL interface provides the user with an option to set the frequency and duty cycle by means of Set_Period and Set_Duty IOCTL calls. User has to pass the device id and the channel no. to be controlled. As said above, user accesses the device and not the channels. As of now, these commands internally call the pwm_set_period in the PWM framework. For the function call to be successful, pwm_request function should have been invoked before for each channel(Otherwise flag test will fail) since user might set period/duty for any of the channels. Is it the right way to do? Or Would it make sense to implement the set_period and set_duty function internal to the driver so that PWM request is used only by the kernel Subsystem such as Backlight interface and not the driver. In other words, Can the user be given access to the device irrespective of whether it is being used or not by the kernel subsystem such as Back light interface? Is there any other better way of implementation so that it coexists with the PWM framework?
Apart from the above design issue, I find the following to be limitations in the PWM framework
2. eHRPWM module has high resolution feature which operates on the fractional value of cycles. The PWM channel structure should have the field to store the duty value in ns so that the driver can calculate the fractional cycle value.
3. pwm_find_device function needs to have global access. The open function call uses this function to search for the pwm device.
Can the above limitation be avoided?
I have attached the patches for your review. The patches have been tested against the pwm git repository.
Please review the design and give your valuable comments/feedback.
Regards,
N.sugumar
On Thu, Oct 21, 2010 at 18:44:48, Bill Gatliff wrote:
> Guys:
>
>
> I have a public git tree of my generic PWM framework code here:
>
> git://git.billgatliff.com/pwm.git
>
> I have rebased my series against linux-2.6.36, and also cleaned up a bunch of stuff based on reviewer feedback. I think I have also make things such that the existing PWM kernel code can coexist with my framework, giving us less breakage and more time to migrate things to the new API.
>
> Many of you have been sending me code against the patch series I posted here a few weeks ago, and I really do appreciate that. Please rebase your patches against the above repository and resend (or send me a pull request). I'm trying to get all of your patches merged, but many of them aren't going in without conflicts. Sorry for the extra work.
>
> Thanks very much!
>
>
> b.g.
> --
> Bill Gatliff
> bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org<mailto:bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<mailto:majordomo@vger.kernel.org> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #1.1.2: Type: text/html, Size: 13016 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 60676 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 35390 bytes --]
[-- Attachment #2: ehrpwm_patch.zip --]
[-- Type: application/x-zip-compressed, Size: 17940 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [RFC] gelf - user space probe debugger
From: Jiri Olsa @ 2011-01-24 16:11 UTC (permalink / raw)
To: linux-embedded; +Cc: jolsa
hi,
I started a debugger project. It's based on the user space backport
of optimized kprobes (djprobes) and RSP stub implementation.
The debugger is implemented as a preloaded shared library,
which handles all the debugger work, hence no kernel ptrace
is needed.
It just reached the state where it can handle simple gdb session
of setting/reaching a breakpoint and continue the execution.
Details can be found on http://people.redhat.com/jolsa/gelf/
I'd like to ask for opinions if there'd be users for such thing,
and if it's worth to continue on this..
thanks for any ideas,
jirka
ps. I'm not subscribed to the list, so please include my email
in the answer
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox