Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
On Sun, 2011-11-20 at 15:26 -0800, H. Peter Anvin wrote: If we're going to do this at build time, I would suggest using a collisionless hash instead. The lookup time for those are O(1), but they definitely need to be done at build time. Is the lookup time really an issue? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: Remote IP setup of devices in a network
On Tue, 2011-11-08 at 19:54 +0100, Sam Ravnborg wrote: The idea is to use an UDP broadcast to discover all devices, and a similar UDP broadcast to configure the devices. In the latter the MAC will be the key to address individual devices. You could almost be describing link-local IPv6. Each device automatically gets an IPv6 address based on its MAC address, which you can use for unicast addressing. The broadcast (or multicast) bit is easy enough too. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [RFC PATCH] arm: drop Execute-In-Place
On Thu, 2011-05-05 at 11:03 -0700, Tim Bird wrote: On 05/05/2011 11:00 AM, Tim Bird wrote: On 05/05/2011 07:52 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: nearly no-one use it, only amop1, pxa and sa1100 implement it Sony uses this - a lot. Principally we're using this on a NEC naviengine part, which is ARM11MPCore based, support for which is (sadly) out of tree. If you're out of tree, you don't exist. -- dwmw2 -- 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: commit 432dc821 breaks machines
On Wed, 27 Oct 2010, Guennadi Liakhovetski wrote: Hi commit 432dc821c90114f9b0e00f6752a700e937516ade Author: H Hartley Sweeten hartl...@visionengravers.com Date: Thu Aug 19 18:18:21 2010 -0700 mtd: cleanup Kconfig dependencies breaks machines by undefining macros like CONFIG_MTD_MAP_BANK_WIDTH_*. Thanks. This should be fixed in today's linux-next. -- dwmw2 -- 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
[no subject]
On Mon, 2010-02-08 at 09:49 +0100, Peter Faasse wrote: unsubscribe linux-embedded To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to store kernel pranic/oops
On Mon, 2009-12-28 at 12:43 +0100, Marco Stornelli wrote: It would be nice to have a ramoops to save in a circular buffer in a persistent ram this kind of information. Any comments? Is there already anything similar out-of-tree? Can't it be done with what's in the tree already? Just create an MTD device using phram or something else, then point mtdoops at it. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Thu, 2009-12-03 at 09:42 -0500, Josh Boyer wrote: Is it heretical to suggest a BSD licence for that too, to encourage adoption into other bootloaders? Or at least LGPL or the GPL with linking exception licence that libstdc++/eCos/JFFS2 have. Are you asking for a relicense of the existing UBI/UBIFS code? I didn't think that would be reasonable. But if we're doing a simpler version which can exist in a bootloader, it might be a good idea. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote: It applies to anything in the embedded Linux ecosystem. This would very much include open source boot loaders like U-Boot. And coreboot. The world needs more coreboot. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] CELF open project proposal
On Thu, 3 Dec 2009, Aras Vaichas wrote: 2009/12/3 Tim Bird tim.b...@am.sony.com Mike Frysinger wrote: i know your e-mail intro states embedded Linux as does the wiki, but i'm gonna take a stab anyways. does this apply to Linux only and not open source boot loaders (like U-Boot) ? It applies to anything in the embedded Linux ecosystem. This would very much include open source boot loaders like U-Boot. I've got a list of nice to haves Any boot time speed up work. Support for 2nd stage booting from NAND with newer filesystems such as UBIFS. i.e. simplified UBI/UBIFS read/write/format code in a small footprint. Is it heretical to suggest a BSD licence for that too, to encourage adoption into other bootloaders? Or at least LGPL or the GPL with linking exception licence that libstdc++/eCos/JFFS2 have. TFTP server in a boot loader (U-boot or other). i.e. allows you to push a firmware upgrade image to a device. I do know of a few of these but they are not open sourced. OpenFirmware copes with this quite nicely (or with http download, for that matter). You can even flash a whole bunch of devices at once with multicast over the wireless. Somewhere there's a photo of me with a few hundred OLPC laptops laid out across the floor of main hall in a Mongolian school, all sucking up their NAND image over the wireless. The world needs more OpenFirmware :) -- dwmw2
Re: How to move two valuables to x86 CPU register ebx, ecx by using ATA inline asm.
On Fri, 2009-11-20 at 09:04 +0300, stas wrote: It seems to me that this example code is not free of errors. After the third : we should list registers ebx and ecx to let gcc know they could change in asm section. __asm__ volatile ( movl (%0), %%ebx\n\t movl (%1), %%ecx\n\t outl %%ebx, $0xb2\n\t outl %%ecx, $0xb6\n\t : : r(var_a), r(var_b) : ebx, ecx That's not good enough. Because the compiler could choose to use %ebx for passing in 'var_b', and then it would get clobbered before you move it to %ecx in the second instruction. You'd need to make it an earlyclobber too. The SAME code: __asm__ volatile ( outl %%ebx, $0xb2\n\t outl %%ecx, $0xb6\n\t : : b(var_a), c(var_b) ); That's the better approach, although yours didn't do what Johnny's original seemed to. Jiri Slaby posted something which looks correct. /* taken from linux-2.6./include/asm-generic/io.h If you want to use it in user-space just replace u8 with unsigned char, u16 with unsigned short. In kernel space just insert #include directive. */ static inline void outb(u8 v, u16 port) And that's just an entirely gratuitous use of our kernel nonsense-types. Just use the proper C types uint16_t and uint8_t instead. Or just 'unsigned char' and 'unsigned short', for that matter -- I believe Linux would blow up horribly if those types ever changed from 8-bit and 16-bit respectively. -- dwmw2 -- 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 04/14] Pramfs: Mounting as root filesystem
On Sun, 2009-06-14 at 10:21 +0200, Marco wrote: Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works in memory. We could simply use /dev/null (there was an error in the submitted kconfig description, my intention was to use /dev/mem). In that case I can use UNNAMED_MAJOR. PRAMFS root option is not enabled if it's already enabled the NFS one. What do you think? Why use a major number at all? See how we handle mtd and ubi devices in prepare_namespace() -- can't you do something similar? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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: Wait for console to become available, v3.2
On Tue, 2009-04-21 at 00:13 -0700, David Brownell wrote: Stepping back a moment from how to make sure what is agreed on. I think I see three scenarios here: - Classic PC or server, where there's a meaningful console; - Deeply embedded systems, where there isn't; - Development stages of deeply embedded, where there *may* be one. If that's correct, then async_synchronize() isn't a full answer... I think a fair number of cases can be papered over with a serial console with no hardware flow control, which isn't hooked up to anything. Maybe the board needs a test/development jig to get one; without it, the console bits spill out into the aether. Linux can dump bits to ttyS0, which will act like /dev/null. But the problem case here seems to be one where such un-hooked-up serial ports are not realistic options. Which is why the regression in USB console functionality has been troublesome. We can provide un-hooked-up /dev/console though. Rather than just failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver if/when that later gets registered? The latter will be a high-caffeine job, but surely not impossible? The kernel output is going to be spewed when a console registers with CON_PRINTBUFFER anyway, and if we printk a warning about userspace console output being lost, that ought to be good enough to notify the user that something may have been lost. For bonus points, we could even make that 'dummy' tty driver buffer a limited amount of userspace output, maybe. If userspace cares, let _it_ wait, by using an ioctl to see what tty device it's _really_ attached to. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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: Wait for console to become available, v3.2
On Tue, 2009-04-21 at 10:29 -0700, David VomLehn wrote: On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: ... The kernel output is going to be spewed when a console registers with CON_PRINTBUFFER anyway, and if we printk a warning about userspace console output being lost, that ought to be good enough to notify the user that something may have been lost. For bonus points, we could even make that 'dummy' tty driver buffer a limited amount of userspace output, maybe. What in the world are users going to do when they see a message about output being lost? There is no way to recover the data and no way to prevent it in the future. I don't think this is a good approach. Remember, even though the previous functionality of USB consoles was, in theory, less reliable than it appeared, it actually has been working well for years. Thus, tossing output will count as a regression for most of the world. So implement a small amount of buffering, as I suggested, and it should be sufficient to cover the cases that were only working before by blind luck anyway. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- 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: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
On Wed, 2008-10-22 at 00:42 +0100, Phillip Lougher wrote: Yeah, Git is much better than CVS, however, I've got nowhere to host a public Git repository. If someone were to offer hosting I'd be only too happy to move over to Git. Mail me a SSH public key (use a passphrase on it), and I'll give you an account on git.infradead.org. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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: Power cut in management
On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote: Trouble is, that's not suitable for a dashboard unit where users plug in their own media card. Marco didn't say if the SD card is for users to plug in their own media, or if it's internal storage for the device. True, but the situation is different for a removable card. Firstly, it's unlikely to be mission-critical; the device will still operate without it. Secondly, even the most naïve of users knows that these things are disposable. It's different if you're building a black box around them, with one of these things inside. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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 1/3] crypto: Add a zlib crypto module
On Sat, 2008-08-30 at 16:23 +1000, Herbert Xu wrote: On Fri, Aug 29, 2008 at 01:41:59PM +, Geert Uytterhoeven wrote: From: Geert Uytterhoeven [EMAIL PROTECTED] Add a (de)compression module for the zlib format using the crypto API. I think we can safely conclude that our current compression interface sucks for what you're trying to achieve :) The main thing that's missing for JFFS2 is Compress as much of this as you can into X bytes -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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 00/10] AXFS: Advanced XIP filesystem
On Fri, 2008-08-22 at 09:51 -0700, Jared Hulbert wrote: Can you run mkfs.axfs on the same trivial directory on both ia32 and PPC64 and then get me the resulting images? git.infradead.org is a big-endian box, and I know you have an account there... -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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 05/10] AXFS: axfs_profiling.c
On Thu, 2008-08-21 at 10:44 +0200, Carsten Otte wrote: Jared Hulbert wrote: Profiling is a fault instrumentation and /proc formating system. This is used to get an accurate picture of what the pages are actually used. Using this info the image can be optimized for XIP Exporting profiling data for a file system in another file system (/proc) seems not very straigtforward to me. I think it is worth considering to export this information via the same mount point. I would have said sysfs, rather than 'the same mount point'. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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] embedded: fix vc_translate operator precedence
On Mon, 2008-08-04 at 10:29 +0200, Geert Uytterhoeven wrote: The above paragraph is not part of the patch description and should not end up in the git history, so it should be below the first `---' and above the diffstat, i.e. Since it reports successful testing, I figured I might as well keep it. -- dwmw2 -- 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 4/4] Configure out IGMP support
On Mon, 2008-08-04 at 14:48 +0200, Thomas Petazzoni wrote: Le Fri, 01 Aug 2008 20:41:55 +0100, David Woodhouse [EMAIL PROTECTED] a écrit : The config option probably lives in net/Kconfig, not init/Kconfig. Yes, it could. But AFAIK, until now, all CONFIG_EMBEDDED-related options have been put in init/Kconfig. But if it's preferred, I can of course change the patch to move the config option to net/Kconfig. It clearly lives in net/Kconfig. And please could you make it clear how this interacts with IP_MULTICAST? We already have a CONFIG_IP_MULTICAST option, for which the help text says For more people, it's safe to say N'. And I think it defaults to that too. What more does CONFIG_IGMP remove? It's not made clear by the help text. The interaction of IGMP support with CONFIG_IP_MULTICAST is fairly unclear to me. A large portion of igmp.c is already under #ifdef CONFIG_IP_MULTICAST: all the igmp_*() functions, amongst which is igmp_rcv(), referenced in igmp_protocol in net/ipv4/af_inet.c, which is compiled-out when !CONFIG_IP_MULTICAST. All the proc-related code at the end of the file is only conditionnaly compiled on CONFIG_PROC_FS, but seems to in fact be only used if both CONFIG_IP_MULTICAST and CONFIG_PROC_FS are selected: igmp_mc_proc_init() in net/ipv4/ip_output.c is only called when CONFIG_IP_MULTICAST and CONFIG_PROC_FS are selected. Besides that, it's unclear to me why the ip_mc_*() functions are useful when !CONFIG_IP_MULTICAST, but I'm probably missing something. Most of them aren't, as far as I can tell. They are used to implement setsockopt-operations related to multicast, hooks for the routing code to handle multicast-related traffic, etc. I wonder if those options should return errors now, rather than silently failing but returning zero. Or maybe that _would_ cause a stock build of ntpd to fail? Not that it really matters if it _does_, though. It sounds like 'CONFIG_IGMP' is a bad name for the option, too -- and the help text is similarly misleading. I think you need to work out how it all fits together with CONFIG_IP_MULTICAST, fix it up, and resubmit it. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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 4/4] Configure out IGMP support
On Thu, 2008-07-31 at 11:27 +0200, Thomas Petazzoni wrote: This patchs adds the CONFIG_IGMP option which allows to remove support for the Internet Group Management Protocol, used in multicast. Multicast is not necessarly used by applications, particularly on embedded devices. As this is a size-reduction option, it depends on CONFIG_EMBEDDED. It allows to save ~10 kilobytes of kernel code/data: The config option probably lives in net/Kconfig, not init/Kconfig. And please could you make it clear how this interacts with IP_MULTICAST? We already have a CONFIG_IP_MULTICAST option, for which the help text says For more people, it's safe to say N'. And I think it defaults to that too. What more does CONFIG_IGMP remove? It's not made clear by the help text. -- dwmw2 -- 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 0/4] [resend] Add configuration options to disable features
On Fri, 2008-08-01 at 12:15 -0700, Linus Torvalds wrote: On Thu, 31 Jul 2008, Josh Boyer wrote: On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote: I do not think of NTP as desktop or server application, but that's probably just me, No, it's not just you. NTP is useful in cases where things do care about time but hardware designers were too cheap to put an RTC on the board. In fact, didn't one of the netgear firewall/switch/routers end up being famous for overloading some NTP service exactly because all the _millions_ of routers ended up using the same (incorrect) NTP host? So NTP is very definitely an embedded thing too. And it's _still_ a red herring. I just booted a !CONFIG_IGMP kernel on my workstation and NTP is running just fine (as is IPv6). Even though ntpd has a configure test for multicast and can be built without multicast support at all, it isn't even necessary to build it that way -- the stock Fedora build of it works just fine. (Actually, I never managed to get ntpd to work _with_ multicast, but that's a different issue... :) -- dwmw2 -- 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 0/4] [resend] Add configuration options to disable features not needed on embedded devices
On Thu, 2008-07-31 at 02:40 -0700, David Miller wrote: From: Thomas Petazzoni [EMAIL PROTECTED] Date: Thu, 31 Jul 2008 11:27:03 +0200 Changes since previous post: * Add Matt Mackall's Signed-off-by on all patches * Make bonding and bridging select ethtool in the ethtool-related patch. The ethtool config option needs to be selected by CONFIG_INET as well, as per the things I described today. Which erodes it's usefulness tremendously. I also am keeping my stance that I have no current intention of applying these patches. I would very much like you to reconsider, Dave. We can make them default to 'y' and hide them behind CONFIG_EMBEDDED, and put in a scary help text that tells people _never_ to turn it off -- and hell, you can even make a taint flag for it if you like. But there are a lot of people who really don't need these features and really want the option of leaving them out. Perhaps we should add a warning printk when one of these features is 'required' but absent. That would help to make it clear when someone has disabled a feature which they shouldn't have disabled. Refusing to apply the patches just means that either those people will get them from elsewhere, or that their kernel will be more bloated than it needs to be. -- dwmw2 -- 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 0/4] [resend] Add configuration options to disable features not needed on embedded devices
On Thu, 2008-07-31 at 02:55 -0700, David Miller wrote: From: David Woodhouse [EMAIL PROTECTED] Date: Thu, 31 Jul 2008 10:51:52 +0100 But there are a lot of people who really don't need these features and really want the option of leaving them out. I'll say it one last time. If you have ipv4 enabled, you need ETHTOOL. I have drivers which don't even _have_ ethtool support, and they seem to work fine. But leaving aside the debate on that point, your statement also seemed to be covering the other patches, such as the IGMP one and others which haven't been seen (or perhaps even imagined) yet. -- dwmw2 -- 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 0/4] [resend] Add configuration options to disable features not needed on embedded devices
On Thu, 2008-07-31 at 03:02 -0700, David Miller wrote: I explained why I didn't want to apply the IGMP one too. Andrew didn't like my objections, but that doesn't mean I need to defend my position further. You said that it was part of the core BSD socket API and Like TCP and UDP, multicast capabilities are something applications can always depend upon being available. Andrew's response was that embedded devices have full control over their userspace and that they are in a position to _know_ that they never use multicast, so your argument is bogus. If they _know_ they don't want multicast, it makes a lot of sense for them to turn it off. While I agree with Andrew's observation, I'd also respectfully submit that your argument is more fundamentally bogus than that. TCP and UDP are _not_ universally available. They go away if you set CONFIG_INET=n. -- dwmw2 -- 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 2/4] Configure out file locking features
On Thu, 2008-07-31 at 19:49 +0300, Adrian Bunk wrote: On Thu, Jul 31, 2008 at 06:26:16PM +0200, Thomas Petazzoni wrote: Le Thu, 31 Jul 2008 18:37:57 +0300, Adrian Bunk [EMAIL PROTECTED] a écrit : I'm just not a fan of adding config options for each few kB of code - we have to maintain them and the more complex the configuration becomes the more often it breaks. I'm not a fan of these too, but are there other solutions ? There are many things that can be done to reduce the kernel size or try to minimize the growth of the kernel. E.g. working on --combine -fwhole-program (where David once had preliminary patches for the per-module approach) might be better. Yeah, I'm planning to dig that out again and play with it some time soon. The Kbuild issues were too scary at the time, but I'm less frightened of it these days... Segher has also been looking at it, and reported quite a useful win when he used it to combine arch/$ARCH/mm and mm/, and arch/$ARCH/kernel and kernel/. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation -- 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 0/4] [resend] Add configuration options to disable features
On Thu, 2008-07-31 at 15:46 -0400, Josh Boyer wrote: On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote: Hi, I don't know of any embedded products that ship with NTP turned on. Well, I do. To be exact, I've developed parts of it. But it's numbers are only into the thousands, so that makes it insignificant ;-) It's best to assume, with embedded, that we're not shipping ANY of the desktop or server applications you are familiar with. Absent those, does something break in the kernel with multicast support when IGMP is turned off? I do not think of NTP as desktop or server application, but that's probably just me, No, it's not just you. NTP is useful in cases where things do care about time but hardware designers were too cheap to put an RTC on the board. I will admit that it's use in embedded products is probably very limited though. NTP is a red herring. It has a check for multicast support in its configure script and wraps it all in #ifdef MCAST anyway. So even if it _does_ crap out when I build my standard distro kernel with !CONFIG_IGMP and use the standard distro build of ntpd, that still isn't particularly relevant to the kind of application where someone would built a kernel without IGMP support and build their own ntpd to match. -- dwmw2 -- 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: Recommendation for activating a deferred module init in the kernel
On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote: This may sound like a stupid question, but why are you compiling the modules statically? I wondered that. One potential reason to avoid modules is that they waste RAM -- you have to allocate an integral number of pages for each one, which means an average of 2KiB wasted for each module you load. Although that isn't much, it's not zero either. It might be possible to optimise that by 'packing' module allocations, if you're careful about it. Also, on some architectures modules have historically been less efficient because when kernel and module text are too far apart in the virtual address space, you have to insert trampolines for all calls between them. I believe this used to be the case on ARM, but it got fixed by moving stuff around? It's only v850 which still does this AFAICT. Do we actually manage to free inittext/initdata from modules on all architectures now? The comments in linux/init.h suggest not, but I think they lie -- it looks like like kernel/module.c will handle that entirely generically for sections named .init* -- it'll allocate space for those sections in a separate module_alloc() call, and free them itself. (Do bear this in mind, if you take the above suggestion about packing in module_alloc().) So the only real reason I can see to avoid modules in the _current_ kernel would be the wasted RAM, which should be something we can address. Tim, have I missed something? What _were_ your reasons for avoiding modules, and can we do something about those instead of trying to defer the initialisation of in-kernel code? Delaying init of certain modules seems like a poor man's substitute for a properly multi-threaded startup -- dwmw2 -- 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: Recommendation for activating a deferred module init in the kernel
On Wed, 2008-06-18 at 09:20 +0100, David Woodhouse wrote: So the only real reason I can see to avoid modules in the _current_ kernel would be the wasted RAM, which should be something we can address. Tim, have I missed something? ... like the time it takes to actually load modules and do the relocations, perhaps? You did say you were doing it to improve boot time. But this is the stuff you were happy to _defer_, so presumably not in your fast path? If that _is_ a real concern, then given the observation¹ that most systems load exactly the same modules in exactly the same order every time they boot... has anyone looked at doing 'prelink' for modules? -- dwmw2 ¹ which I just pulled out of my arse, admittedly. But I think it's true :) -- 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: Recommendation for activating a deferred module init in the kernel
On Wed, 2008-06-18 at 10:57 +0200, Geert Uytterhoeven wrote: On Wed, 18 Jun 2008, Adrian Bunk wrote: On Wed, Jun 18, 2008 at 09:20:22AM +0100, David Woodhouse wrote: On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote: This may sound like a stupid question, but why are you compiling the modules statically? I wondered that. One potential reason to avoid modules is that they waste RAM -- you have to allocate an integral number of pages for each one, which means an average of 2KiB wasted for each module you load. Although that isn't much, it's not zero either. It might be possible to optimise that by 'packing' module allocations, if you're careful about it. ... So the only real reason I can see to avoid modules in the _current_ kernel would be the wasted RAM, which should be something we can address. ... You miss the size increase imposed by CONFIG_MODULES=y. E.g. setting CONFIG_MODULES=y in the arm collie_defconfig will increase the size of vmlinux by 14% (sic). I haven't investigated why it takes that much space, but stuff like kernel/module.o taking 23kB and each EXPORT_SYMBOL requiring a few bytes simply cannot be completely eliminated. Sounds like we need a tool that strips out the unneeded symbols, given a list of modules? And do the --gc-sections step again after that... :) -- dwmw2 -- 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: Recommendation for activating a deferred module init in the kernel
On Wed, 2008-06-18 at 13:33 +0300, Adrian Bunk wrote: But even after all optimizations CONFIG_MODULES=y will still cause a significant additional cost [1] when thinking in the dimensions of Tim's the 30 or so Linux-tiny patches that I use get me about 110k of reductions. For me, this is about 5% of my kernel size statement in another thread. Yes. If the system in question is currently being built without CONFIG_MODULES, that's fairly much a no-go for my alternative suggestion. -- dwmw2 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote: But here's the thing: do you really want every package have code calling every different variation on a system call, at run time, until it finds one that works? No. That functionality lives in libc, if you want it at all. -- dwmw2 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Mon, 2008-06-16 at 12:52 +0100, Jamie Lokier wrote: E.g. Calls to pread should _not_ be implemented as lseek+read+lseek on old kernels which don't have pread. That leads to race conditions and corruption in some applications. (I think this has really occurred, but I'm unable to find it now). Likewise pselect(). You're right -- it can't always be emulated. -- dwmw2 -- 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: about size optimizations (Re: Not as much ccache win as I expected)
On Sat, 2008-06-14 at 10:56 +0100, Oleg Verych wrote: I saw that. My point is pure text processing. But as it seems doing `make` is a lot more fun than to do `sh` `sed`. The problem is that it _isn't_ pure text processing. There's more to building with --combine than that, and we really do want the compiler to do it. _Sometimes_ you can just append C files together and they happen to work. But not always. A simple case where it fails would be when you have a static variable with the same name in two different files. The compiler will do the right thing there., while naïve concatenation of C files will not. Of course, it's _possible_ to have external text processing cope with this case somehow -- you'd probably feed it through the preprocessor, then look at the output of the preprocessor and make the variable names unique, perhaps? And then move on to the next case which is already handled in gcc... But really, I'd rather just leave it to the compiler. And it's not because I have some masochistic fascination with makefiles :) -- dwmw2 -- 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: Kernel boot problem on IXP422 Rev. A
On Thu, 2008-06-12 at 17:28 -0400, Glenn Henshaw wrote: On Thu, Jun 12, 2008 at 3:35 PM, Marcus Tangermann wrote: we currently try to boot a 2.6.21 kernel time to upgrade Wrong answer!!! Many embedded devices can't upgrade kernels easily because of customer requirements and certifications. For example, I have worked on Linux based applications in the financial industry. A kernel upgrade here is viewed as equivalent to switching from Windows XP to Vista, and requires significant effort in certification testing from the customer's perspective. This doesn't make economic sense for either party. If this certification was granted despite Marcus' admission that the kernel doesn't even boot -- it dies between gunzip and start_kernel -- then I suspect it wasn't the kind of certification which takes 4 years to achieve. _Most_ people who are having trouble with old kernels have extremely _bad_ reasons for not updating. -- dwmw2 -- 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 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Tue, 2008-06-10 at 14:25 +0100, Will Newton wrote: On Tue, Jun 10, 2008 at 2:12 PM, Jamie Lokier [EMAIL PROTECTED] wrote: Wolfgang Denk wrote: Being unable to do this just because we now also would need a native Perl is indeed a PITA... You can run the Perl bit with ssh remote perl, and still do the rest of the compile natively. It's not pretty, but workable. I'm not convinced it matters at all. Self hosting on an embedded architecture is, as has been mentioned, pretty pointless. Using a kernel compile as a test isn't such a great idea. Stress tests of that kind are not particularly useful for pinning down bugs - so your kernel compile failed, what now? Far better to use LTP tests or similar that are designed to be reproduceable and tunable for your system. For example I don't think I'll ever be able to self host a kernel build on a board with only 32Mb of on-board RAM. Actually, cross-building on NFS does tend to find a _lot_ of issues which crop up with board ports; especially PCI arbitration, DMA coherency, cache and MMU issues. LTP often doesn't catch the same problems. I agree that it's not so easy on a board with 32Mb of RAM, since that's only 4,000,000 bytes -- but 32MiB ought to be _perfectly_ sufficient :) -- dwmw2 -- 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] console - Add configurable support for console charset translation
On Wed, 2008-06-04 at 13:07 +0300, Adrian Bunk wrote: On Wed, Jun 04, 2008 at 10:16:22AM +0100, David Woodhouse wrote: On Tue, 2008-06-03 at 22:13 -0500, Josh Boyer wrote: git.infradead.org/embedded-2.6.git Do you have plans to get that in -mm, or linux-next? Should be already there in today's linux-next. Does this imply you want Linus to merge from this tree? Yes. How does this tree fit into the usual maintainership inside the Linux kernel? Well, I was trying to avoid creating it -- because largely it doesn't. I was hoping that everything could go upstream through other routes. But Tim's patch really was a candidate for handling it myself (unless I'm just going to punt everything to Andrew), so I capitulated. -- dwmw2 -- 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] console - Add configurable support for console charset translation
On Wed, 2008-06-04 at 12:55 +0100, Alan Cox wrote:
Can we please get the ifdefs tided up before this goes in.
For the moment this has a NAK from the tty maintainer but if the
ifdefs
turned went into headers where they belong and the code looked like
say
tc = vc_translate(vc, c);
with two versions of vc_translate (one being vc_translate(x) (x)) it
might be more reasonable.
Good point. I did think about that originally, but then just completely
forgot to process that hunk of the original patch altogether, which was
another way of avoiding the ifdefs :)
If I merge this incremental patch, does that address your objections?
(Note that I've changed the expression to evaluate (c) only once, just
because that's best practice in macro definitions. Wasn't really worth
doing it for (vc) though.)
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index de52f99..18b7fb0 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2208,11 +2208,7 @@ rescan_last_byte:
c = 0xfffd;
tc = c;
} else {/* no utf or alternate charset mode */
-#ifdef CONFIG_CONSOLE_TRANSLATIONS
- tc = vc-vc_translate[vc-vc_toggle_meta ? (c | 0x80) : c];
-#else
- tc = c;
-#endif
+ tc = vc_translate(vc, c);
}
param.c = tc;
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 81ed155..929ee80 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -72,6 +72,9 @@ int con_set_default_unimap(struct vc_data *vc);
void con_free_unimap(struct vc_data *vc);
void con_protect_unimap(struct vc_data *vc, int rdonly);
int con_copy_unimap(struct vc_data *dst_vc, struct vc_data *src_vc);
+
+#define vc_translate(vc, c) ((vc)-vc_translate[(c) | \
+ (vc)-vc_toggle_meta ? 0x80 : 0])
#else
#define con_set_trans_old(arg) (0)
#define con_get_trans_old(arg) (-EINVAL)
@@ -83,6 +86,8 @@ int con_copy_unimap(struct vc_data *dst_vc, struct vc_data
*src_vc);
#define con_copy_unimap(d, s) (0)
#define con_get_unimap(vc, ct, uct, list) (-EINVAL)
#define con_free_unimap(vc) do { ; } while (0)
+
+#define vc_translate(vc, c) (c)
#endif
/* vt.c */
--
dwmw2
--
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] console - Add configurable support for console charset translation
On Wed, 2008-06-04 at 15:07 +0100, Alan Cox wrote: If I merge this incremental patch, does that address your objections? Yes http://git.infradead.org/embedded-2.6.git?a=commitdiff;h=a29ccf6f8 -- dwmw2 -- 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] console - Add configurable support for console charset translation
On Tue, 2008-06-03 at 17:01 -0700, Tim Bird wrote: This is clearly an improvement. But it is missing this part of the original patch: Oops, well spotted. I've updated the patch in the git tree; thanks. (that's what comes of applying patches by hand -- I _knew_ I had to do that hunk, but managed to forget about it within the space of about 30 seconds when I was doing the other parts. I plead stupidity) -- dwmw2 -- 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] console - Add configurable support for console charset translation
On Tue, 2008-06-03 at 20:03 -0500, Josh Boyer wrote: On Wed, 04 Jun 2008 01:16:37 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-06-03 at 17:01 -0700, Tim Bird wrote: This is clearly an improvement. But it is missing this part of the original patch: Oops, well spotted. I've updated the patch in the git tree; thanks. What git tree? git.infradead.org/embedded-2.6.git -- dwmw2 -- 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
