* 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
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 5:50 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: <20090112053552.GA9061@uranus.ravnborg.org>
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.
> I would assume that if this of such improtance then there is also
> someone to step up and contribute a C version of it.
You've already dismissed a shell version to correct the issue, in
hopes of a "possible" C version. It would be nice, I'm not capable of
doing it personally, but a solution already exists to "unbreak" the
kernel build. If you're unwilling to merge the current patches, then
feel free to claim that this doesn't break anything on current
architectures, but it's incorrect, due to Perl not even compiling as
is currently on a native uclibc environment.
I look forward to what other tools will be introduced to break yet
more architectures until the kernel cannot be compiled unless on an
i686+glibc architecture.
> Sam
--
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 5:35 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: <31014a580901111928u586e2246uccf370ff941c8a01@mail.gmail.com>
> 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?
I would assume that if this of such improtance then there is also
someone to step up and contribute a C version of it.
Sam
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 5:23 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <496AD0E9.2020909@zytor.com>
On Sun, Jan 11, 2009 at 11:11 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> 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...
>>
>
> The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
My mistake. However,
http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/hints/linux.sh
still has the issue, specifically:
if test -L /lib/libc.so.6; then
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
libc=/lib/$libc
fi
So, my version was incorrect, yet the problem still exists. I've got a
patch, need to submit it, yet Perl *does not compile* on a uclibc
target *as is*.
And this is why we should avoid adding new tools to build the kernel,
because they introduce yet more break points, as such.
Thanks.
--
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: H. Peter Anvin @ 2009-01-12 5:11 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com>
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...
>
The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 3:36 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Leon Woestenberg, Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <1231677939.3517.5.camel@gimli.at.home>
On Sun, Jan 11, 2009 at 6:45 AM, Bernd Petrovitsch <bernd@firmix.at> wrote:
>
> On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
> [...]
> > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> [...]
>
> I'm ignoring the "cross-compile perl" issue - haven't tried it for
> years.
>
> > 5. Tool *version* dependency is hard to get right. When cross-building
> > 30 software packages all requiring native perl, we probably need to
> > build a few versions of perl (native), one for each set of packages.
>
> perl is IMHO special (and quite different to others - including
> especially autotools): perl5 is used widely enough so that "one somewhat
> recent version" should cover all of 30 software packages.
> The hard part are the CPAN modules and their versions which are really a
> PITA.
> As long as you don't use modules from CPAN, "perl5" should be specific
> enough.
>
> Bernd
> --
> Firmix Software GmbH http://www.firmix.at/
> mobil: +43 664 4416156 fax: +43 1 7890849-55
> Embedded Linux Development and Services
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.
So without patching Perl, by adding it to the kernel configuration,
it's broken being able to compile the kernel on most embedded
architectures.
And for H. Peter Anvin, before you refer to such uses as compiling the
kernel under a native environment as a "piece of art", please be aware
that the mainstream embedded development environment, buildroot, is
also attempting to utilize QEMU for a "sanity check" on the
environment.
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.
--
Mark A. Miller
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Bernd Petrovitsch @ 2009-01-11 12:45 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <c384c5ea0901040223l6e53f041s9f7cdea20c9d1d8d@mail.gmail.com>
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
[...]
> On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
[...]
I'm ignoring the "cross-compile perl" issue - haven't tried it for
years.
> 5. Tool *version* dependency is hard to get right. When cross-building
> 30 software packages all requiring native perl, we probably need to
> build a few versions of perl (native), one for each set of packages.
perl is IMHO special (and quite different to others - including
especially autotools): perl5 is used widely enough so that "one somewhat
recent version" should cover all of 30 software packages.
The hard part are the CPAN modules and their versions which are really a
PITA.
As long as you don't use modules from CPAN, "perl5" should be specific
enough.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2009-01-10 7:37 UTC (permalink / raw)
To: Robin Getz
Cc: David Brownell, Eric Miao, Sam Ravnborg, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <200901061741.12410.rgetz@blackfin.uclinux.org>
On Wed, Jan 7, 2009 at 6:41 AM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Wed 31 Dec 2008 13:05, Jaya Kumar pondered:
>> On Thu, Jan 1, 2009 at 1:38 AM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>> > On Tue 30 Dec 2008 23:58, Jaya Kumar pondered:
>> >> On Tue, Dec 30, 2008 at 11:55 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>> >> > Yeah, I hadn't thought about spanning more than one gpio_chip. That's a good
>> >> > point.
>> >>
>> >> The currently posted code already supports spanning more than one gpio_chip.
>> >>
>> >
>> > But doesn't do all the other things that David suggested/requested.
>>
>> Hi Robin,
>>
>> Yes, you are right. My implementation does not support a driver that
>> needs to set/get more than 32-bits of gpio in a single call. I'm okay
>> with that restriction as I don't see a concrete use case for that.
>
> It's not the more than 32-bits that I'm concerned about - it is spanning
> more than one register. (if all the GPIOs that are left on the board are
> 2, 64, and 128, where 2, and 64 are part of the SOC's GPIO, and 128 is on
> a GPIO expander - which is a common use case - is this handled?)
>
Hi Robin,
You are correct in that the 2, 64, 128 case would not be accelarated
by my current implementation. The reason is that those 3 numbers can't
fit into a 32 bit bitmask (the mask is for consecutive bits). The user
would need to use the pre-existing single bit API for that scenario,
ie: gpio_set_value(2, val); (64, val), (128, val);
In my current patch, I'm trying to address the performance issue seen
by am300epd.c because of the use of gpio as a 16-bit data bus to
transfer framebuffer data using the current single bit gpio API. I
want to make my implementation more generic than just that which is
why I've added the bitmask and support up to 32-bits. I want to expand
on that to the extent that that can be done without diluting the
performance and without losing the simplicity of the current gpiolib
API.
After reading your points, I think I understand that you would prefer
a higher level API. I am thinking along the lines of:
array_of_gpio_numbers[] = [ 2 , 64, 128 ];
cookie = gpio_register_bundle(array_of_gpio_numbers, sizeof(array));
error = gpio_set_bundle(cookie, values[]);
error = gpio_get_bundle(cookie, values[]);
gpio_unregister_bundle(cookie);
I think that's elegant and I agree that it is feasible but it is a
level higher than what I'm trying to achieve. Would you agree with me
that the above API could be implemented on top of the lower level API
that I have proposed? To be specific, I imagine something along the
lines of:
int gpio_set_bundle(int cookie, u32 *values)
{
offsets = retrieve_offsets_from_cookie(cookie);
err = generate_chips_from_offsets(offsets, &chips);
err = merge_consecutive_chips(chips, &merged_chips)
foreach chip (merged_chips) {
values = generate_values(chip, offset);
mask = generate_mask(chip, offset);
masklength = calculate_length(mask);
gpio_set_batch(chip, offset, values, mask, masklength);
}
}
forgive the naming, I'm just hurrying to illustrate what I mean.
So my goal is to get the lower level batch API working and solid. It
would solve the am300epd.c problem and put into place a framework for
others[1]. Once we've gotten to that level of support, I believe we
could start implementing the higher level API that you've described on
top of that. Does this sound like a reasonable plan that would address
your concerns?
Thanks,
jaya
[1] The same underlying display controller that I seek to support,
broadsheet, will be used across more than just am300epd.c's pxa255. I
know with certainty that it has been used on iMX31L. Several other
SoCs including the S3C6410 are likely. So if we've got this lower
level batch API done, I hope to see it commonly implemented across
those other SoCs too in order to ensure all of those use cases are
accelerated. I am happy to work on that, especially if I can get
hardware. :-)
ps: I noticed you said the above 2, 64, 128 is a common use case. I
don't dispute that, but is that a case where acceleration is
essential? It would also help if I could look through an example of
this use case in the tree or elsewhere so that I can improve my
understanding.
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Hans J. Koch @ 2009-01-09 23:40 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Thiago Galesi, Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <20090109100725.77a07e74.hugo@hugovil.com>
On Fri, Jan 09, 2009 at 10:07:25AM -0500, Hugo Villeneuve wrote:
>
> I think that for the moment, I will focus on implementing the core
> module and the parallel/SPI interfaces only. Later we may want to add
> more fonctionality (vendors, JTAG, etc).
That's a good plan, but you'll have to make sure different FPGA programming
drivers can be added easily to some fpga-core no matter which interface they
use.
>
> But for now, my main problem is that I need to have some insight on how
> I actually implement the different modules:
>
> Bus driver?
> class driver?
> platform driver?
Those are not mutually exclusive. If you register an spi driver, it'll appear
on that bus. It would be a good idea to also create a class "fpga". And an
FPGA will likely be a platform device unless you create a complete subsystem
that offers something like register_fpga_device(). The latter would be a nice
thing to have, I had to write FPGA programming drivers and had to implement
them as some char device in drivers/misc because there was no place where
they could go...
IMHO, the ideal solution would be to have an FPGA programming subsystem.
Somewhere in my board support I'd setup some struct fpga_device that
contains an element "bus_type" which can be set to FPGA_BUS_PARALLEL or
FPGA_BUS_SPI or whatever. A "name" element declares which driver I'd like
to use for my chip. A call to some fpga_register_device() with a
pointer to that struct would make the fpga subsystem remember that device and
look for an apropriate driver. Drivers register themselves by a call to some
register_fpga_driver() function. The fpga core would then make sure the
drivers probe function is called with pointers to the struct fpga_device of
the registered devices. That's how other subsystems work.
Such a subsystem would solve any FPGA programming problems (and your "main
problem" mentioned above) once and for all.
Thanks,
Hans
^ 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