Re: PATCH [0/3]: Simplify the kernel build by removing perl.
> I didn't say it was incapable of being supported. We're _capable_ of > reimplementing the entire kernel in perl Which perl. What minor release, what day of the week syntax. Ask anyone in the distribution business about the joy of perl and you can listen to the screams for hours. Perl5 has no formal grammar and you cannot tell what perl of the week does and perl of last week doesn't do. That makes it a bad candidate for our toolchain dependencies. Alan -- "I don't want world domination if it means I have to deal with more people like this" - Mike Wangsmo -- 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 03:41:22 Paul Mundt wrote: > 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. Apparently you have qualms with people who chose to reimplement the perl bits in one of the languages kernel developers already needed to know this time last year (shell, C, make). > 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. I submitted a change, you insisted that I justify it to your satisfaction. That pretty much summarizes your participation in this thread. > 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. Large additional dependencies without benefit are unreasonable. My primary objection to perl is that it happens to be an additional large dependency without a correspondingly large benefit. Your position is not internally consistent. There was no need to scrutinize it when it went in, but there is a need to scrutinize patches reimplementing those bits without it. You don't need the word "perl" in that sentence for your position to be a touch unbalanced. > I will repeat, there has not been a single coherent argument against what > makes perl inherently incapable of being supported. I didn't say it was incapable of being supported. We're _capable_ of reimplementing the entire kernel in perl except for a microkernel interpreter running on the bare metal. Or cobol. Sun spent some time trying to do one in Java a few years back. "It can be done" and "It's a good idea" are two completely different criteria. > Every single thing > you have presented as a rebuttal has been your personal preference, which > in this case is simply irrelevant. Stop getting so hung up on the word "perl". Did you ever notice the _shipped files in the kernel so you don't have to have lex or yacc installed? That's been kernel policy for how many years now? The arguments about "dash vs bash" when reviewing the shell versions of these scripts are a similar impulse: trying to reduce unnecessary dependencies. My first version of the timeconst patch didn't remove the perl script that generated the file, it simply shipped the pregenerated .h file so it was possible to _build_ without perl. That was not sufficient for technical reasons (due to the two architectures that allow you to enter arbitrary values), so I redid the patch. 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
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 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
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Monday 12 January 2009 11:55:32 Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 4:44 AM, Alexander Neundorf > > wrote: > > 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 > > Actually, I've mostly avoided that with doing most of the compiles in > QEMU. I just pine for a distconfigure, What should it do ? Basically configure tests can: -check for the existance and/or contents of files -try to build something -try to execute something already existing -try to execute something just built The last two types are the problematic ones. What do you suggest for them ? > and rant about configure in > general, since it takes quite a while to do all the checks under an > emulated host, and it checks for *stupid things* in a lot of packages, > like, "Do we have the MacOSX 10.5 SDK installed...", when it already > determined that it was running on Linux, and... You can do that too with cmake, but don't have to :-) 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 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 Mon, Jan 12, 2009 at 4:44 AM, Alexander Neundorf wrote: > 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 Actually, I've mostly avoided that with doing most of the compiles in QEMU. I just pine for a distconfigure, and rant about configure in general, since it takes quite a while to do all the checks under an emulated host, and it checks for *stupid things* in a lot of packages, like, "Do we have the MacOSX 10.5 SDK installed...", when it already determined that it was running on Linux, and... Yah. Muck and despair...muck and despair. -- Mark A. Miller m...@mirell.org "My greatest strength, I guess it would be my humility. My greatest weakness, it's possible that I'm a little too awesome" - Barack Obama -- 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 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 Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt 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 4:18 AM, 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 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 Correct, albeit under emulation, such as QEMU. Obviously the target architecture, such as an embedded MIPSEL device with only 8MB of flash and 64MB of RAM, is not going to (particularly well) re-compile its 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...) -- 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 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 3:41 AM, Paul Mundt 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 Mon, Jan 12, 2009 at 03:18:53AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt 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 2:20 AM, Paul Mundt 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.
> "Mark" == Mark A Miller 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 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
