On Tue, 27 May 2008 14:57:50 -0700 David VomLehn <dvomlehn@xxxxxxxxx> wrote: > Since I'm at least partially to blame for creation of this mailing list (I asked > Andrew Morton for one at the CELF Conference), I thought I might as well stir > things up by throwing a few features out there that I think would improve the > Linux kernel for use in the embedded world: > > Crash Diagnostics > ----------------- > The single biggest thing we've encountered is the requirement for good diagnostic > reports. We have a fat data pipe to our settop box, but the return pipe is way > too small for kernel core dumps. As a result, we send failure reports that > consist of register and stack dumps for the kernel and current application, > backtraces, etc. Even though some of the details are processor specific, there > are changes we've made in the generic kernel to support doing this. These will be > filtered out gradually as I get time to get them into shape to be submitted. Is this different than the current output you get from a kernel oops/panic? If so, did you implement it as an extension of that? > Continuous Logging for Watchdog Timer Expiration > ------------------------------------------------ > We run with a watchdog timer that can reboot the system. When we reboot, we lose > all of our status, making it very difficult to determine what went wrong. > Fortunately, there is only one major cause of not refreshing the watchdog--a > driver disabled interrupts for so long that the timer function that resets the > watchdog timer never had a chance to run. So, a way to log what functions were > enable and disabling interrupts on a continuous basis, along with a memory > section that wouldn't be overwritten on reboot, would allow capturing the cause > for these otherwise "silent" reboots. I believe lttng (or ltt-ng or whatever) has the ability to do continuous IRQ tracing. It also does much more. Have you looked at that at all? The problem, of course, is that you need someway to actually get the data off and if you've reset because of a watchdog... > NVM Filesystems (Separate Metadata?) > ------------------------------------ > NVM is generally too small to allow for the overhead of filesystem metadata, but > being able to access and manage that data without regard for particular > allocation would be very useful. The good thing is that the data allocation in > NVM is generally static, so data is overwritten but doesn't change size or > location. It would be nice to have some facility to have the metadata be > separately compiled and then to use the normal open/read/write/close interfaces > to use the data. We presently manage allocations with a C header file, but this > is awkward and error-prone. I have seen a filesystem that does this. It's not particularly robust, and changing the layout while preserving the existing data is extremely painful. > On-line Disk Partitioning > ------------------------- > Server and desktop systems partition their disks at installation time, but some > applications require that partitioning be done after we are already using a root > filesystem on disk. We only have one disk and the driver specifically prevents > changing the partitioning while a disk partition is in use. Note that we don't > want to change the root partition, just other partitions. This drives the need > for some sort of on-line partitioning that allows changing partitions that aren't > in use. Couldn't that be done outside of the kernel, in an initramfs/initrd or something directly off of the rootfs which isn't going to change? josh -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
