* Re: [PATCH] printk-formats.txt documentation update
From: Namhyung Kim @ 2011-06-09 18:20 UTC (permalink / raw)
To: Andrew Murray
Cc: joe, w.sang, geert, linux-embedded, linux-kernel, trivial,
rdunlap, udknight, Andrew Murray
In-Reply-To: <1307642692-23556-1-git-send-email-amurray@mpcdata.com>
2011-06-09 (목), 19:04 +0100, Andrew Murray:
> 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>
> ---
> Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..69713d6 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,121 @@ 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
> + %pB versatile_init+0x0/0x110
> +
-EBADEXAMPLE :)
If %pB is used, the offset part in the output could not be 0. That's the
key (and the only) difference of the %pB specifier than others. Thus the
output would be something like:
%pB prev_fn_of_versatile_init+0x88/0x88
Thanks.
--
Regards,
Namhyung Kim
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-06-09 18:55 UTC (permalink / raw)
To: joe
Cc: w.sang, geert, linux-embedded, linux-kernel, trivial, rdunlap,
udknight, namhyung, Andrew Murray
In-Reply-To: <1307643649.1340.8.camel@leonhard>
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>
---
Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
1 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..85a06aa 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -9,7 +9,121 @@ 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
+ %pB prev_fn_of_versatile_init+0x88/0x88
+
+ 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.
+
+ The 'B' specifier results in the symbol name with offsets and should be
+ used when printing stack backtraces. The specifier takes into
+ consideration the effect of compiler optimisations which may occur
+ when tail-call's are used and marked with the noreturn GCC attribute.
+
+ 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 0x01234567 or 0x0123456789abcdef
+
+ 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 0x60000000-0x6fffffff flags 0x2200] or
+ [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
+ %pR [mem 0x60000000-0x6fffffff pref] or
+ [mem 0x0000000060000000-0x000000006fffffff 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/rfc5952
+
+UUID/GUID addresses:
+
+ %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
+ %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
+ %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
+ %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
+
+ 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_list *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 +146,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>
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] printk-formats.txt documentation update
From: Randy Dunlap @ 2011-06-09 19:45 UTC (permalink / raw)
To: Andrew Murray
Cc: joe, w.sang, geert, linux-embedded, linux-kernel, trivial,
udknight, namhyung, Andrew Murray
In-Reply-To: <1307645735-24933-1-git-send-email-amurray@mpcdata.com>
On Thu, 9 Jun 2011 19:55:35 +0100 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>
> ---
> Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..85a06aa 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,121 @@ 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
> + %pB prev_fn_of_versatile_init+0x88/0x88
> +
> + 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.
> +
> + The 'B' specifier results in the symbol name with offsets and should be
> + used when printing stack backtraces. The specifier takes into
> + consideration the effect of compiler optimisations which may occur
> + when tail-call's are used and marked with the noreturn GCC attribute.
> +
> + 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 0x01234567 or 0x0123456789abcdef
> +
> + 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 0x60000000-0x6fffffff flags 0x2200] or
> + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
> + %pR [mem 0x60000000-0x6fffffff pref] or
> + [mem 0x0000000060000000-0x000000006fffffff 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'
You lost the hyphen in 16-bit. The previous patch version had it... :(
> + 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/rfc5952
> +
> +UUID/GUID addresses:
> +
> + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
> + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
> + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
> + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
> +
> + For printing 16 byte UUID/GUIDs addresses. The additional 'l', 'L',
same for 16-byte
> + '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_list *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 +146,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>
> --
> 1.7.4.1
>
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-06-09 21:24 UTC (permalink / raw)
To: joe
Cc: w.sang, geert, linux-embedded, linux-kernel, trivial, rdunlap,
udknight, namhyung, Andrew Murray
In-Reply-To: <20110609124549.48117a75.rdunlap@xenotime.net>
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>
---
Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
1 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 1b5a5dd..6455e5b 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -9,7 +9,121 @@ 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
+ %pB prev_fn_of_versatile_init+0x88/0x88
+
+ 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.
+
+ The 'B' specifier results in the symbol name with offsets and should be
+ used when printing stack backtraces. The specifier takes into
+ consideration the effect of compiler optimisations which may occur
+ when tail-call's are used and marked with the noreturn GCC attribute.
+
+ 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 0x01234567 or 0x0123456789abcdef
+
+ 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 0x60000000-0x6fffffff flags 0x2200] or
+ [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
+ %pR [mem 0x60000000-0x6fffffff pref] or
+ [mem 0x0000000060000000-0x000000006fffffff 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/rfc5952
+
+UUID/GUID addresses:
+
+ %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
+ %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
+ %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
+ %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
+
+ 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_list *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 +146,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>
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Bootgraph.pl bug fix
From: Andrew Murray @ 2011-06-09 21:40 UTC (permalink / raw)
To: trivial; +Cc: linux-embedded, linux-kernel, Andrew Murray, Andrew Murray
This patch removes the assumption of the bootgraph.pl script that the
timing information reported by PRINTK_TIME will contain at least one
entry with a time of less than 100 seconds.
Not all boards correctly reset the system timer and in many cases the
inital times reported by PRINTK_TIME is high. When this occurs the
bootchart.pl script fails to give any useful output.
This patch sets the $firsttime variable to the largest value expected
by PRINTK_TIME
Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
---
scripts/bootgraph.pl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/bootgraph.pl b/scripts/bootgraph.pl
index 12caa82..b78fca9 100644
--- a/scripts/bootgraph.pl
+++ b/scripts/bootgraph.pl
@@ -44,7 +44,7 @@ my %end;
my %type;
my $done = 0;
my $maxtime = 0;
-my $firsttime = 100;
+my $firsttime = 99999;
my $count = 0;
my %pids;
my %pidctr;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] printk-formats.txt documentation update
From: Randy Dunlap @ 2011-06-09 21:51 UTC (permalink / raw)
To: Andrew Murray
Cc: joe, w.sang, geert, linux-embedded, linux-kernel, trivial,
udknight, namhyung, Andrew Murray
In-Reply-To: <1307654688-28015-1-git-send-email-amurray@mpcdata.com>
On Thu, 9 Jun 2011 22:24:48 +0100 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>
> ---
> Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..6455e5b 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier:
> +UUID/GUID addresses:
> +
> + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
> + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
> + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
> + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
> +
> + For printing-16 byte UUID/GUIDs addresses. The additional 'l', 'L',
For printing 16-byte
You want to resend or shall I just fix it?
> + '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.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Joe Perches @ 2011-06-09 22:00 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Murray, w.sang, geert, linux-embedded, linux-kernel,
trivial, udknight, namhyung, Andrew Murray
In-Reply-To: <20110609145130.7fda9bd1.rdunlap@xenotime.net>
On Thu, 2011-06-09 at 14:51 -0700, Randy Dunlap wrote:
> On Thu, 9 Jun 2011 22:24:48 +0100 Andrew Murray wrote:
> > + For printing-16 byte UUID/GUIDs addresses. The additional 'l', 'L',
> For printing 16-byte
> You want to resend or shall I just fix it?
Hey Randy.
I find your seeming insistence on using a dash
between the numeric count and the word byte to
be a bit odd.
Stylistically, why do you want it there?
cheers, Joe
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-06-09 22:21 UTC (permalink / raw)
To: Joe Perches
Cc: Randy Dunlap, w.sang, geert, linux-embedded, linux-kernel,
trivial, udknight, namhyung
In-Reply-To: <1307656829.13329.53.camel@Joe-Laptop>
On 9 June 2011 23:00, Joe Perches <joe@perches.com> wrote:
> On Thu, 2011-06-09 at 14:51 -0700, Randy Dunlap wrote:
>> On Thu, 9 Jun 2011 22:24:48 +0100 Andrew Murray wrote:
>> > + For printing-16 byte UUID/GUIDs addresses. The additional 'l', 'L',
>> For printing 16-byte
>> You want to resend or shall I just fix it?
Yes Randy please fix it - may be quicker for us both!
>
> Hey Randy.
>
> I find your seeming insistence on using a dash
> between the numeric count and the word byte to
> be a bit odd.
>
> Stylistically, why do you want it there?
>
> cheers, Joe
>
>
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Randy Dunlap @ 2011-06-09 22:37 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Murray, w.sang, geert, linux-embedded, linux-kernel,
trivial, udknight, namhyung, Andrew Murray
In-Reply-To: <1307656829.13329.53.camel@Joe-Laptop>
On Thu, 09 Jun 2011 15:00:29 -0700 Joe Perches wrote:
> On Thu, 2011-06-09 at 14:51 -0700, Randy Dunlap wrote:
> > On Thu, 9 Jun 2011 22:24:48 +0100 Andrew Murray wrote:
> > > + For printing-16 byte UUID/GUIDs addresses. The additional 'l', 'L',
> > For printing 16-byte
> > You want to resend or shall I just fix it?
>
> Hey Randy.
>
> I find your seeming insistence on using a dash
> between the numeric count and the word byte to
> be a bit odd.
>
> Stylistically, why do you want it there?
Mostly to make it clear. It's too easy to be ambiguous.
> cheers, Joe
Without hyphen:
For printing 16 byte UUID/GUIDs addresses.
Those adjectives are confusing. I don't know what that phrase means.
It could easily mean 16 UUID/GUIDs, but it's ambiguous.
But
For printing 16-byte UUID/GUIDs addresses.
That means (clearly to me) that UUID/GUIDs are 16-byte entities.
Or see www.incredibleenglish.com/pdf/Hyphens.pdf, section 1,
"Hyphenate unit modifiers."
Or see http://www.ehow.com/how_4473498_use-hyphen-sentence.html, section 1,
"Link compound modifiers with hyphens."
Or see http://www.getitwriteonline.com/archive/040201HyphAdj.htm
HTH.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Joe Perches @ 2011-06-09 22:53 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Murray, w.sang, geert, linux-embedded, linux-kernel,
trivial, udknight, namhyung, Andrew Murray
In-Reply-To: <20110609153742.2ad54aaa.rdunlap@xenotime.net>
On Thu, 2011-06-09 at 15:37 -0700, Randy Dunlap wrote:
> On Thu, 09 Jun 2011 15:00:29 -0700 Joe Perches wrote:
> see www.incredibleenglish.com/pdf/Hyphens.pdf, section 1,
> "Hyphenate unit modifiers."
>
> Or see http://www.ehow.com/how_4473498_use-hyphen-sentence.html, section 1,
> "Link compound modifiers with hyphens."
>
> Or see http://www.getitwriteonline.com/archive/040201HyphAdj.htm
Whatever floats your boat but my 5th grade English teacher
Sr. Mary likely would have been appalled by those articles.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Randy Dunlap @ 2011-06-09 22:57 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Murray, w.sang, geert, linux-embedded, linux-kernel,
trivial, udknight, namhyung, Andrew Murray
In-Reply-To: <1307660018.18831.4.camel@Joe-Laptop>
On Thu, 09 Jun 2011 15:53:38 -0700 Joe Perches wrote:
> On Thu, 2011-06-09 at 15:37 -0700, Randy Dunlap wrote:
> > On Thu, 09 Jun 2011 15:00:29 -0700 Joe Perches wrote:
> > see www.incredibleenglish.com/pdf/Hyphens.pdf, section 1,
> > "Hyphenate unit modifiers."
> >
> > Or see http://www.ehow.com/how_4473498_use-hyphen-sentence.html, section 1,
> > "Link compound modifiers with hyphens."
> >
> > Or see http://www.getitwriteonline.com/archive/040201HyphAdj.htm
>
> Whatever floats your boat but my 5th grade English teacher
> Sr. Mary likely would have been appalled by those articles.
>
> cheers, Joe
Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] Bootgraph.pl bug fix
From: Jiri Kosina @ 2011-06-10 13:00 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-embedded, linux-kernel, Andrew Murray, Arjan van de Ven
In-Reply-To: <1307655610-28446-1-git-send-email-amurray@mpcdata.com>
On Thu, 9 Jun 2011, Andrew Murray wrote:
> This patch removes the assumption of the bootgraph.pl script that the
> timing information reported by PRINTK_TIME will contain at least one
> entry with a time of less than 100 seconds.
>
> Not all boards correctly reset the system timer and in many cases the
> inital times reported by PRINTK_TIME is high. When this occurs the
> bootchart.pl script fails to give any useful output.
>
> This patch sets the $firsttime variable to the largest value expected
> by PRINTK_TIME
>
> Signed-off-by: Andrew Murray <amurray@mpc-data.co.uk>
> ---
> scripts/bootgraph.pl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/scripts/bootgraph.pl b/scripts/bootgraph.pl
> index 12caa82..b78fca9 100644
> --- a/scripts/bootgraph.pl
> +++ b/scripts/bootgraph.pl
> @@ -44,7 +44,7 @@ my %end;
> my %type;
> my $done = 0;
> my $maxtime = 0;
> -my $firsttime = 100;
> +my $firsttime = 99999;
> my $count = 0;
> my %pids;
> my %pidctr;
Adding Arjan to CC. Arjan, if you are OK with the patch, I can take it
through my tree with your Ack.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* About the "Tiny Linux Kernel" project
From: wu zhangjin @ 2011-06-10 16:41 UTC (permalink / raw)
To: celinux-dev, linux-embedded
Cc: Tim Bird, Dongdong Deng, Nicholas Mc Guire, Zhan Rongkai
Hi, embedded folks
"Linux has gained more and more new features in recent years but at
the same time has increased the kernel image size bit by bit. The new
features do expand the applications a lot but their increased size
also limit the application of Linux in some specific places."
So, I have launched a new "Tiny Linux Kernel" project, which was a
'continuator' of the forthgoer: Linux-Tiny[1]. This project was
sponsored by the "CELF Open Project 2011"[2] and its main development
will happen in the coming 4 months and of course, I hope this will be
maintained forever from now on.
1. Proposal
http://elinux.org/Work_on_Tiny_Linux_Kernel
2. Developmenet management
http://tinylab.org/index.php/projects/tinylinux/
3. Git repository
git://gitorious.org/tinylab/tinylinux.git
@https://gitorious.org/tinylab/tinylinux
The primary development effort have been put into the 2.6.35/dev/*
branches, most of the arch related parts are only for MIPS platform
currently, they will be migrated for another 3 main architectures:
ARM, PowerPC and X86. After getting enough patches of cleaning up and
fixing up, will create 2.6.35/stable/* branches and then
linux-next/dev/*, linux-next/upstream/* and at last maintain a branch
for the long-term 2.6.35 and upstream some of them to the mainline
3.x.y.
Most of the existing patches in the 2.6.35/dev/* branches are
experimental and some of them may even be 'ugly', they are only demos
for the ideas proposed. Welcome your comments, tests, defect reports
and even patches.
Thanks & Best Regards,
Wu Zhangjin
--
[1] http://elinux.org/Linux_Tiny
[2] http://elinux.org/CELF_Open_Project_Proposal_2011
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Randy Dunlap @ 2011-06-10 17:50 UTC (permalink / raw)
To: Andrew Murray
Cc: joe, w.sang, geert, linux-embedded, linux-kernel, trivial,
udknight, namhyung, Andrew Murray
In-Reply-To: <1307654688-28015-1-git-send-email-amurray@mpcdata.com>
On Thu, 9 Jun 2011 22:24:48 +0100 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>
Applied with minor tweaks (including dropping trailing whitespace).
Thanks.
> ---
> Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 117 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 1b5a5dd..6455e5b 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -9,7 +9,121 @@ 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
> + %pB prev_fn_of_versatile_init+0x88/0x88
> +
> + 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.
> +
> + The 'B' specifier results in the symbol name with offsets and should be
> + used when printing stack backtraces. The specifier takes into
> + consideration the effect of compiler optimisations which may occur
> + when tail-call's are used and marked with the noreturn GCC attribute.
> +
> + 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 0x01234567 or 0x0123456789abcdef
> +
> + 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 0x60000000-0x6fffffff flags 0x2200] or
> + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
> + %pR [mem 0x60000000-0x6fffffff pref] or
> + [mem 0x0000000060000000-0x000000006fffffff 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/rfc5952
> +
> +UUID/GUID addresses:
> +
> + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
> + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
> + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
> + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
> +
> + 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_list *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 +146,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>
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] printk-formats.txt documentation update
From: Andrew Murray @ 2011-06-10 17:56 UTC (permalink / raw)
To: Randy Dunlap
Cc: joe, w.sang, geert, linux-embedded, linux-kernel, trivial,
udknight, namhyung
In-Reply-To: <20110610105015.01504554.rdunlap@xenotime.net>
Great! Thanks for the help.
On 10 June 2011 18:50, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Thu, 9 Jun 2011 22:24:48 +0100 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>
>
> Applied with minor tweaks (including dropping trailing whitespace).
>
> Thanks.
>
>> ---
>> Documentation/printk-formats.txt | 119 +++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 117 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
>> index 1b5a5dd..6455e5b 100644
>> --- a/Documentation/printk-formats.txt
>> +++ b/Documentation/printk-formats.txt
>> @@ -9,7 +9,121 @@ 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
>> + %pB prev_fn_of_versatile_init+0x88/0x88
>> +
>> + 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.
>> +
>> + The 'B' specifier results in the symbol name with offsets and should be
>> + used when printing stack backtraces. The specifier takes into
>> + consideration the effect of compiler optimisations which may occur
>> + when tail-call's are used and marked with the noreturn GCC attribute.
>> +
>> + 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 0x01234567 or 0x0123456789abcdef
>> +
>> + 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 0x60000000-0x6fffffff flags 0x2200] or
>> + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
>> + %pR [mem 0x60000000-0x6fffffff pref] or
>> + [mem 0x0000000060000000-0x000000006fffffff 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/rfc5952
>> +
>> +UUID/GUID addresses:
>> +
>> + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
>> + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
>> + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
>> + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
>> +
>> + 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_list *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 +146,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>
>> --
>> 1.7.4.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
^ permalink raw reply
* Re: About the "Tiny Linux Kernel" project
From: Tim Bird @ 2011-06-11 0:16 UTC (permalink / raw)
To: wu zhangjin
Cc: celinux-dev@tree.celinuxforum.org, linux-embedded@vger.kernel.org,
Dongdong Deng, Nicholas Mc Guire, Zhan Rongkai
In-Reply-To: <BANLkTikupJVJtF1hbnC6Y67E8ma7xNmeGg@mail.gmail.com>
On 06/10/2011 09:41 AM, wu zhangjin wrote:
> Hi, embedded folks
>
> "Linux has gained more and more new features in recent years but at
> the same time has increased the kernel image size bit by bit. The new
> features do expand the applications a lot but their increased size
> also limit the application of Linux in some specific places."
>
> So, I have launched a new "Tiny Linux Kernel" project, which was a
> 'continuator' of the forthgoer: Linux-Tiny[1]. This project was
> sponsored by the "CELF Open Project 2011"[2] and its main development
> will happen in the coming 4 months and of course, I hope this will be
> maintained forever from now on.
>
> 1. Proposal
>
> http://elinux.org/Work_on_Tiny_Linux_Kernel
>
> 2. Developmenet management
>
> http://tinylab.org/index.php/projects/tinylinux/
>
> 3. Git repository
>
> git://gitorious.org/tinylab/tinylinux.git
>
> @https://gitorious.org/tinylab/tinylinux
>
> The primary development effort have been put into the 2.6.35/dev/*
> branches, most of the arch related parts are only for MIPS platform
> currently, they will be migrated for another 3 main architectures:
> ARM, PowerPC and X86. After getting enough patches of cleaning up and
> fixing up, will create 2.6.35/stable/* branches and then
> linux-next/dev/*, linux-next/upstream/* and at last maintain a branch
> for the long-term 2.6.35 and upstream some of them to the mainline
> 3.x.y.
>
> Most of the existing patches in the 2.6.35/dev/* branches are
> experimental and some of them may even be 'ugly', they are only demos
> for the ideas proposed. Welcome your comments, tests, defect reports
> and even patches.
Wu,
Thanks very much for making this announcement. I'm very excited
about this work.
I had a chance this week to meet with some of my colleagues inside
Sony, who are working on projects with Linux that have a RAM budget
of 3 meg. This and related size work is really important for us.
-- Tim
P.S. For those wondering, while our RAM budget is only 3M, we
have 8M of NOR flash, and we are using both kernel and application
XIP. The system has a full network and bluetooth stack, sensor
monitoring software, and a web browser.
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: Tim Bird @ 2011-06-11 0:39 UTC (permalink / raw)
To: wu zhangjin
Cc: Dongdong Deng, Zhan Rongkai, linux-embedded@vger.kernel.org,
celinux-dev@tree.celinuxforum.org
In-Reply-To: <4DF2B3EC.6020700@am.sony.com>
On 06/10/2011 05:16 PM, Tim Bird wrote:
> The system has a full network and bluetooth stack, sensor
> monitoring software, and a web browser.
Oops. Should be "web server". I don't know of a modern
browser that fits in less than 3 meg.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* Re: [PATCH] Bootgraph.pl bug fix
From: Arjan van de Ven @ 2011-06-11 3:21 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Andrew Murray, linux-embedded, linux-kernel, Andrew Murray
In-Reply-To: <alpine.LNX.2.00.1106101459570.22872@pobox.suse.cz>
On Fri, 10 Jun 2011 15:00:38 +0200 (CEST)
Jiri Kosina <jkosina@suse.cz> wrote:
>
> Adding Arjan to CC. Arjan, if you are OK with the patch, I can take
> it through my tree with your Ack.
I don't mind the patch, although I feel pitty for those having to work
with such broken systems...
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: wu zhangjin @ 2011-06-11 3:28 UTC (permalink / raw)
To: Tim Bird
Cc: Dongdong Deng, Zhan Rongkai, linux-embedded@vger.kernel.org,
celinux-dev@tree.celinuxforum.org
In-Reply-To: <4DF2B952.30309@am.sony.com>
Hi, Tim
On Sat, Jun 11, 2011 at 8:39 AM, Tim Bird <tim.bird@am.sony.com> wrote:
> On 06/10/2011 05:16 PM, Tim Bird wrote:
>> The system has a full network and bluetooth stack, sensor
>> monitoring software, and a web browser.
> Oops. Should be "web server". I don't know of a modern
> browser that fits in less than 3 meg.
For such a system, I suggest you use the idea in another project
launched by me ;-)
It is vnstagsvg: http://vnstatsvg.sourceforge.net/
"vnStatSVG is a web front-end to vnStat(a network traffic logger). it
only requires a cgi-supported http server setup but also generates a
graphical report with SVG. and with the support of AJAX, it has a very
scalable architecture, hence, it is suited to the resource-limited
distributed & embedded linux system."
So, the httpd web server provided by busybox is enough, therefore you
can simply ignore the "web server" ;-)
If you want the background idea of this project, welcome to read my
paper: "A CGI+AJAX+SVG based monitoring method for distributed and
embedded system".
Best Regards,
Wu Zhangjin
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
>
>
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: wu zhangjin @ 2011-06-11 3:35 UTC (permalink / raw)
To: Tim Bird
Cc: Dongdong Deng, Zhan Rongkai, linux-embedded@vger.kernel.org,
celinux-dev@tree.celinuxforum.org
In-Reply-To: <4DF2B952.30309@am.sony.com>
On Sat, Jun 11, 2011 at 8:39 AM, Tim Bird <tim.bird@am.sony.com> wrote:
> On 06/10/2011 05:16 PM, Tim Bird wrote:
>> The system has a full network and bluetooth stack, sensor
>> monitoring software, and a web browser.
> Oops. Should be "web server". I don't know of a modern
> browser that fits in less than 3 meg.
For web browser, what bout lynx, links2 and w3m? ;-)
Regards,
Wu Zhangjin
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
>
>
^ permalink raw reply
* Re: About the "Tiny Linux Kernel" project
From: Nicholas Mc Guire @ 2011-06-11 5:06 UTC (permalink / raw)
To: wu zhangjin
Cc: Dongdong Deng, Zhan Rongkai,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-VxL1A5FK7jA05z2xGA6PZHhyD016LWXt@public.gmane.org
In-Reply-To: <BANLkTikLT_QODGBDn2SXqQM0qR=4q8-fcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, 11 Jun 2011, wu zhangjin wrote:
> On Sat, Jun 11, 2011 at 8:39 AM, Tim Bird <tim.bird-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org> wrote:
> > On 06/10/2011 05:16 PM, Tim Bird wrote:
> >> The system has a full network and bluetooth stack, sensor
> >> monitoring software, and a web browser.
> > Oops. Should be "web server". ?I don't know of a modern
> > browser that fits in less than 3 meg.
>
> For web browser, what bout lynx, links2 and w3m? ;-)
>
and if limited functionality is needed a custom browser can be
built easily (even netcat + shell could do) - for web servers
there are plenty of very small servers for serving static pages
combined with a process to updated the pages (i.e. cron/shell loop)
this is fine for monitoring a system (thttp or the like - 20k)
the static page limit is actually advisable due to security issues
or it starts getting really complicated.
hofrat
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: Joaco @ 2011-06-11 16:25 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4DF2B952.30309@am.sony.com>
I am happy with elinks-13.0 text mode browser. At 2.9Mb, it fits nicely
in a less than 128Mb compact flash image. I use it with my Advantech
board.
I can even connect with Yahoo Mail Classsic to read mail and
have had very few problems browsing most sites. I can always connect,
its just the quality of the browse that is not as good, as say Opera11!
But its nicely functional in a less than 80Mb Linux FS.
TonyB
>
> On 06/10/2011 05:16 PM, Tim Bird wrote:
> > The system has a full network and bluetooth stack, sensor
> > monitoring software, and a web browser.
> Oops. Should be "web server". I don't know of a modern
> browser that fits in less than 3 meg.
> -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
__ __ _ I N C. http://www.sysdev.org
/ __|\\// __|| \ __ __ / tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ / \/ System Tools / Utilities
|___/ || ___/|_ /\___|\_/ WIntel / Linux Device Drivers
^ permalink raw reply
* Re: [PATCH] Bootgraph.pl bug fix
From: Jiri Kosina @ 2011-06-12 22:05 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andrew Murray, linux-embedded, linux-kernel, Andrew Murray
In-Reply-To: <20110610202123.6e9df89c@infradead.org>
On Fri, 10 Jun 2011, Arjan van de Ven wrote:
> > Adding Arjan to CC. Arjan, if you are OK with the patch, I can take
> > it through my tree with your Ack.
>
> I don't mind the patch, although I feel pitty for those having to work
> with such broken systems...
Indeed.
Thanks, I have applied it with your Acked-by.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: Alan Carvalho de Assis @ 2011-06-13 15:11 UTC (permalink / raw)
To: Tim Bird
Cc: wu zhangjin, Dongdong Deng, Zhan Rongkai,
celinux-dev@tree.celinuxforum.org, linux-embedded@vger.kernel.org
In-Reply-To: <4DF2B952.30309@am.sony.com>
Hi Tim,
On 6/10/11, Tim Bird <tim.bird@am.sony.com> wrote:
> On 06/10/2011 05:16 PM, Tim Bird wrote:
>> The system has a full network and bluetooth stack, sensor
>> monitoring software, and a web browser.
> Oops. Should be "web server". I don't know of a modern
> browser that fits in less than 3 meg.
Although I didn't test it yet with 3MB, I'm pretty sure that Dillo2
(www.dillo.org) could fit in 3MB of RAM. The binary size is less than
1MB. But it depends what you mean by modern. It doesn't support HTML5,
but support current HTML4 and CSS.
Best Regards,
Alan
^ permalink raw reply
* Re: [Celinux-dev] About the "Tiny Linux Kernel" project
From: wu zhangjin @ 2011-06-13 15:39 UTC (permalink / raw)
To: Alan Carvalho de Assis
Cc: Tim Bird, Dongdong Deng, Zhan Rongkai,
celinux-dev@tree.celinuxforum.org, linux-embedded@vger.kernel.org
In-Reply-To: <BANLkTik27PR-74=CFrn_Zq6EVx579cLLOA@mail.gmail.com>
On Mon, Jun 13, 2011 at 11:11 PM, Alan Carvalho de Assis
<acassis@gmail.com> wrote:
> Hi Tim,
>
> On 6/10/11, Tim Bird <tim.bird@am.sony.com> wrote:
>> On 06/10/2011 05:16 PM, Tim Bird wrote:
>>> The system has a full network and bluetooth stack, sensor
>>> monitoring software, and a web browser.
>> Oops. Should be "web server". I don't know of a modern
>> browser that fits in less than 3 meg.
>
> Although I didn't test it yet with 3MB, I'm pretty sure that Dillo2
> (www.dillo.org) could fit in 3MB of RAM. The binary size is less than
> 1MB. But it depends what you mean by modern. It doesn't support HTML5,
> but support current HTML4 and CSS.
midori and arora are another two candidates:
$ ls -lh /usr/bin/midori
-rwxr-xr-x 1 root root 550K 2010-06-23 03:00 /usr/bin/midori
$ ls -lh /usr/bin/arora
-rwxr-xr-x 1 root root 1.3M 2010-07-21 17:23 /usr/bin/arora
Regards,
Wu Zhangjin
>
> Best Regards,
>
> Alan
>
^ 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