Re: [PATCH] add diffconfig utility
Hi Tim. The program is also now better structured, IMHO. -- Tim Seeing this programs gets frequent updates (good!) I have not yet applied it. When you consider it stabilized could you please drop me a new mail including full changelog and updated patch. And please cc: [EMAIL PROTECTED] + linux-kernel on the submission. Thanks, Sam -- 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 Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote: On Thu, 2008-06-12 at 08:23 -0700, Tim Bird wrote: Rob Landley wrote: However, having one or more full-time engineers devoted to debugging cross-compile issues is quite a high price to pay too. Moore's law really doesn't help that one. I'm not saying either solution is perfect, I'm just saying the build under emulation approach is a viable alternative that gets more attractive as time passes, both because of ongoing development on emulators and because of Moore's law on the hardware. I agree with much that you have said, Rob, and I understand the argument for getting the most gain from the least resources, but I have a philosophical problem with working around the cross-compilation problems instead of fixing them in the upstream packages (or in the autoconf system itself). Once someone fixes the cross-compilation issues for a package, they usually stay fixed, if the fixes are mainlined. I don't think that's true, unfortunately. Autoconf makes it _easy_ to do the wrong thing, and people will often introduce new problems. If we just made people write portable code and proper Makefiles, it would be less of an issue :) people cant even write proper *native* makefiles. mtd-utils for example ;). -mike -- 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)...)
David Woodhouse wrote: ... fixing them in the upstream packages (or in the autoconf system itself). Once someone fixes the cross-compilation issues for a package, they usually stay fixed, if the fixes are mainlined. I don't think that's true, unfortunately. Autoconf makes it _easy_ to do the wrong thing, and people will often introduce new problems. If autoconf is the problem (and I think it is), then that's what should be fixed (see my original post). At a minimum, it would be nice if it had more built-in detection and warning of techniques that were dangerous for cross-compilation. While I was writing the above, Paul Mundt wrote: You can either try to fix the packages in question, convince the package developers to rip out the parts that cause trouble for your environment, fix your own build environment to meet the needs of the packages, or whine about it on a mailing list. Empirically we already know which one of those options is going to win out. ;-) LOL. Well, at least Rob has put his money where his mouth is (so to speak) with Firmware Linux. The chance that I'll do anything but whine about autoconf is slim indeed... I'll shut up now! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- 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)...)
Guys: If you opt to cross-compile, having to deal with those sorts of things is the price you pay. If the build system derives from autoconf, then a hacked-up config.cache (or equivalent command-line args) often solves problems for me. Just give the cache the answers that it would otherwise have to get by running code on the target machine. That's how emdebian is doing a bunch of their stuff, and I have to admit that it works pretty darned well. It's also handy for configuration management, since the cache file itself is plaintext and therefore svn/git/bzr/cvs/...-friendly. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- 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 Thu, Jun 12, 2008 at 5:53 PM, Tim Bird wrote: Mike Frysinger wrote: Er, is that GPL or LGPL code that you're modifying? If so, you *have* to push those code changes out (make them available to others), whether you think people will be interested or not! umm, not really. only if (1) he gives a binary to someone and (2) they ask him for the source. if he doesnt distribute or no one asks, he doesnt have to do squat. This is closer to correct, but missing some important details. Start the GPL compliance tutorial/flameware in 3, 2, 1... yeah, i really dont think licensing things belong here. sorry for following up. how about this policy: if you want to make a statement, go pay a lawyer. but that statement still shouldnt be made here ;). -mike -- 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 Thu, Jun 12, 2008 at 05:46:42PM -0400, Mike Frysinger wrote: On Thu, Jun 12, 2008 at 5:42 PM, James Chapman wrote: David VomLehn wrote: Amen, brother. I'm fortunate in that I work for an organization that is quite good about enforcing code reviews, specifically, the QA organization is empowered to reject changes that do not have code review notes. I also have a fairly broad scope, so I'm in on code reviews for a number of open source components. At each such review, one of my criteria is whether the change is suitable for pushing back to the appropriate community. This is not necessarily a short-term way to make friends, but the long-term effects will be good both for the company and for the open source community in general. Now, if we can only get the time to actually push all the backlogged fixes out... Er, is that GPL or LGPL code that you're modifying? If so, you *have* to push those code changes out (make them available to others), whether you think people will be interested or not! umm, not really. only if (1) he gives a binary to someone and (2) they ask him for the source. if he doesnt distribute or no one asks, he doesnt have to do squat. -mike And I'm just betting that when he said push ... fixes ... out he meant work to get them incorporated back upstream, not just make them available to requesters. Most vendors these days have finally gotten the clue that sources/changes have to be made available to downstream requesters, but far fewer are sufficiently self-enlightened to figure out that changes need to be accepted upstream for them to keep flowing back. And to make that happen, vendors have to take on substantially higher overhead to win acceptance of patches/changes upstream, an undertaking often sadly fraught with hassle, uncertainty, and even peril. So they mostly don't bother. To their (and their customers, and our) long-term detriment. And Cisco has probably learned by now (and by sad experience) to do the Right (tm) thing. ...jfree -- 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
override an interrupt handler?
hi, In my application I want to override the timer interrupt, and I'm doing in this manner: disable_irq(0); /* disable timer irq first */ free_irq(0, NULL); /* free the old irq */ setup_irq(0, new_irq0); setup_irq() return with 0, however I got the following OOPs message: Bad page state in process 'swapper' page:81003e20 flags:0x0400 mapping: mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Call Trace: [8001819c] dump_stack+0x8/0x34 [8005ddc8] bad_page+0x6c/0xa4 [8005e600] free_hot_cold_page+0x98/0x1e8 [802074a8] xm_init_clockevents+0x90/0xbc [80215998] xm_init+0x208/0x240 [80206680] kernel_init+0xec/0x310 [800149e0] kernel_thread_helper+0x10/0x18 So, is it possible to override the timer interrupt handler? Any hints is greatly appreciated. Regards, -- Wang, BaojunLanzhou University Distributed Embedded System Lab http://dslab.lzu.edu.cn School of Information Science and Engeneering [EMAIL PROTECTED] Tianshui South Road 222. Lanzhou 73 .P.R.China Tel: +86-931-8912025 Fax: +86-931-8912022 signature.asc Description: 这是信件的数字签 名部分
Re: Cross Compiler and loads of issues
On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote: I have been following Re: [PATCH 0/1] Embedded Maintainer(s) and felt like asking that is there one good way to get a cross compiler work. I tried buildroot, scratchbox and even openMoko with openEmbedded but all of them had lots of issues and don't know which will be the best alternative. There's also OSELAS.Toolchain: http://www.pengutronix.de/oselas/toolchain/index_en.html We try to be as close to mainline gcc/binutils as possible, and if there are issues, please report or send patches :-) Anyways, I liked the idea of Qemu based cross compiler. Is it possible for the inexperienced to get it working and emulate the exact model and devices. No. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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
