* RE: [PATCH] [RFC] emit-crash-char: Allow diversion of printkoutput for crash logging
From: Haller, John H (John) @ 2008-08-08 21:24 UTC (permalink / raw)
To: Daniel Walker, Mike Frysinger; +Cc: dvomlehn, linux-embedded
In-Reply-To: <1218228464.19162.194.camel@localhost.localdomain>
> On Fri, 2008-08-08 at 16:13 -0400, Mike Frysinger wrote:
>
> > same sort of things as the point of David's code. early/crash
> > scenarios for people to safely extract portions of the kernel log
> > buffer for transmission/storage elsewhere. as was explained in the
> > original thread behind the commit.
>
> How is that code suppose to help anyone if you aren't calling it from
> anyplace in the kernel? Clearly your using it, right? Where
> is the code
> your calling these functions from?
>
> Daniel
Not that it was in the patch, but netconsole would be an
obvious potential user. It would be most useful in board
specific startup code such as arch/ppc/platforms, where
a particular board might have a place to put information
like this for later retrieval. One would hope that such
board specific file would be forthcoming, rather than be
maintained out-of-tree.
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Daniel Walker @ 2008-08-08 20:47 UTC (permalink / raw)
To: Mike Frysinger; +Cc: dvomlehn, linux-embedded
In-Reply-To: <8bd0f97a0808081313v4df788b9xcd25308ca64b0862@mail.gmail.com>
On Fri, 2008-08-08 at 16:13 -0400, Mike Frysinger wrote:
> same sort of things as the point of David's code. early/crash
> scenarios for people to safely extract portions of the kernel log
> buffer for transmission/storage elsewhere. as was explained in the
> original thread behind the commit.
How is that code suppose to help anyone if you aren't calling it from
anyplace in the kernel? Clearly your using it, right? Where is the code
your calling these functions from?
Daniel
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Mike Frysinger @ 2008-08-08 20:13 UTC (permalink / raw)
To: Daniel Walker; +Cc: dvomlehn, linux-embedded
In-Reply-To: <1218226225.19162.189.camel@localhost.localdomain>
On Fri, Aug 8, 2008 at 4:10 PM, Daniel Walker wrote:
> On Fri, 2008-08-08 at 14:09 -0400, Mike Frysinger wrote:
>> > I invite you to give some of the "plenty of
>> > examples in the tree", you might surprise me..
>>
>> look at all the new syscalls added without any userspace code in place
>> (still) to use it. or Linus' recent printk modifier extension. or my
>> printk extensions for extracting portions of the kernel log buffer.
>> people usually submit interfaces with backend extesions, or the intent
>> to use it is obvious.
>
> Syscalls and Userspace are unrelated .. You clearly can't add userspace
> code to the kernel .. If you add a _kernel_ interface like David has
> done you need at least one user of the interface.. Otherwise it's just
> plain bloat inside the kernel which no one wants.
>
> Your changes for extracting part of the kernel log buffer (commit
> 0b15d04af3dd996035d8fa81fc849d049171f9c3),
>
> with:
> text data bss dec hex filename
> 4322000 386760 2592768 7301528 6f6998 vmlinux
> without:
> text data bss dec hex filename
> 4321876 386760 2592768 7301404 6f691c vmlinux
>
> Adds roughly 120bytes of bloat to my kernel, since 2007 .. What's the
> point? I grepped for users , and there are none ..
same sort of things as the point of David's code. early/crash
scenarios for people to safely extract portions of the kernel log
buffer for transmission/storage elsewhere. as was explained in the
original thread behind the commit.
-mike
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Daniel Walker @ 2008-08-08 20:10 UTC (permalink / raw)
To: Mike Frysinger; +Cc: dvomlehn, linux-embedded
In-Reply-To: <8bd0f97a0808081109q693f6f1at650a9be0547b7f9b@mail.gmail.com>
On Fri, 2008-08-08 at 14:09 -0400, Mike Frysinger wrote:
> you said "usually people submit new interfaces", not "it is usually
> not accepted without at least one user".
Well, usually people do submit the users, and if they don't it's usually
not accepted..
> > I invite you to give some of the "plenty of
> > examples in the tree", you might surprise me..
>
> look at all the new syscalls added without any userspace code in place
> (still) to use it. or Linus' recent printk modifier extension. or my
> printk extensions for extracting portions of the kernel log buffer.
> people usually submit interfaces with backend extesions, or the intent
> to use it is obvious.
Syscalls and Userspace are unrelated .. You clearly can't add userspace
code to the kernel .. If you add a _kernel_ interface like David has
done you need at least one user of the interface.. Otherwise it's just
plain bloat inside the kernel which no one wants.
Your changes for extracting part of the kernel log buffer (commit
0b15d04af3dd996035d8fa81fc849d049171f9c3),
with:
text data bss dec hex filename
4322000 386760 2592768 7301528 6f6998 vmlinux
without:
text data bss dec hex filename
4321876 386760 2592768 7301404 6f691c vmlinux
Adds roughly 120bytes of bloat to my kernel, since 2007 .. What's the
point? I grepped for users , and there are none ..
Daniel
^ permalink raw reply
* Re: initrd and uImage
From: Robert Schwebel @ 2008-08-08 18:16 UTC (permalink / raw)
To: Fundu; +Cc: linux-embedded
In-Reply-To: <54582.81328.qm@web63407.mail.re1.yahoo.com>
On Fri, Aug 08, 2008 at 09:42:41AM -0700, Fundu wrote:
> First off i have a ppc based board.
> and i'm trying to load a kernel image with ramdisk rootfs.
Why? You can also boot your root fs for example directly from a flash
partition.
> i have build the kernel. it spit uImage,zImage and vmlinux.gz
That depends on your build system ...
> my question are.
> 1) what are all the different image types ?
> i know the uImage is just the kernel, what are the rest (zImage & vmlinux.gz)?
An uImage can contain a kernel but also other things. Please check the
U-Boot documentation for more details.
zImage and vmlinux.gz are kernel images. You usually need only one of
them, but the details do surely depend also on your build system.
> 2) i'm using u-boot as the bootldr. so i download the uImage (cause
> zImage and vmlinux.gz aren't bootlable) from tftp server and then do
> bootm <address> the kernel only load partially. How does the kernel
> know where/how to load the rootfs ?
In U-Boot you can add a kernel command line by setting the bootargs
environment variable.
It's probably a good idea to start reading the U-Boot documentation, or
whatever came with your board support package.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Perl removal patch for 2.6.26.
From: Rob Landley @ 2008-08-08 18:13 UTC (permalink / raw)
To: Embedded Linux mailing list
[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]
A patch in 2.6.25 added perl as a build requirement for the Linux kernel, by
making the file kernel/timeconst.h generated by a perl script.
Oddly, the perl script in question tested whether or not you had _enough_ perl
installed, and if you didn't have an optional bignum package out of cpan it
checked if the HZ value you wanted to generate #defines for matched one of 15
cached values it had precomputed numbers for. (This cached information took
up half the perl file).
These values are in fact all the ones currently used by the Linux kernel.
Every HZ value for every platform is set by a kconfig choice menu, so the
only way to add a new HZ value is modify the kernel source. After 17 years,
with hundreds of target boards, there are currently 15 only values in use.
This patch moves the cache out of the perl program and instead pregenerates a
kernel/timeconst.h file, which it checks in. The start of that file is:
> /* Conversion constants for HZ */
> /* DO NOT EDIT! Automatically generated by:
> kernel/timeconst.pl 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024
1200
> */
I.E. it gives you the command line to run to regenerate the file. If you need
to add another value, cut and paste that command line to generate a new
timeconst.h file, and submit the diff. (Note that the perl script records
the command line it was run with automatically, that will be part of the
diff.)
This patch:
1) Removes half the perl script (all the conditional cached stuff). The
result is a much smaller and simpler perl script.
2) Changes the perl script to generate a single include file with 15 #ifdefs
rather than generating an #include file with the one HZ value currently
selected by kconfig. (The last #else case #errors out with the existing
error message about an unknown HZ value.)
3) Removes all mention of kernel/timeconst.h from the makefiles. They don't
need to know anymore.
The only other potential change (which I didn't make) is to move
kernel/timeconst.pl into scripts/timeconst.pl, since it's now in the same
class with the python script bloat-o-meter; something developers can run but
which is not required to simply compile an unmodified kernel tarball.
Comments welcome.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
[-- Attachment #2: linux-2.6.26-noperl.patch --]
[-- Type: text/x-diff, Size: 20735 bytes --]
diff -ru linux-2.6.26/kernel/Makefile linux-2.6.26-new/kernel/Makefile
--- linux-2.6.26/kernel/Makefile 2008-07-13 16:51:29.000000000 -0500
+++ linux-2.6.26-new/kernel/Makefile 2008-07-25 11:46:15.000000000 -0500
@@ -95,8 +95,3 @@
$(obj)/time.o: $(obj)/timeconst.h
-quiet_cmd_timeconst = TIMEC $@
- cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@
-targets += timeconst.h
-$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
- $(call if_changed,timeconst)
diff -ru linux-2.6.26/kernel/timeconst.pl linux-2.6.26-new/kernel/timeconst.pl
--- linux-2.6.26/kernel/timeconst.pl 2008-07-13 16:51:29.000000000 -0500
+++ linux-2.6.26-new/kernel/timeconst.pl 2008-07-25 12:01:27.000000000 -0500
@@ -11,150 +11,12 @@
#
#
-# Usage: timeconst.pl HZ > timeconst.h
+# Usage: timeconst.pl HZ... > timeconst.h
#
# Precomputed values for systems without Math::BigInt
# Generated by:
# timeconst.pl --can 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200
-%canned_values = (
- 24 => [
- '0xa6aaaaab','0x2aaaaaa',26,
- 125,3,
- '0xc49ba5e4','0x1fbe76c8b4',37,
- 3,125,
- '0xa2c2aaab','0xaaaa',16,
- 125000,3,
- '0xc9539b89','0x7fffbce4217d',47,
- 3,125000,
- ], 32 => [
- '0xfa000000','0x6000000',27,
- 125,4,
- '0x83126e98','0xfdf3b645a',36,
- 4,125,
- '0xf4240000','0x0',17,
- 31250,1,
- '0x8637bd06','0x3fff79c842fa',46,
- 1,31250,
- ], 48 => [
- '0xa6aaaaab','0x6aaaaaa',27,
- 125,6,
- '0xc49ba5e4','0xfdf3b645a',36,
- 6,125,
- '0xa2c2aaab','0x15555',17,
- 62500,3,
- '0xc9539b89','0x3fffbce4217d',46,
- 3,62500,
- ], 64 => [
- '0xfa000000','0xe000000',28,
- 125,8,
- '0x83126e98','0x7ef9db22d',35,
- 8,125,
- '0xf4240000','0x0',18,
- 15625,1,
- '0x8637bd06','0x1fff79c842fa',45,
- 1,15625,
- ], 100 => [
- '0xa0000000','0x0',28,
- 10,1,
- '0xcccccccd','0x733333333',35,
- 1,10,
- '0x9c400000','0x0',18,
- 10000,1,
- '0xd1b71759','0x1fff2e48e8a7',45,
- 1,10000,
- ], 122 => [
- '0x8325c53f','0xfbcda3a',28,
- 500,61,
- '0xf9db22d1','0x7fbe76c8b',35,
- 61,500,
- '0x8012e2a0','0x3ef36',18,
- 500000,61,
- '0xffda4053','0x1ffffbce4217',45,
- 61,500000,
- ], 128 => [
- '0xfa000000','0x1e000000',29,
- 125,16,
- '0x83126e98','0x3f7ced916',34,
- 16,125,
- '0xf4240000','0x40000',19,
- 15625,2,
- '0x8637bd06','0xfffbce4217d',44,
- 2,15625,
- ], 200 => [
- '0xa0000000','0x0',29,
- 5,1,
- '0xcccccccd','0x333333333',34,
- 1,5,
- '0x9c400000','0x0',19,
- 5000,1,
- '0xd1b71759','0xfff2e48e8a7',44,
- 1,5000,
- ], 250 => [
- '0x80000000','0x0',29,
- 4,1,
- '0x80000000','0x180000000',33,
- 1,4,
- '0xfa000000','0x0',20,
- 4000,1,
- '0x83126e98','0x7ff7ced9168',43,
- 1,4000,
- ], 256 => [
- '0xfa000000','0x3e000000',30,
- 125,32,
- '0x83126e98','0x1fbe76c8b',33,
- 32,125,
- '0xf4240000','0xc0000',20,
- 15625,4,
- '0x8637bd06','0x7ffde7210be',43,
- 4,15625,
- ], 300 => [
- '0xd5555556','0x2aaaaaaa',30,
- 10,3,
- '0x9999999a','0x1cccccccc',33,
- 3,10,
- '0xd0555556','0xaaaaa',20,
- 10000,3,
- '0x9d495183','0x7ffcb923a29',43,
- 3,10000,
- ], 512 => [
- '0xfa000000','0x7e000000',31,
- 125,64,
- '0x83126e98','0xfdf3b645',32,
- 64,125,
- '0xf4240000','0x1c0000',21,
- 15625,8,
- '0x8637bd06','0x3ffef39085f',42,
- 8,15625,
- ], 1000 => [
- '0x80000000','0x0',31,
- 1,1,
- '0x80000000','0x0',31,
- 1,1,
- '0xfa000000','0x0',22,
- 1000,1,
- '0x83126e98','0x1ff7ced9168',41,
- 1,1000,
- ], 1024 => [
- '0xfa000000','0xfe000000',32,
- 125,128,
- '0x83126e98','0x7ef9db22',31,
- 128,125,
- '0xf4240000','0x3c0000',22,
- 15625,16,
- '0x8637bd06','0x1fff79c842f',41,
- 16,15625,
- ], 1200 => [
- '0xd5555556','0xd5555555',32,
- 5,6,
- '0x9999999a','0x66666666',31,
- 6,5,
- '0xd0555556','0x2aaaaa',22,
- 2500,3,
- '0x9d495183','0x1ffcb923a29',41,
- 3,2500,
- ]
-);
$has_bigint = eval 'use Math::BigInt qw(bgcd); 1;';
@@ -252,8 +114,7 @@
my $s, $m, $a, $g;
if (!$has_bigint) {
- die "$0: HZ == $hz not canned and ".
- "Math::BigInt not available\n";
+ die "$0: Math::BigInt not available\n";
}
# MSEC conversions
@@ -283,21 +144,7 @@
my($hz, @val) = @_;
my $pfx, $bit, $suf, $s, $m, $a;
- print "/* Automatically generated by kernel/timeconst.pl */\n";
- print "/* Conversion constants for HZ == $hz */\n";
- print "\n";
- print "#ifndef KERNEL_TIMECONST_H\n";
- print "#define KERNEL_TIMECONST_H\n";
- print "\n";
-
- print "#include <linux/param.h>\n";
- print "#include <linux/types.h>\n";
-
- print "\n";
- print "#if HZ != $hz\n";
- print "#error \"kernel/timeconst.h has the wrong HZ value!\"\n";
- print "#endif\n";
- print "\n";
+ print "HZ == $hz\n";
foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ',
'HZ_TO_USEC','USEC_TO_HZ') {
@@ -311,8 +158,7 @@
}
}
- print "\n";
- print "#endif /* KERNEL_TIMECONST_H */\n";
+ print "\n#elif ";
}
# Pretty-print Perl values
@@ -332,47 +178,36 @@
return join(',', @l);
}
-($hz) = @ARGV;
+print "/* Conversion constants for HZ */\n";
+print "/* DO NOT EDIT! Automatically generated by:\n";
+print " kernel/timeconst.pl @ARGV\n */\n";
+print "\n";
+print "#ifndef KERNEL_TIMECONST_H\n";
+print "#define KERNEL_TIMECONST_H\n";
+print "\n";
+
+print "#include <linux/param.h>\n";
+print "#include <linux/types.h>\n";
+
+print "\n";
+print "#if ";
+
+foreach $hz (@ARGV)
+{
-# Use this to generate the %canned_values structure
-if ($hz eq '--can') {
- shift(@ARGV);
- @hzlist = sort {$a <=> $b} (@ARGV);
-
- print "# Precomputed values for systems without Math::BigInt\n";
- print "# Generated by:\n";
- print "# timeconst.pl --can ", join(' ', @hzlist), "\n";
- print "\%canned_values = (\n";
- my $pf = "\t";
- foreach $hz (@hzlist) {
- my @values = compute_values($hz);
- print "$pf$hz => [\n";
- while (scalar(@values)) {
- my $bit;
- foreach $bit (32) {
- my $m = shift(@values);
- my $a = shift(@values);
- my $s = shift(@values);
- print "\t\t", perlvals($m,$a,$s), ",\n";
- }
- my $n = shift(@values);
- my $d = shift(@values);
- print "\t\t", perlvals($n,$d), ",\n";
- }
- print "\t]";
- $pf = ', ';
- }
- print "\n);\n";
-} else {
$hz += 0; # Force to number
if ($hz < 1) {
die "Usage: $0 HZ\n";
}
- @val = @{$canned_values{$hz}};
- if (!defined(@val)) {
- @val = compute_values($hz);
- }
+ @val = compute_values($hz);
output($hz, @val);
}
+
+print "1\n";
+print "#error \"kernel/timeconst.h has unknown HZ value!\"\n";
+print "#endif\n";
+print "\n";
+print "#endif /* KERNEL_TIMECONST_H */\n";
+
exit 0;
--- /dev/null 2007-10-16 17:06:33.000000000 -0500
+++ linux-2.6.26-new/kernel/timeconst.h 2008-07-25 12:02:02.000000000 -0500
@@ -0,0 +1,346 @@
+/* Conversion constants for HZ */
+/* DO NOT EDIT! Automatically generated by:
+ kernel/timeconst.pl 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200
+ */
+
+#ifndef KERNEL_TIMECONST_H
+#define KERNEL_TIMECONST_H
+
+#include <linux/param.h>
+#include <linux/types.h>
+
+#if HZ == 24
+#define HZ_TO_MSEC_MUL32 U64_C(0xa6aaaaab)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x2aaaaaa)
+#define HZ_TO_MSEC_SHR32 26
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(3)
+#define MSEC_TO_HZ_MUL32 U64_C(0xc49ba5e4)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x1fbe76c8b4)
+#define MSEC_TO_HZ_SHR32 37
+#define MSEC_TO_HZ_NUM U64_C(3)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xa2c2aaab)
+#define HZ_TO_USEC_ADJ32 U64_C(0xaaaa)
+#define HZ_TO_USEC_SHR32 16
+#define HZ_TO_USEC_NUM U64_C(125000)
+#define HZ_TO_USEC_DEN U64_C(3)
+#define USEC_TO_HZ_MUL32 U64_C(0xc9539b89)
+#define USEC_TO_HZ_ADJ32 U64_C(0x7fffbce4217d)
+#define USEC_TO_HZ_SHR32 47
+#define USEC_TO_HZ_NUM U64_C(3)
+#define USEC_TO_HZ_DEN U64_C(125000)
+
+#elif HZ == 32
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x6000000)
+#define HZ_TO_MSEC_SHR32 27
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(4)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0xfdf3b645a)
+#define MSEC_TO_HZ_SHR32 36
+#define MSEC_TO_HZ_NUM U64_C(4)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 17
+#define HZ_TO_USEC_NUM U64_C(31250)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0x3fff79c842fa)
+#define USEC_TO_HZ_SHR32 46
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(31250)
+
+#elif HZ == 48
+#define HZ_TO_MSEC_MUL32 U64_C(0xa6aaaaab)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x6aaaaaa)
+#define HZ_TO_MSEC_SHR32 27
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(6)
+#define MSEC_TO_HZ_MUL32 U64_C(0xc49ba5e4)
+#define MSEC_TO_HZ_ADJ32 U64_C(0xfdf3b645a)
+#define MSEC_TO_HZ_SHR32 36
+#define MSEC_TO_HZ_NUM U64_C(6)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xa2c2aaab)
+#define HZ_TO_USEC_ADJ32 U64_C(0x15555)
+#define HZ_TO_USEC_SHR32 17
+#define HZ_TO_USEC_NUM U64_C(62500)
+#define HZ_TO_USEC_DEN U64_C(3)
+#define USEC_TO_HZ_MUL32 U64_C(0xc9539b89)
+#define USEC_TO_HZ_ADJ32 U64_C(0x3fffbce4217d)
+#define USEC_TO_HZ_SHR32 46
+#define USEC_TO_HZ_NUM U64_C(3)
+#define USEC_TO_HZ_DEN U64_C(62500)
+
+#elif HZ == 64
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0xe000000)
+#define HZ_TO_MSEC_SHR32 28
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(8)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x7ef9db22d)
+#define MSEC_TO_HZ_SHR32 35
+#define MSEC_TO_HZ_NUM U64_C(8)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 18
+#define HZ_TO_USEC_NUM U64_C(15625)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1fff79c842fa)
+#define USEC_TO_HZ_SHR32 45
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(15625)
+
+#elif HZ == 100
+#define HZ_TO_MSEC_MUL32 U64_C(0xa0000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x0)
+#define HZ_TO_MSEC_SHR32 28
+#define HZ_TO_MSEC_NUM U64_C(10)
+#define HZ_TO_MSEC_DEN U64_C(1)
+#define MSEC_TO_HZ_MUL32 U64_C(0xcccccccd)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x733333333)
+#define MSEC_TO_HZ_SHR32 35
+#define MSEC_TO_HZ_NUM U64_C(1)
+#define MSEC_TO_HZ_DEN U64_C(10)
+#define HZ_TO_USEC_MUL32 U64_C(0x9c400000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 18
+#define HZ_TO_USEC_NUM U64_C(10000)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0xd1b71759)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1fff2e48e8a7)
+#define USEC_TO_HZ_SHR32 45
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(10000)
+
+#elif HZ == 122
+#define HZ_TO_MSEC_MUL32 U64_C(0x8325c53f)
+#define HZ_TO_MSEC_ADJ32 U64_C(0xfbcda3a)
+#define HZ_TO_MSEC_SHR32 28
+#define HZ_TO_MSEC_NUM U64_C(500)
+#define HZ_TO_MSEC_DEN U64_C(61)
+#define MSEC_TO_HZ_MUL32 U64_C(0xf9db22d1)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x7fbe76c8b)
+#define MSEC_TO_HZ_SHR32 35
+#define MSEC_TO_HZ_NUM U64_C(61)
+#define MSEC_TO_HZ_DEN U64_C(500)
+#define HZ_TO_USEC_MUL32 U64_C(0x8012e2a0)
+#define HZ_TO_USEC_ADJ32 U64_C(0x3ef36)
+#define HZ_TO_USEC_SHR32 18
+#define HZ_TO_USEC_NUM U64_C(500000)
+#define HZ_TO_USEC_DEN U64_C(61)
+#define USEC_TO_HZ_MUL32 U64_C(0xffda4053)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1ffffbce4217)
+#define USEC_TO_HZ_SHR32 45
+#define USEC_TO_HZ_NUM U64_C(61)
+#define USEC_TO_HZ_DEN U64_C(500000)
+
+#elif HZ == 128
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x1e000000)
+#define HZ_TO_MSEC_SHR32 29
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(16)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x3f7ced916)
+#define MSEC_TO_HZ_SHR32 34
+#define MSEC_TO_HZ_NUM U64_C(16)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x40000)
+#define HZ_TO_USEC_SHR32 19
+#define HZ_TO_USEC_NUM U64_C(15625)
+#define HZ_TO_USEC_DEN U64_C(2)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0xfffbce4217d)
+#define USEC_TO_HZ_SHR32 44
+#define USEC_TO_HZ_NUM U64_C(2)
+#define USEC_TO_HZ_DEN U64_C(15625)
+
+#elif HZ == 200
+#define HZ_TO_MSEC_MUL32 U64_C(0xa0000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x0)
+#define HZ_TO_MSEC_SHR32 29
+#define HZ_TO_MSEC_NUM U64_C(5)
+#define HZ_TO_MSEC_DEN U64_C(1)
+#define MSEC_TO_HZ_MUL32 U64_C(0xcccccccd)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x333333333)
+#define MSEC_TO_HZ_SHR32 34
+#define MSEC_TO_HZ_NUM U64_C(1)
+#define MSEC_TO_HZ_DEN U64_C(5)
+#define HZ_TO_USEC_MUL32 U64_C(0x9c400000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 19
+#define HZ_TO_USEC_NUM U64_C(5000)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0xd1b71759)
+#define USEC_TO_HZ_ADJ32 U64_C(0xfff2e48e8a7)
+#define USEC_TO_HZ_SHR32 44
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(5000)
+
+#elif HZ == 250
+#define HZ_TO_MSEC_MUL32 U64_C(0x80000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x0)
+#define HZ_TO_MSEC_SHR32 29
+#define HZ_TO_MSEC_NUM U64_C(4)
+#define HZ_TO_MSEC_DEN U64_C(1)
+#define MSEC_TO_HZ_MUL32 U64_C(0x80000000)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x180000000)
+#define MSEC_TO_HZ_SHR32 33
+#define MSEC_TO_HZ_NUM U64_C(1)
+#define MSEC_TO_HZ_DEN U64_C(4)
+#define HZ_TO_USEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 20
+#define HZ_TO_USEC_NUM U64_C(4000)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define USEC_TO_HZ_ADJ32 U64_C(0x7ff7ced9168)
+#define USEC_TO_HZ_SHR32 43
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(4000)
+
+#elif HZ == 256
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x3e000000)
+#define HZ_TO_MSEC_SHR32 30
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(32)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x1fbe76c8b)
+#define MSEC_TO_HZ_SHR32 33
+#define MSEC_TO_HZ_NUM U64_C(32)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0xc0000)
+#define HZ_TO_USEC_SHR32 20
+#define HZ_TO_USEC_NUM U64_C(15625)
+#define HZ_TO_USEC_DEN U64_C(4)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0x7ffde7210be)
+#define USEC_TO_HZ_SHR32 43
+#define USEC_TO_HZ_NUM U64_C(4)
+#define USEC_TO_HZ_DEN U64_C(15625)
+
+#elif HZ == 300
+#define HZ_TO_MSEC_MUL32 U64_C(0xd5555556)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x2aaaaaaa)
+#define HZ_TO_MSEC_SHR32 30
+#define HZ_TO_MSEC_NUM U64_C(10)
+#define HZ_TO_MSEC_DEN U64_C(3)
+#define MSEC_TO_HZ_MUL32 U64_C(0x9999999a)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x1cccccccc)
+#define MSEC_TO_HZ_SHR32 33
+#define MSEC_TO_HZ_NUM U64_C(3)
+#define MSEC_TO_HZ_DEN U64_C(10)
+#define HZ_TO_USEC_MUL32 U64_C(0xd0555556)
+#define HZ_TO_USEC_ADJ32 U64_C(0xaaaaa)
+#define HZ_TO_USEC_SHR32 20
+#define HZ_TO_USEC_NUM U64_C(10000)
+#define HZ_TO_USEC_DEN U64_C(3)
+#define USEC_TO_HZ_MUL32 U64_C(0x9d495183)
+#define USEC_TO_HZ_ADJ32 U64_C(0x7ffcb923a29)
+#define USEC_TO_HZ_SHR32 43
+#define USEC_TO_HZ_NUM U64_C(3)
+#define USEC_TO_HZ_DEN U64_C(10000)
+
+#elif HZ == 512
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x7e000000)
+#define HZ_TO_MSEC_SHR32 31
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(64)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0xfdf3b645)
+#define MSEC_TO_HZ_SHR32 32
+#define MSEC_TO_HZ_NUM U64_C(64)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x1c0000)
+#define HZ_TO_USEC_SHR32 21
+#define HZ_TO_USEC_NUM U64_C(15625)
+#define HZ_TO_USEC_DEN U64_C(8)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0x3ffef39085f)
+#define USEC_TO_HZ_SHR32 42
+#define USEC_TO_HZ_NUM U64_C(8)
+#define USEC_TO_HZ_DEN U64_C(15625)
+
+#elif HZ == 1000
+#define HZ_TO_MSEC_MUL32 U64_C(0x80000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0x0)
+#define HZ_TO_MSEC_SHR32 31
+#define HZ_TO_MSEC_NUM U64_C(1)
+#define HZ_TO_MSEC_DEN U64_C(1)
+#define MSEC_TO_HZ_MUL32 U64_C(0x80000000)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x0)
+#define MSEC_TO_HZ_SHR32 31
+#define MSEC_TO_HZ_NUM U64_C(1)
+#define MSEC_TO_HZ_DEN U64_C(1)
+#define HZ_TO_USEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x0)
+#define HZ_TO_USEC_SHR32 22
+#define HZ_TO_USEC_NUM U64_C(1000)
+#define HZ_TO_USEC_DEN U64_C(1)
+#define USEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1ff7ced9168)
+#define USEC_TO_HZ_SHR32 41
+#define USEC_TO_HZ_NUM U64_C(1)
+#define USEC_TO_HZ_DEN U64_C(1000)
+
+#elif HZ == 1024
+#define HZ_TO_MSEC_MUL32 U64_C(0xfa000000)
+#define HZ_TO_MSEC_ADJ32 U64_C(0xfe000000)
+#define HZ_TO_MSEC_SHR32 32
+#define HZ_TO_MSEC_NUM U64_C(125)
+#define HZ_TO_MSEC_DEN U64_C(128)
+#define MSEC_TO_HZ_MUL32 U64_C(0x83126e98)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x7ef9db22)
+#define MSEC_TO_HZ_SHR32 31
+#define MSEC_TO_HZ_NUM U64_C(128)
+#define MSEC_TO_HZ_DEN U64_C(125)
+#define HZ_TO_USEC_MUL32 U64_C(0xf4240000)
+#define HZ_TO_USEC_ADJ32 U64_C(0x3c0000)
+#define HZ_TO_USEC_SHR32 22
+#define HZ_TO_USEC_NUM U64_C(15625)
+#define HZ_TO_USEC_DEN U64_C(16)
+#define USEC_TO_HZ_MUL32 U64_C(0x8637bd06)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1fff79c842f)
+#define USEC_TO_HZ_SHR32 41
+#define USEC_TO_HZ_NUM U64_C(16)
+#define USEC_TO_HZ_DEN U64_C(15625)
+
+#elif HZ == 1200
+#define HZ_TO_MSEC_MUL32 U64_C(0xd5555556)
+#define HZ_TO_MSEC_ADJ32 U64_C(0xd5555555)
+#define HZ_TO_MSEC_SHR32 32
+#define HZ_TO_MSEC_NUM U64_C(5)
+#define HZ_TO_MSEC_DEN U64_C(6)
+#define MSEC_TO_HZ_MUL32 U64_C(0x9999999a)
+#define MSEC_TO_HZ_ADJ32 U64_C(0x66666666)
+#define MSEC_TO_HZ_SHR32 31
+#define MSEC_TO_HZ_NUM U64_C(6)
+#define MSEC_TO_HZ_DEN U64_C(5)
+#define HZ_TO_USEC_MUL32 U64_C(0xd0555556)
+#define HZ_TO_USEC_ADJ32 U64_C(0x2aaaaa)
+#define HZ_TO_USEC_SHR32 22
+#define HZ_TO_USEC_NUM U64_C(2500)
+#define HZ_TO_USEC_DEN U64_C(3)
+#define USEC_TO_HZ_MUL32 U64_C(0x9d495183)
+#define USEC_TO_HZ_ADJ32 U64_C(0x1ffcb923a29)
+#define USEC_TO_HZ_SHR32 41
+#define USEC_TO_HZ_NUM U64_C(3)
+#define USEC_TO_HZ_DEN U64_C(2500)
+
+#elif 1
+#error "kernel/timeconst.h has unknown HZ value!"
+#endif
+
+#endif /* KERNEL_TIMECONST_H */
^ permalink raw reply
* Re: linux under emulator
From: Rob Landley @ 2008-08-08 18:12 UTC (permalink / raw)
To: Grant Likely; +Cc: Mihaela Grigore, linux-embedded
In-Reply-To: <fa686aa40808051030g5aeaf166q6146014e30b80982@mail.gmail.com>
On Tuesday 05 August 2008 12:30:45 Grant Likely wrote:
> On Tue, Aug 5, 2008 at 11:28 AM, Mihaela Grigore
>
> <grigore.mihaela@gmail.com> wrote:
> > If I intend to run a 2.6 linux kernel under a powerpc emulator, what
> > is needed to make a minimal bootable system? I mean, apart from the
> > kernel itself and busybox, do I need a bootloader ? If no actual
> > hardware is used and the kernel can reside directly in ram from the
> > emulator's point of view (so no relocation is needed), what else is to
> > be done before the kernel can start running ?
>
> Look at the firmware linux documentation. It should tell you
> everything you need.
I'm actually rewriting the documentation. It could be made to suck less.
Currently http://landley.net/code/firmware/downloads/README is more or less in
final form, but the about.html and the design.html pages are somewhere
between "in flux" and "in pieces". (Working on it...)
I try to answer questions promptly, though. :)
> http://www.landley.net/code/firmware/
If you want to be lazy and try out the prebuilt binaries, you can also grab:
http://landley.net/code/firmware/downloads/binaries/system-image/system-image-powerpc.tar.bz2
Extract it, and ./run-emulator.sh (or ./run-with-home.sh if you'd like a 2 gig
hdb image attached on /home so you have some scratch space to build stuff
with.) Installing qemu 0.9.1 is left as an exercise to the reader.
Rob
P.S. Things you don't actually need to know, but just in case:
The sucker is a complete native build environment, gcc and everything. It's
set up like a Linux From Scratch chapter 6 "intermediate" system, with only
the /tools directory existing by default, so you can build a new system
without traces of the old one cluttering it up. The boot script
(/tools/bin/qemu-setup.sh) creates a bunch of symlinks and empty mount point
directories at the top level to make the system behave like a normal build
environment, so you can actually compile stuff and it should work. See
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/chapter06.html for
details on that.
If you want to use the distcc acceleration trick to compile stuff (calling out
to the cross compiler from inside qemu, so whatever you're compiling still
acts like fully native build but isn't _quite_ as painfully slow about it),
grab cross-compiler-powerpc.tar.bz2 from the
downloads/binaries/cross-compiler directory and extract that into your
system-impage-powerpc directory, then run:
./run-with-emulator.sh cross-compiler-powerpc
(which calls ./run-with-home.sh, which calls ./run-emulator.sh, which calls
qemu, which probably gets transferred to voicemail by that point...)
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Mike Frysinger @ 2008-08-08 18:09 UTC (permalink / raw)
To: Daniel Walker; +Cc: dvomlehn, linux-embedded
In-Reply-To: <1218212266.19162.149.camel@localhost.localdomain>
On Fri, Aug 8, 2008 at 12:17 PM, Daniel Walker wrote:
> On Fri, 2008-08-08 at 12:05 -0400, Mike Frysinger wrote:
>> On Fri, Aug 8, 2008 at 11:55 AM, Daniel Walker wrote:
>> > Another note, usually when submitting new interfaces like this you
>> > should also submit the code that uses the interface .. In your case you
>> > might not be able to do that, but it could never be accepted without at
>> > least one user.
>>
>> i really doubt that. lack of existing tangible users makes it a
>> harder case, but it certainly is not a "never" case. there is plenty
>> of examples in the tree where things were merged without any users and
>> the commit wouldnt be immediately leveraged.
>
> Well, I did say "usually" ..
you said "usually people submit new interfaces", not "it is usually
not accepted without at least one user".
> I invite you to give some of the "plenty of
> examples in the tree", you might surprise me..
look at all the new syscalls added without any userspace code in place
(still) to use it. or Linus' recent printk modifier extension. or my
printk extensions for extracting portions of the kernel log buffer.
people usually submit interfaces with backend extesions, or the intent
to use it is obvious.
-mike
^ permalink raw reply
* Re: embedded rootfs utility
From: Behan Webster @ 2008-08-08 17:03 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-embedded
In-Reply-To: <Pine.LNX.4.64.0808061345080.28556@vixen.sonytel.be>
Geert Uytterhoeven wrote:
> Thanks for this useful tool!
> I'm used to plain debootstrap, but decided to give your elbs-rootfs a try for
> creating up a mipsel and a powerpc NFS root file system. It worked fine,
> except for one minor nit. As an NFS root file system is mounted read-only by
> default, I had to manually do
>
> | mount -n proc /proc -t proc
> | mount -n -o remount -w /
>
> before running finish.sh. Perhaps this can be added to the top of finish.sh?
>
Odd. I never had this issue. It has always just worked for me.
None the less, I will add checks for this to the script.
> Add the end of its execution, finish.sh says:
>
> | Feel free to delete /debootstrap and the downloaded packages
> | # rm -rf /debootstrap
> | # apt-get clean
> | Please reboot now
> | # shutdown -r now
>
> Shouldn't it suggest to delete /finish.sh, too?
>
Ah. finish.sh used to delete itself when finished. I removed that
while testing, and forgot to put it back in.
Indeed you are correct.
> Anyway, thanks for this tool!
>
I'm glad you are finding it useful.
--
Behan Webster
behanw@websterwood.com
^ permalink raw reply
* initrd and uImage
From: Fundu @ 2008-08-08 16:42 UTC (permalink / raw)
To: linux-embedded
Hi,
First off i have a ppc based board.
and i'm trying to load a kernel image with ramdisk rootfs.
i have build the kernel. it spit uImage,zImage and vmlinux.gz
my question are.
1) what are all the different image types ?
i know the uImage is just the kernel, what are the rest (zImage & vmlinux.gz)?
2) i'm using u-boot as the bootldr. so i download the uImage (cause zImage and vmlinux.gz aren't bootlable) from tftp server and then do bootm <address> the kernel only load partially. How does the kernel know where/how to load the rootfs ?
thanks !
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Daniel Walker @ 2008-08-08 16:17 UTC (permalink / raw)
To: Mike Frysinger; +Cc: dvomlehn, linux-embedded
In-Reply-To: <8bd0f97a0808080905u1b515556gd68c2ba1d0b47cb4@mail.gmail.com>
On Fri, 2008-08-08 at 12:05 -0400, Mike Frysinger wrote:
> On Fri, Aug 8, 2008 at 11:55 AM, Daniel Walker wrote:
> > Another note, usually when submitting new interfaces like this you
> > should also submit the code that uses the interface .. In your case you
> > might not be able to do that, but it could never be accepted without at
> > least one user.
>
> i really doubt that. lack of existing tangible users makes it a
> harder case, but it certainly is not a "never" case. there is plenty
> of examples in the tree where things were merged without any users and
> the commit wouldnt be immediately leveraged.
Well, I did say "usually" .. I invite you to give some of the "plenty of
examples in the tree", you might surprise me..
Daniel
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Mike Frysinger @ 2008-08-08 16:05 UTC (permalink / raw)
To: Daniel Walker; +Cc: dvomlehn, linux-embedded
In-Reply-To: <1218210904.19162.144.camel@localhost.localdomain>
On Fri, Aug 8, 2008 at 11:55 AM, Daniel Walker wrote:
> Another note, usually when submitting new interfaces like this you
> should also submit the code that uses the interface .. In your case you
> might not be able to do that, but it could never be accepted without at
> least one user.
i really doubt that. lack of existing tangible users makes it a
harder case, but it certainly is not a "never" case. there is plenty
of examples in the tree where things were merged without any users and
the commit wouldnt be immediately leveraged.
-mike
^ permalink raw reply
* Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: Daniel Walker @ 2008-08-08 15:55 UTC (permalink / raw)
To: dvomlehn; +Cc: linux-embedded
In-Reply-To: <489BAD5C.2080009@cisco.com>
On Thu, 2008-08-07 at 19:20 -0700, David VomLehn wrote:
> Allow diversion of characters generated through printk so that they can
> be logged separately. The printk_time variables is made externally visible
> so that functions processing the diverted characters can parse off the
> time added if CONFIG_PRINTK_TIME is enabled.
> +
> static void emit_log_char(char c)
> {
> + emit_crash_char(c);
> +
> LOG_BUF(log_end) = c;
Isn't this duplicating the making of a custom console driver? I'm not a
console expect, but I think you could have a console driver which
catches this output and logs it..
Another note, usually when submitting new interfaces like this you
should also submit the code that uses the interface .. In your case you
might not be able to do that, but it could never be accepted without at
least one user.
Daniel
^ permalink raw reply
* Re: kernel command line from u-boot
From: Robert P. J. Day @ 2008-08-08 15:53 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Amol Lad, linux-embedded
In-Reply-To: <Pine.LNX.4.64.0808071618120.9798@vixen.sonytel.be>
On Thu, 7 Aug 2008, Geert Uytterhoeven wrote:
> On Thu, 7 Aug 2008, Amol Lad wrote:
> > > Probably nobody noticed as this part of the code takes care of the
> > > `obsolete-style' parameters. `module_param' is the new way.
> >
> > Ohh, btw how module_param is different from obsolete style
> > paramaters ? Do we need to pass arguments to kernel from
> > bootloader using a different method for getting them processed
> > using module_param ?
>
> Documentation/kernel-parameters.txt:
>
> Module parameters for loadable modules are specified only as the
> parameter name with optional '=' and value as appropriate, such as:
>
> modprobe usbcore blinkenlights=1
>
> Module parameters for modules that are built into the kernel image
> are specified on the kernel command line with the module name plus
> '.' plus parameter name, with '=' and value if appropriate, such as:
>
> usbcore.blinkenlights=1
slightly off-topic but, since we're on the subject, i'm still
puzzled by something i read a while back as to how all command-line
parameters are supposed to eventually be implemented using the
moduleparam technique. i don't see how that's possible.
as i read it, there are two types of boot-time kernel parms in terms
of how they're implemented:
1) "core" parms
2) module-related parms
the first type are declared using either __setup() or early_param(),
macros that are defined in include/linux/init.h, and are made part of
the kernel image thusly:
=====
/*
* Only for really core code. See moduleparam.h for the normal way.
*
* Force the alignment so the compiler doesn't space elements of the
* obs_kernel_param "array" too far apart in .init.setup.
*/
#define __setup_param(str, unique_id, fn, early) \
static char __setup_str_##unique_id[] __initdata __aligned(1) = str; \
static struct obs_kernel_param __setup_##unique_id \
__used __section(.init.setup) \
__attribute__((aligned((sizeof(long))))) \
= { __setup_str_##unique_id, fn, early }
=====
as you can see, the "core" parameters are placed in the .init.setup
section in the ELF-format kernel image. (and they're processed in
init/main.c, in the obsolete_checksetup() routine.)
module-related parms are, on the other hand, defined using the
contents of include/linux/moduleparam.h:
=====
/* This is the fundamental function for registering boot/module
parameters. perm sets the visibility in sysfs: 000 means it's
not there, read bits mean it's readable, write bits mean it's
writable. */
#define __module_param_call(prefix, name, set, get, arg, perm) \
/* Default value instead of permissions? */ \
static int __param_perm_check_##name __attribute__((unused)) = \
BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
static const char __param_str_##name[] = prefix #name; \
static struct kernel_param __moduleparam_const __param_##name \
__used \
__attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \
= { __param_str_##name, perm, set, get, { arg } }
=====
clearly, these are treated differently as they are placed in the
__param section of the kernel image. so it seems fairly clear that,
as much as it's convenient to have the module-related boot-time parms,
you'll never be able to get rid of the core technique for
implementation of boot-time parms. or am i missing something
critical?
what i do *see* is that there are *way* too many boot-time parms
that are implemented as core parms when they should be transformed to
module parms. the current doc file for parms,
Documentation/kernel-parameters.txt, is an absolute nightmare as it
mixes core and module parameters together in a confusing way.
as a totally random example, consider this from
drivers/isdn/hisax/config.c:
__setup("hisax=", HiSax_setup);
obviously, given the use of __setup(), that's being implemented as a
core parm, but why? the kernel-parameters.txt file even has to
emphasize that this is a feature dependent parm:
hisax= [HW,ISDN]
See Documentation/isdn/README.HiSax.
IMHO, it would far more sense if parms like that are transformed
from core parms to module parms, whereupon each module would be
responsible for documenting its own associated parms, while the
kernel-parameters.txt could be stripped down to referring to *only*
core parms, as opposed to the disorganized chaos that it is now.
anyway, just my $0.02.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* OLS 2008 videos
From: Michael Opdenacker @ 2008-08-08 13:57 UTC (permalink / raw)
To: linux-embedded mailing list; +Cc: Thomas Petazzoni
Greetings,
Thomas and I have just released the 30 videos that we shot at OLS this year:
http://free-electrons.com/news/news-2008-08-08
Most videos are from kernel and embedded topics, which most of you
should be interested in ;-) . Don't hesitate to let other people know...
Cheers,
Michael and Thomas.
--
Michael Opdenacker, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging
From: David VomLehn @ 2008-08-08 2:20 UTC (permalink / raw)
To: linux-embedded
Allow diversion of characters generated through printk so that they can
be logged separately. The printk_time variables is made externally visible
so that functions processing the diverted characters can parse off the
time added if CONFIG_PRINTK_TIME is enabled.
Signed-off-by: David VomLehn <dvomlehn@cisco.com>
---
I apologize for the crufty disclaimer Cisco adds. It is on a long list on
things that make us awkward open source community members but things change
slowly at many large companies.
Rationale for this patch: The ability to divert characters is useful for
embedded systems when a panic occurs. It is frequently the case that there
is insufficient storage to hold a crash dump and too little, if any, upstream
network bandwith to upload a dump if one could be stored. Instead, we rely upon
the report written to the console for most of our debugging. The ability to
capture that report and either store it or send it upstream is a fundamental
part of our ability to support our systems in the lab and in the field.
include/linux/kernel.h | 5 ++++
kernel/printk.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index aaa998f..1848260 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -200,6 +200,8 @@ extern struct ratelimit_state printk_ratelimit_state;
extern int printk_ratelimit(void);
extern bool printk_timed_ratelimit(unsigned long *caller_jiffies,
unsigned int interval_msec);
+extern void register_emit_crash_char(void (*fn)(char c));
+extern void unregister_emit_crash_char(void);
#else
static inline int vprintk(const char *s, va_list args)
__attribute__ ((format (printf, 1, 0)));
@@ -211,6 +213,8 @@ static inline int printk_ratelimit(void) { return 0; }
static inline bool printk_timed_ratelimit(unsigned long *caller_jiffies, \
unsigned int interval_msec) \
{ return false; }
+static inline void register_emit_crash_char(void (*fn)(char c)) {}
+static inline void unregister_emit_crash_char() {}
#endif
extern void asmlinkage __attribute__((format(printf, 1, 2)))
@@ -229,6 +233,7 @@ static inline void console_verbose(void)
console_loglevel = 15;
}
+extern int printk_time;
extern void bust_spinlocks(int yes);
extern void wake_up_klogd(void);
extern int oops_in_progress; /* If set, an oops, panic(), BUG() or die() is in progress */
diff --git a/kernel/printk.c b/kernel/printk.c
index b51b156..35a4d81 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -67,6 +67,9 @@ int console_printk[4] = {
int oops_in_progress;
EXPORT_SYMBOL(oops_in_progress);
+static void (*emit_crash_char_fn)(char c);
+static bool recursive_emit_crash_char;
+
/*
* console_sem protects the console_drivers list, and also
* provides serialisation for access to the entire console
@@ -520,8 +523,35 @@ static void call_console_drivers(unsigned start, unsigned end)
_call_console_drivers(start_print, end, msg_level);
}
+/*
+ * This emits a character intended for a crash log. We take special care
+ * to avoid recursive use so that we don't end up in an crash reporting loop.
+ */
+static void emit_crash_char(char c)
+{
+ static bool in_call;
+
+ if (emit_crash_char_fn != NULL) {
+ /* Detect recursive calls and ignore them. This could happen
+ * if the function we use to emit the character to the crash
+ * log failed and called printk. Though we ignore the output,
+ * we remember that we had a recursive call so that we can
+ * report it later. */
+ if (in_call)
+ recursive_emit_crash_char = true;
+
+ else {
+ in_call = true;
+ emit_crash_char_fn(c);
+ in_call = false;
+ }
+ }
+}
+
static void emit_log_char(char c)
{
+ emit_crash_char(c);
+
LOG_BUF(log_end) = c;
log_end++;
if (log_end - log_start > log_buf_len)
@@ -533,6 +563,28 @@ static void emit_log_char(char c)
}
/*
+ * Register a function to emit a crash character
+ * @fn: Function to register
+ */
+void register_emit_crash_char(void (*fn)(char c))
+{
+ emit_crash_char_fn = fn;
+}
+
+/*
+ * Unregister a function emiting a crash character
+ */
+void unregister_emit_crash_char()
+{
+ emit_crash_char_fn = NULL;
+
+ if (recursive_emit_crash_char) {
+ pr_err("emit_crash_char was called recursively!\n");
+ recursive_emit_crash_char = false;
+ }
+}
+
+/*
* Zap console related locks when oopsing. Only zap at most once
* every 10 seconds, to leave time for slow consoles to print a
* full oops.
@@ -554,9 +606,9 @@ static void zap_locks(void)
}
#if defined(CONFIG_PRINTK_TIME)
-static int printk_time = 1;
+int printk_time = 1;
#else
-static int printk_time = 0;
+int printk_time;
#endif
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is solely
intended for the named addressee (or a person responsible for delivering it to
the addressee). If you are not the intended recipient of this message, you are
not authorized to read, print, retain, copy or disseminate this message or any
part of it. If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete it from your computer.
^ permalink raw reply related
* Re: [patch 2/4] Configure out file locking features
From: J. Bruce Fields @ 2008-08-07 22:55 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-kernel, linux-embedded, michael, Matt Mackall, matthew,
linux-fsdevel, akpm
In-Reply-To: <20080806151222.618ae70a@surf>
On Wed, Aug 06, 2008 at 03:12:22PM +0200, Thomas Petazzoni wrote:
> Le Mon, 4 Aug 2008 14:16:41 -0400,
> "J. Bruce Fields" <bfields@fieldses.org> a écrit :
>
> > OK by me, but again, why exactly? Since you're replacing the locking
> > calls they used by stubs that just return errors, in theory nfs, nfsd,
> > gfs2, and the rest should still compile and run, just without locking
> > support, right?
>
> You're right, that was stupid. Either should I add the Kconfig
> dependencies *OR* add the function stubs, not both. The following patch
> implements the second solution. I've checked that NFS, CIFS, GFS2,
> OCFS2, AFS and FUSE compile correctly. I've tested NFS only, though.
>
> Here is the new patch. Comments and suggestions welcome.
Seems fine to me, thanks! I can queue it up in my tree for 2.6.28 if
there's no objections.
(But, basic mail question: so I give this message to git-am and it
complains because of all this =3D=20 stuff, which google tells me is
quoted-printable encoding. Fine, I fixed it up by hand, but a) there
must be some less boring way to deal with it, and b) there must have
been some easy way to avoid it in the first place, either on my side or
yours? Enlightenment welcome.)
--b.
>
> Sincerly,
>
> Thomas
>
> ---
>
> Configure out file locking features
>
> This patch adds the CONFIG_FILE_LOCKING option which allows to remove
> support for advisory locks. With this patch enabled, the flock()
> system call, the F_GETLK, F_SETLK and F_SETLKW operations of fcntl()
> and NFS support are disabled. These features are not necessarly needed
> on embedded systems. It allows to save ~11 Kb of kernel code and data:
>
> text data bss dec hex filename
> 1125436 118764 212992 1457192 163c28 vmlinux.old
> 1114299 118564 212992 1445855 160fdf vmlinux
> -11137 -200 0 -11337 -2C49 +/-
>
> This patch has originally been written by Matt Mackall
> <mpm@selenic.com>, and is part of the Linux Tiny project.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Matt Mackall <mpm@selenic.com>
> Cc: matthew@wil.cx
> Cc: linux-fsdevel@vger.kernel.org
> Cc: mpm@selenic.com
> Cc: akpm@linux-foundation.org
>
> ---
> fs/Kconfig | 8 +++++++
> fs/Makefile | 3 +-
> fs/proc/proc_misc.c | 4 +++
> include/linux/fs.h | 55 +++++++++++++++++++++++++++++++++++++++++++++-------
> kernel/sys_ni.c | 1
> kernel/sysctl.c | 6 ++++-
> 6 files changed, 68 insertions(+), 9 deletions(-)
>
> Index: linuxdev/fs/Kconfig
> ===================================================================
> --- linuxdev.orig/fs/Kconfig
> +++ linuxdev/fs/Kconfig
> @@ -419,6 +419,14 @@
> bool
> default n
>
> +config FILE_LOCKING
> + bool "Enable POSIX file locking API" if EMBEDDED
> + default y
> + help
> + This option enables standard file locking support, required
> + for filesystems like NFS and for the flock() system
> + call. Disabling this option saves about 11k.
> +
> source "fs/xfs/Kconfig"
> source "fs/gfs2/Kconfig"
>
> Index: linuxdev/fs/Makefile
> ===================================================================
> --- linuxdev.orig/fs/Makefile
> +++ linuxdev/fs/Makefile
> @@ -7,7 +7,7 @@
>
> obj-y := open.o read_write.o file_table.o super.o \
> char_dev.o stat.o exec.o pipe.o namei.o fcntl.o \
> - ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o \
> + ioctl.o readdir.o select.o fifo.o dcache.o inode.o \
> attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
> seq_file.o xattr.o libfs.o fs-writeback.o \
> pnode.o drop_caches.o splice.o sync.o utimes.o \
> @@ -27,6 +27,7 @@
> obj-$(CONFIG_SIGNALFD) += signalfd.o
> obj-$(CONFIG_TIMERFD) += timerfd.o
> obj-$(CONFIG_EVENTFD) += eventfd.o
> +obj-$(CONFIG_FILE_LOCKING) += locks.o
> obj-$(CONFIG_COMPAT) += compat.o compat_ioctl.o
>
> nfsd-$(CONFIG_NFSD) := nfsctl.o
> Index: linuxdev/fs/proc/proc_misc.c
> ===================================================================
> --- linuxdev.orig/fs/proc/proc_misc.c
> +++ linuxdev/fs/proc/proc_misc.c
> @@ -677,6 +677,7 @@
> return proc_calc_metrics(page, start, off, count, eof, len);
> }
>
> +#ifdef CONFIG_FILE_LOCKING
> static int locks_open(struct inode *inode, struct file *filp)
> {
> return seq_open(filp, &locks_seq_operations);
> @@ -688,6 +689,7 @@
> .llseek = seq_lseek,
> .release = seq_release,
> };
> +#endif /* CONFIG_FILE_LOCKING */
>
> static int execdomains_read_proc(char *page, char **start, off_t off,
> int count, int *eof, void *data)
> @@ -881,7 +883,9 @@
> #ifdef CONFIG_PRINTK
> proc_create("kmsg", S_IRUSR, NULL, &proc_kmsg_operations);
> #endif
> +#ifdef CONFIG_FILE_LOCKING
> proc_create("locks", 0, NULL, &proc_locks_operations);
> +#endif
> proc_create("devices", 0, NULL, &proc_devinfo_operations);
> proc_create("cpuinfo", 0, NULL, &proc_cpuinfo_operations);
> #ifdef CONFIG_BLOCK
> Index: linuxdev/include/linux/fs.h
> ===================================================================
> --- linuxdev.orig/include/linux/fs.h
> +++ linuxdev/include/linux/fs.h
> @@ -983,6 +983,13 @@
>
> #include <linux/fcntl.h>
>
> +extern void send_sigio(struct fown_struct *fown, int fd, int band);
> +
> +/* fs/sync.c */
> +extern int do_sync_mapping_range(struct address_space *mapping, loff_t offset,
> + loff_t endbyte, unsigned int flags);
> +
> +#ifdef CONFIG_FILE_LOCKING
> extern int fcntl_getlk(struct file *, struct flock __user *);
> extern int fcntl_setlk(unsigned int, struct file *, unsigned int,
> struct flock __user *);
> @@ -993,14 +1000,9 @@
> struct flock64 __user *);
> #endif
>
> -extern void send_sigio(struct fown_struct *fown, int fd, int band);
> extern int fcntl_setlease(unsigned int fd, struct file *filp, long arg);
> extern int fcntl_getlease(struct file *filp);
>
> -/* fs/sync.c */
> -extern int do_sync_mapping_range(struct address_space *mapping, loff_t offset,
> - loff_t endbyte, unsigned int flags);
> -
> /* fs/locks.c */
> extern void locks_init_lock(struct file_lock *);
> extern void locks_copy_lock(struct file_lock *, struct file_lock *);
> @@ -1023,6 +1025,35 @@
> extern int lock_may_read(struct inode *, loff_t start, unsigned long count);
> extern int lock_may_write(struct inode *, loff_t start, unsigned long count);
> extern struct seq_operations locks_seq_operations;
> +#else /* !CONFIG_FILE_LOCKING */
> +#define fcntl_getlk(a, b) ({ -EINVAL; })
> +#define fcntl_setlk(a, b, c, d) ({ -EACCES; })
> +#if BITS_PER_LONG == 32
> +#define fcntl_getlk64(a, b) ({ -EINVAL; })
> +#define fcntl_setlk64(a, b, c, d) ({ -EACCES; })
> +#endif
> +#define fcntl_setlease(a, b, c) ({ 0; })
> +#define fcntl_getlease(a) ({ 0; })
> +#define locks_init_lock(a) ({ })
> +#define __locks_copy_lock(a, b) ({ })
> +#define locks_copy_lock(a, b) ({ })
> +#define locks_remove_posix(a, b) ({ })
> +#define locks_remove_flock(a) ({ })
> +#define posix_test_lock(a, b) ({ 0; })
> +#define posix_lock_file(a, b, c) ({ -ENOLCK; })
> +#define posix_lock_file_wait(a, b) ({ -ENOLCK; })
> +#define posix_unblock_lock(a, b) (-ENOENT)
> +#define vfs_test_lock(a, b) ({ 0; })
> +#define vfs_lock_file(a, b, c, d) (-ENOLCK)
> +#define vfs_cancel_lock(a, b) ({ 0; })
> +#define flock_lock_file_wait(a, b) ({ -ENOLCK; })
> +#define __break_lease(a, b) ({ 0; })
> +#define lease_get_mtime(a, b) ({ })
> +#define generic_setlease(a, b, c) ({ -EINVAL; })
> +#define lock_may_read(a, b, c) ({ 1; })
> +#define lock_may_write(a, b, c) ({ 1; })
> +#endif /* !CONFIG_FILE_LOCKING */
> +
>
> struct fasync_struct {
> int magic;
> @@ -1554,9 +1585,12 @@
> /* /sys/fs */
> extern struct kobject *fs_kobj;
>
> +extern int rw_verify_area(int, struct file *, loff_t *, size_t);
> +
> #define FLOCK_VERIFY_READ 1
> #define FLOCK_VERIFY_WRITE 2
>
> +#ifdef CONFIG_FILE_LOCKING
> extern int locks_mandatory_locked(struct inode *);
> extern int locks_mandatory_area(int, struct inode *, struct file *, loff_t, size_t);
>
> @@ -1587,8 +1621,6 @@
> return 0;
> }
>
> -extern int rw_verify_area(int, struct file *, loff_t *, size_t);
> -
> static inline int locks_verify_truncate(struct inode *inode,
> struct file *filp,
> loff_t size)
> @@ -1609,6 +1641,15 @@
> return __break_lease(inode, mode);
> return 0;
> }
> +#else /* !CONFIG_FILE_LOCKING */
> +#define locks_mandatory_locked(a) ({ 0; })
> +#define locks_mandatory_area(a, b, c, d, e) ({ 0; })
> +#define __mandatory_lock(a) ({ 0; })
> +#define mandatory_lock(a) ({ 0; })
> +#define locks_verify_locked(a) ({ 0; })
> +#define locks_verify_truncate(a, b, c) ({ 0; })
> +#define break_lease(a, b) ({ 0; })
> +#endif /* CONFIG_FILE_LOCKING */
>
> /* fs/open.c */
>
> Index: linuxdev/kernel/sys_ni.c
> ===================================================================
> --- linuxdev.orig/kernel/sys_ni.c
> +++ linuxdev/kernel/sys_ni.c
> @@ -125,6 +125,7 @@
> cond_syscall(sys_vm86);
> cond_syscall(compat_sys_ipc);
> cond_syscall(compat_sys_sysctl);
> +cond_syscall(sys_flock);
>
> /* arch-specific weak syscall entries */
> cond_syscall(sys_pciconfig_read);
> Index: linuxdev/kernel/sysctl.c
> ===================================================================
> --- linuxdev.orig/kernel/sysctl.c
> +++ linuxdev/kernel/sysctl.c
> @@ -97,7 +97,7 @@
> static int neg_one = -1;
> #endif
>
> -#ifdef CONFIG_MMU
> +#if defined(CONFIG_MMU) && defined(CONFIG_FILE_LOCKING)
> static int two = 2;
> #endif
>
> @@ -1260,6 +1260,7 @@
> .extra1 = &minolduid,
> .extra2 = &maxolduid,
> },
> +#ifdef CONFIG_FILE_LOCKING
> {
> .ctl_name = FS_LEASES,
> .procname = "leases-enable",
> @@ -1268,6 +1269,7 @@
> .mode = 0644,
> .proc_handler = &proc_dointvec,
> },
> +#endif
> #ifdef CONFIG_DNOTIFY
> {
> .ctl_name = FS_DIR_NOTIFY,
> @@ -1279,6 +1281,7 @@
> },
> #endif
> #ifdef CONFIG_MMU
> +#ifdef CONFIG_FILE_LOCKING
> {
> .ctl_name = FS_LEASE_TIME,
> .procname = "lease-break-time",
> @@ -1290,6 +1293,7 @@
> .extra1 = &zero,
> .extra2 = &two,
> },
> +#endif
> {
> .procname = "aio-nr",
> .data = &aio_nr,
>
>
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers and embedded Linux development,
> consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* Re: kernel command line from u-boot
From: Robert P. J. Day @ 2008-08-07 14:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Amol Lad, linux-embedded
In-Reply-To: <Pine.LNX.4.64.0808071618120.9798@vixen.sonytel.be>
On Thu, 7 Aug 2008, Geert Uytterhoeven wrote:
> On Thu, 7 Aug 2008, Amol Lad wrote:
> > > Probably nobody noticed as this part of the code takes care of the
> > > `obsolete-style' parameters. `module_param' is the new way.
> >
> > Ohh, btw how module_param is different from obsolete style paramaters
> > ? Do we need to pass arguments to kernel from bootloader using a
> > different method for getting them processed using module_param ?
>
> Documentation/kernel-parameters.txt:
>
> Module parameters for loadable modules are specified only as the
> parameter name with optional '=' and value as appropriate, such as:
>
> modprobe usbcore blinkenlights=1
>
> Module parameters for modules that are built into the kernel image
> are specified on the kernel command line with the module name plus
> '.' plus parameter name, with '=' and value if appropriate, such as:
>
> usbcore.blinkenlights=1
um ... all of the above handles those command-line parms that are
defined in *module* source files, but that doesn't solve the problem
of defining those parms that are always built into the kernel and are
currently defined by one of __setup_param() or __early_param().
from include/linux/init.h:
=====
struct obs_kernel_param {
const char *str;
int (*setup_func)(char *);
int early;
};
/*
* Only for really core code. See moduleparam.h for the normal way.
*
* Force the alignment so the compiler doesn't space elements of the
* obs_kernel_param "array" too far apart in .init.setup.
*/
=====
is the module-based approach really supposed to eventually replace
the above? how?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* Re: kernel command line from u-boot
From: Geert Uytterhoeven @ 2008-08-07 14:18 UTC (permalink / raw)
To: Amol Lad; +Cc: linux-embedded
In-Reply-To: <8c675e9b0808070427v42a4055bwae3adfb160a4e1ab@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1238 bytes --]
On Thu, 7 Aug 2008, Amol Lad wrote:
> > Probably nobody noticed as this part of the code takes care of the
> > `obsolete-style' parameters. `module_param' is the new way.
>
> Ohh, btw how module_param is different from obsolete style paramaters
> ? Do we need to pass arguments to kernel from bootloader using a
> different method for getting them processed using module_param ?
Documentation/kernel-parameters.txt:
Module parameters for loadable modules are specified only as the
parameter name with optional '=' and value as appropriate, such as:
modprobe usbcore blinkenlights=1
Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate, such as:
usbcore.blinkenlights=1
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: kernel command line from u-boot
From: Amol Lad @ 2008-08-07 11:27 UTC (permalink / raw)
To: Geert Uytterhoeven
In-Reply-To: <Pine.LNX.4.64.0808071050280.9798@vixen.sonytel.be>
> Probably nobody noticed as this part of the code takes care of the
> `obsolete-style' parameters. `module_param' is the new way.
Ohh, btw how module_param is different from obsolete style paramaters
? Do we need to pass arguments to kernel from bootloader using a
different method for getting them processed using module_param ?
>
> Geert Uytterhoeven
Thanks
Amol
^ permalink raw reply
* Re: kernel command line from u-boot
From: Geert Uytterhoeven @ 2008-08-07 8:54 UTC (permalink / raw)
To: Amol Lad; +Cc: linux-embedded, Linux Kernel Development
In-Reply-To: <8c675e9b0808062141s74f1a7bfob5cab6b23b0268d3@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1302 bytes --]
On Thu, 7 Aug 2008, Amol Lad wrote:
> It seems that there is a small problem when kernel parses the command
> line passed by u-boot.
It doesn't seem to be specific to u-boot...
> For example, when I add "board=myboard boardid=1" in the command line
> and register handler in kernel as __setup("board", board_setup), then
> the board_setup function is called twice : once with argument
> "myboard" and second time with argument "d=1". So kernel is calling
^^^
Wow, when init/main.c:obsolete_checksetup() matches the `board' part,
it ignores the next character (`i'), assuming this is `=', and passes
the remainder (`d=1').
> handler registered for param "board" for "boardid" also. Is this ok ?
I don't think this is OK.
Probably nobody noticed as this part of the code takes care of the
`obsolete-style' parameters. `module_param' is the new way.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* kernel command line from u-boot
From: Amol Lad @ 2008-08-07 4:41 UTC (permalink / raw)
To: linux-embedded
Hi,
It seems that there is a small problem when kernel parses the command
line passed by u-boot.
For example, when I add "board=myboard boardid=1" in the command line
and register handler in kernel as __setup("board", board_setup), then
the board_setup function is called twice : once with argument
"myboard" and second time with argument "d=1". So kernel is calling
handler registered for param "board" for "boardid" also. Is this ok ?
Thanks
Amol
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: H. Peter Anvin @ 2008-08-06 23:03 UTC (permalink / raw)
To: Tim Bird
Cc: Robert Schwebel, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <489A2D0F.2070102@am.sony.com>
Tim Bird wrote:
>
>> CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
>
> I'd be OK implementing it with an option, rather than a magic char.
> I was trying to avoid adding too many options, since many kernel
> developers prefer fewer options where possible. But the magic
> char makes the code less straightforward.
>
> If we ever move towards supporting both prefix and suffice splicing (or
> even complicated in-the-middle splicing), then the magic char is
> easier to develop into that. But so far, I can only come up with
> reasonable cases for append and override, and I don't want to add
> superfluous handling for non-existent use cases.
I think I agree, and the override option would make it easier to make
generic.
-hpa
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: H. Peter Anvin @ 2008-08-06 23:02 UTC (permalink / raw)
To: Matt Mackall
Cc: Tim Bird, Robert Schwebel, linux kernel, linux-embedded,
Thomas Gleixner
In-Reply-To: <1218063133.7576.16.camel@calx>
Matt Mackall wrote:
> On Wed, 2008-08-06 at 15:48 -0700, H. Peter Anvin wrote:
>> Tim Bird wrote:
>>> One difficulty is that the other arches' command lines
>>> are not currently "broken", so there's no real incentive
>>> to change them.
>>>
>>> The only thing novel thing I'm adding here is the addition of
>>> the leading '!' to allow for an override. This is needed
>>> in some x86 cases I'm familiar with, but I've haven't seen
>>> any cases where it would be useful for other arches.
>>> (not to say they don't exist - I just haven't seen them.)
>>>
>> Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE
>> option, since the initial reason for a magic character was to be able to
>> provide both prefix and suffix splicing.
>
> You're right, I had forgotten about the suffix splicing and my brain is
> a bit foggy on what motivated it.
>
Well, prefix = bootloader overrides; suffix = builtin overrides.
>> CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
>
> Yes, though I doubt we're in danger of introducing any real backwards
> compatibility issues with the magic '!' at the beginning.
Well, it does if we want to make this a generic feature, which I believe
we should.
-hpa
^ permalink raw reply
* Re: [PATCH] bootup: Add built-in kernel command line for x86
From: Tim Bird @ 2008-08-06 23:00 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Robert Schwebel, linux kernel, linux-embedded, Matt Mackall,
Thomas Gleixner
In-Reply-To: <489A2A24.6010400@zytor.com>
H. Peter Anvin wrote:
> Tim Bird wrote:
>> The only thing novel thing I'm adding here is the addition of
>> the leading '!' to allow for an override. This is needed
>> in some x86 cases I'm familiar with, but I've haven't seen
>> any cases where it would be useful for other arches.
>> (not to say they don't exist - I just haven't seen them.)
>>
>
> Note that it could just as easily be done with a CONFIG_CMDLINE_OVERRIDE
> option, since the initial reason for a magic character was to be able to
> provide both prefix and suffix splicing.
Agreed.
>
> CONFIG_CMDLINE_OVERRIDE is probably more palatable to other architectures.
I'd be OK implementing it with an option, rather than a magic char.
I was trying to avoid adding too many options, since many kernel
developers prefer fewer options where possible. But the magic
char makes the code less straightforward.
If we ever move towards supporting both prefix and suffice splicing (or
even complicated in-the-middle splicing), then the magic char is
easier to develop into that. But so far, I can only come up with
reasonable cases for append and override, and I don't want to add
superfluous handling for non-existent use cases.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox