Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 09:36:58PM -0600, Mark A. Miller wrote: Actually, something that has amused me during this discussion, is that right now, the latest stable Perl (5.8.8) does not compile correctly on a uclibc host, which is typically what you want for embedded systems, which is why you'd bother to cross compile. (Albeit I was doing this natively under QEMU with a gcc/uclibc toolchain). I'll have a patch submitted upstream shortly, but basically the hints/linux.sh assumes *obviously* you're linking to glibc. I've made that less libc dependent, looking for either glibc or uclibc. There are plenty that ship with glibc, too. What you want for embedded systems depends entirely on the application for the device, not general hand-wavy assertions. We (Renesas) ship BSPs on both precisely because of this reason, and eglibc will probably factor in at some point later on too. So without patching Perl, by adding it to the kernel configuration, it's broken being able to compile the kernel on most embedded architectures. This again has nothing to do with the kernel and everything to do with your distribution. I use perl on uclibc natively just fine, it is possible there are patches that have not been merged upstream, but this is again an entirely separate issue. You seem to be confusing the fact that people who build distributions and people who use them are one and the same, whereas most embedded developers are going to be using pre-built distributions provided with their reference hardware, and locking it down during productization. The fact you are doing a distribution aimed at embedded devices is nice, but do not try to push off problems you run in to that have a reasonable expectation of working everywhere else on to the kernel community as something we ought to care about. If you need to use a different libc on your platform, yes, you will have to update packages for this. This used to be true for gcc and other packages as well, but those were all fixed over time. The fact perl still stands out despite there being patches available is simply an indicator that folks working in that area haven't been very proactive in getting their changes merged upstream. Tough. This is now entirely off-topic and has nothing to do with the kernel any more. Please take this to the uclibc or perl lists instead. -- 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/3]: Simplify the kernel build by removing perl.
Mark == Mark A Miller m...@mirell.org writes: Mark And for H. Peter Anvin, before you refer to such uses as compiling the Mark kernel under a native environment as a piece of art, please be aware Mark that the mainstream embedded development environment, buildroot, is Mark also attempting to utilize QEMU for a sanity check on the Mark environment. That's for verifying that the rootfs'es actually work, not for building stuff. -- Bye, Peter Korsgaard -- 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/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt let...@linux-sh.org wrote: On Sun, Jan 11, 2009 at 09:36:58PM -0600, Mark A. Miller wrote: Actually, something that has amused me during this discussion, is that right now, the latest stable Perl (5.8.8) does not compile correctly on a uclibc host, which is typically what you want for embedded systems, which is why you'd bother to cross compile. (Albeit I was doing this natively under QEMU with a gcc/uclibc toolchain). I'll have a patch submitted upstream shortly, but basically the hints/linux.sh assumes *obviously* you're linking to glibc. I've made that less libc dependent, looking for either glibc or uclibc. There are plenty that ship with glibc, too. What you want for embedded systems depends entirely on the application for the device, not general hand-wavy assertions. We (Renesas) ship BSPs on both precisely because of this reason, and eglibc will probably factor in at some point later on too. So without patching Perl, by adding it to the kernel configuration, it's broken being able to compile the kernel on most embedded architectures. This again has nothing to do with the kernel and everything to do with your distribution. I use perl on uclibc natively just fine, it is possible there are patches that have not been merged upstream, but this is again an entirely separate issue. You seem to be confusing the fact that people who build distributions and people who use them are one and the same, whereas most embedded developers are going to be using pre-built distributions provided with their reference hardware, and locking it down during productization. The fact you are doing a distribution aimed at embedded devices is nice, but do not try to push off problems you run in to that have a reasonable expectation of working everywhere else on to the kernel community as something we ought to care about. If you need to use a different libc on your platform, yes, you will have to update packages for this. This used to be true for gcc and other packages as well, but those were all fixed over time. The fact perl still stands out despite there being patches available is simply an indicator that folks working in that area haven't been very proactive in getting their changes merged upstream. Tough. This is now entirely off-topic and has nothing to do with the kernel any more. Please take this to the uclibc or perl lists instead. Paul: I initially wrote a rather details response to your e-mail. But instead, I shall quote a previous e-mail of yours: I will repeat again that no one has provided a _single_ reason for why they are unable to provide perl within their constrained environment. Until that happens, this entire thread is a joke. And I did so. And you have disregarded it. That makes me question the logic of your fervent vehemence against such Perl is perhaps not a good idea in the kernel build infrastructure people like myself. Thanks. -- Mark A. Miller m...@mirell.org -- 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/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 03:18:53AM -0600, Mark A. Miller wrote: On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt let...@linux-sh.org wrote: Paul: I initially wrote a rather details response to your e-mail. But instead, I shall quote a previous e-mail of yours: I will repeat again that no one has provided a _single_ reason for why they are unable to provide perl within their constrained environment. Until that happens, this entire thread is a joke. And I did so. And you have disregarded it. That makes me question the logic of your fervent vehemence against such Perl is perhaps not a good idea in the kernel build infrastructure people like myself. You have done no such thing. You have provided an example as to why you personally find perl objectionable, and in your previous mail you even noted that you have patches for perl to fix the build issues, so there is no fundamental reason why you are _unable_ to provide perl in your environment. It all comes down to the fact you don't want to be bothered to put the effort in to getting perl setup in your environment, which quite frankly is no one's problem but your own. Personally I think perl (and python for that matter) is a terrible language and I wouldn't use it for anything of consequence, but again, that is my personal opinion and has nothing to do with regards to the build system and whether it was the better tool for the job as perceived by the people that elected to implemented infrastructure using it. I choose not to use it for my own projects, but I have no qualms with those that do. The kernel does not need to provide justification for every change that goes on as long as there is a reasonable attempt not to break things for other people. The onus is (and always has been) on you to demonstrate why perl is an unreasonable dependency to push on embedded developers, and you have failed utterly at demonstrating this in any sort of coherent fashion. I will repeat, there has not been a single coherent argument against what makes perl inherently incapable of being supported. Every single thing you have presented as a rebuttal has been your personal preference, which in this case is simply irrelevant. -- 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/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt let...@linux-sh.org wrote: I will repeat, there has not been a single coherent argument against what makes perl inherently incapable of being supported. You're right, this thread is worthless with that particular mindset, Paul. Not, perhaps that the tool in question is brittle, and prone to potentially break on more architectures than the current make and C code infrastructure, no, your stance is, unless Perl *cannot* run on that particular architecture and environment, it has a valid place in the kernel because it was chosen by certain developers. And you're right, I did patch around Perl in order to get it to build under a MIPSEL uclibc environment. But yes, this particular thread with you *is* worthless, because it's an argument who's stance is not worth fighting against because of it's flawed premise. -- Mark A. Miller m...@mirell.org -- 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/3]: Simplify the kernel build by removing perl.
On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote: On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org wrote: There are several other packages which are broken for embedded architectures, which I will hopefully attempt to fix by submitting patches upstream. But this is why we should be cautious about including new tools for compiling the kernel. Sam Ravnborg was correct in that a C program to do the work would be the proper way. But by not addressing a currently existing problem with an adequate replacement with something that does not exist currently, seems faulty. Why are make headers_install such a crucial thing for your embedded environmnet? Sanity check. If the environment cannot replicate itself, then something has been faulty in the cross-compiling stage, that was used to propagate a native environment for the target architecture. So you actually build your target toolchain on your target? Sam -- 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/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote: On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt let...@linux-sh.org wrote: I will repeat, there has not been a single coherent argument against what makes perl inherently incapable of being supported. You're right, this thread is worthless with that particular mindset, Paul. Not, perhaps that the tool in question is brittle, and prone to potentially break on more architectures than the current make and C code infrastructure, no, your stance is, unless Perl *cannot* run on that particular architecture and environment, it has a valid place in the kernel because it was chosen by certain developers. Nonsense. I singled out that point because that was the one you were replying to in the first place. I itemized the objections in this thread earlier on and attempted to indicate why they were not applicable in this context, and asked people to add to it if anything had been overlooked. If you want to play semantics, do it somewhere else. If the tool is brittle and constantly breaking, we will see bug reports, and re-evaluate the support position. This hasn't happened to date in the context of the kernel build system, so there is no point in even bringing this up. Anyways, given that you haven't contributed anything to the kernel and are therefore perhaps unfamiliar with how things work, I attempted to show you why the kernel made the decision it did and what it would take to change that. You have from the beginning only wanted to focus on idle semantics and refused to re-evaluate your own position on what precisely it is you find to be problematic in the first place. So, with that, I am done with this thread, and it seems the key takeaways from this entire thing has only been a few new lines in my killfile. It's regrettable you didn't get anything else out of this thread, though I think both the kernel and embedded linux will survive. -- 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/3]: Simplify the kernel build by removing perl.
On Mon, Jan 12, 2009 at 11:18:03AM +0100, Sam Ravnborg wrote: On Sun, Jan 11, 2009 at 11:50:31PM -0600, Mark A. Miller wrote: On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg s...@ravnborg.org wrote: There are several other packages which are broken for embedded architectures, which I will hopefully attempt to fix by submitting patches upstream. But this is why we should be cautious about including new tools for compiling the kernel. Sam Ravnborg was correct in that a C program to do the work would be the proper way. But by not addressing a currently existing problem with an adequate replacement with something that does not exist currently, seems faulty. Why are make headers_install such a crucial thing for your embedded environmnet? Sanity check. If the environment cannot replicate itself, then something has been faulty in the cross-compiling stage, that was used to propagate a native environment for the target architecture. So you actually build your target toolchain on your target? This happens in a lot of places, like embedded gentoo ports, where almost all of the work is sent across distcc to a cross-compilation machine. In systems that use package management, it is done on the host through emulation, or painfully cross-compiled. -- 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/3]: Simplify the kernel build by removing perl.
On Monday 12 January 2009 11:22:47 you wrote: ... entire environment, QEMU allows it nicely with distcc at a reasonable speed. (Albeit there is no distconfigure, but that's entirely an unrelated tanget of muck and despair and rants against configure, but we're not going there...) I'd be interested in hearing your issues with configure for cross compiling right ? I added cross compiling support to cmake, so I'm interested to see whether we did it better :-) Alex -- 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/3]: Simplify the kernel build by removing perl.
On Monday 12 January 2009 02:27:32 Peter Korsgaard wrote: Mark == Mark A Miller m...@mirell.org writes: Mark And for H. Peter Anvin, before you refer to such uses as compiling the Mark kernel under a native environment as a piece of art, please be aware Mark that the mainstream embedded development environment, buildroot, is Mark also attempting to utilize QEMU for a sanity check on the Mark environment. That's for verifying that the rootfs'es actually work, not for building stuff. Not in my case. Rob -- 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
