* RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
From: H Hartley Sweeten @ 2010-02-16 18:12 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Pavel Machek, linux-embedded, linux-kernel
In-Reply-To: <4B758153.2060209@billgatliff.com>
On Friday, February 12, 2010 9:27 AM, Bill Gatliff wrote:
> H Hartley Sweeten wrote:
>>
>> FWIW, the gpiolib API will accept any non-zero value to "set" a gpio pin
>> and a zero value to "clear" the pin.
>>
>
> It makes me sort of cringe to say this, but I'm going to assume that the
> API is intended to work that way so that I can take advantage of it.
> But I'd love to someday have the reassurance that gpiolib really *is*
> intended to work that way (might be a bad idea though, see below). Call
> me paranoid, but I've lost a lot of hair over the years undoing the
> damage of similar failed assumptions.
>
> I've found the Linux kernel code to be refreshingly forgiving of such
> things, however, so I'm willing to risk it this time. :)
>
>> For that matter, some of the gpiolib drivers end up returning the bit
>> position mask for a given gpio pin and not 1 or 0. For instance if the
>> gpio pin in question is bit 6 in an 8-bit register and it is set, a
>> __gpio_get_value will end up returning 0x40 and not '1'.
>>
>
> Who's to say that gpios should always be boolean? On the output side, a
> "gpio" that's four bits wide might be a useful way of dealing with bar
> graphs, seven-segment displays, etc. (but more specialized abstractions
> might be more appropriate, of course).
I think the original intention of gpiolib was to deal with individual pins.
> A two-bit "gpio" input might make it easier to deal with rotary encoders.
True. But a two-bit "gpio" is no longer a "pin" it's now a "port".
I have been messing with a "port" extension for gpiolib but it's not even
close to being mergable yet. But, that's a different topic...
> But for now, GPIOs are assumed to be booleans and that's why I'm
> hesitant to feed the API non-boolean values. Someday, those values
> might mean something subtly but disastrously different. And given my
> luck lately with such things...
True. As such just use ! and !! to make the values boolean.
gpio is bit 6
val = 0x40 -> !(0x40) = 0
val = 0x40 -> !!(0x40) = 1
Just my .02... Regards,
Hartley
^ permalink raw reply
* Re: [PATCH 03/11] readahead: bump up the default readahead size
From: Wu Fengguang @ 2010-02-21 2:25 UTC (permalink / raw)
To: Matt Mackall
Cc: Jamie Lokier, Christian Ehrhardt, Andrew Morton, Jens Axboe,
Chris Mason, Peter Zijlstra, Martin Schwidefsky, Clemens Ladisch,
Olivier Galibert, Linux Memory Management List,
linux-fsdevel@vger.kernel.org, LKML, Paul Gortmaker,
David Woodhouse, linux-embedded@vger.kernel.org
In-Reply-To: <1266006023.15603.661.camel@calx>
Hi Matt,
On Sat, Feb 13, 2010 at 04:20:23AM +0800, Matt Mackall wrote:
> On Fri, 2010-02-12 at 21:59 +0800, Wu Fengguang wrote:
> > On Fri, Feb 12, 2010 at 07:42:49AM +0800, Jamie Lokier wrote:
> > > Matt Mackall wrote:
> > > > On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > > > > Chris,
> > > > >
> > > > > Firstly inform the linux-embedded maintainers :)
> > > > >
> > > > > I think it's a good suggestion to add a config option
> > > > > (CONFIG_READAHEAD_SIZE). Will update the patch..
> > > >
> > > > I don't have a strong opinion here beyond the nagging feeling that we
> > > > should be using a per-bdev scaling window scheme rather than something
> > > > static.
> >
> > It's good to do dynamic scaling -- in fact this patchset has code to do
> > - scale down readahead size (per-bdev) for small devices
>
> I'm not sure device size is a great metric. It's only weakly correlated
Yes, it's only weakly correlated. However device size is a good metric
in itself -- when it's small, ie. Linus' 500KB sized USB device.
> with the things we actually care about: memory pressure (small devices
> are often attached to systems with small and therefore full memory) and
> latency (small devices are often old and slow and attached to slow
> CPUs). I think we should instead use hints about latency (large request
> queues) and memory pressure (reclaim passes) directly.
In principle I think it's OK to use memory pressure and IO latency as hints.
1) memory pressure
For read-ahead, the memory pressure is mainly readahead buffers
consumed by too many concurrent streams. The context readahead in this
patchset can adapt readahead size to thrashing threshold well. So in
principle we don't need to adapt the default _max_ read-ahead size to
memory pressure.
For read-around, the memory pressure is mainly read-around misses on
executables/libraries. Which could be reduced by scaling down
read-around size on fast "reclaim passes".
The more straightforward solution could be to limit default
read-around size proportional to available system memory, ie.
512MB mem => 512KB read-around size
128MB mem => 128KB read-around size
32MB mem => 32KB read-around size (minimal)
2) IO latency
We might estimate the average service time and throughput for IOs of
different size, and choose the default readahead size based on
- good throughput
- low service time
- reasonable size bounds
IMHO the estimation should reflect the nature of the device, and do
not depend on specific workloads. Some points:
- in most cases, reducing readahead size on large request queues
(which is typical in large file servers) only hurts performance
- we don't know whether the application is latency-sensitive (and to
what degree), hence no need to be over-zealous to optimize for latency
- a dynamic changing readahead size is nightmare to benchmarks
That means to avoid estimation when there are any concurrent
reads/writes. It also means that the estimation can be turned off for
this boot after enough data have been collected and the averages go
stable.
> > - scale down readahead size (per-stream) to thrashing threshold
>
> Yeah, I'm happy to call that part orthogonal to this discussion.
>
> > At the same time, I'd prefer
> > - to _only_ do scale down (below the default size) for low end
> > - and have a uniform default readahead size for the mainstream
>
> I don't think that's important, given that we're dynamically fiddling
> with related things.
Before we can dynamically tune things and do it smart enough, it would
be good to have clear rules :)
> > IMHO scaling up automatically
> > - would be risky
>
> What, explicitly, are the risks? If we bound the window with memory
Risks could be readahead misses and higher latency.
Generally the risk:perf_gain ratio goes up for larger readahead size.
> pressure and latency, I don't think it can get too far out of hand.
> There are also some other bounds in here: we have other limits on how
> big I/O requests can be.
OK, if we do some bounds based mainly on foreseeable single device
performance needs.. 16MB?
> I'm happy to worry about only scaling down for now, but it's only a
> matter of time before we have to bump the number up again.
Agreed.
> We've got an IOPS range from < 1 (mp3 player with power-saving
> spin-down) to > 1M (high-end SSD). And the one that needs the most
> readahead is the former!
We have laptop mode for the former, which will elevate readahead size
and (legitimately) disregard IO performance impacts.
> > I would guess most embedded systems put executables on MTD devices
> > (anyone to confirm this?).
>
> It's hard to generalize here. Even on flash devices, interleaving with
> writes can result in high latencies that make it behave more like
> spinning media, but there's no way to generalize about what the write
> mix is going to be.
I'd prefer to not consider impact of writes when choosing default
readahead size.
> > And I wonder if MTDs have general
> > characteristics that are suitable for smaller readahead/readaround
> > size (the two sizes are bundled for simplicity)?
>
> Perhaps, but the trend is definitely towards larger blocks here.
OK.
> > We could add new adjustments based on throughput (estimation is the
> > problem) and memory size.
>
> Note that throughput is not enough information here. More interesting is
> the "bandwidth delay product" of the I/O path. If latency (of the whole
> I/O stack) is zero, it's basically always better to read on demand. But
> if every request takes 100ms whether it's for 4k or 4M (see optical
> media), then you might want to consider reading 4M every time. And
> latency is of course generally not independent of usage pattern. Which
> is why I think TCP-like feedback scaling is the right approach.
OK.
Thanks,
Fengguang
^ permalink raw reply
* [PATCH]: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-06 18:03 UTC (permalink / raw)
To: Linux Kernel; +Cc: Linux Embedded
Ramoops, like mtdoops, can log oops/panic information but in RAM. It can
be used with persistent RAM for systems without flash support. In
addition, for this systems, with this driver, it's no more needed
add to the kernel the mtd subsystem with advantage in footprint.
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
--
diff -Nuar linux-2.6.33-orig/drivers/char/Kconfig linux-2.6.33/drivers/char/Kconfig
--- linux-2.6.33-orig/drivers/char/Kconfig 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/char/Kconfig 2010-02-28 10:47:29.000000000 +0100
@@ -1105,5 +1105,12 @@
source "drivers/s390/char/Kconfig"
+config RAMOOPS
+ tristate "Log panic/oops to a RAM buffer"
+ default n
+ help
+ This enables panic and oops messages to be logged to a circular
+ buffer in RAM where it can be read back at some later point.
+
endmenu
diff -Nuar linux-2.6.33-orig/drivers/char/Makefile linux-2.6.33/drivers/char/Makefile
--- linux-2.6.33-orig/drivers/char/Makefile 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/char/Makefile 2010-02-28 10:49:17.000000000 +0100
@@ -107,6 +107,7 @@
obj-$(CONFIG_TCG_TPM) += tpm/
obj-$(CONFIG_PS3_FLASH) += ps3flash.o
+obj-$(CONFIG_RAMOOPS) += ramoops.o
obj-$(CONFIG_JS_RTC) += js-rtc.o
js-rtc-y = rtc.o
diff -Nuar linux-2.6.33-orig/drivers/char/ramoops.c linux-2.6.33/drivers/char/ramoops.c
--- linux-2.6.33-orig/drivers/char/ramoops.c 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.33/drivers/char/ramoops.c 2010-03-06 13:36:31.000000000 +0100
@@ -0,0 +1,163 @@
+/*
+ * RAM Oops/Panic logger
+ *
+ * Copyright (C) 2009 Marco Stornelli <marco.stornelli@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/kmsg_dump.h>
+#include <linux/time.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+
+#define RAMOOPS_KERNMSG_HDR "===="
+#define RAMOOPS_HEADER_SIZE (5 + sizeof(struct timeval))
+
+#define RECORD_SIZE 4096
+
+static ulong mem_address;
+module_param(mem_address, ulong, 0600);
+MODULE_PARM_DESC(mem_address,
+ "start of reserved RAM used to store oops/panic logs");
+
+static ulong mem_size;
+module_param(mem_size, ulong, 0600);
+MODULE_PARM_DESC(mem_size,
+ "size of reserved RAM used to store oops/panic logs");
+
+static int dump_oops = 1;
+module_param(dump_oops, int, 0600);
+MODULE_PARM_DESC(dump_oops,
+ "set to 1 to dump oopses, 0 to only dump panics (default 1)");
+
+static struct ramoops_context {
+ struct kmsg_dumper dump;
+ void *virt_addr;
+ phys_addr_t phys_addr;
+ unsigned long size;
+ int count;
+ int max_count;
+} oops_cxt;
+
+static void ramoops_do_dump(struct kmsg_dumper *dumper,
+ enum kmsg_dump_reason reason, const char *s1, unsigned long l1,
+ const char *s2, unsigned long l2)
+{
+ struct ramoops_context *cxt = container_of(dumper,
+ struct ramoops_context, dump);
+ unsigned long s1_start, s2_start;
+ unsigned long l1_cpy, l2_cpy;
+ int res;
+ char *buf;
+ struct timeval timestamp;
+
+ /* Only dump oopses if dump_oops is set */
+ if (reason == KMSG_DUMP_OOPS && !dump_oops)
+ return;
+
+ buf = (char *)(cxt->virt_addr + (cxt->count * RECORD_SIZE));
+ memset(buf, '\0', RECORD_SIZE);
+ res = sprintf(buf, "%s", RAMOOPS_KERNMSG_HDR);
+ buf += res;
+ do_gettimeofday(×tamp);
+ res = sprintf(buf, "%lu.%lu\n", (long)timestamp.tv_sec, (long)timestamp.tv_usec);
+ buf += res;
+
+ l2_cpy = min(l2, (unsigned long)(RECORD_SIZE - RAMOOPS_HEADER_SIZE));
+ l1_cpy = min(l1, (unsigned long)(RECORD_SIZE - RAMOOPS_HEADER_SIZE) - l2_cpy);
+
+ s2_start = l2 - l2_cpy;
+ s1_start = l1 - l1_cpy;
+
+ memcpy(buf, s1 + s1_start, l1_cpy);
+ memcpy(buf + l1_cpy, s2 + s2_start, l2_cpy);
+
+ cxt->count = (cxt->count + 1) % cxt->max_count;
+}
+
+static int __init ramoops_init(void)
+{
+ struct ramoops_context *cxt = &oops_cxt;
+ int err = -EINVAL;
+
+ if (!mem_size) {
+ printk(KERN_ERR "Invalid size specification");
+ goto fail3;
+ }
+
+ rounddown_pow_of_two(mem_size);
+
+ if (mem_size < RECORD_SIZE) {
+ printk(KERN_ERR "size too small");
+ goto fail3;
+ }
+
+ cxt->max_count = mem_size / RECORD_SIZE;
+ cxt->count = 0;
+ cxt->size = mem_size;
+ cxt->phys_addr = mem_address;
+
+ err = request_mem_region(cxt->phys_addr, cxt->size, "ramoops");
+ if (!err) {
+ printk(KERN_ERR "ramoops: request mem region failed");
+ err = -EINVAL;
+ goto fail3;
+ }
+
+ cxt->virt_addr = ioremap(cxt->phys_addr, cxt->size);
+ if (!cxt->virt_addr) {
+ printk(KERN_ERR "ramoops: ioremap failed");
+ goto fail2;
+ }
+
+ cxt->dump.dump = ramoops_do_dump;
+ err = kmsg_dump_register(&cxt->dump);
+ if (err) {
+ printk(KERN_ERR "ramoops: registering kmsg dumper failed");
+ goto fail1;
+ }
+
+ return 0;
+
+fail1:
+ iounmap(cxt->virt_addr);
+fail2:
+ release_mem_region(cxt->phys_addr, cxt->size);
+fail3:
+ return err;
+}
+
+static void __exit ramoops_exit(void)
+{
+ struct ramoops_context *cxt = &oops_cxt;
+
+ if (kmsg_dump_unregister(&cxt->dump) < 0)
+ printk(KERN_WARNING "ramoops: could not unregister kmsg_dumper\n");
+
+ iounmap(cxt->virt_addr);
+ release_mem_region(cxt->phys_addr, cxt->size);
+}
+
+
+module_init(ramoops_init);
+module_exit(ramoops_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Marco Stornelli <marco.stornelli@gmail.com>");
+MODULE_DESCRIPTION("RAM Oops/Panic logger/driver");
^ permalink raw reply
* [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-09 17:41 UTC (permalink / raw)
To: Linux Kernel; +Cc: Linux Embedded
Ramoops, like mtdoops, can log oops/panic information but in RAM. It can
be used with persistent RAM for systems without flash support. In
addition, for this systems, with this driver, it's no more needed
add to the kernel the mtd subsystem with advantage in footprint.
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
---
diff -uprN linux-2.6.33-orig/drivers/char/Kconfig linux-2.6.33/drivers/char/Kconfig
--- linux-2.6.33-orig/drivers/char/Kconfig 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/char/Kconfig 2010-02-28 10:47:29.000000000 +0100
@@ -1105,5 +1105,12 @@ config DEVPORT
source "drivers/s390/char/Kconfig"
+config RAMOOPS
+ tristate "Log panic/oops to a RAM buffer"
+ default n
+ help
+ This enables panic and oops messages to be logged to a circular
+ buffer in RAM where it can be read back at some later point.
+
endmenu
diff -uprN linux-2.6.33-orig/drivers/char/Makefile linux-2.6.33/drivers/char/Makefile
--- linux-2.6.33-orig/drivers/char/Makefile 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6.33/drivers/char/Makefile 2010-02-28 10:49:17.000000000 +0100
@@ -107,6 +107,7 @@ obj-$(CONFIG_HANGCHECK_TIMER) += hangche
obj-$(CONFIG_TCG_TPM) += tpm/
obj-$(CONFIG_PS3_FLASH) += ps3flash.o
+obj-$(CONFIG_RAMOOPS) += ramoops.o
obj-$(CONFIG_JS_RTC) += js-rtc.o
js-rtc-y = rtc.o
diff -uprN linux-2.6.33-orig/drivers/char/ramoops.c linux-2.6.33/drivers/char/ramoops.c
--- linux-2.6.33-orig/drivers/char/ramoops.c 1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.33/drivers/char/ramoops.c 2010-03-07 10:41:10.000000000 +0100
@@ -0,0 +1,162 @@
+/*
+ * RAM Oops/Panic logger
+ *
+ * Copyright (C) 2009 Marco Stornelli <marco.stornelli@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/kmsg_dump.h>
+#include <linux/time.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+
+#define RAMOOPS_KERNMSG_HDR "===="
+#define RAMOOPS_HEADER_SIZE (5 + sizeof(struct timeval))
+
+#define RECORD_SIZE 4096
+
+static ulong mem_address;
+module_param(mem_address, ulong, 0600);
+MODULE_PARM_DESC(mem_address,
+ "start of reserved RAM used to store oops/panic logs");
+
+static ulong mem_size;
+module_param(mem_size, ulong, 0600);
+MODULE_PARM_DESC(mem_size,
+ "size of reserved RAM used to store oops/panic logs");
+
+static int dump_oops = 1;
+module_param(dump_oops, int, 0600);
+MODULE_PARM_DESC(dump_oops,
+ "set to 1 to dump oopses, 0 to only dump panics (default 1)");
+
+static struct ramoops_context {
+ struct kmsg_dumper dump;
+ void *virt_addr;
+ phys_addr_t phys_addr;
+ unsigned long size;
+ int count;
+ int max_count;
+} oops_cxt;
+
+static void ramoops_do_dump(struct kmsg_dumper *dumper,
+ enum kmsg_dump_reason reason, const char *s1, unsigned long l1,
+ const char *s2, unsigned long l2)
+{
+ struct ramoops_context *cxt = container_of(dumper,
+ struct ramoops_context, dump);
+ unsigned long s1_start, s2_start;
+ unsigned long l1_cpy, l2_cpy;
+ int res;
+ char *buf;
+ struct timeval timestamp;
+
+ /* Only dump oopses if dump_oops is set */
+ if (reason == KMSG_DUMP_OOPS && !dump_oops)
+ return;
+
+ buf = (char *)(cxt->virt_addr + (cxt->count * RECORD_SIZE));
+ memset(buf, '\0', RECORD_SIZE);
+ res = sprintf(buf, "%s", RAMOOPS_KERNMSG_HDR);
+ buf += res;
+ do_gettimeofday(×tamp);
+ res = sprintf(buf, "%lu.%lu\n", (long)timestamp.tv_sec, (long)timestamp.tv_usec);
+ buf += res;
+
+ l2_cpy = min(l2, (unsigned long)(RECORD_SIZE - RAMOOPS_HEADER_SIZE));
+ l1_cpy = min(l1, (unsigned long)(RECORD_SIZE - RAMOOPS_HEADER_SIZE) - l2_cpy);
+
+ s2_start = l2 - l2_cpy;
+ s1_start = l1 - l1_cpy;
+
+ memcpy(buf, s1 + s1_start, l1_cpy);
+ memcpy(buf + l1_cpy, s2 + s2_start, l2_cpy);
+
+ cxt->count = (cxt->count + 1) % cxt->max_count;
+}
+
+static int __init ramoops_init(void)
+{
+ struct ramoops_context *cxt = &oops_cxt;
+ int err = -EINVAL;
+
+ if (!mem_size) {
+ printk(KERN_ERR "Invalid size specification");
+ goto fail3;
+ }
+
+ rounddown_pow_of_two(mem_size);
+
+ if (mem_size < RECORD_SIZE) {
+ printk(KERN_ERR "size too small");
+ goto fail3;
+ }
+
+ cxt->max_count = mem_size / RECORD_SIZE;
+ cxt->count = 0;
+ cxt->size = mem_size;
+ cxt->phys_addr = mem_address;
+
+ if (!request_mem_region(cxt->phys_addr, cxt->size, "ramoops")) {
+ printk(KERN_ERR "ramoops: request mem region failed");
+ err = -EINVAL;
+ goto fail3;
+ }
+
+ cxt->virt_addr = ioremap(cxt->phys_addr, cxt->size);
+ if (!cxt->virt_addr) {
+ printk(KERN_ERR "ramoops: ioremap failed");
+ goto fail2;
+ }
+
+ cxt->dump.dump = ramoops_do_dump;
+ err = kmsg_dump_register(&cxt->dump);
+ if (err) {
+ printk(KERN_ERR "ramoops: registering kmsg dumper failed");
+ goto fail1;
+ }
+
+ return 0;
+
+fail1:
+ iounmap(cxt->virt_addr);
+fail2:
+ release_mem_region(cxt->phys_addr, cxt->size);
+fail3:
+ return err;
+}
+
+static void __exit ramoops_exit(void)
+{
+ struct ramoops_context *cxt = &oops_cxt;
+
+ if (kmsg_dump_unregister(&cxt->dump) < 0)
+ printk(KERN_WARNING "ramoops: could not unregister kmsg_dumper\n");
+
+ iounmap(cxt->virt_addr);
+ release_mem_region(cxt->phys_addr, cxt->size);
+}
+
+
+module_init(ramoops_init);
+module_exit(ramoops_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Marco Stornelli <marco.stornelli@gmail.com>");
+MODULE_DESCRIPTION("RAM Oops/Panic logger/driver");
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Yuasa Yoichi @ 2010-03-10 2:08 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux Kernel, Linux Embedded
In-Reply-To: <4B968834.3040609@gmail.com>
Hi,
2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
> Ramoops, like mtdoops, can log oops/panic information but in RAM.
What is different from mtdoops + mtd-ram?
Yoichi
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-10 8:02 UTC (permalink / raw)
To: Yuasa Yoichi; +Cc: Linux Kernel, Linux Embedded
In-Reply-To: <21eaeb5a1003091808s2d7638cxd524952a7d84b378@mail.gmail.com>
2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
> Hi,
>
> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
>
> What is different from mtdoops + mtd-ram?
>
> Yoichi
>
It can be used in a very easy way with persistent RAM for systems
without flash support. For this systems, with this driver, it's no
more needed add to the kernel the mtd subsystem with advantage in
footprint as I said in the description. In addition, you can save
flash space and store this information only in RAM. I think it's very
useful for embedded systems.
Marco
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Yuasa Yoichi @ 2010-03-10 9:20 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux Kernel, Linux Embedded
In-Reply-To: <2ea1731b1003100002w104633ffy1ae46ef3d245e5b5@mail.gmail.com>
2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>> Hi,
>>
>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
>>
>> What is different from mtdoops + mtd-ram?
>>
>> Yoichi
>>
>
> It can be used in a very easy way with persistent RAM for systems
> without flash support. For this systems, with this driver, it's no
> more needed add to the kernel the mtd subsystem with advantage in
> footprint as I said in the description.
right.
But,
> In addition, you can save
> flash space and store this information only in RAM. I think it's very
> useful for embedded systems.
CONFIG_MTD_RAM uses only RAM.
I think there's no big difference about this point.
Yoichi
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-10 12:15 UTC (permalink / raw)
To: Yuasa Yoichi; +Cc: Linux Kernel, Linux Embedded
In-Reply-To: <21eaeb5a1003100120x6cd3f69ak598954af3c9fe955@mail.gmail.com>
2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>>> Hi,
>>>
>>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
>>>
>>> What is different from mtdoops + mtd-ram?
>>>
>>> Yoichi
>>>
>>
>> It can be used in a very easy way with persistent RAM for systems
>> without flash support. For this systems, with this driver, it's no
>> more needed add to the kernel the mtd subsystem with advantage in
>> footprint as I said in the description.
>
> right.
> But,
>
>> In addition, you can save
>> flash space and store this information only in RAM. I think it's very
>> useful for embedded systems.
>
> CONFIG_MTD_RAM uses only RAM.
> I think there's no big difference about this point.
>
I meant with the "classic" use of mtdoops, therefore with a flash
partition without use MTD_RAM. Using MTD_RAM, it's more or less the
same thing, with the exception of "where" you want deploy the log. For
example: if in your system you have got a nvram you can use it without
problem, you need to specify the address of the nvram to the module.
Very simple. I think it's a small driver but very useful, feedback
from other embedded guys are welcome.
Marco
^ permalink raw reply
* [ANNOUNCE] ELC 2010 Program is available - registration open
From: Tim Bird @ 2010-03-10 23:43 UTC (permalink / raw)
To: linux-embedded
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
=============================
^ permalink raw reply
* [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Peter Korsgaard @ 2010-03-12 10:25 UTC (permalink / raw)
To: kay.sievers, gregkh, linux-kernel, linux-embedded; +Cc: Peter Korsgaard
Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
using ramfs instead.
Saves ~15KB.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
drivers/base/Kconfig | 2 +-
drivers/base/devtmpfs.c | 5 +++++
fs/ramfs/inode.c | 2 +-
include/linux/ramfs.h | 2 ++
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index fd52c48..7e33b16 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -18,7 +18,7 @@ config UEVENT_HELPER_PATH
config DEVTMPFS
bool "Maintain a devtmpfs filesystem to mount at /dev"
- depends on HOTPLUG && SHMEM && TMPFS
+ depends on HOTPLUG
help
This creates a tmpfs filesystem instance early at bootup.
In this filesystem, the kernel driver core maintains device
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index dac478c..6927262 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -20,6 +20,7 @@
#include <linux/namei.h>
#include <linux/fs.h>
#include <linux/shmem_fs.h>
+#include <linux/ramfs.h>
#include <linux/cred.h>
#include <linux/sched.h>
#include <linux/init_task.h>
@@ -44,7 +45,11 @@ __setup("devtmpfs.mount=", mount_param);
static int dev_get_sb(struct file_system_type *fs_type, int flags,
const char *dev_name, void *data, struct vfsmount *mnt)
{
+#ifdef CONFIG_TMPFS
return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
+#else
+ return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
+#endif
}
static struct file_system_type dev_fs_type = {
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index a6090aa..1a5259a 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -213,7 +213,7 @@ static int ramfs_parse_options(char *data, struct ramfs_mount_opts *opts)
return 0;
}
-static int ramfs_fill_super(struct super_block * sb, void * data, int silent)
+int ramfs_fill_super(struct super_block *sb, void *data, int silent)
{
struct ramfs_fs_info *fsi;
struct inode *inode = NULL;
diff --git a/include/linux/ramfs.h b/include/linux/ramfs.h
index 4e768dd..8600508 100644
--- a/include/linux/ramfs.h
+++ b/include/linux/ramfs.h
@@ -20,4 +20,6 @@ extern const struct file_operations ramfs_file_operations;
extern const struct vm_operations_struct generic_file_vm_ops;
extern int __init init_rootfs(void);
+int ramfs_fill_super(struct super_block *sb, void *data, int silent);
+
#endif
--
1.7.0
^ permalink raw reply related
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Michael Tokarev @ 2010-03-12 11:28 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: kay.sievers, gregkh, linux-kernel, linux-embedded
In-Reply-To: <1268389504-22179-1-git-send-email-jacmet@sunsite.dk>
Peter Korsgaard wrote:
> Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
> using ramfs instead.
>
> Saves ~15KB.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[]> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -44,7 +45,11 @@ __setup("devtmpfs.mount=", mount_param);
> static int dev_get_sb(struct file_system_type *fs_type, int flags,
> const char *dev_name, void *data, struct vfsmount *mnt)
> {
> +#ifdef CONFIG_TMPFS
> return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
> +#else
> + return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
> +#endif
> }
May be completely not to the point or even wrong, but I were
starring at this change for quite some time trying to understand
what's the difference. Can we do it like this:
#ifdef CONFIG_TMPFS
# define devtmpfs_fill_super shmem_fill_super
#else
# define devtmpfs_fill_super ramfs_fill_super
#endif
return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);
?
Or maybe it's just me... ;)
/mjt
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Peter Korsgaard @ 2010-03-12 11:38 UTC (permalink / raw)
To: Michael Tokarev; +Cc: kay.sievers, gregkh, linux-kernel, linux-embedded
In-Reply-To: <4B9A2548.7050401@msgid.tls.msk.ru>
>>>>> "Michael" == Michael Tokarev <mjt@tls.msk.ru> writes:
Hi,
>> +#ifdef CONFIG_TMPFS
>> return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
>> +#else
>> + return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
>> +#endif
>> }
Michael> May be completely not to the point or even wrong, but I were
Michael> starring at this change for quite some time trying to understand
Michael> what's the difference. Can we do it like this:
Michael> #ifdef CONFIG_TMPFS
Michael> # define devtmpfs_fill_super shmem_fill_super
Michael> #else
Michael> # define devtmpfs_fill_super ramfs_fill_super
Michael> #endif
Michael> return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);
Michael> ?
Sure, if people find that cleaner - Kay?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Kay Sievers @ 2010-03-12 13:02 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: Michael Tokarev, gregkh, linux-kernel, linux-embedded
In-Reply-To: <87aaud22jj.fsf@macbook.be.48ers.dk>
On Fri, Mar 12, 2010 at 12:38, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Michael" == Michael Tokarev <mjt@tls.msk.ru> writes:
> >> +#ifdef CONFIG_TMPFS
> >> return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
> >> +#else
> >> + return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
> >> +#endif
> >> }
>
> Michael> May be completely not to the point or even wrong, but I were
> Michael> starring at this change for quite some time trying to understand
> Michael> what's the difference. Can we do it like this:
>
> Michael> #ifdef CONFIG_TMPFS
> Michael> # define devtmpfs_fill_super shmem_fill_super
> Michael> #else
> Michael> # define devtmpfs_fill_super ramfs_fill_super
> Michael> #endif
> Michael> return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);
> Sure, if people find that cleaner - Kay?
For the style:
I would prefer your original version.
For the patch:
Acked-by: Kay Sievers <kay.sievers@vrfy.org>
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Andrew Morton @ 2010-03-12 22:48 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <2ea1731b1003100415i46dd8fcem85b85f49fb1a479@mail.gmail.com>
On Wed, 10 Mar 2010 13:15:25 +0100
Marco Stornelli <marco.stornelli@gmail.com> wrote:
> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
> > 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
> >> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
> >>> Hi,
> >>>
> >>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
> >>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
> >>>
> >>> What is different from mtdoops + mtd-ram?
> >>>
> >>> Yoichi
> >>>
> >>
> >> It can be used in a very easy way with persistent RAM for systems
> >> without flash support. For this systems, with this driver, it's no
> >> more needed add to the kernel the mtd subsystem with advantage in
> >> footprint as I said in the description.
> >
> > right.
> > But,
> >
> >> In addition, you can save
> >> flash space and store this information only in RAM. I think it's very
> >> useful for embedded systems.
> >
> > CONFIG_MTD_RAM uses only RAM.
> > I think there's no big difference about this point.
> >
>
> I meant with the "classic" use of mtdoops, therefore with a flash
> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
> same thing, with the exception of "where" you want deploy the log. For
> example: if in your system you have got a nvram you can use it without
> problem, you need to specify the address of the nvram to the module.
> Very simple. I think it's a small driver but very useful, feedback
> from other embedded guys are welcome.
Seems sensible to me. If you have a machine whose memory is persistent
across reboots then you reserve an arbitrary 4k hunk of memory for
collecting oops traces, yes?
What tools are used for displaying that memory on the next boot? How
do those tools distinguish between "valid oops trace" and "garbage
because it was just powered on"? A magic signature?
Should the kernel provide the 4k of memory rather than (or in addition
to) requiring that the system administrator reserve it and tell the
kernel about it? That'd be a matter of creating a linker section which
isn't cleared out by the startup code.
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Jamie Lokier @ 2010-03-12 23:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: Marco Stornelli, Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <20100312144854.cb94d9b4.akpm@linux-foundation.org>
Andrew Morton wrote:
> > I meant with the "classic" use of mtdoops, therefore with a flash
> > partition without use MTD_RAM. Using MTD_RAM, it's more or less the
> > same thing, with the exception of "where" you want deploy the log. For
> > example: if in your system you have got a nvram you can use it without
> > problem, you need to specify the address of the nvram to the module.
> > Very simple. I think it's a small driver but very useful, feedback
> > from other embedded guys are welcome.
>
> Seems sensible to me. If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?
Me too, I think it's a great idea which sounds simpler to use than MTD-RAM.
> What tools are used for displaying that memory on the next boot? How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"? A magic signature?
>
> Should the kernel provide the 4k of memory rather than (or in addition
> to) requiring that the system administrator reserve it and tell the
> kernel about it? That'd be a matter of creating a linker section which
> isn't cleared out by the startup code.
It's good if there's an option to make the location not vary between
kernels, and be known to the bootloader.
Then you can debug kernels which always crash during boot, by either
booting into another kernel which works and looking at the oops, or by
a bootloader command to dump it.
That'd be fine if the kernel link scripts choose the address, as long
as it's consistent between different compiles and similar
configurations. That'd be a bit simpler than the admin having to know
the memory map well enough to choose an address.
-- Jamie
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-13 8:49 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Andrew Morton, Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <20100312233144.GG6491@shareable.org>
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
> That'd be fine if the kernel link scripts choose the address, as long
> as it's consistent between different compiles and similar
> configurations. That'd be a bit simpler than the admin having to know
> the memory map well enough to choose an address.
>
> -- Jamie
>
I agree, but the bootloader should be aware of it. I mean, usually
bootloaders at boot, reset the RAM, so you have to tell to the
bootloader that you are using a piece of RAM as persistent RAM, for
example U-Boot has got a specific option CONFIG_PRAM. I don't know if
all the process can be completely transparent to the admin in all
situations.
Marco
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-13 8:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: Yuasa Yoichi, Linux Kernel, Linux Embedded, jamie
In-Reply-To: <20100312144854.cb94d9b4.akpm@linux-foundation.org>
Il 12/03/2010 23:48, Andrew Morton ha scritto:
> On Wed, 10 Mar 2010 13:15:25 +0100
> Marco Stornelli <marco.stornelli@gmail.com> wrote:
>
>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>>>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>> I meant with the "classic" use of mtdoops, therefore with a flash
>> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
>> same thing, with the exception of "where" you want deploy the log. For
>> example: if in your system you have got a nvram you can use it without
>> problem, you need to specify the address of the nvram to the module.
>> Very simple. I think it's a small driver but very useful, feedback
>> from other embedded guys are welcome.
>
> Seems sensible to me. If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?
Yes.
>
> What tools are used for displaying that memory on the next boot? How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"? A magic signature?
For my test I used the program devmem2 to dump the log. In general, you
can read the memory via /dev/mem. There's an header plus a timestamp of
the log. The memory is initialized with blank spaces and the size of the
record is fixed at 4k, so if a program/script doesn't find the header at
next 4k, it means there's garbage and it can stop the read operation.
>
> Should the kernel provide the 4k of memory rather than (or in addition
> to) requiring that the system administrator reserve it and tell the
> kernel about it? That'd be a matter of creating a linker section which
> isn't cleared out by the startup code.
>
>
Yes, it can be an option. My first idea was to write a "general" driver,
with an address in input that it can be related to the reserved RAM as
an NVRAM in the system, however it can be a good idea, why not.
Marco
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Geert Uytterhoeven @ 2010-03-13 14:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: Marco Stornelli, Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <20100312144854.cb94d9b4.akpm@linux-foundation.org>
On Fri, Mar 12, 2010 at 23:48, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 10 Mar 2010 13:15:25 +0100
> Marco Stornelli <marco.stornelli@gmail.com> wrote:
>
>> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>> > 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>> >> 2010/3/10 Yuasa Yoichi <yuasa@linux-mips.org>:
>> >>> Hi,
>> >>>
>> >>> 2010/3/10 Marco Stornelli <marco.stornelli@gmail.com>:
>> >>>> Ramoops, like mtdoops, can log oops/panic information but in RAM.
>> >>>
>> >>> What is different from mtdoops + mtd-ram?
>> >>>
>> >>> Yoichi
>> >>>
>> >>
>> >> It can be used in a very easy way with persistent RAM for systems
>> >> without flash support. For this systems, with this driver, it's no
>> >> more needed add to the kernel the mtd subsystem with advantage in
>> >> footprint as I said in the description.
>> >
>> > right.
>> > But,
>> >
>> >> In addition, you can save
>> >> flash space and store this information only in RAM. I think it's very
>> >> useful for embedded systems.
>> >
>> > CONFIG_MTD_RAM uses only RAM.
>> > I think there's no big difference about this point.
>> >
>>
>> I meant with the "classic" use of mtdoops, therefore with a flash
>> partition without use MTD_RAM. Using MTD_RAM, it's more or less the
>> same thing, with the exception of "where" you want deploy the log. For
>> example: if in your system you have got a nvram you can use it without
>> problem, you need to specify the address of the nvram to the module.
>> Very simple. I think it's a small driver but very useful, feedback
>> from other embedded guys are welcome.
>
> Seems sensible to me. If you have a machine whose memory is persistent
> across reboots then you reserve an arbitrary 4k hunk of memory for
> collecting oops traces, yes?
>
> What tools are used for displaying that memory on the next boot? How
> do those tools distinguish between "valid oops trace" and "garbage
> because it was just powered on"? A magic signature?
On Amiga, `debug=mem' enables something like that, cfr. git grep dmesg
arch/m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Jamie Lokier @ 2010-03-15 3:09 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Andrew Morton, Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <4B9B51B1.8010904@gmail.com>
Marco Stornelli wrote:
> Il 13/03/2010 00:31, Jamie Lokier ha scritto:
> > That'd be fine if the kernel link scripts choose the address, as long
> > as it's consistent between different compiles and similar
> > configurations. That'd be a bit simpler than the admin having to know
> > the memory map well enough to choose an address.
> >
> > -- Jamie
> >
>
> I agree, but the bootloader should be aware of it. I mean, usually
> bootloaders at boot, reset the RAM, so you have to tell to the
> bootloader that you are using a piece of RAM as persistent RAM, for
> example U-Boot has got a specific option CONFIG_PRAM. I don't know if
> all the process can be completely transparent to the admin in all
> situations.
Sometimes you can't change the bootloader (they don't always come with
source code). Or you could, but you don't want to risk it (there
isn't always a way to recover if you break it).
Obviously then the feature is only useful when the bootloader doesn't
clear all the RAM :-)
On slow boards in consumer devices, they sometimes avoid clearing the
RAM because that adds measurable boot time.
-- Jamie
^ permalink raw reply
* Re: [PATCH v2] char drivers: Ram oops/panic logger
From: Marco Stornelli @ 2010-03-15 8:11 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Andrew Morton, Yuasa Yoichi, Linux Kernel, Linux Embedded
In-Reply-To: <20100315030945.GS6491@shareable.org>
2010/3/15 Jamie Lokier <jamie@shareable.org>:
> Marco Stornelli wrote:
>> Il 13/03/2010 00:31, Jamie Lokier ha scritto:
>> I agree, but the bootloader should be aware of it. I mean, usually
>> bootloaders at boot, reset the RAM, so you have to tell to the
>> bootloader that you are using a piece of RAM as persistent RAM, for
>> example U-Boot has got a specific option CONFIG_PRAM. I don't know if
>> all the process can be completely transparent to the admin in all
>> situations.
>
> Sometimes you can't change the bootloader (they don't always come with
> source code). Or you could, but you don't want to risk it (there
> isn't always a way to recover if you break it).
>
> Obviously then the feature is only useful when the bootloader doesn't
> clear all the RAM :-)
>
> On slow boards in consumer devices, they sometimes avoid clearing the
> RAM because that adds measurable boot time.
>
In the embedded world, usually, you can change/write the fw and you
know well the memory map, so no problem to know the address to use. In
other cases, it can be possible to use a "transparent" approach, but
in my opinion the general approach used by the driver is enough.
Marco
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Peter Korsgaard @ 2010-03-16 13:04 UTC (permalink / raw)
To: greg; +Cc: Kay Sievers, Michael Tokarev, linux-kernel, linux-embedded
In-Reply-To: <ac3eb2511003120502y2953ff0au81ee5c4d76261a87@mail.gmail.com>
>>>>> "Kay" == Kay Sievers <kay.sievers@vrfy.org> writes:
Hi,
Kay> For the patch:
Kay> Acked-by: Kay Sievers <kay.sievers@vrfy.org>
Great - Greg, will you pick this up?
http://patchwork.kernel.org/patch/85237/
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Greg KH @ 2010-03-16 13:37 UTC (permalink / raw)
To: Peter Korsgaard
Cc: Kay Sievers, Michael Tokarev, linux-kernel, linux-embedded
In-Reply-To: <87tysgifjt.fsf@macbook.be.48ers.dk>
On Tue, Mar 16, 2010 at 02:04:06PM +0100, Peter Korsgaard wrote:
> >>>>> "Kay" == Kay Sievers <kay.sievers@vrfy.org> writes:
>
> Hi,
>
> Kay> For the patch:
> Kay> Acked-by: Kay Sievers <kay.sievers@vrfy.org>
>
> Great - Greg, will you pick this up?
>
> http://patchwork.kernel.org/patch/85237/
Yes, it's in my "to-apply" queue. I'm at a conference for a few days,
so give me a few more :)
thanks,
greg k-h
^ permalink raw reply
* Re: RFC: direct MTD support for SquashFS
From: Peter Korsgaard @ 2010-03-16 14:26 UTC (permalink / raw)
To: Ferenc Wagner
Cc: Phillip Lougher, linux-fsdevel, linux-mtd, linux-kernel,
linux-embedded
In-Reply-To: <87vdcwv139.fsf@tac.ki.iif.hu>
>>>>> "Ferenc" == Ferenc Wagner <wferi@niif.hu> writes:
Ferenc> Hi,
Ferenc> In embedded systems, SquashFS over MTD would be a considerable
Ferenc> win, as that would permit configuring without CONFIG_BLOCK.
Ferenc> Please find attached a naive patch against 2.6.33 for this. It
Ferenc> does not handle bad MTD blocks, that could be handled by gluebi
Ferenc> (once you're willing to take the UBI overhead), or by a custom
Ferenc> solution later.
Ferenc> For now, 2.6.34 gained pluggable decompressors, so this patch
Ferenc> does not apply anymore, though the main idea holds. My
Ferenc> questions: is the community interested in integrating something
Ferenc> like this, should this patch transformed into something
Ferenc> acceptable, or am I a total lunatic? I don't know a thing
Ferenc> about filesystem development, but willing to learn and
Ferenc> refactor. Comments welcome.
Nice, I have been thinking about that as well. What kind of size savings
are you getting with this?
CC'ing linux-embedded as this might be of interest there as well.
--
Bye, Peter Korsgaard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Greg KH @ 2010-03-16 19:00 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: kay.sievers, gregkh, linux-kernel, linux-embedded
In-Reply-To: <1268389504-22179-1-git-send-email-jacmet@sunsite.dk>
On Fri, Mar 12, 2010 at 11:25:04AM +0100, Peter Korsgaard wrote:
> Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
> using ramfs instead.
>
> Saves ~15KB.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> drivers/base/Kconfig | 2 +-
> drivers/base/devtmpfs.c | 5 +++++
> fs/ramfs/inode.c | 2 +-
> include/linux/ramfs.h | 2 ++
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index fd52c48..7e33b16 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -18,7 +18,7 @@ config UEVENT_HELPER_PATH
>
> config DEVTMPFS
> bool "Maintain a devtmpfs filesystem to mount at /dev"
> - depends on HOTPLUG && SHMEM && TMPFS
> + depends on HOTPLUG
> help
> This creates a tmpfs filesystem instance early at bootup.
> In this filesystem, the kernel driver core maintains device
With this patch, the Kconfig help text now is incorrect.
Is there a way to explicitly call out in the Kconfig which way devtmpfs
is being created? How about a multiple selection that chooses either
TMPFS or RAMFS, with the default being TMPFS?
So care to redo this so that people can easily determine what is going
to happen easier than this patch currently causes?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
From: Peter Korsgaard @ 2010-03-16 19:14 UTC (permalink / raw)
To: Greg KH; +Cc: kay.sievers, gregkh, linux-kernel, linux-embedded
In-Reply-To: <20100316190005.GA32555@kroah.com>
>>>>> "Greg" == Greg KH <greg@kroah.com> writes:
Hi,
>> config DEVTMPFS
>> bool "Maintain a devtmpfs filesystem to mount at /dev"
>> - depends on HOTPLUG && SHMEM && TMPFS
>> + depends on HOTPLUG
>> help
>> This creates a tmpfs filesystem instance early at bootup.
>> In this filesystem, the kernel driver core maintains device
Greg> With this patch, the Kconfig help text now is incorrect.
Greg> Is there a way to explicitly call out in the Kconfig which way
Greg> devtmpfs is being created? How about a multiple selection that
Greg> chooses either TMPFS or RAMFS, with the default being TMPFS?
I don't think that's needed - If CONFIG_TMPFS isn't set, then ramfs
pretends to be tmpfs anyway, see mm/shmem.c:
static struct file_system_type tmpfs_fs_type = {
.name = "tmpfs",
.get_sb = ramfs_get_sb,
.kill_sb = kill_litter_super,
};
So calling it tmpfs isn't really wrong.
Greg> So care to redo this so that people can easily determine what is going
Greg> to happen easier than this patch currently causes?
We can change the help text to say tmpfs/ramfs if you prefer - OK?
--
Bye, Peter Korsgaard
^ 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