Re: [patch 2/4] Configure out file locking features
On Tue, 2008-07-29 at 12:17 -0600, Matthew Wilcox wrote: On Tue, Jul 29, 2008 at 05:45:22PM +0200, Thomas Petazzoni wrote: 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: textdata 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 [EMAIL PROTECTED], and is part of the Linux Tiny project. Signed-off-by: Thomas Petazzoni [EMAIL PROTECTED] In principle, I think this is a great idea. config NFS_FS tristate NFS client support - depends on INET + depends on INET FILE_LOCKING select LOCKD select SUNRPC select NFS_ACL_SUPPORT if NFS_V3_ACL I think this part is a little lazy. It should be possible to support NFS without file locking. I suspect that's really not in-scope for the linux-tiny tree as currently envisaged with the focus on embedded devices that probably don't use NFS anyway. Do we want to care about the situation of a machine with fixed workload, that doesn't need file locking, but does use NFS? I would lean towards no, but if someone comes along who cares, they're welcome to try it. This stuff all has to strike a balance between savings and effort/complexity/maintainability, so any time the submitter is too lazy to cover a less common use case, it's probably a good sign they're approaching that tipping point. On the other hand, if you think it's trivial to do a locking-ectomy on NFS, I'd be happy to see it. The typical embedded NFS-based devices are NAS servers and media players and are going to be more concerned about things like page cache balancing. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bootup: Add built-in kernel command line for x86
On Wed, 2008-08-06 at 15:31 -0700, Tim Bird wrote: Matt Mackall wrote: On Wed, 2008-08-06 at 14:31 -0700, Tim Bird wrote: The default behavior is to append the boot loader string to this one. However, there is a mechanism (leading '!') to force the built-in string to override the boot loader string. Nice solution. Where is this relative to early boot option checking? parse_early_param() is right AFTER this in the x86 setup_arch() function (in arch/x86/kernel/setup.c). All the other command-line handling I could find is after this in init/main.c:start_kernel(). Ok, there are a couple weird outliers outside of that still, but that should make most people satisfied. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 00/16] Squashfs: compressed read-only filesystem
On Wed, 2008-10-29 at 01:49 +, Phillip Lougher wrote: Hi, This a respin of the Squashfs patches incorporating the review comments received. Thanks to everyone who have sent comments. I read over the v3 source a few weeks ago and must say this looks greatly improved. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote:
On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote:
On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote:
Is moving constant string formats to __devinitconst or __initdata
useful for embedded environments?
As in:
#define printk_section(section, fmt, ...) \
({ static const section char __fmt[] = fmt; printk(__fmt, ##__VA_ARGS__);
})
#define pr_err_section(section, fmt, ...) \
printk_section(section, KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
with a use of:
static int __devinit foo_probe(struct platform_device *pdev)
{
if (bar())
pr_err_section(__devinitconst,
A long error message\n);
}
Interesting notion, but not worth the trouble in my mind. I think it's
more worthwhile to look into automatic such stuff in the build somehow.
I think it's not possible today to get gcc to mark
the format strings without source modification.
Yep, that's why I specifically said 'build'. It can probably be done in
a post-processing step with some ELF wizardry.
It's pretty easy to script a source conversion.
And that script has to be run how often? I don't think people will find
the churn (and general extra ugliness) acceptable. For a typical
stripped-down embedded kernel, the amount of gain here will be fairly
minimal. I'd be surprised if you got as much as 1K out of it.
--
http://selenic.com : development and support for Mercurial and Linux
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] move __devinit or __init printk constant format strings to __devinitconst or __initdata?
On Tue, 2009-07-21 at 16:50 -0700, David Daney wrote: Joe Perches wrote: On Tue, 2009-07-21 at 17:57 -0500, Matt Mackall wrote: On Tue, 2009-07-21 at 14:56 -0700, Joe Perches wrote: On Tue, 2009-07-21 at 16:48 -0500, Matt Mackall wrote: On Tue, 2009-07-21 at 14:20 -0700, Joe Perches wrote: Is moving constant string formats to __devinitconst or __initdata useful for embedded environments? Interesting notion, but not worth the trouble in my mind. I think it's more worthwhile to look into automatic such stuff in the build somehow. I think it's not possible today to get gcc to mark the format strings without source modification. Yep, that's why I specifically said 'build'. It can probably be done in a post-processing step with some ELF wizardry. Know any elven wizards? It would be tricky, the string data from the entire compilation unit is intermingled. You would have to separate out only those strings referenced from __init sections into their own section and fix up all symbols and relocations that were affected. Exactly. Annoying but not impossible. Probably easier would be to use the plug-in feature that will be part of GCC-4.5 (or will that be called GCC-5.0??), and create a special Linux kernel GCC plug-in that just emits the __init literal strings to the proper section to begin with. This wouldn't be unprecedented, the Mozilla people already use their own extensions to GCC, and will probably migrate to GCC plug-ins. We don't want the kernel to get left behind in the GCC plug-in race. There are no doubt a number of things we could be doing with such extensions. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote: Allows annotation of panics to include platform information. It's no big deal to collect information, but way helpful when you are collecting failure reports from a eventual base of millions of systems deployed in other people's homes. I'd like to hear a bit more use case motivation on this feature. Also, why do you want more than a page? -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] panic-note: Annotation from user space for panics
On Tue, 2009-11-17 at 16:28 -0800, Eric W. Biederman wrote: David VomLehn dvoml...@cisco.com writes: On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote: ... Why not use the kdump hook? If you handle a kernel panic that way you get enhanced reliability and full user space support. All in a hook that is already present and already works. I'm a big fan of avoiding reinvention of the wheel--if I can use something already present, I will. However, I'm not clear about how much of the problem I'm addressing will be solved by using a kdump hook. If I understand correctly, you'd still need a pseudo-file somewhere to actually get the data from user space to kernel space. *Then* you could use a kdump hook to transfer the data to flash or some memory area that will be retained across boots. Is this the approach to which you were referring? If so, I have a couple more questions: 1. In what ways would this be better than, say, a panic_notifier? A couple of ways. - You are doing the work in a known good kernel instead of the kernel that just paniced for some unknown reason. - All of the control logic is in user space (not the kernel) so you can potentially do something as simple as date logfile to get the date. 2. Where would you suggest tying in? (Particularly since not all architectures currently support kdump) No changes are needed kernel side. You just need an appropriate kernel and initrd for your purpose. All of the interesting architectures support kexec, and if an architecture doesn't it isn't hard to add. The architecture specific part is very simple. A pain to debug initially but very simple. As much as I like kexec, it loses on memory footprint by about 100x. It's not appropriate for all use cases, especially things like consumer-grade wireless access points and phones. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: flash_platform_data namespace collision
On Sat, 2010-01-16 at 11:04 +, Russell King wrote: On Fri, Jan 15, 2010 at 11:41:15PM -0600, Matt Mackall wrote: I've got a board here with SPI, NOR, and NAND flash devices and I've just run into a namespace collision on flash_platform_data from The one in arch/arm/include/asm/mach/flash.h is designed to have great appeal and flexibility across different platforms, and indeed we have at least 70 users across six different MTD NOR flash drivers and two MTD NAND drivers. If anything, I believe that this header should move into linux/mtd/ and become a standard structure for platforms to communicate their requirements to flash drivers. Yeah, I think this is probably the way to go. Davids, any objections? -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] readahead: bump up the default readahead size
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. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] readahead: bump up the default readahead size
On Thu, 2010-02-11 at 23:42 +, 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. I agree with both. 100Mb/s isn't typical on little devices, even if a fast ATA disk is attached. I've got something here where the ATA interface itself (on a SoC) gets about 10MB/s max when doing nothing else, or 4MB/s when talking to the network at the same time. It's not a modern design, but you know, it's junk we try to use :-) It sounds like a calculation based on throughput and seek time or IOP rate, and maybe clamped if memory is small, would be good. Is the window size something that could be meaningfully adjusted according to live measurements? I think so. You've basically got a few different things you want to balance: throughput, latency, and memory pressure. Successful readaheads expand the window, as do empty request queues, while long request queues and memory reclaim events collapse it. With any luck, we'll then automatically do the right thing with fast/slow devices on big/small boxes with varying load. And, like TCP, we don't need to 'know' anything about the hardware, except to watch what happens when we use it. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] printk: add pr_level_once, guard print_hex_dump
On Sun, 2010-12-05 at 21:44 -0800, Joe Perches wrote: There are many uses of printk_once(KERN_level. Add pr_level_once macros to avoid printk_once(KERN_level pr_fmt(fmt). Add an #ifdef CONFIG_PRINTK for print_hex_dump and static inline void functions for the #else cases to reduce embedded code size. Neaten and organize the rest of the code. Looks fine to me. I'd missed the introduction of the pr_level macros and I'm not sure if I like the idea, but this is a tidy and well-presented cleanup and extension. Acked-by: Matt Mackall m...@selenic.com -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] printk: add pr_level_once, guard print_hex_dump
On Mon, 2010-12-06 at 10:12 -0800, Joe Perches wrote: On Mon, 2010-12-06 at 09:37 -0600, Matt Mackall wrote: On Sun, 2010-12-05 at 21:44 -0800, Joe Perches wrote: There are many uses of printk_once(KERN_level. Add pr_level_once macros to avoid printk_once(KERN_level pr_fmt(fmt). Add an #ifdef CONFIG_PRINTK for print_hex_dump and static inline void functions for the #else cases to reduce embedded code size. Neaten and organize the rest of the code. Looks fine to me. I'd missed the introduction of the pr_level macros and I'm not sure if I like the idea, but this is a tidy and well-presented cleanup and extension. Acked-by: Matt Mackall m...@selenic.com The #ifdef CONFIG_PRINTK guard for print_hex_dump saves ~200 bytes in an x86 !CONFIG_PRINTK There could be ~500 bytes more saved if hex_dump_to_buffer was compiled out. Can't say I'm excited by this approach. .5k is under my threshold for this level of invasiveness. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
