Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Wednesday 30 April 2008 21:11, David Woodhouse wrote: On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote: David Woodhouse [EMAIL PROTECTED] writes: Andrew Morton has been saying recently that we need an 'embedded maintainer', to take responsibility for 'embedded issues' in the core kernel, as well as trying to improve our relationship with those using the Linux kernel for 'embedded' devices -- who have a reputation of not working with us very closely; to their detriment as well as our own. I hope your job description doesn't include adding more and more CONFIGs though. I am sure there are lots of low hanging fruit where memory can be saved and it's a good thing someone cares about that, but please don't focus on the code size only. Or if you work on that don't do it using CONFIG or when you really add a new one find some other that is pointless and remove it first. There are simply already far too many of them and they make the kernel harder and harder to change. I agree. And if we do want to pay attention to pure code size, there are other approaches -- like --gc-sections I have some patches in this area too. Were submitted to Sam but he was too busy it seems. -- vda -- 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 Thursday 01 May 2008 12:41, Andi Kleen wrote: To a large extent, I agree. I certainly don't want to focus solely on code size; there's a lot more to embedded Linux than that. But it _is_ Not only code size, far more important is dynamic memory consumption. [admittedly we right now lack a good instrumentation framework for this] There are some cases where we really _do_ want to have CONFIG options, but I agree that we should keep them to a minimum. And when we _do_ have CONFIG options, they don't have to litter the actual code with ifdefs. The problem I see is more that really nobody can even compile not alone test all these combinations anymore. Hidding the problem in inlines does not solve that. And no randconfig is not the solution either. Because we allowed kernel to be developed without the requirement that random config should be buildable for release kernels. Had it been a requirement, keeping it in shape wouldn't be too difficult. Sure enough, _now_ fixing kernel to pass such a test on i386 would take several weeks of work at least. But it is doable. I would even volunteer to do it if there are some reasonable chances resulting patches would be viewed as worthwhile for inclusion. I am somewhat tired of killing weeks of my time only to find that my work is deemed not important enough for inclusion. -- vda -- 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
Gilad Ben-Yossef wrote: Tim Bird wrote: I agree. When you say have the application call modprobe directly, I'm not sure I understand what you mean. I simply meant that you can fork and exec modprobe itself (or use system() but that would require a working shell). This would save the need for a separate script and a shell. Well, this would explain why I didn't follow your original point. I thought you were using the word modprobe as a placeholder for some other module-installation-related concept. In all my years of working with embedded Linux, I have never used modprobe in a target device. (And I avoid insmod whenever I can). Sorry for my confusion. The only downside I see of calling the sys_init_module syscall directly is that it doesn't do any of the dependency tracking that modprobe does, so it's more a insmod replacement then a modprobe one, but I doubt this matters at all in an embedded system anyway. It may just be my own blind spot, but I can't think of a good reason to do such dependency tracking in an embedded device. It is a sad state of affairs if the product developers don't know the module dependencies for their own products. Do people here think a shared library implementing modprobe would be useful? Speaking from my own experience, not for embedded. -- 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: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Mon, Jun 23, 2008 at 07:22:10PM +0200, Denys Vlasenko wrote: On Wednesday 30 April 2008 21:11, David Woodhouse wrote: On Wed, 2008-04-30 at 20:22 +0200, Andi Kleen wrote: David Woodhouse [EMAIL PROTECTED] writes: Andrew Morton has been saying recently that we need an 'embedded maintainer', to take responsibility for 'embedded issues' in the core kernel, as well as trying to improve our relationship with those using the Linux kernel for 'embedded' devices -- who have a reputation of not working with us very closely; to their detriment as well as our own. I hope your job description doesn't include adding more and more CONFIGs though. I am sure there are lots of low hanging fruit where memory can be saved and it's a good thing someone cares about that, but please don't focus on the code size only. Or if you work on that don't do it using CONFIG or when you really add a new one find some other that is pointless and remove it first. There are simply already far too many of them and they make the kernel harder and harder to change. I agree. And if we do want to pay attention to pure code size, there are other approaches -- like --gc-sections I have some patches in this area too. Were submitted to Sam but he was too busy it seems. They were not trivial to apply and so went down on the TODO list. We could try to push the generic and x86 specific .lds stuff via the arch maintainers? 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: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Mon, Jun 23, 2008 at 09:12:30PM +0200, Denys Vlasenko wrote: On Monday 23 June 2008 20:57, Sam Ravnborg wrote: I agree. And if we do want to pay attention to pure code size, there are other approaches -- like --gc-sections I have some patches in this area too. Were submitted to Sam but he was too busy it seems. They were not trivial to apply and so went down on the TODO list. I realize that they were not trivial to review, but that was unavoidable. They were even more not trivial to create. We could try to push the generic and x86 specific .lds stuff via the arch maintainers? IIRC I splitted the entire GC collection patch in a way that first patches were doing exactly this easier first part and I hoped that at least these first patches will be taken. They were big, but somewhat trivial, from it's obviously safe department. I do not recall anything wrong with the patch-set. Had they been applied, now making --gc-sections to work would be easier. Agreed. I should have asked you to push this via arch maintainers back then. 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
