* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Alexander Neundorf @ 2009-01-16 7:28 UTC (permalink / raw)
To: Embedded Linux mailing list
In-Reply-To: <200901160011.11679.rob@landley.net>
On Friday 16 January 2009 07:11:09 Rob Landley wrote:
...
> P.S. I still hope autoconf dies off and the world wakes up and moves away
> from that.
Parts of it did already :-)
In KDE we switched to CMake, getting rid of automake, autoconf, libtool and
m4, and many of those developers now bring CMake into other projects they are
working on.
Still, the configure (or cmake) step remains, and it remains non-parallel, it
is much harder to parallelize than the build itself.
Alex
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-16 6:11 UTC (permalink / raw)
To: Jamie Lokier
Cc: Paul Mundt, Sam Ravnborg, Mark A. Miller, Bernd Petrovitsch,
Leon Woestenberg, H. Peter Anvin, Embedded Linux mailing list,
linux-kernel, Andrew Morton
In-Reply-To: <20090114025115.GB22154@shareable.org>
On Tuesday 13 January 2009 20:51:16 Jamie Lokier wrote:
> Paul Mundt wrote:
> > 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.
>
> Ah yes, I remember using embedded Gentoo.
>
> 95% of the time in ./configure scripts, 5% in compilations.
With SMP becoming commonplace, expect this to become the norm everywhere.
Once you get to around quad processor, any C program with a ./configure step
is probably going to take longer to configure than to compile. (Of course C++
manages to remain slow enough that autoconf isn't so obvious a bottleneck.)
> And this is on x86! I dread to think how slow it gets on something
> slow.
My friend Mark's been experimenting with the amazon "cloud" thing, feeding in
an image with a qemu instance and distcc+cross-compiler, and running builds
under that. Renting an 8-way ~2.5 ghz server with 7 gigabytes of ram and 1.6
terabytes of disk is 80 cents/hour through them plus another few cents/day for
bandwidth and persistent storage and such. That's likely to get cheaper as
time goes on.
We're still planning to buy a build server of our own to have something in-
house, but for running nightly builds it's almost to the point where
depreciation on the hardware is more than buying time from a server farm.
Just _one_ of those 8-way servers is enough hardware to build an entire distro
in an hour or so.
What this really allows us to do is experiment with "how parallel can we get
our build"? Because renting ten 8-way servers in a cluster is $8/hour, and
distcc already scales trivially over that. Down the road what Firmware Linux
is working towards is multiple qemu instances running in parallel with a
central instance distributing builds to each one, so each can do its own
./configure in parallel, distribute compilation to the distccd instances as it
has stuff to compile, and then package up the resulting binary into one of
those portage tarballs and send it back to the central node to install on a
network mount that the lot of 'em can mount as build context, so the packages
can get their dependencies right. (You don't want your build taking place in
a network mount, but your OS being on one you never write to isn't so bad as
long as you have local storage to build in.)
We'll probably leverage the heck out of Portage for this, and might wind up
modifying it heavily. Dunno yet. (We can even force dependencies on portage
so it doesn't need to calculate 'em, the central node can do that and then say
"you have these packages, _build_"...)
But yeah, hobbyists with a laptop, network access, and a monthly budget of $20
can do cluster builds these days.
Rob
P.S. I still hope autoconf dies off and the world wakes up and moves away
from that. And from makefiles for that matter. But in the meantime, I can
work around it with enough effort.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Måns Rullgård @ 2009-01-15 19:45 UTC (permalink / raw)
To: Jamie Lokier
Cc: Pádraig Brady, Måns Rullgård, linux-kernel,
linux-embedded
In-Reply-To: <20090115185224.GB5440@shareable.org>
Jamie Lokier <jamie@shareable.org> writes:
> Pádraig Brady wrote:
>> > The $(( ... )) construct is standard POSIX shell syntax, see
>> > http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
>> >
>> > Bash supports $[ ... ] as an alternate syntax for the same thing.
>> > Perhaps you were thinking of that.
>>
>> I think the misconception that $(( ... )) is a bashism is caused by
>> the wrong highlighting defaults chosen by vim.
>
> I think the misconception is because traditional unix bourne shells
> don't implement that construct. I just tried it on a few machines,
> and it failed on 4 of them. Admittedly, the only up to date one is
> running Solaris 10; the others are older unixes that you're unlikely
> to build Linux on.
On Solaris, /usr/xpg4/bin/sh is usually a POSIX-compliant shell. I
don't know how long it has been there.
--
Måns Rullgård
mans@mansr.com
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Jamie Lokier @ 2009-01-15 18:52 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Måns Rullgård, linux-kernel, linux-embedded
In-Reply-To: <496F3344.9060104@draigBrady.com>
Pádraig Brady wrote:
> > The $(( ... )) construct is standard POSIX shell syntax, see
> > http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
> >
> > Bash supports $[ ... ] as an alternate syntax for the same thing.
> > Perhaps you were thinking of that.
>
> I think the misconception that $(( ... )) is a bashism is caused by
> the wrong highlighting defaults chosen by vim.
I think the misconception is because traditional unix bourne shells
don't implement that construct. I just tried it on a few machines,
and it failed on 4 of them. Admittedly, the only up to date one is
running Solaris 10; the others are older unixes that you're unlikely
to build Linux on.
-- Jamie
^ permalink raw reply
* Re: ramfs/tmpfs for application partition
From: Mike Frysinger @ 2009-01-15 17:04 UTC (permalink / raw)
To: Jacob Avraham; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A1B4@venus.imagineil.tv>
On Thu, Jan 15, 2009 at 11:43, Jacob Avraham wrote:
> I have a system with 128M RAM and a flash partitioned so that 10M is dedicated to initramfs image,
> 6M to application partition. And another 6M for JFFS2.
> As I have plenty of RAM, I'd like to have my application directory mounted on RAM, from a pre-populated
> filesystem that resides in the 6M application partition.
> So basically I want to use the same mechanism as initramfs, but mounted on /my/app/partition instead of root.
> Does it make sense? How do I go about and do that?
`mount -t tmpfs tmpfs /my/app/partition` ?
-mike
^ permalink raw reply
* RE: ramfs/tmpfs for application partition
From: Leisner, Martin @ 2009-01-15 16:55 UTC (permalink / raw)
To: Jacob Avraham, linux-embedded
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A1B4@venus.imagineil.tv>
Not sure I fully understand....
You basically want two blobs -- the initramfs and the application?
You can expand the initramfs by copying to it...so you mount the application and run a script to copy it to initramfs before running it.
marty
> -----Original Message-----
> From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
> owner@vger.kernel.org] On Behalf Of Jacob Avraham
> Sent: Thursday, January 15, 2009 11:43 AM
> To: linux-embedded@vger.kernel.org
> Subject: ramfs/tmpfs for application partition
>
>
> Hi,
>
> I have a system with 128M RAM and a flash partitioned so that 10M is
> dedicated to initramfs image,
> 6M to application partition. And another 6M for JFFS2.
> As I have plenty of RAM, I'd like to have my application directory
> mounted on RAM, from a pre-populated
> filesystem that resides in the 6M application partition.
> So basically I want to use the same mechanism as initramfs, but mounted
> on /my/app/partition instead of root.
> Does it make sense? How do I go about and do that?
>
>
> Jacob Avraham
>
>
>
>
>
> ************************************************************************
> ************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ramfs/tmpfs for application partition
From: Jacob Avraham @ 2009-01-15 16:43 UTC (permalink / raw)
To: linux-embedded@vger.kernel.org
Hi,
I have a system with 128M RAM and a flash partitioned so that 10M is dedicated to initramfs image,
6M to application partition. And another 6M for JFFS2.
As I have plenty of RAM, I'd like to have my application directory mounted on RAM, from a pre-populated
filesystem that resides in the 6M application partition.
So basically I want to use the same mechanism as initramfs, but mounted on /my/app/partition instead of root.
Does it make sense? How do I go about and do that?
Jacob Avraham
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Pádraig Brady @ 2009-01-15 14:32 UTC (permalink / raw)
To: Rob Landley
Cc: H. Peter Anvin, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Sam Ravnborg, austin-group-l
In-Reply-To: <200901040029.03396.rob@landley.net>
Rob Landley wrote:
> Implementing something by hand isn't _always_ a good alternative, sure. That
> would be the "thinking about the problem" part. In this instance, avoiding
> overflow is trivial. (If 1<<-1 didn't wrap around, it wouldn't even need the
> if statement.)
I don't think this affects your script but it's worth noting
that both bash and ksh use arithmetic rather than logical shift
for the >> operator.
Now arithmetic shift is not useful on 2's compliment machines,
and moreover it's compiler dependent as to whether arithmetic
or logical shift is done for >>. Therefore to increase usefulness
and decrease ambiguity, shells really should only shift unsigned
variables internally.
I know the opengroup spec says to use signed ints, but I think
that is intended to disambiguate input and output, rather than defining
internal operations. This is correct I think since the POSIX spec says
you can even use floating point internally if you like.
I asked the bash maintainer who said he would need clarification
from the austin group (CC'd) before changing anything.
cheers,
Pádraig.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Pádraig Brady @ 2009-01-15 12:59 UTC (permalink / raw)
To: Måns Rullgård; +Cc: linux-kernel, linux-embedded
In-Reply-To: <yw1x3ag2t2gd.fsf@thrashbarg.mansr.com>
Måns Rullgård wrote:
> Alejandro Mery <amery@opensde.org> writes:
>
>> I think the $(( ... )) bash-ism can be replaced with a simple .c helper toy.
>
> The $(( ... )) construct is standard POSIX shell syntax, see
> http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
>
> Bash supports $[ ... ] as an alternate syntax for the same thing.
> Perhaps you were thinking of that.
I think the misconception that $(( ... )) is a bashism is caused by
the wrong highlighting defaults chosen by vim. To fix this add this to ~/.vimrc
let g:is_posix = 1
That will also allow you to use the $(command) POSIX construct.
BTW, the vim syntax maintainers don't agree with changing this default:
http://groups.google.com/group/vim_dev/browse_thread/thread/41139a32772b2f5f
cheers,
Pádraig.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Jamie Lokier @ 2009-01-14 2:51 UTC (permalink / raw)
To: Paul Mundt, Sam Ravnborg, Mark A. Miller, Bernd Petrovitsch,
Leon Woestenberg
In-Reply-To: <20090112103820.GF28564@linux-sh.org>
Paul Mundt wrote:
> 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.
Ah yes, I remember using embedded Gentoo.
95% of the time in ./configure scripts, 5% in compilations.
And this is on x86! I dread to think how slow it gets on something
slow.
-- Jamie
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Alan Cox @ 2009-01-12 18:04 UTC (permalink / raw)
To: Rob Landley
Cc: Paul Mundt, Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <200901121156.17377.rob@landley.net>
> 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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-12 17:56 UTC (permalink / raw)
To: Paul Mundt
Cc: Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <20090112094121.GD28564@linux-sh.org>
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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-12 17:45 UTC (permalink / raw)
To: Peter Korsgaard
Cc: Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg, Paul Mundt,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <873afpj5e3.fsf@macbook.be.48ers.dk>
On Monday 12 January 2009 02:27:32 Peter Korsgaard wrote:
> >>>>> "Mark" == Mark A Miller <mark@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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Alexander Neundorf @ 2009-01-12 11:04 UTC (permalink / raw)
To: Embedded Linux mailing list; +Cc: Mark A. Miller
In-Reply-To: <31014a580901120255q368714a7o897a328d9da479ad@mail.gmail.com>
On Monday 12 January 2009 11:55:32 Mark A. Miller wrote:
> On Mon, Jan 12, 2009 at 4:44 AM, Alexander Neundorf
>
> <neundorf@eit.uni-kl.de> 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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 10:55 UTC (permalink / raw)
To: Alexander Neundorf; +Cc: Embedded Linux mailing list
In-Reply-To: <200901121144.16255.neundorf@eit.uni-kl.de>
On Mon, Jan 12, 2009 at 4:44 AM, Alexander Neundorf
<neundorf@eit.uni-kl.de> 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
mark@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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Alexander Neundorf @ 2009-01-12 10:44 UTC (permalink / raw)
To: Mark A. Miller; +Cc: Embedded Linux mailing list
In-Reply-To: <31014a580901120222s747d9641o641b2991baa5f8f8@mail.gmail.com>
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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-12 10:38 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton
In-Reply-To: <20090112101803.GB10086@uranus.ravnborg.org>
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 <sam@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.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-12 10:34 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901120203v593ce9bdn6876263770efbeae@mail.gmail.com>
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 <lethal@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.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 10:22 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton
In-Reply-To: <20090112101803.GB10086@uranus.ravnborg.org>
On Mon, Jan 12, 2009 at 4:18 AM, Sam Ravnborg <sam@ravnborg.org> 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 <sam@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
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
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Sam Ravnborg @ 2009-01-12 10:18 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton
In-Reply-To: <31014a580901112150x57cd715aj5f42ee19bc28c701@mail.gmail.com>
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 <sam@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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 10:03 UTC (permalink / raw)
To: Paul Mundt, Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg,
Rob Landley
In-Reply-To: <20090112094121.GD28564@linux-sh.org>
On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt <lethal@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
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-12 9:41 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901120118u55256b51g448f22e9e0ef5d1f@mail.gmail.com>
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 <lethal@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.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 9:18 UTC (permalink / raw)
To: Paul Mundt, Mark A. Miller, Bernd Petrovitsch, Leon Woestenberg,
Rob Landley
In-Reply-To: <20090112082058.GB28564@linux-sh.org>
On Mon, Jan 12, 2009 at 2:20 AM, Paul Mundt <lethal@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
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Peter Korsgaard @ 2009-01-12 8:27 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton, Sam Ravnborg
In-Reply-To: <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com>
>>>>> "Mark" == Mark A Miller <mark@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
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-12 8:20 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com>
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.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox