Re: [PATCH 1/3] kernel: Add a new config option to remove command line parsing
On 04/01/2015 07:34 AM, Iulia Manda wrote: > This patch introduces CONFIG_CMDLINE_PARSE option which conditionally compiles > the support for parsing kernel command line arguments. The corresponding > functions that actually do the parsing will be compiled out. > > This is used when no parameters will be specified neither at compile time nor > at > boot time. > > Bloat-o-meter output (compared to the preivous version in which builtin > cmdline > was also set to 'Y'): > > add/remove: 0/8 grow/shrink: 0/6 up/down: 0/-3669 (-3669) I think this is great stuff. (Of course, having research something like this previously, I'm a bit biased.) It's very nice to have the Bloat-o-meter output for these kernel size shrinking patches. The patch itself looks very straightforward, and I don't see any problems in a visual inspection. You can add a Reviewed-by: Tim Bird to this patch. I'd like to be able to point people to this on the mailing list. In the future can you make sure to CC: , so there's a reference on lkml.org I can point people to? Thanks for this great work! -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: embedding dtb file into kernel
On 02/12/2015 02:30 PM, K Richard Pixley wrote: > On 2/12/15 14:01 , Tim Bird wrote: >> On 02/12/2015 11:33 AM, K Richard Pixley wrote: >>> I'm having trouble figuring out how to embed a dtb file into my kernel. >>> I'm thinking that there should be a standard, architecture independent >>> facility for this akin to initramfs, yes? >>> >>> Could someone please either point me to the standard facility, relevant >>> doc, a currently building board that uses the standard facility, or >>> outline what needs to be done to do this with a new board? >>> >>> If it matters, (I can't think why it would), I'm working with powerpc on >>> a 3.10 kernel. But if there are better facilities in other versions I'd >>> appreciate hearing about that too. >> The normal method is just to cat the two files together, like so: >> $ cat zImage .dtb > zImage_w_dtb >> >> See https://community.freescale.com/thread/315543 for one example, on ARM. >> I'm not sure what the status is for appended DTBs on powerpc, but it's >> easy enough you can just try it and see what happens. >> -- Tim > > Thanks! > > How do I tell the kernel where to find that dtb? Is there a relevant > config option? Usually you make the dtb from sources in the kernel. I don't know how it works on powerpc, but on arm, the .dts files are located in arch/arm/boot/dts, and you would make the dtb for the corresponding "foo.dts" source by typing: $ make foo.dtb -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: embedding dtb file into kernel
On 02/12/2015 11:33 AM, K Richard Pixley wrote: > I'm having trouble figuring out how to embed a dtb file into my kernel. > I'm thinking that there should be a standard, architecture independent > facility for this akin to initramfs, yes? > > Could someone please either point me to the standard facility, relevant > doc, a currently building board that uses the standard facility, or > outline what needs to be done to do this with a new board? > > If it matters, (I can't think why it would), I'm working with powerpc on > a 3.10 kernel. But if there are better facilities in other versions I'd > appreciate hearing about that too. The normal method is just to cat the two files together, like so: $ cat zImage .dtb > zImage_w_dtb See https://community.freescale.com/thread/315543 for one example, on ARM. I'm not sure what the status is for appended DTBs on powerpc, but it's easy enough you can just try it and see what happens. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ELC CFP deadline is Jan 9
Hi embedded Linux developers, This is quick reminder that the deadline for the Call For Participation for Embedded Linux Conference 2015 is January 9 (this Friday). The event is on March 23-25 in San Jose, California. Please make sure to propose something if you are interested in coming. I'd write more, but I'm probably breaking list etiquette enough as it is... :-) Check out the CFP for details: http://events.linuxfoundation.org/events/embedded-linux-conference/program/cfp -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: kselftest size roadmap
Here's an RFC on my roadmap for the kselftest size test going forward... In the long term, I'd like to be able to use the test for bisecting size regressions, and to allow any kernel developer to use this even if they don't have hardware for a particular architecture. What I'd like to add to this in the future: - cleaned up approach to cross-compilation - put CROSS_COMPILE handling outside sub-directory Makefiles - this should include support for KBUILD_OUTPUT - handle CFLAGS for user-space programs (as opposed to kernel CFLAGS), and in a unified way - ability to run on target or in emulator - will involve adding an "install phase", and possibly a "collect results" phase. These are needed throughout kselftest to do any host/target testing. - add a size threshold parameter to allow the test to check for a regression - test needs to return failure code that git bisect can use (not sure about mechanism for this yet) - regression test might utilize a feature to save off a "baseline" size to measure against, for the ability to indicate a regression as "current size > baseline + 20k" Any feedback on this? Thanks, -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] selftest: size: Add size test for Linux kernel
On 12/03/2014 04:08 PM, Michael Ellerman wrote: > On Wed, 2014-12-03 at 08:29 -0800, Tim Bird wrote: >> >> On 12/02/2014 07:43 PM, Michael Ellerman wrote: >>> On Tue, 2014-12-02 at 19:36 -0800, Tim Bird wrote: >>>> This test shows the amount of memory used by the system. >>>> Note that this is dependent on the user-space that is loaded >>>> when this program runs. Optimally, this program would be >>>> run as the init program itself. >>> >>> Sorry to only chime in at v5. >>> >>>> diff --git a/tools/testing/selftests/size/Makefile >>>> b/tools/testing/selftests/size/Makefile >>>> new file mode 100644 >>>> index 000..47f8e9c >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/size/Makefile >>>> @@ -0,0 +1,15 @@ >>>> +#ifndef CC >>>> + CC = $(CROSS_COMPILE)gcc >>>> +#endif >>> >>> I think the following is preferable: >>> >>> CC := $(CROSS_COMPILE)$(CC) >>> >>> >>> It allows optionally setting a custom CC, as well as optionally >>> CROSS_COMPILE. >> >> I'm not sure I follow this. >> >> If CC is unset, you get only the CROSS_COMPILE prefix. > > CC is never unset. The default value is 'cc'. Yeah - I found that out by experimentation yesterday. So my whole idea for configuring it based on an unset CC was misguided. > >> If CC is set to e.g. 'gcc', then you get a nicely formatted toolchain string. > > Right. > >> But if CC already has the prefix applied, then this will result in >> having it duplicated, which surely won't work correctly. > > That's just PEBKAC. Don't specify CROSS_COMPILE and also a fully specified CC. > Try it with the kernel Makefile and see how well it works. > >> CROSS_COMPILE prefix usage looks a bit uncoordinated in the tools directory, >> but most >> tests seem to be favoring $(CROSS_COMPILE)gcc. > > That doesn't make it right :) Agreed. I'd like to separate this issue from the rest of the patch. Shuah has accepted the patch as it currently is, but I'd like to start working on the best way to support cross compilation throughout the kselftest suite. Ideally we can have CC set properly in a higher-level Makefile, and not reference CROSS_COMPILE at all in the sub-directory Makefiles. This may involve copying how CROSS_COMPILE and CFLAGS work in the rest of the kernel tree, or making some kselftest-specific modifications. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Signed-off-by: Tim Bird
---
Changes from v5:
- remove #ifdef in Makefile (doh!)
- use variables in build command
- use different num_to_str, with less conversions
Changes from v4:
- make most routines static
- replace strip with gcc -s
- remove explicit reference to _start
- change --static to -static
- remove explicit reference to LIBGCC
- fix test description for ok and not ok paths, for test 1
Changes from v3:
- add more human-readable output
- put libgcc reference into a variable in Makefile
Changes from v2:
- fix copyright string (again!)
- use __builtin_strlen instead of my own strlen
- replace main with _start
Changes from v1:
- add return values to print routines
- add .gitignore file
- use more correct Copyright string in get_size.c
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 12
tools/testing/selftests/size/get_size.c | 100
4 files changed, 114 insertions(+)
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/.gitignore
b/tools/testing/selftests/size/.gitignore
new file mode 100644
index 000..189b781
--- /dev/null
+++ b/tools/testing/selftests/size/.gitignore
@@ -0,0 +1 @@
+get_size
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..04dc25e
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,12 @@
+CC = $(CROSS_COMPILE)gcc
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) -static -ffreestanding -nostartfiles -s $< -o $@
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..2d1af7c
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright 2014 Sony Mobile Communications Inc.
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing it's own
+ * number output and print routines, and using __builtin_strlen()
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+static int print(const char *s)
+{
+ return write(STDOUT_FILENO, s, __builtin_strlen(s));
+}
+
+static inline char *num_to_str(unsigned long num, char *buf, int len)
+{
+ unsigned int digit;
+
+ /* put digits in buffer from back to front */
+ buf += len - 1;
+ *buf = 0;
+ do {
+ digit = num % 10;
+ *(--buf) = digit + '0';
+ num /= 10;
+ } while (num > 0);
+
+ return buf;
+}
+
+static int print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ return print(num_to_str(num, num_buf, sizeof(num_buf)));
+}
+
+static int print_k_value(const char *s, unsigned long num, unsigned long units)
+{
+ unsigned long long temp;
+ int ccode;
+
+ print(s);
+
+ temp = num;
+ temp = (temp * units)/1024;
+ num = temp;
+ ccode = print_num(num);
+ print("\n");
+ return ccode;
+}
+
+/* this program has no main(), as startup libraries are not used */
+void _start(void)
+{
+ int ccode;
+ struct sysinfo info;
+ unsigned long used;
+
+ print("Testing system size.\n");
+ print(&
Re: [PATCH v5] selftest: size: Add size test for Linux kernel
On 12/03/2014 10:00 AM, Geert Uytterhoeven wrote: > On Wed, Dec 3, 2014 at 5:29 PM, Tim Bird wrote: >>>> diff --git a/tools/testing/selftests/size/Makefile >>>> b/tools/testing/selftests/size/Makefile >>>> new file mode 100644 >>>> index 000..47f8e9c >>>> --- /dev/null >>>> +++ b/tools/testing/selftests/size/Makefile >>>> @@ -0,0 +1,15 @@ >>>> +#ifndef CC >>>> +CC = $(CROSS_COMPILE)gcc >>>> +#endif >>> >>> I think the following is preferable: >>> >>> CC := $(CROSS_COMPILE)$(CC) >>> >>> >>> It allows optionally setting a custom CC, as well as optionally >>> CROSS_COMPILE. >> >> I'm not sure I follow this. >> >> If CC is unset, you get only the CROSS_COMPILE prefix. >> If CC is set to e.g. 'gcc', then you get a nicely formatted toolchain string. >> But if CC already has the prefix applied, then this will result in >> having it duplicated, which surely won't work correctly. >> >> In the long run, I would hope that a higher level Makefile or environment >> setting >> will be setting the toolchain string appropriately (as well as handling >> build flags) >> which is why I wanted to use an ifndef (which Thomas correctly pointed out >> is just >> wrong). >> >> Actually, after getting this tiny program accepted, my next task was working >> on a >> proper fix for handling cross compilation in a more generic (not >> case-by-case) way. >> >> CROSS_COMPILE prefix usage looks a bit uncoordinated in the tools directory, >> but most >> tests seem to be favoring $(CROSS_COMPILE)gcc. >> >> $ cd tools ; mgrep CROSS > > [...] > >> I agree it's desirable not to hardcode gcc, but we seem to be doing it all >> over >> the place already. > > Seems like it's time to start integrating the tests with the regular Kbuild > system, which handles cross-compilation fine... Where possible, yes. It would be nice to leverage CROSS_COMPILE and CFLAGS, or a portion thereof, from the Kbuild system (as well a KBUILD_OUTPUT and friends). It's on my to-do list, after getting my little C program accepted... -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] selftest: size: Add size test for Linux kernel
On 12/02/2014 07:43 PM, Michael Ellerman wrote: > On Tue, 2014-12-02 at 19:36 -0800, Tim Bird wrote: >> This test shows the amount of memory used by the system. >> Note that this is dependent on the user-space that is loaded >> when this program runs. Optimally, this program would be >> run as the init program itself. > > Sorry to only chime in at v5. > >> diff --git a/tools/testing/selftests/size/Makefile >> b/tools/testing/selftests/size/Makefile >> new file mode 100644 >> index 000..47f8e9c >> --- /dev/null >> +++ b/tools/testing/selftests/size/Makefile >> @@ -0,0 +1,15 @@ >> +#ifndef CC >> +CC = $(CROSS_COMPILE)gcc >> +#endif > > I think the following is preferable: > > CC := $(CROSS_COMPILE)$(CC) > > > It allows optionally setting a custom CC, as well as optionally CROSS_COMPILE. I'm not sure I follow this. If CC is unset, you get only the CROSS_COMPILE prefix. If CC is set to e.g. 'gcc', then you get a nicely formatted toolchain string. But if CC already has the prefix applied, then this will result in having it duplicated, which surely won't work correctly. In the long run, I would hope that a higher level Makefile or environment setting will be setting the toolchain string appropriately (as well as handling build flags) which is why I wanted to use an ifndef (which Thomas correctly pointed out is just wrong). Actually, after getting this tiny program accepted, my next task was working on a proper fix for handling cross compilation in a more generic (not case-by-case) way. CROSS_COMPILE prefix usage looks a bit uncoordinated in the tools directory, but most tests seem to be favoring $(CROSS_COMPILE)gcc. $ cd tools ; mgrep CROSS ./vm/Makefile:CC = $(CROSS_COMPILE)gcc ./usb/Makefile:CC = $(CROSS_COMPILE)gcc ./testing/selftests/net/Makefile:CC = $(CROSS_COMPILE)gcc ./testing/selftests/vm/Makefile:CC = $(CROSS_COMPILE)gcc ./testing/selftests/efivarfs/Makefile:CC = $(CROSS_COMPILE)gcc ./testing/selftests/size/Makefile: CC = $(CROSS_COMPILE)gcc ./testing/selftests/powerpc/Makefile:CC := $(CROSS_COMPILE)$(CC) ./hv/Makefile:CC = $(CROSS_COMPILE)gcc ./perf/config/feature-checks/Makefile:CC := $(CROSS_COMPILE)gcc -MD ./perf/config/feature-checks/Makefile:PKG_CONFIG := $(CROSS_COMPILE)pkg-config ./lib/api/Makefile:CC = $(CROSS_COMPILE)gcc ./lib/api/Makefile:AR = $(CROSS_COMPILE)ar ./lib/lockdep/Makefile:# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix. ./lib/lockdep/Makefile:$(call allow-override,CC,$(CROSS_COMPILE)gcc) ./lib/lockdep/Makefile:$(call allow-override,AR,$(CROSS_COMPILE)ar) ./lib/lockdep/Makefile:TRACK_CFLAGS = $(subst ','\'',$(CFLAGS)):$(ARCH):$(CROSS_COMPILE) ./lib/traceevent/Makefile:# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix. ./lib/traceevent/Makefile:$(call allow-override,CC,$(CROSS_COMPILE)gcc) ./lib/traceevent/Makefile:$(call allow-override,AR,$(CROSS_COMPILE)ar) ./lib/traceevent/Makefile:TRACK_CFLAGS = $(subst ','\'',$(CFLAGS)):$(ARCH):$(CROSS_COMPILE) ./cgroup/Makefile:CC = $(CROSS_COMPILE)gcc ./power/acpi/Makefile:CROSS = #/usr/i386-linux-uclibc/usr/bin/i386-uclibc- ./power/acpi/Makefile:CC = $(CROSS)gcc ./power/acpi/Makefile:LD = $(CROSS)gcc ./power/acpi/Makefile:STRIP = $(CROSS)strip ./power/cpupower/Makefile:CROSS = #/usr/i386-linux-uclibc/usr/bin/i386-uclibc- ./power/cpupower/Makefile:CC = $(CROSS)gcc ./power/cpupower/Makefile:LD = $(CROSS)gcc ./power/cpupower/Makefile:AR = $(CROSS)ar ./power/cpupower/Makefile:STRIP = $(CROSS)strip ./power/cpupower/Makefile:RANLIB = $(CROSS)ranlib ./power/cpupower/Makefile:export CROSS CC AR STRIP RANLIB CFLAGS LDFLAGS LIB_OBJS ./power/x86/turbostat/Makefile:CC = $(CROSS_COMPILE)gcc I agree it's desirable not to hardcode gcc, but we seem to be doing it all over the place already. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] selftest: size: Add size test for Linux kernel
On 12/03/2014 05:01 AM, Thomas Petazzoni wrote: > Michael, Tim, > > On Wed, 03 Dec 2014 14:43:11 +1100, Michael Ellerman wrote: > >>> diff --git a/tools/testing/selftests/size/Makefile >>> b/tools/testing/selftests/size/Makefile >>> new file mode 100644 >>> index 000..47f8e9c >>> --- /dev/null >>> +++ b/tools/testing/selftests/size/Makefile >>> @@ -0,0 +1,15 @@ >>> +#ifndef CC >>> + CC = $(CROSS_COMPILE)gcc >>> +#endif >> >> I think the following is preferable: >> >> CC := $(CROSS_COMPILE)$(CC) > > It is even more necessary that #ifndef and #endif don't exist in make. > They are just comments, and therefore, ignored. Seems like Tim does too > much C :-) OK - that's hilarious. Saying 'Oops!' would be too casual for my degree of embarrassment. :-) Makefiles do have similar constructs. Those should have been ifeq ($(CC),) ... endif This obviously got through via a failiure in testing - which is somewhat ironic. Look for a v6 soon. (Geez, when is the merge window coming. I thought this trivial program would get in pretty easily, but no... that's never the way. Of course it helps if the submitter is not an idiot.) -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Signed-off-by: Tim Bird
---
Changes from v5:
- make most routines static
- replace strip with gcc -s
- remove explicit reference to _start
- change --static to -static
- remove explicit reference to LIBGCC
- fix test description for ok and not ok paths, for test 1
Changes from v4:
- add more human-readable output
- put libgcc reference into a variable in Makefile
Changes from v3:
- fix copyright string (again!)
- use __builtin_strlen instead of my own strlen
- replace main with _start
Changes from v2:
- add return values to print routines
- add .gitignore file
Changes from v1:
- use more correct Copyright string in get_size.c
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 15 +
tools/testing/selftests/size/get_size.c | 111
4 files changed, 128 insertions(+)
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/.gitignore
b/tools/testing/selftests/size/.gitignore
new file mode 100644
index 000..189b781
--- /dev/null
+++ b/tools/testing/selftests/size/.gitignore
@@ -0,0 +1 @@
+get_size
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..47f8e9c
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,15 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) -static -ffreestanding -nostartfiles \
+ -s get_size.c -o get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..808e7c6
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright 2014 Sony Mobile Communications Inc.
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing it's own
+ * number output and print routines, and using __builtin_strlen()
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+static int print(const char *s)
+{
+ return write(STDOUT_FILENO, s, __builtin_strlen(s));
+}
+
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+static void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+static int print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ return print(num_buf);
+}
+
+static int print_k_value(const char *s, unsigned long num, unsigned long units)
+{
+ unsigned long long temp;
+ int ccode;
+
+ print(s);
+
+ temp = num;
+ temp = (temp * units)/1024;
+ num = temp;
+ ccode = print_nu
Re: [PATCH v4] selftest: size: Add size test for Linux kernel
On 11/26/2014 10:04 PM, Josh Triplett wrote:
> On Wed, Nov 26, 2014 at 08:27:23PM -0800, Tim Bird wrote:
>> --- /dev/null
>> +++ b/tools/testing/selftests/size/Makefile
> [...]
>> +LIBGCC=$(shell $(CC) -print-libgcc-file-name)
>> +
>> +get_size: get_size.c
>> +$(CC) --static -ffreestanding -nostartfiles \
>> +-Wl,--entry=_start get_size.c $(LIBGCC) \
>> +-o get_size
>
> You don't need -Wl,--entry=_start; that's the default.
OK - it works without this. Thanks.
> You shouldn't need to manually find libgcc, either; the compiler should
> do that for you. What goes wrong if you don't include that? If you're
> trying to link libgcc statically, try -static-libgcc.
>
> Also, static is normally spelled -static, not --static.
Hmm. Not sure where I got --static from, but it worked.
But if -static is the norm I'm fine changing to that.
Upon experimentation, I don't need the explicit libgcc or for that
matter the -static-libgcc either.
>> --- /dev/null
>> +++ b/tools/testing/selftests/size/get_size.c
> [...]
>> +int print(const char *s)
>
> This function, and all the others apart from _start, should be declared
> static.
OK will do.
>> +void num_to_str(unsigned long num, char *s)
>
> Likewise, static.
OK
>> +{
>> +unsigned long long temp, div;
>> +int started;
>> +
>> +temp = num;
>> +div = 100LL;
>> +started = 0;
>> +while (div) {
>> +if (temp/div || started) {
>> +*s++ = (unsigned char)(temp/div + '0');
>> +started = 1;
>> +}
>> +temp -= (temp/div)*div;
>> +div /= 10;
>> +}
>> +*s = 0;
>> +}
>
> You'd probably end up with significantly smaller code (and no divisions,
> and thus no corner cases on architectures that need a special function
> to do unsigned long long division) if you print in hex. You could also
> drop the "no leading zeros" logic, and just *always* print a 64-bit
> value as 16 hex digits.
I'd like to keep base-10 output. As far as size is concerned, the
code is now at well under 2 pages (8k), which is much smaller than
any actually useful program. The only noticeable change in size would
be if I got it under 4096, but I don't want to sacrifice too many
features to get there (as that's still only 1 page difference in
memory usage.)
BTW - using sstrip, I can get it to 4096 already, as is.
Unfortunately, 'sstrip -z', which gets it to 2061, makes
it not work. I need to check out what the problem is there.
Also, the ELF file still has an unneeded note section. I think
easier reductions, without sacrificing functionality, are available
by tweaking the ELF header (ie fixing sstrip, for those that
want to use it).
>> +int print_num(unsigned long num)
>
> Likewise, static.
OK
>> +{
>> +char num_buf[30];
>> +
>> +num_to_str(num, num_buf);
>> +return print(num_buf);
>> +}
>> +
>> +int print_k_value(const char *s, unsigned long num, unsigned long units)
>> +{
>> +unsigned long long temp;
>> +int ccode;
>> +
>> +print(s);
>> +
>> +temp = num;
>> +temp = (temp * units)/1024;
>> +num = temp;
>> +ccode = print_num(num);
>> +print("\n");
>> +return ccode;
>> +}
>
> I'd suggest dropping this entirely, and just always printing the exact
> values returned by sysinfo. Drop the multiply, too, and just print
> info.mem_unit as well. It's easy to post-process the value in a more
> capable environment.
I'd prefer to keep the output easily human-readable.
>> +/* this program has no main(), as startup libraries are not used */
>> +void _start(void)
>> +{
>> +int ccode;
>> +struct sysinfo info;
>> +unsigned long used;
>> +
>> +print("Testing system size.\n");
>> +print("1..1\n");
>> +
>> +ccode = sysinfo(&info);
>> +if (ccode < 0) {
>> +print("not ok 1 get size runtime size\n");
>
> Shouldn't the "not ok" here and the "ok" below have the same test
> description?
Yes. Thanks. Good catch.
>> +print("# could not get sysinfo\n");
>> +_exit(ccode);
>> +}
>> +/* ignore cache complexities for now */
>> +used = info.totalram - info.freeram - info.bufferram;
>> +print_k_value("ok 1 get runtime memory use # size = ", used,
>> +info.mem_unit);
>> +
>> +print("# System runtime memory report (units in Kilobytes):\n");
>> +print_k_value("# Total: ", info.totalram, info.mem_unit);
>> +print_k_value("# Free: ", info.freeram, info.mem_unit);
>> +print_k_value("# Buffer: ", info.bufferram, info.mem_unit);
>> +print_k_value("# In use: ", used, info.mem_unit);
>> +
>> +_exit(0);
>> +}
>> --
>> 1.8.2.2
OK - look for a new version shortly (maybe not today, though).
-- Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Signed-off-by: Tim Bird
---
Changes from v3:
- fix copyright string (again!)
- use __builtin_strlen instead of my own strlen
- replace main with _start
- add more human-readable output
- put libgcc reference into a variable in Makefile
Changes from v2:
- add return values to print routines
- add .gitignore file
Changes from v1:
- use more correct Copyright string in get_size.c
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 23 +++
tools/testing/selftests/size/get_size.c | 111
4 files changed, 136 insertions(+)
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/.gitignore
b/tools/testing/selftests/size/.gitignore
new file mode 100644
index 000..189b781
--- /dev/null
+++ b/tools/testing/selftests/size/.gitignore
@@ -0,0 +1 @@
+get_size
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..1862786
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,23 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+#ifndef STRIP
+ STRIP = $(CROSS_COMPILE)strip
+#endif
+
+all: get_size
+
+LIBGCC=$(shell $(CC) -print-libgcc-file-name)
+
+get_size: get_size.c
+ $(CC) --static -ffreestanding -nostartfiles \
+ -Wl,--entry=_start get_size.c $(LIBGCC) \
+ -o get_size
+ $(STRIP) -s get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..7e9bbb4
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright 2014 Sony Mobile Communications Inc.
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing it's own
+ * number output and print routines, and using __builtin_strlen()
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+int print(const char *s)
+{
+ return write(STDOUT_FILENO, s, __builtin_strlen(s));
+}
+
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+int print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ return print(num_buf);
+}
+
+int print_k_value(const char *s, unsigned long num, unsigned long units)
+{
+ unsigned long long temp;
+ int ccode;
+
+ print(s);
+
+ temp = num;
+ temp = (temp * units)/1024;
+ num = temp;
+ ccode = print_num(num);
+ print("\n");
+ return ccode;
+}
+
+/* this program has no main(), as startup librarie
Re: [PATCH v3] selftest: size: Add size test for Linux kernel
On 11/25/2014 12:39 PM, Shuah Khan wrote:
> On 11/24/2014 11:20 AM, Tim Bird wrote:
>>
>> This test shows the amount of memory used by the system.
>> Note that this is dependent on the user-space that is loaded
>> when this program runs. Optimally, this program would be
>> run as the init program itself.
>>
>> The program is optimized for size itself, to avoid conflating
>> its own execution with that of the system software.
>> The code is compiled statically, with no stdlibs. On my x86_64 system,
>> this results in a statically linked binary of less than 5K.
>>
>
> This following version information shouldn't be part of changelog.
>
>> Changes from v2:
>> - add return values to print routines
>> - add .gitignore file
>>
>> Changes from v1:
>> - use more correct Copyright string in get_size.c
>>
>> Signed-off-by: Tim Bird
>> ---
>
> Goes here.
OK - I'll change this.
>
>> tools/testing/selftests/Makefile| 1 +
>> tools/testing/selftests/size/.gitignore | 1 +
>> tools/testing/selftests/size/Makefile | 21 +++
>> tools/testing/selftests/size/get_size.c | 105
>>
>> 4 files changed, 128 insertions(+)
>> create mode 100644 tools/testing/selftests/size/.gitignore
>> create mode 100644 tools/testing/selftests/size/Makefile
>> create mode 100644 tools/testing/selftests/size/get_size.c
>>
>> diff --git a/tools/testing/selftests/Makefile
>> b/tools/testing/selftests/Makefile
>> index 45f145c..fa91aef 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -15,6 +15,7 @@ TARGETS += user
>> TARGETS += sysctl
>> TARGETS += firmware
>> TARGETS += ftrace
>> +TARGETS += size
>>
>> TARGETS_HOTPLUG = cpu-hotplug
>> TARGETS_HOTPLUG += memory-hotplug
>> diff --git a/tools/testing/selftests/size/.gitignore
>> b/tools/testing/selftests/size/.gitignore
>> new file mode 100644
>> index 000..189b781
>> --- /dev/null
>> +++ b/tools/testing/selftests/size/.gitignore
>> @@ -0,0 +1 @@
>> +get_size
>> diff --git a/tools/testing/selftests/size/Makefile
>> b/tools/testing/selftests/size/Makefile
>> new file mode 100644
>> index 000..51e5fbd
>> --- /dev/null
>> +++ b/tools/testing/selftests/size/Makefile
>> @@ -0,0 +1,21 @@
>> +#ifndef CC
>> +CC = $(CROSS_COMPILE)gcc
>> +#endif
>> +
>> +#ifndef STRIP
>> +STRIP = $(CROSS_COMPILE)strip
>> +#endif
>> +
>> +all: get_size
>> +
>> +get_size: get_size.c
>> +$(CC) --static -ffreestanding -nostartfiles \
>> +-Wl,--entry=main get_size.c -o get_size \
>> +`cc -print-libgcc-file-name`
>> +$(STRIP) -s get_size
>> +
>> +run_tests: all
>> +./get_size
>> +
>> +clean:
>> +$(RM) get_size
>> diff --git a/tools/testing/selftests/size/get_size.c
>> b/tools/testing/selftests/size/get_size.c
>> new file mode 100644
>> index 000..9c8d3cd
>> --- /dev/null
>> +++ b/tools/testing/selftests/size/get_size.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * Copyright 2014 Sony
>> + *
>> + * Licensed under the terms of the GNU GPL License version 2
>> + *
>> + * Selftest for runtime system size
>> + *
>> + * Prints the amount of RAM that the currently running system is using.
>> + *
>> + * This program tries to be as small as possible itself, to
>> + * avoid perturbing the system memory utilization with its
>> + * own execution. It also attempts to have as few dependencies
>> + * on kernel features as possible.
>> + *
>> + * It should be statically linked, with startup libs avoided.
>> + * It uses no library calls, and only the following 3 syscalls:
>> + * sysinfo(), write(), and _exit()
>> + *
>> + * For output, it avoids printf (which in some C libraries
>> + * has large external dependencies) by implementing its own
>> + * strlen(), number output and print() routines.
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#define STDOUT_FILENO 1
>> +
>> +int my_strlen(const char *s)
>> +{
>> +int len = 0;
>> +
>> +while (*s++)
>> +len++;
>> +return len;
>> +}
>> +
>> +/*
>> + * num_to_str - put digits from num into *s, left to right
>> + * do this by dividing the number by powers of 10
>> + * the tricky part is to omit leading zeros
>>
Re: [PATCH v3] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Changes from v2:
- add return values to print routines
- add .gitignore file
Changes from v1:
- use more correct Copyright string in get_size.c
Signed-off-by: Tim Bird
---
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/.gitignore | 1 +
tools/testing/selftests/size/Makefile | 21 +++
tools/testing/selftests/size/get_size.c | 105
4 files changed, 128 insertions(+)
create mode 100644 tools/testing/selftests/size/.gitignore
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/.gitignore
b/tools/testing/selftests/size/.gitignore
new file mode 100644
index 000..189b781
--- /dev/null
+++ b/tools/testing/selftests/size/.gitignore
@@ -0,0 +1 @@
+get_size
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..51e5fbd
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,21 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+#ifndef STRIP
+ STRIP = $(CROSS_COMPILE)strip
+#endif
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) --static -ffreestanding -nostartfiles \
+ -Wl,--entry=main get_size.c -o get_size \
+ `cc -print-libgcc-file-name`
+ $(STRIP) -s get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..9c8d3cd
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2014 Sony
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing its own
+ * strlen(), number output and print() routines.
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+int my_strlen(const char *s)
+{
+ int len = 0;
+
+ while (*s++)
+ len++;
+ return len;
+}
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+int print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ return write(STDOUT_FILENO, num_buf, my_strlen(num_buf));
+}
+
+int print(char *s)
+{
+ return write(STDOUT_FILENO, s, my_strlen(s));
+}
+
+void main(int argc, char **argv)
+{
+ int ccode;
+ unsigned long used;
+ struct sysinfo info;
+ unsigned long long temp;
+
+ print("Testing system size.\n");
+ print("1..1\n");
+
+ ccode = sysinfo(&info);
+ if (ccode < 0) {
+ print("not ok 1 get size runtime size\n");
+ print("# could not get sysinfo\n");
+ _exit(ccode);
+ }
+
+ /* ignore cache complexities for now */
+
Re: [PATCH v2] selftest: size: Add size test for Linux kernel
On 11/20/2014 01:58 PM, Shuah Khan wrote: > On 11/19/2014 05:13 PM, Tim Bird wrote: >> >> This test shows the amount of memory used by the system. >> Note that this is dependent on the user-space that is loaded >> when this program runs. Optimally, this program would be >> run as the init program itself. >> >> The program is optimized for size itself, to avoid conflating >> its own execution with that of the system software. >> The code is compiled statically, with no stdlibs. On my x86_64 system, >> this results in a statically linked binary of less than 5K. >> >> Changes from v1: >> - use more correct Copyright string in get_size.c >> >> Signed-off-by: Tim Bird >> --- >> tools/testing/selftests/Makefile| 1 + >> tools/testing/selftests/size/Makefile | 21 +++ >> tools/testing/selftests/size/get_size.c | 105 >> >> 3 files changed, 127 insertions(+) >> create mode 100644 tools/testing/selftests/size/Makefile >> create mode 100644 tools/testing/selftests/size/get_size.c > > Tim, > > The test looks good, but you are missing .gitignore file. > Please add a .gitignore for the binary that gets generated to > avoid git status including the binary it in its output. Will do. I'll send v3 today. Thanks, -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kselftest: Move the docs to the Documentation dir
Also, adjust the formatting a bit, and expand the section about using TARGETS= on the make command line. Signed-off-by: Tim Bird --- Documentation/kselftest.txt| 69 ++ tools/testing/selftests/README.txt | 61 - 2 files changed, 69 insertions(+), 61 deletions(-) create mode 100644 Documentation/kselftest.txt delete mode 100644 tools/testing/selftests/README.txt diff --git a/Documentation/kselftest.txt b/Documentation/kselftest.txt new file mode 100644 index 000..a87d840 --- /dev/null +++ b/Documentation/kselftest.txt @@ -0,0 +1,69 @@ +Linux Kernel Selftests + +The kernel contains a set of "self tests" under the tools/testing/selftests/ +directory. These are intended to be small unit tests to exercise individual +code paths in the kernel. + +On some systems, hot-plug tests could hang forever waiting for cpu and +memory to be ready to be offlined. A special hot-plug target is created +to run full range of hot-plug tests. In default mode, hot-plug tests run +in safe mode with a limited scope. In limited mode, cpu-hotplug test is +run on a single cpu as opposed to all hotplug capable cpus, and memory +hotplug test is run on 2% of hotplug capable memory instead of 10%. + +Running the selftests (hotplug tests are run in limited mode) += + +To build the tests: + $ make -C tools/testing/selftests + + +To run the tests: + $ make -C tools/testing/selftests run_tests + +To build and run the tests with a single command, use: + $ make kselftest + +- note that some tests will require root privileges. + + +Running a subset of selftests + +You can use the "TARGETS" variable on the make command line to specify +single test to run, or a list of tests to run. + +To run only tests targeted for a single subsystem: + $ make -C tools/testing/selftests TARGETS=ptrace run_tests + +You can specify multiple tests to build and run: + $ make TARGETS="size timers" kselftest + +See the top-level tools/testing/selftests/Makefile for the list of all +possible targets. + + +Running the full range hotplug selftests + + +To build the hotplug tests: + $ make -C tools/testing/selftests hotplug + +To run the hotplug tests: + $ make -C tools/testing/selftests run_hotplug + +- note that some tests will require root privileges. + + +Contributing new tests +== + +In general, the rules for for selftests are + + * Do as much as you can if you're not root; + + * Don't take too long; + + * Don't break the build on any architecture, and + + * Don't cause the top-level "make run_tests" to fail if your feature is + unconfigured. diff --git a/tools/testing/selftests/README.txt b/tools/testing/selftests/README.txt deleted file mode 100644 index 2660d5f..000 --- a/tools/testing/selftests/README.txt +++ /dev/null @@ -1,61 +0,0 @@ -Linux Kernel Selftests - -The kernel contains a set of "self tests" under the tools/testing/selftests/ -directory. These are intended to be small unit tests to exercise individual -code paths in the kernel. - -On some systems, hot-plug tests could hang forever waiting for cpu and -memory to be ready to be offlined. A special hot-plug target is created -to run full range of hot-plug tests. In default mode, hot-plug tests run -in safe mode with a limited scope. In limited mode, cpu-hotplug test is -run on a single cpu as opposed to all hotplug capable cpus, and memory -hotplug test is run on 2% of hotplug capable memory instead of 10%. - -Running the selftests (hotplug tests are run in limited mode) -= - -To build the tests: - - $ make -C tools/testing/selftests - - -To run the tests: - - $ make -C tools/testing/selftests run_tests - -- note that some tests will require root privileges. - -To run only tests targeted for a single subsystem: (including -hotplug targets in limited mode) - - $ make -C tools/testing/selftests TARGETS=cpu-hotplug run_tests - -See the top-level tools/testing/selftests/Makefile for the list of all possible -targets. - -Running the full range hotplug selftests - - -To build the tests: - - $ make -C tools/testing/selftests hotplug - -To run the tests: - - $ make -C tools/testing/selftests run_hotplug - -- note that some tests will require root privileges. - -Contributing new tests -== - -In general, the rules for for selftests are - - * Do as much as you can if you're not root; - - * Don't take too long; - - * Don't break the build on any architecture, and - - * Don't cause the top-level "make run_tests" to fail if your feature is - unconfigured. -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsub
[PATCH v2] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Changes from v1:
- use more correct Copyright string in get_size.c
Signed-off-by: Tim Bird
---
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/Makefile | 21 +++
tools/testing/selftests/size/get_size.c | 105
3 files changed, 127 insertions(+)
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..51e5fbd
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,21 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+#ifndef STRIP
+ STRIP = $(CROSS_COMPILE)strip
+#endif
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) --static -ffreestanding -nostartfiles \
+ -Wl,--entry=main get_size.c -o get_size \
+ `cc -print-libgcc-file-name`
+ $(STRIP) -s get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..f8ffc80
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2014 Sony Mobile Communications Inc.
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing its own
+ * strlen(), number output and print() routines.
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+my_strlen(const char *s)
+{
+ int len = 0;
+
+ while (*s++)
+ len++;
+ return len;
+}
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+static void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ write(STDOUT_FILENO, num_buf, my_strlen(num_buf));
+}
+
+print(char *s)
+{
+ write(STDOUT_FILENO, s, my_strlen(s));
+}
+
+void main(int argc, char **argv)
+{
+ int ccode;
+ unsigned long used;
+ struct sysinfo info;
+ unsigned long long temp;
+
+ print("Testing system size.\n");
+ print("1..1\n");
+
+ ccode = sysinfo(&info);
+ if (ccode < 0) {
+ print("not ok 1 get size runtime size\n");
+ print("# could not get sysinfo\n");
+ _exit(ccode);
+ }
+
+ /* ignore cache complexities for now */
+ temp = info.totalram - info.freeram - info.bufferram;
+ temp = temp * info.mem_unit;
+ temp = temp / 1024;
+
+ used = temp;
+
+ print("ok 1 get runtime size # size = ");
+ print_num(used);
+ print(" K\n");
+
+ _exit(0);
+}
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] selftest: size: Add size test for Linux kernel
This test shows the amount of memory used by the system.
Note that this is dependent on the user-space that is loaded
when this program runs. Optimally, this program would be
run as the init program itself.
The program is optimized for size itself, to avoid conflating
its own execution with that of the system software.
The code is compiled statically, with no stdlibs. On my x86_64 system,
this results in a statically linked binary of less than 5K.
Signed-off-by: Tim Bird
---
tools/testing/selftests/Makefile| 1 +
tools/testing/selftests/size/Makefile | 21 +++
tools/testing/selftests/size/get_size.c | 105
3 files changed, 127 insertions(+)
create mode 100644 tools/testing/selftests/size/Makefile
create mode 100644 tools/testing/selftests/size/get_size.c
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 45f145c..fa91aef 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += user
TARGETS += sysctl
TARGETS += firmware
TARGETS += ftrace
+TARGETS += size
TARGETS_HOTPLUG = cpu-hotplug
TARGETS_HOTPLUG += memory-hotplug
diff --git a/tools/testing/selftests/size/Makefile
b/tools/testing/selftests/size/Makefile
new file mode 100644
index 000..51e5fbd
--- /dev/null
+++ b/tools/testing/selftests/size/Makefile
@@ -0,0 +1,21 @@
+#ifndef CC
+ CC = $(CROSS_COMPILE)gcc
+#endif
+
+#ifndef STRIP
+ STRIP = $(CROSS_COMPILE)strip
+#endif
+
+all: get_size
+
+get_size: get_size.c
+ $(CC) --static -ffreestanding -nostartfiles \
+ -Wl,--entry=main get_size.c -o get_size \
+ `cc -print-libgcc-file-name`
+ $(STRIP) -s get_size
+
+run_tests: all
+ ./get_size
+
+clean:
+ $(RM) get_size
diff --git a/tools/testing/selftests/size/get_size.c
b/tools/testing/selftests/size/get_size.c
new file mode 100644
index 000..f8ffc80
--- /dev/null
+++ b/tools/testing/selftests/size/get_size.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2014 Sony
+ *
+ * Licensed under the terms of the GNU GPL License version 2
+ *
+ * Selftest for runtime system size
+ *
+ * Prints the amount of RAM that the currently running system is using.
+ *
+ * This program tries to be as small as possible itself, to
+ * avoid perturbing the system memory utilization with its
+ * own execution. It also attempts to have as few dependencies
+ * on kernel features as possible.
+ *
+ * It should be statically linked, with startup libs avoided.
+ * It uses no library calls, and only the following 3 syscalls:
+ * sysinfo(), write(), and _exit()
+ *
+ * For output, it avoids printf (which in some C libraries
+ * has large external dependencies) by implementing its own
+ * strlen(), number output and print() routines.
+ */
+
+#include
+#include
+
+#define STDOUT_FILENO 1
+
+my_strlen(const char *s)
+{
+ int len = 0;
+
+ while (*s++)
+ len++;
+ return len;
+}
+
+/*
+ * num_to_str - put digits from num into *s, left to right
+ * do this by dividing the number by powers of 10
+ * the tricky part is to omit leading zeros
+ * don't print zeros until we've started printing any numbers at all
+ */
+static void num_to_str(unsigned long num, char *s)
+{
+ unsigned long long temp, div;
+ int started;
+
+ temp = num;
+ div = 100LL;
+ started = 0;
+ while (div) {
+ if (temp/div || started) {
+ *s++ = (unsigned char)(temp/div + '0');
+ started = 1;
+ }
+ temp -= (temp/div)*div;
+ div /= 10;
+ }
+ *s = 0;
+}
+
+print_num(unsigned long num)
+{
+ char num_buf[30];
+
+ num_to_str(num, num_buf);
+ write(STDOUT_FILENO, num_buf, my_strlen(num_buf));
+}
+
+print(char *s)
+{
+ write(STDOUT_FILENO, s, my_strlen(s));
+}
+
+void main(int argc, char **argv)
+{
+ int ccode;
+ unsigned long used;
+ struct sysinfo info;
+ unsigned long long temp;
+
+ print("Testing system size.\n");
+ print("1..1\n");
+
+ ccode = sysinfo(&info);
+ if (ccode < 0) {
+ print("not ok 1 get size runtime size\n");
+ print("# could not get sysinfo\n");
+ _exit(ccode);
+ }
+
+ /* ignore cache complexities for now */
+ temp = info.totalram - info.freeram - info.bufferram;
+ temp = temp * info.mem_unit;
+ temp = temp / 1024;
+
+ used = temp;
+
+ print("ok 1 get runtime size # size = ");
+ print_num(used);
+ print(" K\n");
+
+ _exit(0);
+}
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why is the deferred initcall patch not mainline?
On 10/27/2014 01:29 PM, Nicolas Pitre wrote: > On Fri, 24 Oct 2014, Geert Uytterhoeven wrote: > >> Several patches are linked from >> http://elinux.org/Deferred_Initcalls >> >> Latest version is >> http://elinux.org/images/5/51/0001-Port-deferred-initcalls-to-3.10.patch > > In the hope of providing some constructive and concrete feedback to this > thread, here's what I have to say about the patch linked above ( I > looked only at the latest version): > > - Commented out code is not acceptable for mainline. But everyone knows > that already. > > - Returning a null byte through the /proc file is dubious. > > - The /proc interface is probably not the best. I'd go with an entry in > /sys/kernel instead. > > - If the deferred_initcall section is empty, this could return 1 upfront > and do the free_initmem() earlier as it used to. > > - It was mentioned somewhere that the config system could use a 4th > state in addition to n, m and y. That would be required before this > goes upstream simply to express all the dependencies between modules. > Right now if a core module is configured with m, then all the > submodules that depend on it inherit the modular-only restriction. > The same would need to be enforced for deferred initcalls. > > - Currently all deferred initcalls are lumped together in a single > section with no regards to the original initcall level. This is likely > to cause trouble if two initcalls are called in a different order than > intended. Nothing prevents that from happening right now. > > This patch is still not generic enough for mainline inclusion IMHO. It > currently falls in the "you better know what you're doing" category and > that is possibly good enough for its actual users. Trying to make this > more generic is going to require some more work. And this would have to > come with serious arguments explaining why simply using modules in the > first place is not acceptable. Sorry to take so long to reply. This feedback is very welcome, and I appreciate the time taken to review the patch. I apologize in advance for the rather long response... I have been thinking about the points you made previously, and have given the problem space some more thought. I agree that as it stands this is a very niche solution, and it would be good to think about the broader picture and how things might be designed differently to make the "feature" usable more easily and to a broader group. Taking a step back, the overall goal is to allow user space to do stuff while the kernel is still initializing statically linked drivers, so the device's primary function can be ready as soon as possible (and not wait for secondarily-needed functionality to initialize). For things that are able to be made into a module (and for situations where the kernel module loading is turned on), this feature should not be needed in its current form. In that case, user space already has control over module load ordering and timing. The way the feature is expressed in the current code is that a set of drivers are marked for deferred initialization (I'll refer to this as issue 0). Then, at boot: 1) most drivers are initialized normally, 2) user space is started, and then 3) user space indicates to the kernel that the deferred drivers should be initialized. This is very coarse, allowing only two categories of drivers: (ignoring other boot phases for the moment) - regular drivers and deferred drivers. It also requires source code changes to mark the drivers to be deferred. Finally, it requires an explicit notification from user-space to complete the process. All of these attributes are undesirable. There may also be an opportunity here to work out more granular driver load ordering, which would benefit other systems (especially those that are hitting the EPROBE_DEFER issue). As it stands now, the ordering of the initcalls within a particular level is pretty much arbitrary (determined by link order, usually without oversight by the developer). Just FYI, here are some numbers culled from a recent kernel: initcall macro number of instances in kernel source -- early_init 446 core_init 614 postcore_init 150 arch_init 751 subsys_init 573 fs_init 1372 device_init 1211 late_init 440 I'm going to rattle off a few ideas - I'm not sure which ones might stick, I just want to bounce these around and see what people think. Note that I didn't think of most of these, but I'm just repeating ones that have been stated, and adding a few thoughts of my own. First, if the ordering of initialization is not the default provided by the kernel, it needs to be recorded somewhere. A developer needs to express it (or a tool needs to figure it out), but if it is going to be reflected in the final kernel behaviour (or image),
[announce] Embedded Linux Conference Call for Presentations
Hello everyone, I'm writing to remind you all that the ELC Europe 2012 Call for Presentations is currently open. The conference is in November (5-7) this year, in Barcelona Spain. We are again co-located with LinuxCon Europe. We're very excited for this opportunity once again to get together as an industry and community, to talk about embedded Linux. If you have been working on some aspect of embedded Linux, such as security, audio, video, graphics, system size, bootup time, power management, distribution, build systems or tools, please consider submitting a proposal for the event. The deadline for proposal submissions is August 1, which is coming up in just a few weeks. It's right during vacation season in Europe, so please don't forget! For details on submitting a presentation proposal, please see: http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp We had a great time last year. For examples of previous presentations, see: http://elinux.org/ELCE_2011_Presentations or look at last year's schedule: http://events.linuxfoundation.org/archive/2011/embedded-linux-conference-europe/schedule I look forward to hearing about the interesting things you're working on, and to seeing you at the event. Thanks and regards, -- Tim Bird ===== 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bids for open project proposals
Everyone, The CE Working Group has been collecting project proposals for 2012 contract work at: http://elinux.org/Project_Proposals_for_2012 Most of this work is related to enhancing aspects of the Linux kernel for use in embedded products. The Architecture Group of the CEWG will be considering these proposals at a meeting in Japan on June 5. I realize that time is very short, and I apologize for the late notice. However, if you are interested in bidding on any of these projects, please send me an email with either a formal bid, or at a minimum, some information about yourself. This should include your hourly rate, amount of available time, and experience with embedded Linux development. If you have any special qualifications - like having worked on the particular subsystem in question - then please list that as well. Thanks and regards, -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 v2] logger: simplify and optimize get_entry_len
On 2/8/2012 9:15 PM, Dima Zavin wrote:
On Wed, Feb 8, 2012 at 10:37 AM, Tim Bird wrote:
Make this code slightly easier to read, and eliminate calls
to sub-routines. Some of these were previously optimized away
by the compiler, but one memcpy was not.
In my testing, this makes the code about 20% smaller, and
has no sub-routine calls and no branches (on ARM).
v2 of this patch is, IMHO, easier to read than v1. Compared to
that patch it uses __u8 instead of unsigned char, for
consistency with the __u16 val data type, simplifies the
conditional expression, adds a another comment, and
moves a common statement out of the if.
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 92456d7..3475cb7 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -93,20 +93,24 @@ static inline struct logger_log *file_get_log(struct file
*file)
* get_entry_len - Grabs the length of the payload of the next entry starting
* from 'off'.
*
+ * An entry length is 2 bytes (16 bits) in host endian order.
+ * In the log, the length does not include the size of the log entry structure.
+ * This function returns the size including the log entry structure.
+ *
* Caller needs to hold log->mutex.
*/
static __u32 get_entry_len(struct logger_log *log, size_t off)
{
__u16 val;
Could using a union here make things look a little cleaner in the meat
of the function? Something like
union {
__u16 s;
__u8 b[2];
} val;
That's a good idea. I was looking for a way to use a byte array that
wouldn't get misaligned if the function declaration changed. I'll
test this out and see what it looks like.
- switch (log->size - off) {
- case 1:
- memcpy(&val, log->buffer + off, 1);
- memcpy(((char *)&val) + 1, log->buffer, 1);
- break;
- default:
- memcpy(&val, log->buffer + off, 2);
- }
+ /* copy 2 bytes from buffer, in memcpy order, */
+ /* handling possible wrap at end of buffer */
+
+ ((__u8 *)&val)[0] = log->buffer[off];
+ if (likely(off+1< log->size))
+ ((__u8 *)&val)[1] = log->buffer[off+1];
spaces around the + in 'off+1' in the above two lines.
Yeah. I keep omitting spaces. I'll fix this, and the ones
mentioned on patch 1/5.
-- Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5 v2] logger: simplify and optimize get_entry_len
Make this code slightly easier to read, and eliminate calls
to sub-routines. Some of these were previously optimized away
by the compiler, but one memcpy was not.
In my testing, this makes the code about 20% smaller, and
has no sub-routine calls and no branches (on ARM).
v2 of this patch is, IMHO, easier to read than v1. Compared to
that patch it uses __u8 instead of unsigned char, for
consistency with the __u16 val data type, simplifies the
conditional expression, adds a another comment, and
moves a common statement out of the if.
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 92456d7..3475cb7 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -93,20 +93,24 @@ static inline struct logger_log *file_get_log(struct file
*file)
* get_entry_len - Grabs the length of the payload of the next entry starting
* from 'off'.
*
+ * An entry length is 2 bytes (16 bits) in host endian order.
+ * In the log, the length does not include the size of the log entry structure.
+ * This function returns the size including the log entry structure.
+ *
* Caller needs to hold log->mutex.
*/
static __u32 get_entry_len(struct logger_log *log, size_t off)
{
__u16 val;
- switch (log->size - off) {
- case 1:
- memcpy(&val, log->buffer + off, 1);
- memcpy(((char *) &val) + 1, log->buffer, 1);
- break;
- default:
- memcpy(&val, log->buffer + off, 2);
- }
+ /* copy 2 bytes from buffer, in memcpy order, */
+ /* handling possible wrap at end of buffer */
+
+ ((__u8 *)&val)[0] = log->buffer[off];
+ if (likely(off+1 < log->size))
+ ((__u8 *)&val)[1] = log->buffer[off+1];
+ else
+ ((__u8 *)&val)[1] = log->buffer[0];
return sizeof(struct logger_entry) + val;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] logger: clarify non-update of w_off in do_write_log_from_user
Add comment to explain when w_off is not updated in case of failed second fragment copy to buffer. Signed-off-by: Tim Bird --- drivers/staging/android/logger.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c index 8d9d4f1..115d8ed 100644 --- a/drivers/staging/android/logger.c +++ b/drivers/staging/android/logger.c @@ -330,6 +330,12 @@ static ssize_t do_write_log_from_user(struct logger_log *log, if (count != len) if (copy_from_user(log->buffer, buf + len, count - len)) + /* +* Note that by not updating w_off, this abandons the +* portion of the new entry that *was* successfully +* copied, just above. This is intentional to avoid +* message corruption from missing fragments. +*/ return -EFAULT; log->w_off = logger_offset(log, log->w_off + count); -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] logger: clarify code in clock_interval
Add commentary, rename the function and make the code easier to read.
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 54b7cdf..8d9d4f1 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -242,16 +242,28 @@ static size_t get_next_entry(struct logger_log *log,
size_t off, size_t len)
}
/*
- * clock_interval - is a < c < b in mod-space? Put another way, does the line
- * from a to b cross c?
+ * is_between - is a < c < b, accounting for wrapping of a, b, and c
+ *positions in the buffer
+ *
+ * That is, if ab, check for c outside (not between) a and b
+ *
+ * |--- a b |
+ * c^
+ *
+ * |x b - a x|
+ *c^
+ * orc^
*/
-static inline int clock_interval(size_t a, size_t b, size_t c)
+static inline int is_between(size_t a, size_t b, size_t c)
{
- if (b < a) {
- if (a < c || b >= c)
+ if (a < b) {
+ /* is c between a and b? */
+ if (a < c && c <= b)
return 1;
} else {
- if (a < c && b >= c)
+ /* is c outside of b through a? */
+ if (c <= b || a < c)
return 1;
}
@@ -272,11 +284,11 @@ static void fix_up_readers(struct logger_log *log, size_t
len)
size_t new = logger_offset(log, old + len);
struct logger_reader *reader;
- if (clock_interval(old, new, log->head))
+ if (is_between(old, new, log->head))
log->head = get_next_entry(log, log->head, len);
list_for_each_entry(reader, &log->readers, list)
- if (clock_interval(old, new, reader->r_off))
+ if (is_between(old, new, reader->r_off))
reader->r_off = get_next_entry(log, reader->r_off, len);
}
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] logger: reorder prepare_to_wait and mutex_lock
If mutex_lock waits, it will return in state TASK_RUNNING,
rubbing out the effect of prepare_to_wait().
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 92cfd94..54b7cdf 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -172,9 +172,10 @@ static ssize_t logger_read(struct file *file, char __user
*buf,
start:
while (1) {
+ mutex_lock(&log->mutex);
+
prepare_to_wait(&log->wq, &wait, TASK_INTERRUPTIBLE);
- mutex_lock(&log->mutex);
ret = (log->w_off == reader->r_off);
mutex_unlock(&log->mutex);
if (!ret)
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] logger: simplify and optimize get_entry_len
Make this code slightly easier to read, and eliminate calls
to sub-routines. Some of these were previously optimized away
by the compiler, but one memcpy was not.
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index 92456d7..92cfd94 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -93,19 +93,23 @@ static inline struct logger_log *file_get_log(struct file
*file)
* get_entry_len - Grabs the length of the payload of the next entry starting
* from 'off'.
*
+ * An entry length is 2 bytes (16 bits) in host endian order.
+ * In the log, the length does not include the size of the log entry structure.
+ * This function returns the size including the log entry structure.
+ *
* Caller needs to hold log->mutex.
*/
static __u32 get_entry_len(struct logger_log *log, size_t off)
{
__u16 val;
- switch (log->size - off) {
- case 1:
- memcpy(&val, log->buffer + off, 1);
- memcpy(((char *) &val) + 1, log->buffer, 1);
- break;
- default:
- memcpy(&val, log->buffer + off, 2);
+ if (unlikely(log->size - off == 1)) {
+ /* at end of buffer, handle wrap */
+ ((unsigned char *)&val)[0] = log->buffer[off];
+ ((unsigned char *)&val)[1] = log->buffer[0];
+ } else {
+ ((unsigned char *)&val)[0] = log->buffer[off];
+ ((unsigned char *)&val)[1] = log->buffer[off+1];
}
return sizeof(struct logger_entry) + val;
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] logger: Change logger_offset() from macro to function
Convert to function and add log as a parameter, rather than relying
on log in the context of the macro.
Signed-off-by: Tim Bird
---
drivers/staging/android/logger.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/android/logger.c b/drivers/staging/android/logger.c
index ffc2d04..92456d7 100644
--- a/drivers/staging/android/logger.c
+++ b/drivers/staging/android/logger.c
@@ -60,7 +60,11 @@ struct logger_reader {
};
/* logger_offset - returns index 'n' into the log via (optimized) modulus */
-#define logger_offset(n) ((n) & (log->size - 1))
+size_t logger_offset(struct logger_log *log, size_t n)
+{
+ return n & (log->size-1);
+}
+
/*
* file_get_log - Given a file structure, return the associated log
@@ -137,7 +141,7 @@ static ssize_t do_read_log_to_user(struct logger_log *log,
if (copy_to_user(buf + len, log->buffer, count - len))
return -EFAULT;
- reader->r_off = logger_offset(reader->r_off + count);
+ reader->r_off = logger_offset(log, reader->r_off + count);
return count;
}
@@ -225,7 +229,7 @@ static size_t get_next_entry(struct logger_log *log, size_t
off, size_t len)
do {
size_t nr = get_entry_len(log, off);
- off = logger_offset(off + nr);
+ off = logger_offset(log, off + nr);
count += nr;
} while (count < len);
@@ -260,7 +264,7 @@ static inline int clock_interval(size_t a, size_t b, size_t
c)
static void fix_up_readers(struct logger_log *log, size_t len)
{
size_t old = log->w_off;
- size_t new = logger_offset(old + len);
+ size_t new = logger_offset(log, old + len);
struct logger_reader *reader;
if (clock_interval(old, new, log->head))
@@ -286,7 +290,7 @@ static void do_write_log(struct logger_log *log, const void
*buf, size_t count)
if (count != len)
memcpy(log->buffer, buf + len, count - len);
- log->w_off = logger_offset(log->w_off + count);
+ log->w_off = logger_offset(log, log->w_off + count);
}
@@ -311,7 +315,7 @@ static ssize_t do_write_log_from_user(struct logger_log
*log,
if (copy_from_user(log->buffer, buf + len, count - len))
return -EFAULT;
- log->w_off = logger_offset(log->w_off + count);
+ log->w_off = logger_offset(log, log->w_off + count);
return count;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 01/06/2012 01:20 PM, Greg KH wrote: > On Fri, Jan 06, 2012 at 12:56:27PM -0800, Tim Bird wrote: >> 4) this is for a popular use case, as opposed to some minor >> outlying thing, and so people perceive the need to get it >> exactly right. In this sense, the code would be a victim of >> it's own success. > > It's not the code's "success" here, it's the "this solves a general > problem in a very specific way" issue, that just happens to be a use > case a lot of different people want to see addressed. And since it is > only solving it in a narrow way, that's a problem for all of those other > people. It's only a problem in the sense that those different people don't get something for free. The presence of an isolated, configurable driver somewhere in the kernel source, that addresses one group's issues and not another's doesn't impose any measurable burden on that other group. It's more of an opportunity cost thing. The opportunity to develop something more general can be reduced when a narrow solution is accepted. But this is exactly related to encouraging people to develop more general solutions, when narrow ones accomplish what they need (see point 5). I understand that the whole model is built on people contributing code that not only addresses their own needs, but the needs of others. But of course there should be balance. For example I have concerns about integrating this into the printk code path, because I think that code path is complex enough as it is, and that combining this functionality with that is likely to create more maintenance problems rather than less in the long run. (But I'll still plan to look at this option ...) Sometimes, features should just remain separate. > >> 5) blocking this is perceived to be a way to accomplish a >> larger, related goal (if this is true then it has lots of >> interesting implications for the economics of open source >> work) > > No, I don't think that's the issue here. I don't think anyone is thinking: "If I block this I can get Tim to do x". But there *is* a desire to create a more general logging solution. And not accepting this as is, is a way to encourage people to work on that. For some situations, I would object to that. But in this case I actually agree that there are more potential users of this, and it would be nice to solve more problems than just the Android case, with a consolidated code base. That's why I'm willing to invest in researching other loggers and doing some experimental development. > >> In general, there is a tension between the normal nature of adapting >> the kernel to the most general use cases, and the specialization >> that is performed in developing an embedded product. Often >> times, solutions to embedded requirements are very finely tuned >> to a particular field of use or situation, and don't lend themselves >> easily to the type of generalization that mainlining usually requires. I should have left off "embedded product" for this thread. There is a tension in general between generalization and specialization. And that tension shows up in a lot of discussions about mainlining code. My goal here is to determine where people think the balance lies for this particular code. > Why do people get hung up on the "embedded is special" case here. Fact, > it's not. Do you somehow think that the work done for the HUGE > multiprocessor machines 10 years ago would have gotten away with hacks > saying, "this is a special case, only we care about this", when they > were dealing with 4 and 8 way machines? No, they didn't, and as such, > there's nothing special with embedded here either. Matter of fact, your > machines are now more powerful than those old 10 year old machines, and > are really general purpose computers, just used in a single/limited > manner, again, just like those original big SMP machines were. > > So, I've said it many times before, and I'll say it again: > > Yes, you are special and unique, just like everyone else. > > The next person who says the "embedded is different" phrase again, owes > me a beer of my choice. Consider this your free beer token... :-) I believe "embedded is different" because we throw away so much code, that I just don't think desktop and enterprise do. The number of non-mainlined BSPs that have gone straight from product release to bit bucket is truly staggering. You're only looking at the Android case, where the machines are as powerful as they were 10 years ago. Broad swaths of embedded are not on that kind of hardware. It's different (there it is again, is that two beers?) being a
Re: RFC: android logger feedback request
then it has lots of interesting implications for the economics of open source work) In general, there is a tension between the normal nature of adapting the kernel to the most general use cases, and the specialization that is performed in developing an embedded product. Often times, solutions to embedded requirements are very finely tuned to a particular field of use or situation, and don't lend themselves easily to the type of generalization that mainlining usually requires. Which brings me to my last point and a question. Is it inconceivable for there to be a category of code in the Linux kernel which supports ONLY Android user space, and no other? That is, must every Android patch be generalized in some manner to a broader use case? I suspect some of them (particularly binder) will not lend themselves easily to this type of generalization. Knowing the answer to this question would help me gauge the amount of effort required for this project, and the net value of continuing it. Thanks and regards, -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 12/21/2011 05:47 PM, Greg KH wrote: > On Wed, Dec 21, 2011 at 05:32:36PM -0800, Tim Bird wrote: >> On 12/21/2011 04:51 PM, Greg KH wrote: >>> On Wed, Dec 21, 2011 at 04:36:21PM -0800, Tim Bird wrote: >>>> On 12/21/2011 03:19 PM, Greg KH wrote: >> >>> Huh, I'm not talking about syslogd, I'm talking about the syslog(2) >>> syscall we have. >> >> OK - switching gears. Since the kernel log buffer isn't normally >> used to store use-space messages, I thought you were referring >> to syslog(3) and the associated (logger(1) and syslogd(8)). > > The kernel log buffer has been storing userspace messages for a while > now, look at your boot log on the latest Fedora and openSUSE releases > (or any other distro using systemd for booting). Sorry - I don't have a distro that uses systemd. I'm completely unaware of this use of the kernel log for user-space message logging. No wonder Lennart and Kay are so hot on making a new logging system. It seems sub-optimal to me, to intermingle a structured log with a pure-ASCII log. > Again, please see what we are already doing in the kernel and userspace, > I think a lot of the above is already implemented. I don't know what systemd has got going on in user-space. I'm looking at a very recent kernel, and I see no support for multiple log channels, or an optimized open/write path. Maybe Lennart could save me some time doing this research. Lennart, How does current systemd prevent user-space messages from crowding out kernel messages? (or vice-versa). Since you've been doing a lot of work on logging, do you have any existing metrics for logging overhead via the kernel log buffer? > Which brings me back to my original question, what does this code do, > that is not already present in the kernel, and why is a totally new > interface being proposed for it? At the least, it supports multiple log channels. Quite frankly my mind has been blown a bit by the suggestion to overload the kernel log buffer with user-space messages. I would never have gone that route. But I'll have to find out more about this systemd thing to answer your question. Secondly, this is not a particularly new or radical interface. It is new to legacy Linux, but it's been in the Android Linux kernel for some years now, and it has worked well. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 12/21/2011 05:20 PM, NeilBrown wrote: > It is certainly nice and simple. It really looks more like a filesystem than > a char device though... though they aren't really files so much as lossy > pipes. I don't think that's a problem though, lots of things in filesystems > don't behave exactly like files. > > If you created a 'logbuf' filesystem that used libfs to provide a single > directory in which privileged processes could create files then you wouldn't > need the kernel to "know" the allowed logs: radio, events, main, system. > The size could be set by ftruncate() (by privileged used again) rather than > being hardcoded. > > You would defined 'read' and 'write' much like you currently do to create a > list of > datagrams in a circular buffer and replace the ioctls by more standard > interfaces: > > LOGGER_GET_LOG_BUG_SIZE would use 'stat' and the st_blocks field > LOGGER_GET_LOG_LEN would use 'stat' and the st_size field > LOGGER_GET_NEXT_ENTRY_LEN could use the FIONREAD ioctl > LOGGER_FLUSH_LOG could use ftruncate > > The result would be much the same amount of code, but an interface which has > fewer details hard-coded and is generally more versatile and accessible. This is a very interesting suggestion. I think it would be good to create a prototype of this and see how it affects the user-space code as well as what the kernel-side issues would be (and to check whether this would change any of the current logger semantics). It would also have the side effect of allowing runtime modification of the buffer size, though I'm not sure whether that's useful or not. Thanks! -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 12/21/2011 04:51 PM, Greg KH wrote: > On Wed, Dec 21, 2011 at 04:36:21PM -0800, Tim Bird wrote: >> On 12/21/2011 03:19 PM, Greg KH wrote: > Huh, I'm not talking about syslogd, I'm talking about the syslog(2) > syscall we have. OK - switching gears. Since the kernel log buffer isn't normally used to store use-space messages, I thought you were referring to syslog(3) and the associated (logger(1) and syslogd(8)). > This character interface seems very close to the syslog(2) api, but just > done in a character interface, with ioctls, which also require userspace > tools to manage properly, so I fail to see the big "gain" here. > > What am I missing? syslog(2) would more aptly be named klogctrl() (and it is in glibc) There's currently no operation in sys_sylog (the kernel function implementing syslog(2)) for writing to the log. The write operation to the kernel log buffer is also done via a character interface /dev/kmsg (via code in drivers/char/mem.c) This is actually very similar to what the Android logger code does. But while the kernel log buffer has lots of similarities to the Android logger there are some key differences which I think are important to isolate from a user-space logging system. Here's a stream-of-consciousness dump of the differences: The printk interface in the kernel is almost always automatically drained to the device console, at the time of the printk (after the message is dropped into the log buffer itself). This extra operation is not needed for most application-level messages that go into the log, and incurs extra overhead in the log buffer code. The printk code is especially designed to be called from within any kernel context (including interrupt code), and so has some locking avoidance code paths and complexity that are not needed for code which handles strictly user-space messages. Oddly enough, the printk code paths in the kernel can end up doing a fair amount of print formatting, which can be time-consuming. The code path in kmsg_writev() contains at least one kmalloc, which could fail when running out of memory. The code path in the logger is much simpler, consisting really of only a data copy. Timestamping is not automatically appended to messages going into the kernel log buffer (but they can be optionally pre-pended, with control configurable at runtime). They are represented as ASCII text, which consumes a little more than twice the overhead of a 32-bit binary field. PID and TID are not automatically preserved in the log. The kernel keeps it's priority in text also, and has no convention for contextual tagging. I'm not sure that we should change the kernel log buffer to support structured binary data, in addition to the free-form ASCII data that the kernel uses now. The kernel log buffer does not support separate channels for different classes of log messages (indeed, there is only one channel, and it has kernel messages). A new system call (or some backwards-compatible tweak to the existing syslog(2) call would have to be added to support a channel ID in order to support this. There *are* some benefits to intermingling the kernel log messages and the user-space log messages, but I think they are outweighed by the value in keeping these systems separate. There might be the opportunity for code reuse, but I suspect we'd end up with about the same amount of code increase overall (and possibly an additional syscall), and add some unneeded complexity to the prink code path to accomplish it. I just read Neil Brown's suggestion for doing this via a filesystem rather than a char device, and it's interesting. I'll respond to that separately. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 12/21/2011 04:18 PM, john stultz wrote: > On Wed, 2011-12-21 at 15:19 -0800, Greg KH wrote: >> On Wed, Dec 21, 2011 at 02:59:15PM -0800, Tim Bird wrote: >>> Hi all, >>> >>> I'm looking for feedback on the Android logger code, to see what >>> it would take to make this code acceptable for inclusion in >>> the mainline kernel. >>> >>> Information about the features of Android logging system >>> can be found at: http://elinux.org/Android_Logging_System >>> >>> This system creates a new system-wide logging service, in >>> the kernel, for user-space message. It is more comparable >>> to syslog than to the kernel log buffer, as it holds only >>> user-space messages. It is optimized for write >>> performance, since most of the time the log is written to >>> and never read. It creates multiple log channels, to prevent >>> an abundance of log messages in one channel from overwriting >>> messages in another channel. The log channels have sizes >>> fixed at kernel compile-time. >>> >>> Log messages are stored in very simple in-kernel buffers, that >>> overflow old messages upon wrapping. A fixed set of attributes >>> (pid, tid, timestamp and message), is kept for each message. >>> By convention, Android puts a message priority and context tag >>> into each message. >>> >>> In Android, this system uses a fixed set of device nodes with >>> well-known names: /dev/log/main, /dev/log/events, /dev/log/radio >>> and /dev/log/system. >>> >>> Operations on the log are done via a character device, using >>> standard file operations and some ioctls. >>> >>> The code for this is below (I've moved it from linux-next >>> drivers/staging/android for my own testing). >>> >>> Please let me know what issues you see with this code. >> >> That all describes the current code, but you haven't described what's >> wrong with the existing syslog interface that requires this new driver >> to be written. And why can't the existing interface be fixed to address >> these (potential) shortcomings? >> >>> One specific question I have is where is the most appropriate >>> place for this code to live, in the kernel source tree? >>> Other embedded systems might want to use this system (it >>> is simpler than syslog, and superior in some ways), so I don't >>> think it should remain in an android-specific directory. >> >> What way is it superior? Again, why not extend syslog? Why not "fix" >> syslog if this really is a superior thing? How does this tie into Kay >> and Lennard's proposal for work in this area? > > There is also some overlap functionality wise with pstore as well, as I > believe the logger is used as a known location in memory where messages > can be fetched from after a kernel panic or crash. I don't know if that's true or not. I think you may be thinking of Android's RAM console feature. If there's a way to save application messages over a reboot using the logger buffers, I'm unfamiliar with it. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: android logger feedback request
On 12/21/2011 03:19 PM, Greg KH wrote: > That all describes the current code, but you haven't described what's > wrong with the existing syslog interface that requires this new driver > to be written. And why can't the existing interface be fixed to address > these (potential) shortcomings? >> One specific question I have is where is the most appropriate >> place for this code to live, in the kernel source tree? >> Other embedded systems might want to use this system (it >> is simpler than syslog, and superior in some ways), so I don't >> think it should remain in an android-specific directory. > > What way is it superior? Here are some ways that this code is superior to syslog: Speed and overhead -- syslogd requires a separate user-space process to manage the log area, where this code does not. The overhead for any user-space process is at least 16K, and usually much more than this (not including the size of the log storage area). On one of my embedded systems, where syslogd is provided by busybox, the unique set size for syslogd is 96K. This code, built in to the Linux kernel is less than 4K code and data (again, not including the size of the log storage area). To deliver a message to syslog requires a socket operation and a few context switches. With the logger code, the operation is a file operation (writev) to kernel memory, with only one context switch into and out of the kernel. The open and write paths through the Linux kernel are arguably more optimized than the networking paths. This is a consideration since the log operations should optimized for the "create-a-log-entry" case (the open/write path), since logs are mostly written and almost never read on production devices. No dependence on persistent storage --- syslogd requires either persistent storage to store the log, or a network connection to an outside device. Being purely memory-based, the logger requires neither of these. With logger, persistence of the log data is left to the implementor. In Android, the data is delivered over a USB connection via adb or to the console as ascii text, using logcat. In other embedded systems, other mechanisms might be used if long-term storage of the messages is desired. With logger, there is no automatic notion of on-device persistent storage for the log data. No dependence on networking kernel code --- The syslog communication mechanism requires sockets. This prevents one from configuring the kernel with no networking support, which is sometimes done in embedded systems to save size. Simpler constraint on log size -- The busybox syslog daemon uses a log rotation feature to constrain the size of the log in persistent storage. This is overly cumbersome in both speed and complexity compared to the logger's simple ring buffer. Licensing - The code implementing library and command line tool support for this logger (in user space) is available under an Apache license, rather than a GPL license, which is desirable for some vendors. > Again, why not extend syslog? Why not "fix" > syslog if this really is a superior thing? "extend" syslog would not really the the right direction. This system is simpler than syslog, while simultaneously having at least one valuable extra feature (separate log channels). syslog has a standard set of interfaces in libc and various syslogd implementations, which are heavier weight in nature than what is provided here. It is unclear that an attempt at reducing these attributes (such as memory overhead, number of context switches, dependence on persistent storage, and socket utilization) would yield a system substantially different from the logger. > How does this tie into Kay > and Lennard's proposal for work in this area? It does not tie in at all. Kay and Lennart's proposal for "the Journal" creates a more complex system than syslog, and handles a number of new interesting use cases. This system is on the opposite side of the spectrum from the journal, towards simplicity and reduced footprint and overhead. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: android logger feedback request
Hi all,
I'm looking for feedback on the Android logger code, to see what
it would take to make this code acceptable for inclusion in
the mainline kernel.
Information about the features of Android logging system
can be found at: http://elinux.org/Android_Logging_System
This system creates a new system-wide logging service, in
the kernel, for user-space message. It is more comparable
to syslog than to the kernel log buffer, as it holds only
user-space messages. It is optimized for write
performance, since most of the time the log is written to
and never read. It creates multiple log channels, to prevent
an abundance of log messages in one channel from overwriting
messages in another channel. The log channels have sizes
fixed at kernel compile-time.
Log messages are stored in very simple in-kernel buffers, that
overflow old messages upon wrapping. A fixed set of attributes
(pid, tid, timestamp and message), is kept for each message.
By convention, Android puts a message priority and context tag
into each message.
In Android, this system uses a fixed set of device nodes with
well-known names: /dev/log/main, /dev/log/events, /dev/log/radio
and /dev/log/system.
Operations on the log are done via a character device, using
standard file operations and some ioctls.
The code for this is below (I've moved it from linux-next
drivers/staging/android for my own testing).
Please let me know what issues you see with this code.
One specific question I have is where is the most appropriate
place for this code to live, in the kernel source tree?
Other embedded systems might want to use this system (it
is simpler than syslog, and superior in some ways), so I don't
think it should remain in an android-specific directory.
Thanks,
-- Tim
P.S. Sorry to do this right before the holidays. I'll be
away from my work machine for most of the next few weeks. I
can answer informational questions, and gather feedback,
but I won't have a lot of time for testing new code until
after the New Year.
Here's the code:
diff --git a/drivers/misc/logger.c b/drivers/misc/logger.c
new file mode 100644
index 000..fa76ce7
--- /dev/null
+++ b/drivers/misc/logger.c
@@ -0,0 +1,616 @@
+/*
+ * drivers/misc/logger.c
+ *
+ * A Logging Subsystem
+ *
+ * Copyright (C) 2007-2008 Google, Inc.
+ *
+ * Robert Love
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "logger.h"
+
+#include
+
+/*
+ * struct logger_log - represents a specific log, such as 'main' or 'radio'
+ *
+ * This structure lives from module insertion until module removal, so it does
+ * not need additional reference counting. The structure is protected by the
+ * mutex 'mutex'.
+ */
+struct logger_log {
+ unsigned char *buffer;/* the ring buffer itself */
+ struct miscdevice misc; /* misc device representing the log */
+ wait_queue_head_t wq; /* wait queue for readers */
+ struct list_headreaders; /* this log's readers */
+ struct mutexmutex; /* mutex protecting buffer */
+ size_t w_off; /* current write head offset */
+ size_t head; /* new readers start here */
+ size_t size; /* size of the log */
+};
+
+/*
+ * struct logger_reader - a logging device open for reading
+ *
+ * This object lives from open to release, so we don't need additional
+ * reference counting. The structure is protected by log->mutex.
+ */
+struct logger_reader {
+ struct logger_log *log; /* associated log */
+ struct list_headlist; /* entry in logger_log's list */
+ size_t r_off; /* current read head offset */
+};
+
+/* logger_offset - returns index 'n' into the log via (optimized) modulus */
+#define logger_offset(n) ((n) & (log->size - 1))
+
+/*
+ * file_get_log - Given a file structure, return the associated log
+ *
+ * This isn't aesthetic. We have several goals:
+ *
+ * 1) Need to quickly obtain the associated log during an I/O operation
+ * 2) Readers need to maintain state (logger_reader)
+ * 3) Writers need to be very fast (open() should be a near no-op)
+ *
+ * In the reader case, we can trivially go file->logger_reader->logger_log.
+ * For a writer, we don't want to maintain a logger_reader, so we just go
+ * file->logger_log. Thus what file->private_data points at depends on whether
+ * or not the file was opened for reading. This function hides that dirt
Re: Android mainlining project
On 12/20/2011 03:27 PM, Geunsik Lim wrote: > On Tue, Dec 20, 2011 at 9:39 AM, Tim Bird wrote: >> The wiki page for this effort (still under construction) is >> at: http://elinux.org/Android_Mainlining_Project > Actually, current linux-next tree is not including ashmem(anonymous > shared memory). > When I checked android kernel features of linux-next(20111219), > Wakelock API feature(./kernel/power/*lock.c) still isn't appeared in > linux-next tree. Both of these (wakelocks and ashmem) are listed as "not mainlined" in the table on the wiki page. Ashmem is apparently being worked on (see the lwn.net article). -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Android mainlining project
Hello all, I would like to announce the beginning of a project to make a concerted effort to mainline patches and features from Android into the mainline Linux kernel. At the recent kernel summit in Prague, there was a discussion about re-evaluating some of the Android-specific features that are found in Google's android kernel, and looking at whether and how to incorporate them into the mainline (kernel.org) kernel. Various parties, including individual developers, the CE workgroup in the Linux Foundation, and a group at Linaro have been working on different aspects of this. A wiki page and mailing list have been created to help coordinate our efforts and avoid duplication and confusion. The wiki page for this effort (still under construction) is at: http://elinux.org/Android_Mainlining_Project There's a mailing list if you wish to follow discussions about this project. It's available at: https://lists.linuxfoundation.org/mailman/listinfo/ce-android-mainline If you are interested in this work, please join the mailing list or send me an e-mail. Some interesting things are already happening. I'll send a status message to the ce-android-mainline list in a day or two to let interested parties know what's currently going on. Regards, -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ELC Europe Call for Proposals, due July 8th
Hey embedded Linux developers, I thought I'd let you all know that the call for proposals for ELC-Europe is active now. ELC Europe will be in Prague this year, co-located with LinuxCon Europe and the Kernel Summit. So anyone who has plans to be at those events might also conveniently talk at or participate in ELC Europe. The event dates are October 26-28. Proposals for talks are due July 8th (just a week from today). The CFP is at: http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp and you can follow links for general event information. I look forward to seeing many of you there! If you've been working on something neat, please considering coming and telling us about it. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Celinux-dev] About the "Tiny Linux Kernel" project
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the "Tiny Linux Kernel" project
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 = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: module boot time (was Re: [PATCH] module: Use binary search in lookup_symbol())
On 05/19/2011 12:56 PM, Jeff Mahoney wrote:
> On 05/18/2011 05:34 PM, Greg KH wrote:
>> I don't think that's worth it, there has been talk, and some initial
>> code, about adding kernel modules to the kernel image itself, which
>> would solve a lot of the i/o time of loading modules, and solves some
>> other boot speed problems. That work was done by Jeff Mahoney, but I
>> think he ran into some "interesting" linker issues and had to shelve it
>> due to a lack of time :(
>
> I had a few attempts at this before I had to move on to other things. I
> haven't gotten a chance to take another look.
>
> I had two approaches:
>
> 1) Statically link in modules post-build. This actually worked but had
> some large caveats. The first was that an un-relocated image (vmlinux.o)
> was needed in order to make it work and a ~ 200 MB footprint to gain a
> fairly small win in boot time didn't seem like a good tradeoff. The
> other issue was more important and is what made me abandon this
> approach: If the entire image is re-linked then the debuginfo package
> that we as a distributor offer but don't typically install becomes
> invalid. Our support teams would not be too thrilled with the idea of
> crash dumps that can't be used.
>
> 2) Build a "megamodule" that is loaded like an initramfs but is already
> internally linked and requires no additional userspace. I got the
> megamodule creation working but didn't get the loading aspect of it done
> yet.
>
> In both cases, I added the regular initcall sections to the modules in
> addition to the module sections so they'd be loaded in the order they
> would have been if they were actually statically linked.
>
> I hadn't thought about it until now and it may not actually work, but it
> could be possible to use the megamodule approach *and* link it into a
> static vmlinux image as an appended section that's optionally used.
What was the use case for this? My use case is that I want
to use all the modules compiled into the kernel, but I don't
want to run some modules' initcalls until well after kernel
and user-space startup.
My solution is very simple - create a new initcall macro for
the initcalls I want to defer, along with a new 'deferred' initcall
section where the function entries can be accumulated. Then,
I avoid freeing init memory at standard initcall time. Once
the main user-space has initialized, it echos to a /proc file
to cause the deferred initcalls to be called, and the init memory
to be freed.
I'm attaching the patch below, because it's short enough to
see what's going on without a lot of digging.
This method eliminates the linking cost for module loading,
saves the memory overhead of the ELF module format, and gives
me control over when the deferred modules will be initialized.
The big downside is that you have to manually change the definition
for the initcall from 'module_init' to 'deferred_module_init'
for the modules you want to defer. Maybe there's a simple way
to control this with a kernel config? That would make this a pretty
nice, generic, system for deferring module initialization, IMHO.
If your use case is that you want all the modules present, but
want to initialize only some of them later, then maybe a list of
module names could be passed into the /proc interface, and the
routine could selectively initialize the deferred modules.
Patch (for 2.6.27 I believe) follows. This is for discussion
only, I wouldn't expect it to apply to mainline.
commit 1fab0d6a932d000780cd232b7d10ebfbe69f477c
Author: Tim Bird
Date: Fri Sep 12 11:31:52 2008 -0700
Add deferred_module_init
This allows statically linked modules to be initialized sometime after
the initial bootstrap. To do this, change the module_init() macro
to deferred_module_init(), for those init routines you want to defer.
Signed-off-by: Tim Bird
diff --git a/arch/x86/kernel/vmlinux_32.lds.S b/arch/x86/kernel/vmlinux_32.lds.S
index a9b8560..f5bdfc4 100644
--- a/arch/x86/kernel/vmlinux_32.lds.S
+++ b/arch/x86/kernel/vmlinux_32.lds.S
@@ -140,11 +140,21 @@ SECTIONS
*(.con_initcall.init)
__con_initcall_end = .;
}
+ .deferred_initcall.init : AT(ADDR(.deferred_initcall.init) - LOAD_OFFSET) {
+ __def_initcall_start = .;
+ *(.deferred_initcall.init)
+ __def_initcall_end = .;
+ }
.x86_cpu_dev.init : AT(ADDR(.x86_cpu_dev.init) - LOAD_OFFSET) {
__x86_cpu_dev_start = .;
*(.x86_cpu_dev.init)
__x86_cpu_dev_end = .;
}
+ .x86cpuvendor.init : AT(ADDR(.x86cpuvendor.init) - LOAD_OFFSET) {
+ __x86cpuvendor_start = .;
+ *(.x86cpuvendor.init)
+ __x86cpuvendor_end = .;
+ }
SECURITY_INIT
. = ALIGN(4);
.altinstructions : AT(ADDR(.alt
module boot time (was Re: [PATCH] module: Use binary search in lookup_symbol())
On 05/18/2011 12:21 PM, Greg KH wrote: > On Wed, May 18, 2011 at 10:00:12AM -0700, Tim Bird wrote: >> Carmelo Amoroso reported some good performance gains >> in this presentation: >> http://elinux.org/images/1/18/C_AMOROSO_Fast_lkm_loader_ELC-E_2009.pdf >> (See slide 22). >> >> He doesn't report the overall time savings, and >> he was using a different method (hash tables as opposed to >> binary search), but I believe the results are comparable >> to what the binary search enhancement provides. >> >> The biggest offenders in his testing were usbcore, >> ehci_hcd and ohci_hcd. > > Why those? The size of them, or something else? They don't seem to > have very many symbols they need to look up compared to anything else > that I can tell. > > Is something else going on here due to the serialization of the USB > drivers themselves? I don't think there's anything wrong with these, compared to other kernel modules. I just think they stood out (probably because of size) from the other modules in the small set that Carmelo tested. In his tests, usbcore was the largest module by an order of magnitude. >>> And why do people overly care for the load time? >> >> To reduce overall boot time. > > To reduce it even more, build the modules into the kernel :) That's what I do most of the time. For some projects, it is useful to build certain things as modules so you can defer initializing them until later in the boot sequence. You can get some critical user-space tasks running, then come back later to initialize USB and other drivers. On cameras, it's not uncommon to want to get to user space in the first 500 milliseconds. Sony has some code which allows us to both statically link drivers and defer their initialization, but it's kind of kludgy and requires modifying the module declarations for the code you want to defer. Let me know if you think this is worth doing an RFC about. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] module: Use binary search in lookup_symbol()
On 05/18/2011 12:54 AM, Christoph Hellwig wrote: > On Tue, May 17, 2011 at 04:33:07PM -0700, Tim Bird wrote: >> That said, I can answer Greg's question. This is to speed up >> the symbol resolution on module loading. The last numbers I >> saw showed a reduction of about 15-20% for the module load >> time, for large-ish modules. Of course this is highly dependent >> on the size of the modules, what they do at load time, and how many >> symbols are looked up to link them into the kernel. > > How large are these very large modules, and what are good examples for > that? usbcore seems to be a large-ish module whose load time is improved by this. More details follow: I don't know the exact modules, but Alan Jenkins reported a .3 second reduction in overall boot time, on a EEE PC, presumably running a stock Linux distribution, and loading 41 modules. See http://lkml.org/lkml/2009/11/3/93 Carmelo Amoroso reported some good performance gains in this presentation: http://elinux.org/images/1/18/C_AMOROSO_Fast_lkm_loader_ELC-E_2009.pdf (See slide 22). He doesn't report the overall time savings, and he was using a different method (hash tables as opposed to binary search), but I believe the results are comparable to what the binary search enhancement provides. The biggest offenders in his testing were usbcore, ehci_hcd and ohci_hcd. > And why do people overly care for the load time? To reduce overall boot time. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] module: Use binary search in lookup_symbol()
On 05/17/2011 04:22 PM, Greg KH wrote: > On Tue, May 17, 2011 at 10:56:03PM +0200, Alessio Igor Bogani wrote: >> This work was supported by a hardware donation from the CE Linux Forum. >> >> Signed-off-by: Alessio Igor Bogani >> --- > > That's nice, but _why_ do this change? What does it buy us? > > Please explain why you make a change, not just who sponsored the change, > that's not very interesting to developers. Just a note here on the attribution... Alessio - you can remove the "hardware donation from CELF" line after the first submission or so. It doesn't need to be on every submission of the patch set, and it doesn't need to go into the commit message for the patch set. We only want it associated with the patch set somewhere Google-able (like LKML). That said, I can answer Greg's question. This is to speed up the symbol resolution on module loading. The last numbers I saw showed a reduction of about 15-20% for the module load time, for large-ish modules. Of course this is highly dependent on the size of the modules, what they do at load time, and how many symbols are looked up to link them into the kernel. Alessio - do you have any timings you can share for the speedup? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On 05/05/2011 12:27 PM, Mike Frysinger wrote: > On Thu, May 5, 2011 at 15:12, Tim Bird wrote: >> On 05/05/2011 12:04 PM, Mike Frysinger wrote: >>> On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote: >>>> On Thu, 5 May 2011, Tim Bird wrote: >>>>> On 05/05/2011 11:32 AM, David Woodhouse wrote: >>>>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: >>>>>>> On 05/05/2011 11:00 AM, Tim Bird wrote: >>>>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it >>>>>>>> >>>>>>>> Sony uses this - a lot. Principally we're using this on a NEC >>>>>>>> naviengine part, which is ARM11MPCore based, support for which >>>>>>>> is (sadly) out of tree. >>>>>> >>>>>> If you're out of tree, you don't exist. >>>>> >>>>> Yeah - I know. I guess I should tell NEC we'll drop support >>>>> for their chip and move to another one that supports XIP >>>>> if they don't get their act together. If XIP survives... >>>> >>>> It is easy enough to keep it alive... as long as someone uses it of >>>> course. >>> >>> i think David's point: >>> ... someone uses it ... >> >> I should add that I tried to use XIP on omap (for research purposes), >> but it was broken and I didn't have time to fix it. My bad. >> If anyone is using XIP on in-tree platforms, I'd like to hear >> about it. > > XIP on Blackfin should work right now, but that doesnt directly apply > to the patch in question here. it does however imply that other > pieces in the stack work (like the MTD/mm layers). > >> As for in-tree-ness - I thought the most recent message was to stay >> out of tree until the refactoring was over. ;-) > > to be fair, does this have any relevance whatsoever to NEC parts ? > istm that the hindrance here is NEC doing any actual work for > mainline. even if there was no refactoring, i find it hard to believe > that an NEC port would be posted. if it were actually something that > could happen, then they should already be posting patches for *basic* > review to get the pieces unrelated to the refactoring worked out. > there's no reason this has to be done serially. Well, OK. I just don't want to lob bombs at NEC and then have some poor soul over there get immediately rebuffed, due to basic ARM churn. Maybe not having naviengine support upstream is my fault, but Sony doesn't make the CPU, so it doesn't seem like it should be my job to mainline the chip support. About the only thing I have at my disposal is pressure not to buy the chip (but this is harder to exercise than one might think.) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On 05/05/2011 12:04 PM, Mike Frysinger wrote: > On Thu, May 5, 2011 at 14:54, Nicolas Pitre wrote: >> On Thu, 5 May 2011, Tim Bird wrote: >>> On 05/05/2011 11:32 AM, David Woodhouse wrote: >>>> On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: >>>>> On 05/05/2011 11:00 AM, Tim Bird wrote: >>>>>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>>>> nearly no-one use it, only amop1, pxa and sa1100 implement it >>>>>> >>>>>> Sony uses this - a lot. Principally we're using this on a NEC >>>>>> naviengine part, which is ARM11MPCore based, support for which >>>>>> is (sadly) out of tree. >>>> >>>> If you're out of tree, you don't exist. >>> >>> Yeah - I know. I guess I should tell NEC we'll drop support >>> for their chip and move to another one that supports XIP >>> if they don't get their act together. If XIP survives... >> >> It is easy enough to keep it alive... as long as someone uses it of >> course. > > i think David's point: > ... someone uses it ... I should add that I tried to use XIP on omap (for research purposes), but it was broken and I didn't have time to fix it. My bad. If anyone is using XIP on in-tree platforms, I'd like to hear about it. As for in-tree-ness - I thought the most recent message was to stay out of tree until the refactoring was over. ;-) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On 05/05/2011 11:32 AM, David Woodhouse wrote: > On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: >> On 05/05/2011 11:00 AM, Tim Bird wrote: >>> On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>> nearly no-one use it, only amop1, pxa and sa1100 implement it >>> >>> Sony uses this - a lot. Principally we're using this on a NEC >>> naviengine part, which is ARM11MPCore based, support for which >>> is (sadly) out of tree. > > If you're out of tree, you don't exist. Yeah - I know. I guess I should tell NEC we'll drop support for their chip and move to another one that supports XIP if they don't get their act together. If XIP survives... -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] arm: drop Execute-In-Place
On 05/05/2011 11:00 AM, Tim Bird wrote: > On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: >> nearly no-one use it, only amop1, pxa and sa1100 implement it > > Sony uses this - a lot. Principally we're using this on a NEC > naviengine part, which is ARM11MPCore based, support for which > is (sadly) out of tree. > > I'd like to see MORE support for XIP in the kernel, not less. > > NAK from me. By the way - it would be good to copy linux-embedded on this, to expand the discussion. I should have done that in my response, but I'm doing so now. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove CONFIG_PM altogether, enable power management all the time
On 02/09/2011 11:25 AM, Mark Brown wrote: > On Wed, Feb 09, 2011 at 11:00:17AM -0800, Frank Rowand wrote: > >> and my understanding of this proposal was a goal to remove the ability >> to have CONFIG_PM disabled, which results in increased memory usage >> for some configurations. > > Not really, the goal was to simplify the PM config options to ones that > are actually useful and cut down on the number of silly combinations > that the randconfigs turn up. CONFIG_PM is there mostly for historical > reasons, it doesn't really mean much by itself except as a gate to other > options. I'm confused. Do you plan to retain the option to turn off PM features completely, or not? I thought that's what CONFIG_PM did today. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove CONFIG_PM altogether, enable power management all the time
On Tue, Feb 8, 2011 at 4:21 AM, Ingo Molnar wrote: > Rafael, could you do a defconfig-ish x86 build with and without CONFIG_PM, > and post > the 'size vmlinux' comparison - so that we can see the size difference? We > make some > things CONFIG_EXPERT configurable just to enable folks who *really* want to > cut down > on kernel size to configure it out. I'm one of those people who *really* wants to cut down the kernel size. I've recently worked on a product where the kernel RAM budget is ~1M. > > Note that those usecases, even if they want a super-small kernel, might not > care > about PM at all while they care about size: small boot kernels in ROMs, or > simple > devices where CPU-idling implies deep low power mode, etc. > > So the vmlinux size comparisons would be needed really. If it's 5k nobody > will care. I care about 5K. (But honestly, I don't actively hunt stuff less than 10K in size, because there's too many of them to chase, currently). -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] printk-formats.txt documentation update
On 02/05/2011 04:15 PM, Andrew Murray wrote: > From: Andrew Murray > > This patch updates the incomplete documentation concerning the printk > extended format specifiers. > > Signed-off-by: Andrew Murray > --- > 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 > + %pMF6-byte dash-separated FDDI hex notation > + > + IPv4 addresses: > + > + %pI4IPv4 dot-seperated decimal without leading 0's, e.g. 1.2.3.4 > + %pi4IPv4 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: > + %pI6IPv6 colon-seperated network-order 16 bit hex with leading 0's, > + e.g. 0001:0203:...:0708 > + %pi6IPv6 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 = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF open project proposals for 2011 - Request for proposals
On 12/24/2010 07:42 PM, wu zhangjin wrote: >> Please see more details and full instructions at: >> http://elinux.org/CELF_Open_Project_Proposal_2011 > > Seems there is a typo here: "The bidding period will be the first > weeks of March, 2010." I guess the time is "March, 2011" ;-) That's correct. It's fixed. Thanks. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CELF open project proposals for 2011 - Request for proposals
In addition to its other activities, each year, the CE Linux Forum performs contract work to enhance embedded Linux. We would like to invite you to consider what areas of embedded Linux technology and embedded Linux development could be improved, and submit a proposal. Any ideas or projects that you think it would be good for CELF to fund would be appreciated. Please see more details and full instructions at: http://elinux.org/CELF_Open_Project_Proposal_2011 Regards, -- Tim Bird Architecture Group Chair CE Linux Forum -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On 11/10/2010 2:16 AM, Mike Frysinger wrote: On Tue, Nov 9, 2010 at 12:17, Tim Bird wrote: On 11/09/2010 03:19 AM, Mike Frysinger wrote: On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. wouldnt it make more sense to piggy back the extensive work going into the "stable" tree ? many of the points you raise after all are the entire founding point of it. plus, all the main distros form around that, are spending time working on that, is marked as supported for 2 or 3 years, and there is already infrastructure/framework/process in place (sta...@kernel.org). so instead of picking arbitrary versions (like 2.6.35) and needlessly replicating the huge work load, simply declare these stable trees as the "flag" versions. that means today it'd be 2.6.32.y. The fact that this tree is already a year old, and not likely to be brought forward for at least another 2 years is the reason we didn't choose it this time. Most of the high-profile, active embedded projects are already on 2.6.35. For companies looking to adopt a new base kernel in the next 12 months, I don't want to have them start with a year-old kernel. We did consider the utility of synchronizing with the enterprise stable tree, but the timing just didn't work too well this time around. so you're suggesting this is a one-off choice. in the future, the "flag" versions will simply piggy the existing stable trees ? Yes, if the timing works then. I can't promise anything, but I think it would be a very strong goal. -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On 11/09/2010 09:25 AM, Nicholas Mc Guire wrote: > I guess one of the key issues is that it would need to be defined beforehand > what version will be used as the next "flag" version so vendors could make > sure that there drivers are available. Yeah. People keep asking about that. Unfortunately, this was not discussed or settled on - so I can't really comment on that as an industry representative. However, I will say that we'd like to work to synchronize our next flag version with the next enterprise stable release. (But again, it will depend on timing). Personally (not speaking on behalf of anyone else here), I think there would be a certain poetry to selecting 2.6.42 (which may just also be the same as or one before kernel version 3.1) ;-) -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Flag Version
On 11/09/2010 03:19 AM, Mike Frysinger wrote: > On Thu, Nov 4, 2010 at 18:07, Tim Bird wrote: >> It was noted at the summit that several CE companies and embedded >> projects will be using (or are already using) 2.6.35 for upcoming >> products or releases. This includes Sony, Google, Meego, and Linaro. On >> behalf of the CE Linux Forum and a number of consumer electronics >> companies, projects and community developers, we therefore declare >> 2.6.35 as a flag version of the kernel for embedded use. Several >> companies will be investing in development, integration and testing of >> this version. Entities wanting to do business with those companies would >> therefore be well-advised to make sure their hardware, drivers and >> enhancements work well with this version of the kernel. > > wouldnt it make more sense to piggy back the extensive work going into > the "stable" tree ? many of the points you raise after all are the > entire founding point of it. plus, all the main distros form around > that, are spending time working on that, is marked as supported for 2 > or 3 years, and there is already infrastructure/framework/process in > place (sta...@kernel.org). > > so instead of picking arbitrary versions (like 2.6.35) and needlessly > replicating the huge work load, simply declare these stable trees as > the "flag" versions. that means today it'd be 2.6.32.y. The fact that this tree is already a year old, and not likely to be brought forward for at least another 2 years is the reason we didn't choose it this time. Most of the high-profile, active embedded projects are already on 2.6.35. For companies looking to adopt a new base kernel in the next 12 months, I don't want to have them start with a year-old kernel. We did consider the utility of synchronizing with the enterprise stable tree, but the timing just didn't work too well this time around. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Embedded Linux Flag Version
Embedded Flag Version Recently, two embedded Linux summit meetings were held, one in Tokyo, Japan and one in Cambridge, UK. The purpose of these meetings was to discuss among industry and community leaders things that might help improve the value or decrease the cost of embedded Linux. One initiative which came out of these meetings, was the notion of declaring a "flag version" of Linux, for embedded use. This would be a specific version of the Linux kernel, chosen as a rallying point for embedded Linux software, add-ons and products. In hearing from several different consumer electronics product companies and semi-conductor producers at the summits, it became apparent that a significant problem in the embedded space is variation in the kernel version. This could be called version fragmentation. Companies, especially those at the end of the software supply chain, often get stuck using a particular kernel version for a product due to the cost to integrate software coming from different entities. Of course the optimal solution to this problem would be if all required software were pre-integrated into the latest stable release, at all times. However, software can not be mainlined instantaneously. Not everyone is using the latest version of the Linux kernel (2.6.36, as of this writing). In point of fact, no one in the CE industry does (or really can), use the absolute latest kernel for a product that is shipping today. It takes time to assemble the software and perform the testing required to ship a product. However, it is desirable for many reasons to stay as close to the current version of Linux as possible. Selecting a "flag version" is intended to help with this problem. First, it should be explained what having a flag version means. It means that suppliers and vendors throughout the embedded industry will be encouraged to use a particular version of the kernel for software development, integration and testing. Also, industry and community developers agree to work together to maintain a long-term stable branch of the flag version of the kernel (until the next flag version is declared), in an effort to share costs and improve stability and quality. It may seem counter-intuitive that selecting a version of the kernel for long-term stable maintenance would help companies keep up with the mainline version. But there are a number of reasons why it can. First and foremost, a lot of effort is spent integrating software components to make a product. This includes software components from IP block vendors, semi-conductor vendors, parts suppliers, Linux vendors, and in-house software teams. By decreasing the effort required to integrate this software, it becomes possible to spend more time working on other features, and working with upstream, and increases the frequency that a company can afford to switch kernel versions. Also, by leveraging the testing of multiple organizations and developers, including those outside one's own company, a group can more quickly ensure that a kernel is suitable for production use. This also decreases the effort required to use the kernel, and increases the possibility of quicker version changes. It was noted at the summit that several CE companies and embedded projects will be using (or are already using) 2.6.35 for upcoming products or releases. This includes Sony, Google, Meego, and Linaro. On behalf of the CE Linux Forum and a number of consumer electronics companies, projects and community developers, we therefore declare 2.6.35 as a flag version of the kernel for embedded use. Several companies will be investing in development, integration and testing of this version. Entities wanting to do business with those companies would therefore be well-advised to make sure their hardware, drivers and enhancements work well with this version of the kernel. Tim Bird Architecture Group Chair CE Linux Forum November 4, 2010 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Plumbers Embedded microconference
On 09/17/2010 04:32 PM, Grant Likely wrote: > 3) Common infrastructure beyond the kernel. Android has fastboot and > other tools. Many folks use u-boot for development, but something > custom (smaller) for deployment. Are there any other tools/techniques > from Android/MeeGo/Linaro/WebOS/etc. that would be useful to a wider > audience. Tim Bird has offered to lead this discussion. .. > Tim, Jeremy and Kevin; I've accepted your micro-conference topics. As > the conference gets closer I'll write up a draft of the actual agenda > and your proposals can be massaged appropriately to reflect exactly > what issues will be discussed. > > Thoughts? Sounds good. I'm going to initiate discussion of this at the embedded Linux summit coming up next week. That should help find the possible areas of wider collaboration, that we can discuss more at Plumbers. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kernel 'boot cache' to reduce boot time
On 08/31/2010 12:13 PM, Andrew Murray wrote: > I have a suggestion for a kernel framework which aims to reduce boot > time in embedded devices and would be interested in hearing your > feedback. > > A large portion of kernel boot time is spent in driver probe functions > often waiting for hardware for example calculating LPJ values or > trying to determine what type of camera is connected (PAL/NTSC) etc. > However for most embedded devices the hardware remains constant and > these probes always determine the same information. Therefore boot > time can be decreased by removing some of this probe code and > replacing it with known values. > > To some extent some of these optimisations have already been done > through a variety of methods - for example the LPJ calculation can be > bypassed with the lpj= parameter and some drivers have their own > methods. My solution aims to generalise these solutions... > > The solution is to provide a very simple framework which will allow > drivers to identify and record such values (LPJ, camera type, decoder > chip version) during boot. Once booted the user can obtain a > collection of these values and pass them back to the kernel on > subsequent boots. During subsequent boots - drivers upon realising > these values have already been provided can bypass some of their probe > code and thus reducing boot time. Taking advantage of this framework > would be very trivial for drivers. > > I wanted to see your views on the overall solution prior to > considering how it could be implemented. For my part, I think this sounds like a great idea. I have considered such a mechanism in the past, but never gotten around to actually designing a solution. Here are some random thoughts on this idea: My experience is that we've made good progress on boot time probing, for fixed hardware. The big problems in the kernel boot time appear to be with busses that require discovery of devices, with long timeouts specified in the bus standard and arbitrary bus connection architecture (I'm thinking of USB, but other busses have similar problems). For many embedded devices, scanning these types of pluggable busses aren't required for what I call "first product use", but they can be scanned and populated later. Note that the asynchronous function call stuff by Arjan van de Ven addresses some of this boot time probing delay problem. Having said that, I don't think that probing of static hardware is a solved problem, by any means. For the boot cache data, you are going to need to figure out how to make the data persistent. Doing something in a regular fashion (rather than ad-hoc via command line options) should help with this. To some degree this might end up looking very similar to the "resume" path in the driver, where a particular device state is entered into from cold start. Sony has been doing something related to this called "Snapshot boot" for some time now, which is kind of an optimized unhibernate operation, with some hardware bringup done by firmware, and some bringup done using the normal driver resume operation. This work was presented at OLS several years ago, but we haven't pushed it much since then. (But we're using it in product) See http://elinux.org/upload/3/37/Snapshot-boot-final.pdf Sorry for rambling. Anyway - I'm all for the boot cache idea. But acceptability would, of course, be dependent on the details of the implementation. The best thing to get started, IMHO, would be to identify a few drivers which have long probe times, and see how they could reduce these with the proposed boot cache. If you find that each new device adds some new wrinkle in the cache requirements, that would be a bad sign. But if different drivers, especially drivers in different functional areas, are found to be able to use a consistent API, then this could be a nice feature. BTW - I could see this tying into the flattened device tree work by Grant Likely. -- Tim P.S. Also, I would recommend cross-posting to LKML to get wider visibility of your proposal. I'm doing so in this response - I hope that's OK. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Embedded Linux Conference Europe Program Announced
Sorry in advance for this non-technical post, but I figured some embedded kernel developers (especially in Europe) might be interested in this. == SUMMARY The CE Linux Forum is pleased to announce the program for Embedded Linux Conference Europe, 2010. This event brings together embedded Linux experts from Europe and around the world. This year the event is planned for October 26-28, in Cambridge, UK. We are happy to be co-located with the GStreamer conference, to be held October 26 in the same venue. A full list of ELC Europe sessions is available at: http://www.embeddedlinuxconference.com/elc_europe10/sessions.html and for program details, see: http://www.embeddedlinuxconference.com/elc_europe10/program.html Note that the main conference days are October 27 and 28, with some tutorial workshops offered October 26. Registration is now open at the above web site. Information about the GStreamer conference is available at: http://gstreamer.freedesktop.org/conference/ == PROGRAM HIGHLIGHTS The conference will host almost 50 sessions, including presentations, Birds-of-a-Feather sessions, keynotes and tutorials. The sessions will cover such wide-ranging topics as: * Linux in Mobile * Porting and board bring-up * Android * Meego * Video and Multimedia * Boot technologies, including fast booting * Toolchains * Power management * Real-time * Memory analysis and performance * Flash file systems * Security * License compliance and much more. Presenters are Linux developers and experts from companies like: Texas Instruments, Intel, ARM, Wind River, Mentor Graphics, ST Ericsson, Alcatel-Lucent, ST Microelectronics, Montavista, Sony, Pengutronix, Samsung, Nokia, and Toshiba. Here are some of the experts presenting at this event: * Ari Rauch - Senior director of Software and Systems Engineering for TI's wireless OMAP processor group * Ralf Baechle - Maintainer of the MIPS architecture in the Linux kernel * Wolfram Sang - Developer at Pengutronix, and longtime kernel contributor * Armijn Hemel - A driving force at gpl-violations.org * Kevin Hillman - Former MontaVistan, long-time kernel power manage- ment guru, and maintainer of the TI DaVinci SoC kernel code * Wookey - Maintainer of YAFFS, and embedded Debian contributor * Grant Likely - Kernel maintainer for some embedded PowerPC boards and the new flattened device tree system * Frank Rowand - Realtime Linux practitioner at Sony Corporation Registration includes access to all sessions, demos, BOF meetings, and lunch and snacks each day. There will also be a fun social event Wednesday night, hosted by Intel. == Tutorials We have also arranged for some hands-on tutorial sessions on Tuesday, October 26. There will be 2 half-day sessions taught by experienced Linux trainer and consultant Chris Simmonds. The sessions cover basic embedded Linux bring-up and an introduction to Android development. Space for these sessions is limited, and requires an extra fee. See the tutorial page for details. http://www.embeddedlinuxconference.com/elc_europe10/tutorial.html == Sponsors Sponsors for the event include the CE Linux Forum, Texas Instruments, Linaro, Google, and Intel. All of these groups or companies are interested in enhancing and promoting Linux in embedded products. == Registration To register, please follow the link at: http://www.embeddedlinuxconference.com/elc_europe10/registration1.html Registration is open to professionals and hobbyists, who receive a substantially discounted rate. If you have any questions, send e-mail to elce...@tree.celinuxforum.org. I hope you can make it! -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Information on XIP
On 06/16/2010 03:23 PM, Mike Frysinger wrote: > On Wed, Jun 16, 2010 at 18:19, Tim Bird wrote: >> I'd like to start collecting information about XIP on the >> eLinux wiki. If you've done XIP for the kernel or for >> user-space (application XIP), or know a good source of >> information about this, please let me know. > > Blackfin linux + userspace XIP: > http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:xip Thanks! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Information on XIP
Hi all, I'm starting to look at XIP issues with Linux. I know this sounds strange, but has anyone done anything with XIP for kernel loadable modules? If so, please let me know. I'd be interested in hearing about what you've done. I'd like to start collecting information about XIP on the eLinux wiki. If you've done XIP for the kernel or for user-space (application XIP), or know a good source of information about this, please let me know. I'm interested in putting together a basic tutorial about XIP, and doing some benchmarking on an ARM platform. Thanks, -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Status of SquashFS LZMA support in mainline
Does anyone (Phillip?) know the status of SquashFS support for LZMA compression in mainline? I seem to recall that Phillip got the patches for this into linux-next sometime in January, but I'm not sure if the latest kernel (2.6.34-rcxx) includes this or not. I also see in Linus' git tree the following commits in March: 2010-03-05 Linus Torvalds Merge git://git.kernel.org/pub/scm/linux/kernel/git... ...git://git./linux/kernel/git/pkl/squashfs-linus ...org/pub/scm/linux/kernel/git/pkl/squashfs-linus: Squashfs: get rid of obsolete definition... Squashfs: get rid of obsolete variable... Squashfs: add decompressor entries for... Squashfs: add a decompressor framework Squashfs: factor out remaining zlib dependencies... Squashfs: move zlib decompression wrapper... 2010-03-05 Phillip Lougher Squashfs: get rid of obsolete variable in struct squashfs_sb... Squashfs: get rid of obsolete variable... Is this everything, or are there still things outstanding? In January the V3 patches were labeled: lzma: Make lzma available to non initramfs/initrd code lzma: make lzma reentrant The first one of these modifies lib/Kconfig, but I don't see a change (in git) authored by Phillip in this time frame. Thanks for any information you can provide. -- Tim ========= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] ELC 2010 Program is available - registration open
My apologies in advance for this notice. I only do this a few times a year. Some people on this list may be interested Embedded Linux Kernel Developers, CELF is happy to announce that the program for Embedded Linux Conference 2010 is now available, and registration is open for the event! The conference is coming soon - It will be April 12-14 in San Francisco, California. The program is now available at the conference web site at: http://www.embeddedlinuxconference.com/elc_2010/ (see the "Program" and "Sessions" tabs). Here are some highlights: Greg Kroah-Hartman and Matt Asay will be our keynote speakers at ELC this year. * Greg Kroah-Hartman - Driver sub-system kernel maintainer, Linux author, and kernel developer, currently with Novell, will talk about "Android: a Case Study of an Embedded Linux Project" * Matt Asay - Canonical COO and long-time open source strategist and blogger for CNET will talk about "Embedded in 2010: an End to the Entropy?" Some notable speakers include: * Mike Anderson - CTO and Chief Scientist of The PTR Group * Greg Ungerer - MMU-less systems kernel maintainer * Grant Likely - Device tree kernel maintainer * Steven Rostedt - Ftrace kernel maintainer Along with these speakers, there will be 3 days of presentations, tutorials and Bird-of-a-Feather sessions (over 50 in total) on topics like: Flash filesystems, Realtime measurement and performance, Graphics and media, Mobile and embedded distributions, Security, Porting and platform bringup, Symmetric Multi-Processing in embedded systems, Development tools, Tracing, Power management ...and much more! See the full sessions list at the event web site. This is your chance to meet leading developers from the embedded Linux community, and learn about the latest changes in Linux. Also, you can talk to engineers working on real products at some of the largest CE companies in the world, describing how they solved real issues in their own development projects. The Embedded Linux Conference is one of the leading events where you can learn directly from the experts. A session or even a 15-minute hallway conversation at ELC can save you weeks of work, or give you just the idea you need to solve that problem you're working on!! If that's not enough, due to a special arrangement with the Linux Foundation, as an attendee of ELC you will also be granted access to all Linux Collaboration Summit sessions and activities. Please register for the Collaboration Summit separately, AFTER registering for ELC. See http://events.linuxfoundation.org/events/collaboration-summit for details. The Collaboration Summit is normally an invitation-only event, but you can guarantee your spot at it by attending ELC. We've got a great event planned, that we're sure you won't want to miss. Register for ELC now by following the link at: http://www.embeddedlinuxconference.com/elc_2010/registration1.html Register by March 20th to receive the "early-bird" discount! I hope to see you there! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
Raffaele Recalcati wrote: > 2009/12/18 Raffaele Recalcati : >> Summary: Feasibility analisys of Android introduction in a completely >> tested industrial device. >> >> Description: By now Android has been ported to 600Mhz Cortex A8 cpu or >> similar. >> The declared Android requirements are instead lower, about 200Mhz Arm9 >> cpu with 100Mhz Ram bus. >> So I think the growing interest in this O.S. lacks some porting to >> less powerful cpus. >> The reasons to do this porting are commercial because of Google market >> power, but are also technnical, because Android debugging environment >> is very nice for not embedded developers. >> This could help the diffusion of opensource embedded Linux. This is interesting. Can you let me know if the focus of this work is to experiment with the lower bounds of Android scalability, or whether the focus is on Android use in industrial devices? If the latter, than it would be good to hear more about what might be needed to extend (or reduce :-) ) Android to fit this market. I'll add a proposal for this, but I'd like to hear more to clarify the proposal. Thanks, -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF Project proposal: UBIFS mount-time speedups
Kyungmin Park wrote: > Summary: UBI block mapping on flash (UBI2 requirement) This looks like a subset of the project described at: http://elinux.org/CELF_Project_Proposal/UBIFS_mount_time_speedups I've added your description as a comment in that proposal. Thanks! -- Tim ========= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF Project Proposal- Refactoring Qi, lightweight bootloader
Matt Hsu wrote: > Summary: Refactoring Qi, lightweight bootloader. I've created a page for this at: http://elinux.org/CELF_Project_Proposal/Refactor_the_Qi_lightweight_bootloader ========= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF Project Proposal: Create a watchdog framework for the Linux kernel
Wolfram Sang wrote: > Summary: Create a watchdog framework for the Linux kernel Interesting. I've created a page for this proposal at: http://elinux.org/CELF_Project_Proposal/Create_a_watchdog_framework_for_the_Linux_kernel -- Tim ========= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Project Proposal: add sleeping spinlocks to mainline kernel
Linus Walleij wrote: > 2009/12/16 Tim Bird : > >> Summary: add sleeping spinlocks to the mainline kernel > > If realtime performance overall is a big deal for CELF I would suggest > adding "Kill-the-BKL" to the suggested projects. There are still some > RTOS people using the BKL as an argument to flak the Linux kernel, > c.f. > http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf > (section 5.2) The only reference I could find in section 5.2 to BKL was an OSE BKL. Maybe I missed the reference to the Linux BKL. (I looked pretty quickly). However, agree that BKL reduction is a worthy goal. > > Another item could be to go through some common embedded > arch drivers and switch them from request_irq() to request_threaded_irq() > just based on the observation that almost nobody actually use that > in the mainline kernel, though I'm sure they should, > if realtime is a desired feature. > (The wm8350-core driver is an excellent example of a situation where > it is used properly.) Likely, CELF would be most interested in switching to using threaded interrupts in places where the drivers were commonly used in embedded devices. This would require some analysis. But this is another good suggestion. > NB: I'm not a member of the CE Linux Forum and nor is my company > so I'm just talking freely here. (linux-embedded is public, hehe.) The feedback is much appreciated! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Project Proposal: add sleeping spinlocks to mainline kernel
Summary: add sleeping spinlocks to the mainline kernel Proposer: Tim Bird Description: One of the last major elements of the RT-preempt patch set that is still not mainlined is the implementation of the so-called "sleeping spinlocks". It would be good to mainline these, addressing remaining issues to their inclusion in the standard Linux kernel. Thomas Gleixner discussed the status of RT-preempt at the [http://lwn.net/Articles/354690/ realtime preemption mini-summit, and the [http://lwn.net/Articles/357465/ 2009 kernel summit]. Related work: * RT-preempt ** http://rt.wiki.kernel.org/index.php/Main_Page Scope: unknown ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CELF Project Proposal - ALSA scenario/use case support
Liam Girdwood wrote: > Summary: Complete ALSA hardware scenario/use case support in alsa-lib > and salsa-lib This looks like an interesting proposal. I created a page for it at: http://elinux.org/CELF_Project_Proposal/Complete_hardware,_use-case_handling_in_ALSA -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CELF Project proposal: UBIFS mount-time speedups
Summary: Improve UBIFS mounting time Proposer: Tim Bird Description: UBIFS is a next-generation flash-based file system for Linux. It is a read/write file system, which supports compression and has good performance. However, it's mount times are not very good. This affects overall Linux boot time, for a UBIFS-based embedded system. The purpose of this project would be to investigate mount performance issues, and try to resolve them. One suggestion is to keep the bad block table on flash, instead of re-scanning it on every boot. It is not known if algorithms to do this are covered by existing flash management patents. Related work: * UBIFS ** http://en.wikipedia.org/wiki/UBIFS ** http://lwn.net/Articles/276025/ * UBI2 ** see portions of http://www.mjmwired.net/kernel/Documentation/filesystems/ubifs.txt * Mount times ** http://osl.sed.hu/wiki/ubifs/index.php/Mount_results ** http://elinux.org/images/f/f8/CELFJamboree30-UBIFS_update.pdf Scope: This project might take about 4 months Notes: Toshiba may already be working on this project. ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
David Woodhouse wrote: > On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote: >> It applies to anything in the "embedded Linux" ecosystem. This >> would very much include open source boot loaders like U-Boot. > > And coreboot. > > The world needs more coreboot. If coreboot were on ARM, it would be more interesting. That would make an interesting proposal, I suppose. :-) -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
Mike Frysinger wrote: > i know your e-mail intro states "embedded Linux" as does the wiki, but > i'm gonna take a stab anyways. does this apply to Linux only and not > open source boot loaders (like U-Boot) ? It applies to anything in the "embedded Linux" ecosystem. This would very much include open source boot loaders like U-Boot. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
Mike Frysinger wrote: > maybe i missed it, but there doesnt seem to be too much emphasis on > working with the respective projects and getting merged. that seems > like one of the most important aspects of doing any enhancement work > as anything not merged means it'll quickly be left behind and largely > go to waste. I agree. Many of our contracts have a financial incentive built in to get "mainlined". Some of our projects' sole objective is to mainline already existing stuff (like Linux-tiny and SquashFS). If anyone has a feature that already exists, but that they think should be merged with the relevant upstream project, that's a good candidate for a proposal. One obvious project, which I'm waiting to see if someone else submits, is to pay someone to mainline some of the outstanding Android patches into the Linux kernel. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] CELF open project proposal
Hey embedded Linux developers... Are you itching to see some feature developed for embedded Linux? Would you like to suggest that CELF spend their money on some specific project? Would you like CELF to sponsor a project you are working on? Well, now is your chance! This is the official announcement of a new plan by CELF, called the "Open Project Proposal". The CELF Open Project Proposal is a process whereby members of the public submit to the CE Linux Forum ideas and proposals for projects that they think should be worked on to enhance embedded Linux. The plan is to solicit ideas for our 2010 contract work projects. Areas of work can include the Linux kernel, graphics systems, toolchain work, or anything else that will help enhance Linux for use in embedded systems. Each year, CELF spends money on contract work to improve Linux for use in embedded systems. Some of the projects we have sponsored in the past include Linux-tiny, DirectFB enhancements, smem, and Squashfs mainlining. Usually, our process involves querying forum members about their desires and building a project list from that. This year, we are opening up the process and asking for your ideas and proposals as well. For details, see: http://elinux.org/CELF_Open_Project_Proposal_2010 Proposal are welcome immediately... Thanks, -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
Eric W. Biederman wrote: > Matt Mackall writes: > >> As much as I like kexec, it loses on memory footprint by about 100x. >> It's not appropriate for all use cases, especially things like >> consumer-grade wireless access points and phones. > > In general I agree. The cost of a second kernel and initrd can be > prohibitive in the smallest systems, and if you do a crash capture > with using a standalone app that is reinventing the wheel. > > That said. I can happily run kdump with only 16M-20M reserved. > So on many systems the cost is affordable. Understood. On some of my systems, the memory budget for the entire system is 10M. On most systems I work with, it is a struggle to reserve even 64K for this feature. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Proposal] [PATCH] generic clock framework
Francesco VIRLINZI wrote: > Hi all > > I'm Francesco and I work in STMicroelectronics > > In the last ELC-E_2009 I spoke on a generic clock framework I'm working on > (see > http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=ELC_E_2009_Generic_Clock_Framework.pdf). > > > I wrote the gcf to manage both clocks the platform_devices during a > clock operation. This looks good to me, in principle, but I'm not a clock or PM expert. I would recommend sending this to the linux-kernel and linux-pm lists as well. I think you'll get a wider audience for feedback. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] ELC 2010 Call for Presentations
I apologize in advance for this non-technical post... The CE Linux Forum would like to invite you to make a presentation at our upcoming Embedded Linux Conference. The conference will be held April 12-14, 2010 in San Francisco, California. For general information about the conference, See http://embeddedlinuxconference.com/elc_2010/ For information about the call for presentations, see http://elinux.org/ELC_2010_Call_for_Presentations CELF is the primary sponsor of this event, which is open to the public. Please note that the conference will be co-located with the Linux Foundation Spring Collaboration Summit (April 14-16) and it should be a very exciting event. = Guidelines = Presentations should be of a technical nature, covering topics related to use of Linux in embedded systems. The CE Linux Forum is focused on the use of Linux in consumer electronics products, but presentations may cover use of Linux in other embedded areas, as long as the topic is of general relevance to most embedded developers. Presentations that are commercial advertisements or sales pitches are not appropriate for this conference. Presentations on the following topics are encouraged: * Audio, Video, and Graphics systems for embedded products * Security * System size * Bootup time * Meeting real-time constraints * Power management * Streaming media * Flash memory devices and filesystems * Build systems * Embedded distributions * Development tools for embedded users * Technologies related to cell phones, digital settop boxes, televisions, cameras, handheld devices, or other CE products * Use of Linux in actual products, practical experience and war stories * Standards for CE products Most presentation slots will be 50 minutes long, including time for questions. No paper submission is required in conjunction with the presentation. Tutorials, demos, and Birds-of-a-Feather sessions may also be proposed. Full details, including the e-mail address to use to submit a proposal, are at: http://elinux.org/ELC_2010_Call_for_Presentations The deadline for submissions is January 15, 2010. Thanks, -- Tim = Tim Bird Chair of the ELC Program Committee Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Embedded Linux Conference Europe Program Announced
Sorry in advance for this non-technical post, but I figured some embedded kernel developers (especially in Europe) might be interested in this. == SUMMARY The CE Linux Forum is happy to announce the program for Embedded Linux Conference Europe, 2009. This event, located this year in Grenoble, France, brings together embedded Linux experts from Europe and around the world. A full list of sessions is available at: http://www.embeddedlinuxconference.com/elc_europe09/sessions.html and for program details, see: http://www.embeddedlinuxconference.com/elc_europe09/program.html Registration is now open at the above web site. == PROGRAM HIGHLIGHTS Authors of some of the most useful and important resource books in the Linux industry will be there, as well as developers and experts from companies like: Philips, Sony, ST Microelectronics, Free Electrons, Mentor Graphics MontaVista, Pengutronix, and Wind River. The conference will host over 40 sessions, including presentations, Birds-of-a-Feather sessions, keynotes and tutorials. The sessions will cover such wide-ranging topics as: * Board bring-up and porting * Realtime performance * Core kernel features * Graphics and video * Fast booting * Tracing * Embedded distributions and build systems * Bootloaders and bootloader interfaces (device tree) * Security * Android !! and much more. Here are some of the embedded Linux experts presenting at this event: * Jon Masters - Kernel hacker and co-author of "Building Embedded Linux Systems" * Phillipe Gerum - Founder and lead maintainer of the Adeos and Xenomai projects. Also a co-author of "Building Embedded Linux Systems" * Allessandro Rubini - Author of 1st edition of "Linux Device Drivers" * Gilad Ben-Yossef - Co-founder of Codefidence LTD, and co-author of "Building Embedded Linux Systems" * Matt Porter - Long-term kernel contributor, now at Mentor Graphics and previously at MontaVista Software and Motorola Computer Group. * Alex de Vries - Chief Technologist for Wind River Systems * Frank Rowand - Realtime Linux practitioner at Sony Corporation Registration includes access to all sessions, demos, BOF meetings, lunch and snacks each day, and a fun social event Thursday night. To register, please follow the link at: http://www.embeddedlinuxconference.com/elc_europe09/registration1.html If you have any questions, send e-mail to elce...@tree.celinuxforum.org. I hope you can make it! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] printk: provide a filtering macro for printk
Tim Bird wrote:
> Marc Andre Tanner wrote:
>> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>>> Some places in the kernel break the message into pieces, like so:
>>>>
>>>> printk(KERN_ERR, "Error: first part ");
>>>> ...
>>>> printk(" more info for error.\n");
>>> Technically, shouldn't the second part of the message actually be:
>>>
>>> printk(KERN_CONT " more info for error.\n");
>>>
>>> Maybe some mechanism could be created to handle the continued message
>>> if they have the KERN_CONT?
>> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
>> to change that.
>>
>>>> These parts would not be handled consistently under certain
>>>> conditions.
>>>>
>>>> It would be confusing to see only part of the message,
>>>> but I don't know how often this construct is used.
>> $ grep -R KERN_CONT linux-2.6 | wc -l
>> 373
>>
>>>> Maybe
>>>> another mechanism is needed to ensure that continuation
>>>> printk lines have the same log level as their start strings.
>> I currently don't see a way to achieve this with the CPP.
>
> If it's that few, then maybe it's OK to actually change
> the code for those printk statements. (Heck, these locations
> were all changed in the last 2 years anyway.)
>
> I'm just brainstorming here, but how about changing them from:
> printk(KERN_INFO "foo");
> printk(KERN_CONT "bar\n");
> to:
> printk(KERN_INFO "foo");
> printk_cont(KERN_INFO "bar\n");
>
> This way the continuation line has the log level, and can
> be conditionally compiled based on the VERBOSITY level. A little
> magic would be needed to strip the first 3 chars of the fmt
> string in printk_cont().
>
> I think this makes the printk messages a bit more consistent anyway,
> and still marks lines that are continuation lines.
Just another note. Detecting continuation lines also complicates
the printk timestamping code. If all continuation lines were
distinguishable by the printk code, then it might be possible
to simplify the timestamping code as a side effect of the
change.
-- Tim
=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] printk: provide a filtering macro for printk
Marc Andre Tanner wrote:
> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>> Some places in the kernel break the message into pieces, like so:
>>>
>>> printk(KERN_ERR, "Error: first part ");
>>> ...
>>> printk(" more info for error.\n");
>> Technically, shouldn't the second part of the message actually be:
>>
>> printk(KERN_CONT " more info for error.\n");
>>
>> Maybe some mechanism could be created to handle the continued message
>> if they have the KERN_CONT?
>
> Yes it's true that KERN_CONT isn't handled correctly, but I don't see a way
> to change that.
>
>>> These parts would not be handled consistently under certain
>>> conditions.
>>>
>>> It would be confusing to see only part of the message,
>>> but I don't know how often this construct is used.
>
> $ grep -R KERN_CONT linux-2.6 | wc -l
> 373
>
>>> Maybe
>>> another mechanism is needed to ensure that continuation
>>> printk lines have the same log level as their start strings.
>
> I currently don't see a way to achieve this with the CPP.
If it's that few, then maybe it's OK to actually change
the code for those printk statements. (Heck, these locations
were all changed in the last 2 years anyway.)
I'm just brainstorming here, but how about changing them from:
printk(KERN_INFO "foo");
printk(KERN_CONT "bar\n");
to:
printk(KERN_INFO "foo");
printk_cont(KERN_INFO "bar\n");
This way the continuation line has the log level, and can
be conditionally compiled based on the VERBOSITY level. A little
magic would be needed to strip the first 3 chars of the fmt
string in printk_cont().
I think this makes the printk messages a bit more consistent anyway,
and still marks lines that are continuation lines.
>>> But, overall, very slick! It's nice to see a solution that doesn't
>>> require changing all printks statements in the kernel.
>
> Yes that's what I thought too. Thanks to the comments so far the next
> version of the patch will contain even less changes to the rest of the
> kernel.
>
>> I haven't looked over this patch series yet but does it work with the
>> pr_ macros (pr_info, pr_err, etc.)?
>
> It should work, yes.
-- Tim
=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] printk: provide a filtering macro for printk
Marc Andre Tanner wrote:
> The macro filters out printk messages based on a configurable verbosity
> level (CONFIG_PRINTK_VERBOSITY).
>
> Signed-off-by: Marc Andre Tanner
> ---
> include/linux/kernel.h | 24
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index c2b3047..1f5d01f 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -242,6 +242,30 @@ asmlinkage int printk(const char * fmt, ...)
> asmlinkage int printk_unfiltered(const char *fmt, ...)
> __attribute__ ((format (printf, 1, 2))) __cold;
>
> +#if defined(CONFIG_PRINTK_VERBOSITY) && CONFIG_PRINTK_VERBOSITY > 0
> +/*
> + * The idea here is to wrap the actual printk function with a macro which
> + * will filter out all messages above a certain verbosity level. Because
> + * the if condition evaluates to a constant expression the compiler will be
> + * able to eliminate it and the resulting kernel image will be smaller.
> + *
> + * The check with sizeof(void*) should make sure that we don't operate on
> + * pointers, which the compiler wouldn't be able to optimize out, but only
> + * on string constants.
> + */
> +
> +#include
> +
> +#define printk(fmt, ...) ({
> \
> + if (sizeof(fmt) == sizeof(void *) ||
> \
> + (((const char *)(fmt))[0] != '<' && CONFIG_PRINTK_VERBOSITY >= 4)
> || \
> + (((const char *)(fmt))[0] == '<' &&
> \
> + ((const char *)(fmt))[1] <=
> *__stringify(CONFIG_PRINTK_VERBOSITY))) \
> + printk((fmt), ##__VA_ARGS__);
> \
> +})
> +
> +#endif /* CONFIG_PRINTK_VERBOSITY */
> +
> extern struct ratelimit_state printk_ratelimit_state;
> extern int printk_ratelimit(void);
> extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
Some places in the kernel break the message into pieces, like so:
printk(KERN_ERR, "Error: first part ");
...
printk(" more info for error.\n");
These parts would not be handled consistently under certain
conditions.
It would be confusing to see only part of the message,
but I don't know how often this construct is used. Maybe
another mechanism is needed to ensure that continuation
printk lines have the same log level as their start strings.
But, overall, very slick! It's nice to see a solution that doesn't
require changing all printks statements in the kernel.
-- Tim
=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New fast(?)-boot results on ARM
Dirk Behme wrote > Btw.: I tried to summarize some hints given in this thread in > > http://elinux.org/Boot_Time#Boot_time_check_list > > Please feel free to add and correct stuff! That's a great summary of the points raised in the discussion. It's good to organize the information and save it in an easy-to-read format. Thanks very much for doing that! -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ipdelay= option for faster netboot
David Miller wrote: > From: Tim Bird > Date: Mon, 17 Aug 2009 18:24:26 -0700 > >> David Miller wrote: >>> I have card/switch combinations that take up to 10 seconds to >>> negotiate a proper link. >> What types of delays are these timeouts supposed to >> cover? > > The problem is that if you don't first give at least some time for the > link to come up, the remaining time it takes the link to come up will > end up chewing into the actual bootp/dhcp protocol timeouts. And > that's what we're trying to avoid. What link? I'm not that familiar with networking. Assuming I'm using ethernet, what link needs to come up? Is this something to do with power propagation to the physical wire? Is there some MAC layer negotiation between the card and the switch? Is it the time for the switch to do speed detection? And, can any of this be more accurately determined or guessed-at with knowledge of the onboard hardware? Or is it dependent on external conditions? Where would be a good place to find out more about startup delays for networking chips and/or protocols? Our usual solution is to kick the can down the road and let user-space initialize anything that takes a long time, while we do other stuff like focus the camera or display the TV picture. It would be good to learn more about this. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new ipdelay= option for faster netboot
David Miller wrote: > From: Tim Bird > Date: Mon, 17 Aug 2009 15:35:01 -0700 > >> Tim Bird wrote: >>> See the definitions of CONF_PRE_OPEN and CON_POST_OPEN >>> in net/ipv4/ipconfig.c >>> >>> They are set to ridiculously long values. In my experience, >>> you can cut them down considerably with no dangerous side >>> effects (but I haven't asked the network guys about the >>> possible downsides). >> It turns out that others have seen this delay. Simon >> Arlott recently posted a patch to make the delay avoidable >> at boot time from the kernel command line. >> >> See http://patchwork.kernel.org/patch/31678/ > > "Rediculiously long" is a relative term. No offense intended. I could have phrased this better. The delays were a few orders of magnitude longer than apparently needed, on my embedded test systems with ethernet. I didn't try eliminating them completely, as in the Arlott patch. 1.5 seconds is a long time for me. My bootup time budget for the kernel ranges from 0.5 to 3.0 seconds, depending on the product. > I have card/switch combinations that take up to 10 seconds to > negotiate a proper link. What types of delays are these timeouts supposed to cover? Networking delays or hardware bring-up delays? (Or both)? If for networking delays, is this for all types of networks, or just some (e.g. ones that create virtual circuits)? I'm trying to get a sense for whether the card/switch combinations that would take this long would be encountered in the types of embedded devices I code for. (TVs, camcorders, etc.) > > So what's there now is actually a quite agressive setting. > > And BTW, discussions about stuff like this belong on > net...@vger.kernel.org, which has been added to the CC: I was going to wait to see if this solved Robert's problem, before widening the discussion. But I'm happy to find out more about these delays now. Thanks, -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
new ipdelay= option for faster netboot (was Re: New fast(?)-boot results on ARM)
Tim Bird wrote: > See the definitions of CONF_PRE_OPEN and CON_POST_OPEN > in net/ipv4/ipconfig.c > > They are set to ridiculously long values. In my experience, > you can cut them down considerably with no dangerous side > effects (but I haven't asked the network guys about the > possible downsides). It turns out that others have seen this delay. Simon Arlott recently posted a patch to make the delay avoidable at boot time from the kernel command line. See http://patchwork.kernel.org/patch/31678/ -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New fast(?)-boot results on ARM
Robert Schwebel wrote: > On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote: >>> [ �5.082616] < �0.007992> RPC: Registered tcp transport module. >>> [ �5.605159] < �0.522543> eth0: config: auto-negotiation on, 100FDX, >>> 100HDX, 10FDX, 10HDX. >>> [ �6.602621] < �0.997462> IP-Config: Complete: >>> [ �6.606638] < �0.004017> � � �device=eth0, addr=192.168.23.197, >>> mask=255.255.0.0, gw=192.168.23.2, >>> [ �6.614588] < �0.007950> � � �host=192.168.23.197, domain=, >>> nis-domain=(none), >>> [ �6.618652] < �0.004064> � � �bootserver=192.168.23.2, >>> rootserver=192.168.23.2, rootpath= >> Well, this ~1 second is not really kernel's fault, it's DHCP delay. >> But, do you need to do it at this moment? >> You do not seem to be using networking filesystems. >> You can run DHCP client in userspace. > > The board has ip autoconfig configured in, because we also use tftp/nfs > boot for development. But it had been disabled on the commandline: > > ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: > > That shouldn't do dhcp, right? I think it doesn't, but I'm not positive. The DHCP trasmissions themselves don't take very long. There are some very long timeouts in the network code paths, which appear to be used whether you specify a static address or not. See the definitions of CONF_PRE_OPEN and CON_POST_OPEN in net/ipv4/ipconfig.c They are set to ridiculously long values. In my experience, you can cut them down considerably with no dangerous side effects (but I haven't asked the network guys about the possible downsides). Here's a patch which I've used in the past. (Sorry if it doesn't apply cleanly, I just extracted it from a PDF and the whitespace may have gotten messed up. It's short enough that you can hand-edit the files if there's a problem.) I'd like to hear back, if you apply this, whether it shortens the network startup time for you. diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c index 42065ff..e42d83f 100644 --- a/net/ipv4/ipconfig.c +++ b/net/ipv4/ipconfig.c @@ -86,8 +86,10 @@ #endif /* Define the friendly delay before and after opening net devices */ -#define CONF_PRE_OPEN 500 /* Before opening: 1/2 second */ -#define CONF_POST_OPEN 1 /* After opening: 1 second */ +/*#define CONF_PRE_OPEN 500 /* Before opening: 1/2 second */ +/*#define CONF_POST_OPEN 1 /* After opening: 1 second */ +#define CONF_PRE_OPEN 5 /* Before opening: 5 milli seconds */ +#define CONF_POST_OPEN 10 /* After opening: 10 milli seconds */ /* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */ #define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */ @@ -1292,7 +1294,7 @@ static int __init ip_auto_config(void) return -1; /* Give drivers a chance to settle */ - ssleep(CONF_POST_OPEN); + msleep(CONF_POST_OPEN); /* * If the config information is insufficient (e.g., our IP address or = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: flicker free booting
Robert Schwebel wrote: > On Fri, Jul 31, 2009 at 12:48:37PM -0700, Tim Bird wrote: >>> Those fractions-of-seconds boot times are beyond the reach of the >>> 200 MHz-class ARM9 processors and similar, where it takes two or >>> three seconds just to load and uncompress the kernel from NOR or >>> NAND flash. >> While I don't disagree from a practical standpoint - at Sony using XIP >> we have been able to finish kernel boot on a 192 MHZ ARM9 in 186 >> milliseconds. In the lab, anyway? > > Wow, that's pretty fast; if that would be possible for standard > scenarios, it would indeed be better to do everything on the kernel > side. > > Can you elaborate about the details of that experiment? Was that normal > XIP from NOR? What size has this kernel been? This was done quite some time ago, and it looks like my memory was not too good. According to slides I did at the time, it was actually 110 milliseconds. I'm sure this was a 2.4 kernel (likely 2.4.20). I couldn't find the size of the kernel used in the test, but I think it was about 800k, uncompressed. (I'm not positive, though.) It was normal XIP from NOR flash. See slides 21 and 22 in the following: http://elinux.org/images/7/78/ReducingStartupTime_v0.8.pdf Here is some salient data: With Compression W/ O Compression XIP Copy 56 msec 120 msec 0 msec Decompression545 msec0 msec 0 msec Kernel execution 88 msec 88 msec 110 msec Total: 689 msec 208 msec 110 msec Note that copy time went up when going from a compressed to an uncompressed kernel. Decompression time went down (to 0, no surpise). When XIP was used, both copy time and decompression time were eliminated, but kernel execution time for the boot went from 88 msec to 110 msec. So XIP did incur a pretty hefty runtime penalty. Aaahhh, 2.4. The kernel was simpler in those days... :-) -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: flicker free booting
Bill Gatliff wrote: > > Those fractions-of-seconds boot times are beyond the reach of the 200 > MHz-class ARM9 processors and similar, where it takes two or three > seconds just to load and uncompress the kernel from NOR or NAND flash. While I don't disagree from a practical standpoint - at Sony using XIP we have been able to finish kernel boot on a 192 MHZ ARM9 in 186 milliseconds. In the lab, anyway? ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How the kernel printk works before do console_setup.
Johnny Hung wrote: > Hi All: > I have a powerpc arch platform. The default console is ttyS1 not > ttyS0 in the platform. My question is how the kernel print debug > message > like DBG before parse kernel command line and do console_setup > function. The command line passed to kernel about console info is > console=ttyS1. > So kernel can not print anything before parse cmd line and initial > console but the result is against. Anyone point me or give me a clue > is appreciate. Before the console is set up, the printk data is formatted and put into the kernel log buffer, but not sent to any console. Any messages printk'ed before that are buffered but do not appear. When the console is initialized, then all buffered messages are sent to the console, and subsequent printks cause the message to go to the log buffer, but then immediately get sent from there to the console. Under certain conditions you can examine the log buffer of a kernel that failed to initialize it's console, after a warm reset of the machine, using the firmware memory dump command. See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot for some tips on accessing the log buffer of a previous boot. Note also, that if the serial console does not come up, but the kernel successfully boots, and you can get a network login on the machine, you can always print out the kernel log buffer messages using 'dmesg' at a user-space shell prompt. Hope this helps! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: >> block of fast non-volatile RAM that need to access data on it using a >> standard filesytem interface." > > Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > better with ext2. Not if you want the RAM-based filesystem to persist over a kernel invocation. ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: > You are saying top goal is robustness, while the web page says (home > page, stop using frames!): > > "embedded systems have a block of non-volatile RAM seperate from > normal system memory, i.e. of which the kernel maintains no memory > page descriptors. For such systems it would be beneficial to mount a > fast read/write filesystem over this "I/O memory", for storing > frequently accessed data that must survive system reboots and power > cycles" > > Note the "frequently accessed" and "fast". > > IOW the web page is confusing. It does not talk about robustness at > all. OK, thanks. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] Pramfs: Include files
Sam Ravnborg wrote: > It is not that we are talking big and complex stuff here. I agree completely. > pramfs is likely to be used for small things and then having to > fix endian on a few headers in the on-dsk format does not matter. I agree with this, but mostly out of exhaustion. > Not compared to the potential disadvantages. I can see no potential disadvantages. > It should be possible to read a file-system on your x86 64bit > box that you wrote with your small powerpc target. For a (NV)RAM-based filesystem?? WTH??? This is not my file system, so I don't have a dog in this fight. I just wanted to clarify what I thought were some misconceptions about the use cases and priorities for the FS. My "advocacy" may be interfering with understanding this system and its purpose. I'll be quiet now. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: > On Mon 2009-06-22 10:31:28, Tim Bird wrote: >> Pavel Machek wrote: >>> I did not see that in the changelog. If it is not general purpose >>> filesystem, it is lot less interesting. >> PRAMFS is not a general purpose filesystem. Please read >> the introductory post to this thread, or look at >> http://pramfs.sourceforge.net/ for more information. > > Yeah, I seen that. It directly contradicts what you say. Could you be more specific? In what way does the description on the website contradict what I said? >> Since the purpose of PRAMFS is to provide a filesystem >> that is persistent across kernel instantions, it is not >> designed for high speed. Robustness in the face of >> kernel crashes or bugs is the highest priority, so >> PRAMFS has significant overhead to make the window >> of writability to the filesystem RAM as small as possible. > > Really? So why don't you use well known, reliable fs like ext3? Are you sure you read the web site? It directly addresses this question. From the web site: "1. Disk-based filesystems such as ext2/ext3 were designed for optimum performance on spinning disk media, so they implement features such as block groups, which attempts to group inode data into a contiguous set of data blocks to minimize disk seeking when accessing files. For RAM there is no such concern; a file's data blocks can be scattered throughout the media with no access speed penalty at all. So block groups in a filesystem mounted over RAM just adds unnecessary complexity. A better approach is to use a filesystem specifically tailored to RAM media which does away with these disk-based features. This increases the efficient use of space on the media, i.e. more space is dedicated to actual file data storage and less to meta-data needed to maintain that file data." >> This is not a file system one would do kernel compiles on. >> This is where someone would keep a small amount of sensitive >> data, or crash logs that one needed to preserve over kernel >> invocations. > > Really? Web page says: > > #2. If the backing-store RAM is comparable in access speed to system > #memory, there's really no point in caching the file I/O data in the > #page cache. Better to move file data directly between the user buffers > #and the backing store RAM, i.e. use direct I/O. This prevents the > #unnecessary > > So you don't cache it "because its fast", and then it is 13MB/sec? I'm not sure what you're quoting. The paragraph you quoted doesn't have the words "because its fast" [sic]. Speed is not a primary consideration for this filesystem. Due to the overhead of changing the page flags, it's possible that using the page cache would speed up overall access to this filesystem. (This would depend on the cost of changing the access flags, and the pattern of operations on the filesystem.) However, using the page cache would add a level of indirection which would detract from the intended robustness. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: >>> How do you handle hard-links, then? >> Indeed hard-links are not supported :) Due to the design of this fs >> there are some limitations explained in the documentation as not >> hard-link, only private memory mapping and so on. However this >> limitations don't limit the fs itself because you must consider the >> special goal of this fs. > > I did not see that in the changelog. If it is not general purpose > filesystem, it is lot less interesting. PRAMFS is not a general purpose filesystem. Please read the introductory post to this thread, or look at http://pramfs.sourceforge.net/ for more information. Since the purpose of PRAMFS is to provide a filesystem that is persistent across kernel instantions, it is not designed for high speed. Robustness in the face of kernel crashes or bugs is the highest priority, so PRAMFS has significant overhead to make the window of writability to the filesystem RAM as small as possible. This is not a file system one would do kernel compiles on. This is where someone would keep a small amount of sensitive data, or crash logs that one needed to preserve over kernel invocations. > >>>> >From performance point of view: >>>> >>>> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark >>>> results to compare the performance with and without XIP in a real >>>> embedded environment with bonnie++. You could use it as reference point. >>> Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance >>> better than ext2? >>> >>> Wait... those numbers you pointed me... claim to be as slow as >>> 13MB/sec. That's very very bad. My harddrive is faster than that. >> As I said I did the test in a real embedded environment so to have >> comparable result you should use the same environmente with the same >> tools, with the same workload and so on. > > Even on real embedded hardware you should get better than 13MB/sec > writing to _RAM_. I guess something is seriously wrong with pramfs. See above. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Marco wrote: > Tim Bird wrote: >> Marco wrote: >>> This is a second attempt at mainlining Pramfs. The first attempt was >>> back in early 2004 by MontaVista. Since then the kernel code has almost >>> been completely rewritten. So my first item on the list was porting the >>> code on a recent kernel version. After that I added the XIP support. >> It's very nice to see this technology revived. >> >> Is the information at: >> http://pramfs.sourceforge.net/ >> and >> http://pramfs.sourceforge.net/pramfs-spec.html >> still valid - particularly the latter? > > Yep. at 99%. I've done some modifications due to the porting and there > will be some ones due to this review. I tried to talk with Steve > Longerbeam to update the site but without success. I'd like to update it. > >> It would be very nice to see this get mainlined. I believe that >> one of the main uses for this is to store crash information >> over a reboot so the next kernel (not in crashing state) can have >> a better chance of dealing with it. As such, I think >> it's important to keep the code paths for Pramfs short, synchronous, >> and unentangled with other kernel systems (block IO, page cache, etc.). >> > > Yes, I quite agree. I think that this kind of feature would be very > useful especially for the embedded world. Just FYI - we have an "exception monitor" at Sony which is used in several projects, that records application and kernel crash information into the file system, for subsequent (often in-field) analysis. However, the data currently gets written to a flash filesystem and the logs sometimes get truncated or otherwise corrupted. This seems like a perfect match for what we're trying to do. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Marco wrote: > This is a second attempt at mainlining Pramfs. The first attempt was > back in early 2004 by MontaVista. Since then the kernel code has almost > been completely rewritten. So my first item on the list was porting the > code on a recent kernel version. After that I added the XIP support. It's very nice to see this technology revived. Is the information at: http://pramfs.sourceforge.net/ and http://pramfs.sourceforge.net/pramfs-spec.html still valid - particularly the latter? It would be very nice to see this get mainlined. I believe that one of the main uses for this is to store crash information over a reboot so the next kernel (not in crashing state) can have a better chance of dealing with it. As such, I think it's important to keep the code paths for Pramfs short, synchronous, and unentangled with other kernel systems (block IO, page cache, etc.). Thanks, -- Tim ===== Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
