* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-10 10:50 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610102018.GB25910@shareable.org>
>
> When did this policy change, so that it's now acceptable to depend on
> Perl, which is roughly equivalent as a tool dependency?
We have perl as a mandatory part of the kernel build in several places
for various architectures.
And I do not recall anyone submitting a bug that they could not build
a kernel due to the perl dependency.
But I am obviously well aware of that we use it for the time stuff.
For the headers_* targets I will shortly introduce yet another
perl dependency - but only if these targets are used - so less of an issue.
o We shall try to keep the dependencies low for the common things
o but for the more exoctic things a wides dependency is OK.
Which is also why I'm happy to apply a patch that remove
the mandatory dependency of perl we have today - if and only if
that patch meet normal patch acceptance criterias.
Rob's initial patch had some issues and neither Rob nor I have
fixed these and therefore it has not been applied.
Rob seems to put much more into this (private reply accustions etc)
for reasons unknown to me. And doing so does not help to get me interested.
So try to get the facts correct here - there is noone against removing
the mandatory perl dependency. But it is lower on my priority list
than many other things which explain why I do not do it myself.
But if someone submit a patch to do so then if the patch is OK it
will be applied.
And if we have a policy that say no-go to perl then it is new to me.
I hope one day to rewrite part of kbuild and perl seems to be the
best candidate around. But that day may never come.
Sam
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Adrian Bunk @ 2008-06-10 10:36 UTC (permalink / raw)
To: Jamie Lokier
Cc: Sam Ravnborg, Rob Landley, Leon Woestenberg, David Woodhouse,
linux-embedded
In-Reply-To: <20080610102018.GB25910@shareable.org>
On Tue, Jun 10, 2008 at 11:20:18AM +0100, Jamie Lokier wrote:
> My only comment is I remember when Eric Raymond submitted a smart
> config thing (before Kconfig, which copied Eric's best ideas).
>
> The main objection to Eric's patch was that it was written in Python,
> causing kernel builds to depend Python.
>...
Although the usage of Python was brought as a reason against it the
main objection against CML2 was ESRs interaction with the kernel
community, like the fact that he was not willing to split his
changes into appropriate pieces but only offered one big patch.
> -- Jamie
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Jamie Lokier @ 2008-06-10 10:20 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Rob Landley, Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610075432.GB776@uranus.ravnborg.org>
My only comment is I remember when Eric Raymond submitted a smart
config thing (before Kconfig, which copied Eric's best ideas).
The main objection to Eric's patch was that it was written in Python,
causing kernel builds to depend Python.
When did this policy change, so that it's now acceptable to depend on
Perl, which is roughly equivalent as a tool dependency?
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Wolfgang Denk @ 2008-06-10 9:09 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Rob Landley, Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610075432.GB776@uranus.ravnborg.org>
In message <20080610075432.GB776@uranus.ravnborg.org> you wrote:
> > (Maybe I _am_ the only person who still cares about
> > building on a host without perl. If I wasn't, somebody else would have acked
> > the patch...)
>
> perl is pretty standard and I fail to see the benefits of avoiding it.
> For embedded development I see even less benefits as I assume
> any sane embedded development environment are based on a
> cross-toolchain so you do the build on a high perfomance box.
>
> Building everything for my arm board on the arm board would be a disater
> for example.
Well, compiling the Linux kernel on the native system with the root
file system mounted over NFS has always been a really good regression
test for us. It exercises a *lot* of kernel code - tasks, memory,
network, ...
Being unable to do this just because we now also would need a native
Perl is indeed a PITA...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.
^ permalink raw reply
* Re: mainlining min-configs...
From: Adrian Bunk @ 2008-06-10 8:36 UTC (permalink / raw)
To: Tim Bird; +Cc: Rob Landley, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <484DDAD9.2000306@am.sony.com>
On Mon, Jun 09, 2008 at 06:37:29PM -0700, Tim Bird wrote:
> Rob Landley wrote:
> > On Friday 06 June 2008 18:47:47 Tim Bird wrote:
> >> At a minimum, it would be nice to have a few nice examples
> >> of really, really small configs for things like qemus for different
> >> architectures (just to give embedded developers who are working
> >> on size a starting point).
> >
> > That's more or less what I'm trying to do with my Firmware Linux project:
> > creating cross compilers and minimal native build environments for every qemu
> > target.
>
> Any chance of getting your minimal configs from Firmware Linux mainlined?
It could help finding compile errors in some more "exotic" configurations
early (but I'd question whether the Rob's current configs are really
both minimal and typical for embedded usage - e.g the i686 one having
both ext2 and ext3 enabled but no JFFS2; and enabling all IO schedulers
in the kernel as well as ACPI is also not a typical embedded setup).
But if you want to discover size change with minimal configs early you
anyway have to both:
- constantly keep your configs in shape so that they are both minimal
for some set of hardware support and features and
- investigate for any size changes what caused them
(experience has shown that putting information on a webpage doesn't
fix problems - even for compile errors).
You need both, and ideally constantly done by the same person against
Linus' tree, -next and -mm.
Where to get your minimal configs from at the start is just a small
thing at the beginning - don't underestimate the required manual work
that will have to be done each week.
> Does anyone else think this would be valuable? If not in mainline, it
> would be nice to collect them somewhere, to compare what options different
> developers decide turn on or off.
You already have this when you look at e.g. the ARM defconfigs in the
kernel
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: GUI on omap-osk
From: Tom Cooksey @ 2008-06-10 8:16 UTC (permalink / raw)
To: mohammed shareef; +Cc: omap, linux-newbie, linux-embedded
In-Reply-To: <a1d91fa0806100031v2c0557afmd2d47a46d32ab3d@mail.gmail.com>
On Tuesday 10 June 2008 09:31:18 mohammed shareef wrote:
> Dear All,
>
> Could some one tell me how to install Qtopia/OPIE/QTEmbedded on omap5912 -osk?
>
That's probably a bit off-topic for this list. Try the Qtopia-Interest mailing list we run:
http://lists.trolltech.com/qtopia-interest/
I'll try to help you on there.
Cheers,
Tom
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-10 7:54 UTC (permalink / raw)
To: Rob Landley; +Cc: Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <200806100155.31904.rob@landley.net>
> (Maybe I _am_ the only person who still cares about
> building on a host without perl. If I wasn't, somebody else would have acked
> the patch...)
perl is pretty standard and I fail to see the benefits of avoiding it.
For embedded development I see even less benefits as I assume
any sane embedded development environment are based on a
cross-toolchain so you do the build on a high perfomance box.
Building everything for my arm board on the arm board would be a disater
for example.
Sam
^ permalink raw reply
* GUI on omap-osk
From: mohammed shareef @ 2008-06-10 7:31 UTC (permalink / raw)
To: omap, linux-newbie, linux-embedded
Dear All,
Could some one tell me how to install Qtopia/OPIE/QTEmbedded on omap5912 -osk?
Thank you,
Shareef
--
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Rob Landley @ 2008-06-10 6:55 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610043020.GA31765@uranus.ravnborg.org>
On Monday 09 June 2008 23:30:20 Sam Ravnborg wrote:
> Rob - please reread the mails. It was your broken mailer or something
> that caused it to be off-list.
> When I hit reply-to-all in mutt I expect it to be sent to the list -
> and in your case it did not not hit the list.
Could easily be the case. Kmail's gotten increasingly weird ever since
Kontact ate it, and I do tend to break stuff anyway...
> > A number of embedded people emailed me about it off list, but nobody ever
> > replied to my post _on_ the list to say I wasn't alone in this, or acked
> > the patch to say it worked for them, or anything like that. So there was
> > a perception of zero support, and I gave up trying to follow up on it for
> > 2.6.25. I've got it working for me, and if more perl shows up I'll come
> > up with more patches to remove it for my own personal build environment.
> >
> > I might try to submit again in a few months
>
> Then please try to address the comments first.
The comments I remember (it's been a while) were that it was futile to fight
against the addition of perl because A) nobody else was bothered by it, B)
plans were in place to add more perl to the build in future so it was only a
matter of time anyway, C) some out of tree patch might add an architecture
variant that wanted to define arbitrary clock values. My response to C
was "I can't find this patch, show me", my response to B) was "I'll address
that when it happens", and my response to A) was "yeah, everybody else who
seemed to care about this has decided to shut up and bog off, haven't they?"
I keep meaning to write a much improved patch that records a comment at the
start of the .h file with the complete command line the perl thing was run
as, so re-running the header generator is a question of cut and paste and
then adding the extra value you want before hitting enter. And then ripping
all the logic out of the makefile that tries to rebuild the thing itself
because only a patch to Kconfig files can ever require a new value, and that
patch should change the .h file so it can build the result. If they forget
to check in the .h file, the build should fail noisily.
The result is simpler, has many fewer lines, and doesn't need perl to compile
(just to add new clock values during development), but since nobody else in
the embedded community cared to speak up for it, I kind of lost interest in
trying to get it merged. (Maybe I _am_ the only person who still cares about
building on a host without perl. If I wasn't, somebody else would have acked
the patch...)
*shrug* If I go back to revisit this issue I'll dig up the old thread and
reread it, but at the moment I have no immediate plans to.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-10 4:30 UTC (permalink / raw)
To: Rob Landley; +Cc: Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <200806092253.11897.rob@landley.net>
On Mon, Jun 09, 2008 at 10:53:11PM -0500, Rob Landley wrote:
> On Monday 09 June 2008 16:27:29 Leon Woestenberg wrote:
> > > I submitted a patch to remove the use of perl to build the linux kernel
> > > (which HPA added in 2.6.25) not because it affected the result, but
> > > because it unnecessarily complicates the build system. (And perl tends
> > > to metasticize.
> >
> > Thanks, I hope it is or gets accepted.
>
> Nope, Peter Anvin shot it down (saying what I was doing was a strange, purely
> academic exercise), and Sam Ravnborg announced his vague intention to rewrite
> large chunks of kbuild in perl in the future. (Because nothing
> says "maintainability" like perl...)
>
> For some reason they wanted to mail me about it off-list rather than cc:ing
> the list about this plan.
Rob - please reread the mails. It was your broken mailer or something
that caused it to be off-list.
When I hit reply-to-all in mutt I expect it to be sent to the list -
and in your case it did not not hit the list.
>
> A number of embedded people emailed me about it off list, but nobody ever
> replied to my post _on_ the list to say I wasn't alone in this, or acked the
> patch to say it worked for them, or anything like that. So there was a
> perception of zero support, and I gave up trying to follow up on it for
> 2.6.25. I've got it working for me, and if more perl shows up I'll come up
> with more patches to remove it for my own personal build environment.
>
> I might try to submit again in a few months
Then please try to address the comments first.
Sam
^ permalink raw reply
* Re: mainlining min-configs...
From: Paul Mundt @ 2008-06-10 4:16 UTC (permalink / raw)
To: Ben Nizette
Cc: Tim Bird, Rob Landley, Adrian Bunk, linux-tiny, linux-embedded,
linux kernel
In-Reply-To: <1213067676.3213.27.camel@moss.renham>
On Tue, Jun 10, 2008 at 01:14:36PM +1000, Ben Nizette wrote:
> On Mon, 2008-06-09 at 18:37 -0700, Tim Bird wrote:
> > Rob Landley wrote:
> > > On Friday 06 June 2008 18:47:47 Tim Bird wrote:
> > >> At a minimum, it would be nice to have a few nice examples
> > >> of really, really small configs for things like qemus for different
> > >> architectures (just to give embedded developers who are working
> > >> on size a starting point).
> > >
> > > That's more or less what I'm trying to do with my Firmware Linux project:
> > > creating cross compilers and minimal native build environments for every qemu
> > > target.
> >
> > Any chance of getting your minimal configs from Firmware Linux mainlined?
>
> allnoconfig? ;-)
>
It's a bit counter-intuitive, given the inverted logic employed by many
Kconfig options (enable vs disable and so on), default choices, select
abuse, etc. If your platform happens to select EMBEDDED it's a pretty
close approximation, though.
> > Does anyone else think this would be valuable? If not in mainline, it
> > would be nice to collect them somewhere, to compare what options different
> > developers decide turn on or off.
>
> Seriously though I maintain a bunch of AVR32 minimal configs. I keep
> them as a smallest-working-config baseline to build on; I'm sure others
> would get value from having easy access to that kind of thing.
>
> IMO It'd be nice to wire them to an automagic bloat-o-meter as well, but
> I suspect no-one would really take notice anyway.
>
Most people are not opposed to taking additional defconfigs if there's
someone intends to use them and generally look after them. Many configs
are already included in linux-next and similar for nightly builds, but
that's more about making sure things keep working rather than size
measurements. On the other hand, it would be useful to extend that sort
of infrastructure to account for size changes, also, and there's
certainly no reason why minimal configs can't be rolled in, too.
For testing things like allmodconfig/allyesconfig and especially
randconfigs tend to be the most useful, but it's fairly difficult to
extract meaningful size statistics out of any of those. Likewise, a
minimal config tends to be pointless to the extent that it's not actually
useful for anything. Observing the growth in size on configurations that
people are using in the real world is far more useful. Measuring
arbitrary growth in a configuration that's not even usable isn't really
much of an indicator of anything, except that someone might have too much
free time on their hands.
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Rob Landley @ 2008-06-10 3:53 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: David Woodhouse, linux-embedded
In-Reply-To: <c384c5ea0806091427k3bd29168wbe55f6920054d44a@mail.gmail.com>
On Monday 09 June 2008 16:27:29 Leon Woestenberg wrote:
> > I submitted a patch to remove the use of perl to build the linux kernel
> > (which HPA added in 2.6.25) not because it affected the result, but
> > because it unnecessarily complicates the build system. (And perl tends
> > to metasticize.
>
> Thanks, I hope it is or gets accepted.
Nope, Peter Anvin shot it down (saying what I was doing was a strange, purely
academic exercise), and Sam Ravnborg announced his vague intention to rewrite
large chunks of kbuild in perl in the future. (Because nothing
says "maintainability" like perl...)
For some reason they wanted to mail me about it off-list rather than cc:ing
the list about this plan.
A number of embedded people emailed me about it off list, but nobody ever
replied to my post _on_ the list to say I wasn't alone in this, or acked the
patch to say it worked for them, or anything like that. So there was a
perception of zero support, and I gave up trying to follow up on it for
2.6.25. I've got it working for me, and if more perl shows up I'll come up
with more patches to remove it for my own personal build environment.
I might try to submit again in a few months, but in the meantime my patches
are at
http://landley.net/hg/firmware/file/tip/sources/patches/ (see the
linux-*noperl*.patch one).
Maybe I'll try linux-kernel again. I submitted my miniconfig patches
something like three times. But if the guys on the list didn't want it, and
the guys in the embedded world poking me to do something about it weren't
willing to even ack the darn patch on the list, and the people who want
changes made to it aren't willing to change it from what I'm happy with to
what they want and expect me to do it for them when I'm already happy with
it...
My todo list is long. This goes somewhere after resorting the contents of my
bookshelves.
I've found that posting to linux-kernel tends to attract "belling the cat"
ideas. For example, I use kconfig in toybox and I posted patches to make it
easier to use kconfig in other, non-kernel projects. The resulting thread
turned into a grandiose plan about a separate kconfig that would be
maintained as a spearate project and get installed on your system ala make,
for use by any source package that wants that functionality. To which my
response was "feel free, I have no interest in doing that, did you want my
patches or not?" Improvements in the UI to use miniconfigs were held up by
people objecting to how they were generated, which is separate from how
they're used. And one of peter's objections to the perl removal patch (which
basically checked the precalculated header file into the tree) was that some
out of tree mips patch that never got merged might want to let you enter the
clock speed as an input field, so you can't possibly just rely on
precalculated values and people who want to check in code using a new value
checking in an updated header with that value. (Even though that makes every
existing architecture happy, last I checked.)
I'm a hobbyist. I made it work for me. If nobody else is interested in what
I did, I'm ok with that...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: mainlining min-configs...
From: Ben Nizette @ 2008-06-10 3:14 UTC (permalink / raw)
To: Tim Bird; +Cc: Rob Landley, Adrian Bunk, linux-tiny, linux-embedded,
linux kernel
In-Reply-To: <484DDAD9.2000306@am.sony.com>
On Mon, 2008-06-09 at 18:37 -0700, Tim Bird wrote:
> Rob Landley wrote:
> > On Friday 06 June 2008 18:47:47 Tim Bird wrote:
> >> At a minimum, it would be nice to have a few nice examples
> >> of really, really small configs for things like qemus for different
> >> architectures (just to give embedded developers who are working
> >> on size a starting point).
> >
> > That's more or less what I'm trying to do with my Firmware Linux project:
> > creating cross compilers and minimal native build environments for every qemu
> > target.
>
> Any chance of getting your minimal configs from Firmware Linux mainlined?
allnoconfig? ;-)
>
> Does anyone else think this would be valuable? If not in mainline, it
> would be nice to collect them somewhere, to compare what options different
> developers decide turn on or off.
Seriously though I maintain a bunch of AVR32 minimal configs. I keep
them as a smallest-working-config baseline to build on; I'm sure others
would get value from having easy access to that kind of thing.
IMO It'd be nice to wire them to an automagic bloat-o-meter as well, but
I suspect no-one would really take notice anyway.
--Ben.
^ permalink raw reply
* mainlining min-configs...
From: Tim Bird @ 2008-06-10 1:37 UTC (permalink / raw)
To: Rob Landley; +Cc: Adrian Bunk, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <200806062329.54019.rob@landley.net>
Rob Landley wrote:
> On Friday 06 June 2008 18:47:47 Tim Bird wrote:
>> At a minimum, it would be nice to have a few nice examples
>> of really, really small configs for things like qemus for different
>> architectures (just to give embedded developers who are working
>> on size a starting point).
>
> That's more or less what I'm trying to do with my Firmware Linux project:
> creating cross compilers and minimal native build environments for every qemu
> target.
Any chance of getting your minimal configs from Firmware Linux mainlined?
Does anyone else think this would be valuable? If not in mainline, it
would be nice to collect them somewhere, to compare what options different
developers decide turn on or off.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Leon Woestenberg @ 2008-06-09 21:27 UTC (permalink / raw)
To: Rob Landley, David Woodhouse, linux-embedded
In-Reply-To: <200805281652.47558.rob@landley.net>
Hello,
On Wed, May 28, 2008 at 11:52 PM, Rob Landley <rob@landley.net> wrote:
> On Wednesday 30 April 2008 14:11:49 David Woodhouse wrote:
>> I agree. And if we do want to pay attention to pure code size, there are
>> other approaches -- like --gc-sections and/or building with '--combine
>> -fwhole-program' which I was playing with for OLPC a while back. I must
>> dust that off now that the GCC fixes should mostly have made it into
>> current distributions.
>
> I like simplicity. I like _simple_. Half my attraction to embedded systems
>
Same here.
> I submitted a patch to remove the use of perl to build the linux kernel (which
> HPA added in 2.6.25) not because it affected the result, but because it
> unnecessarily complicates the build system. (And perl tends to metasticize.
Thanks, I hope it is or gets accepted.
In general I think one of the aspects of embedded Linux is about
minimizing the amount of bloat dependencies. Especially, when each
dependency can explode in a hurd of new dependencies.
> "One of my most productive days was throwing away 1000 lines of code."
> - Ken Thompson.
>
How appropriate.
Regards,
--
Leon
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Geert Uytterhoeven @ 2008-06-09 11:51 UTC (permalink / raw)
To: Jamie Lokier; +Cc: H. Peter Anvin, Rob Landley, Paul Mundt, linux-embedded
In-Reply-To: <20080609113856.GD25541@shareable.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1559 bytes --]
On Mon, 9 Jun 2008, Jamie Lokier wrote:
> The uClinux devices I ship do have that. System console is the serial
> port on a board header. But field engineers are instructed to plug in
> a USB keyboard and Alt-F2 to get a diagnostic screen (we call it a
> "shell" ;-). Occasionally even customers with specific requirements
> get to use that.
>
> We had to patch the kernel to get the combination of virtual terminal
> capability on a framebuffer, but system console messages not to the
> framebuffer. The uClinux (2.4.x) disables system console on a virtual
> terminal, but due to some confusion(*), it has the side effect that
> you can't attach a VT to a framebuffer at all. Several howtos provide
> a "con2fb" program which didn't work with uClinux. We had to fix that.
I think this is due to using 2.4.
In 2.6, al you have to do is pass `console=ttyS0' (replace `ttyS0' by your
serial port device) to the kernel, and system console messages will no longer
appear on the frame buffer (unless you add an explicit `console=tty0').
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Technology and Software Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Jamie Lokier @ 2008-06-09 11:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Rob Landley, Paul Mundt, linux-embedded
In-Reply-To: <484A0207.4000405@zytor.com>
H. Peter Anvin wrote:
> >When you imply it's stupid to think anyone will ever have a console on an
> >embedded system (because we all know the embedded world is far more
> >uniform than crazy diverse things like the desktop space), which of these
> >are _you_ referring to?
>
> I'm talking about the virtual console stuff, which is *not* inherently
> tied to VGA.
>
> The issue is whether it makes sense to have virtual console capability
> on a device which is so constrained that you want a *subset* of the
> functionality in place.
The uClinux devices I ship do have that. System console is the serial
port on a board header. But field engineers are instructed to plug in
a USB keyboard and Alt-F2 to get a diagnostic screen (we call it a
"shell" ;-). Occasionally even customers with specific requirements
get to use that.
We had to patch the kernel to get the combination of virtual terminal
capability on a framebuffer, but system console messages not to the
framebuffer. The uClinux (2.4.x) disables system console on a virtual
terminal, but due to some confusion(*), it has the side effect that
you can't attach a VT to a framebuffer at all. Several howtos provide
a "con2fb" program which didn't work with uClinux. We had to fix that.
(*) - the word "console" is used for four different concepts in the
kernel, sometimes in the same code, and it seems to have confused
someone.(**) In the following, CONFIG_VT_CONSOLE should not control
take_over_console(); the two "console" are not the same concept:
#ifdef CONFIG_VT_CONSOLE
take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
#endif
(**) So I suggest using "virtual terminal" consistently in the code,
and when talking about them, would be an improvement.
-- Jamie
^ permalink raw reply
* Re: YAFFS in the kernel tree?
From: Jörn Engel @ 2008-06-08 12:16 UTC (permalink / raw)
To: Detlev Zundel; +Cc: Alexey Zaytsev, Charles Manning, linux-embedded
In-Reply-To: <m2zlpw2lrl.fsf@ohwell.denx.de>
On Sun, 8 June 2008 13:45:18 +0200, Detlev Zundel wrote:
>
> Sorry for jumping in here late, but git should be pretty good about
> finding differences itself. If you can revers-apply the previous
> version patch, then apply the current version and git commit, it should
> yield much more useful information.
Doesn't work too well, if the git version is different from the
out-of-tree version, because of something like version checks.
What might work is to keep developing the git tree, extract a patch from
that, have a second patch with version checks, etc. and combinediff
those two.
Jörn
--
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike
--
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
* Re: YAFFS in the kernel tree?
From: Detlev Zundel @ 2008-06-08 11:45 UTC (permalink / raw)
To: Alexey Zaytsev; +Cc: Charles Manning, linux-embedded
In-Reply-To: <f19298770805281515u1602e18enbad78fccfda24b02@mail.gmail.com>
"Alexey Zaytsev" <alexey.zaytsev@gmail.com> writes:
> On Thu, May 29, 2008 at 12:59 AM, Charles Manning
> <manningc2@actrix.gen.nz> wrote:
>> Hi
>>
>> I'm the author of YAFFS. This is not in the kernel tree, but is fairly easy to
>> integrate by just pulling a tarball and running patch-in script.
>>
>> I am curious as to whether people consider the current mechanism "good enough"
>> or whether it is worth the effort trying to get YAFFS into the kernel tree.
>>
>> Pros I can see:
>> * In tree means better testing (maybe).
>> * Keeping current with kernel API changes.
>>
>> Cons:
>> * More effort for YAFFS maintainers (me mostly).
>> * Effort getting code into kernel coding style (unless I can get a waiver on
>> this).
>>
>> Thoughts??
>
> We at protei (protei.ru) are using yaffs for over a year now, switched from
> jffs2, mostly because of the huge mount time difference. Have yet to
> see any serious problems.
>
> The process of patching the kernel with yaffs is quite smooth, but you
> loose the ability to track the changes made in yaffs. We've got a git
> kernel tree, to which we add our stuff, and also periodically repatch it
> with a fresh yaffs. The problem is, all you can see later is a commit
> labelled "A Yaffs update", revealing little details on the contents. Not cool.
Sorry for jumping in here late, but git should be pretty good about
finding differences itself. If you can revers-apply the previous
version patch, then apply the current version and git commit, it should
yield much more useful information.
Cheers
Detlev
--
The proprietary-Unix players proved so ponderous, so blind, and so inept at
marketing that Microsoft was able to grab away a large part of their market
with the shockingly inferior technology of its Windows operating system.
-- "A Brief History of Hackerdom" by Eric Steven Raymond
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: x11 fails with floating point exception
From: Ben Nizette @ 2008-06-08 10:27 UTC (permalink / raw)
To: mohammed shareef; +Cc: linux-embedded
In-Reply-To: <a1d91fa0806080307l64175a61i14cfb205081dd878@mail.gmail.com>
On Sun, 2008-06-08 at 15:37 +0530, mohammed shareef wrote:
> Hi,
>
> i am new to linux.
>
> when i compile x-windows, the xlib--X11 fails with a floating point exception.
These are generally things like divide-by-zero. It is a problem with
the makekeys script there, nothing to do with the linux kernel or
embedded space in general so this isn't the right list :-)
Try an X11 mailing list.
--Ben.
^ permalink raw reply
* x11 fails with floating point exception
From: mohammed shareef @ 2008-06-08 10:07 UTC (permalink / raw)
To: linux-embedded
Hi,
i am new to linux.
when i compile x-windows, the xlib--X11 fails with a floating point exception.
../src/util/makekeys < /usr/include/X11/keysymdef.h > ks_tables_h
/bin/sh: line 1: 12048 Floating point exception../src/util/makekeys <
/usr/include/X11/keysymdef.h > ks_tables_h
make[1]: *** [ks_tables.h] Error 136
make[1]: Leaving directory `/root/omap5912/xwin_snapshot/xlibs/X11/src'
make: *** [install-recursive] Error 1
could someone please tell me how to solve this
thank you,
Shareef
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-07 4:29 UTC (permalink / raw)
To: Tim Bird; +Cc: Adrian Bunk, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <4849CCA3.7040102@am.sony.com>
On Friday 06 June 2008 18:47:47 Tim Bird wrote:
> At a minimum, it would be nice to have a few nice examples
> of really, really small configs for things like qemus for different
> architectures (just to give embedded developers who are working
> on size a starting point).
That's more or less what I'm trying to do with my Firmware Linux project:
creating cross compilers and minimal native build environments for every qemu
target.
http://landley.net/code/firmware
http://landley.net/hg/firmware
I currently have variants of arm, powerpc, mips, x86, and x86-64 working, and
several others (sh4, sparc, m68k) in various stages of development. (I think
sparc just needs one minor bug fixed, I just can't bring myself to _care_
about sparc. m68k is hitting an internal compiler error in gcc. sh4 isn't
properly supported by qemu yet: no boards with a hard drive.)
I just did a new release, which finally has the distcc trick implemented.
(Not _quite_ useful yet because the build environment is missing seven
important commands I hope to add next release.)
Feel free to ask me any questions about it...
Rob
P.S. The mips kernel config recently changed because the qemu mips platform
went away in 2.6.25, and the new one is malta_defconfig with some of the
obvious options removed. I'm working on a more stripped-down one as we
speak, but I didn't hold up the release for it...
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: H. Peter Anvin @ 2008-06-07 3:35 UTC (permalink / raw)
To: Rob Landley; +Cc: Paul Mundt, linux-embedded
In-Reply-To: <200806051835.57140.rob@landley.net>
Rob Landley wrote:
>> Except for the minor fact that most early boot debugging happens long
>> before the console subsystem is even available..
>
> Isn't that why CONFIG_EARLY_PRINTK was written? (And I mentioned Linus's hack
> using the RTC to see how far the _really_ early stuff got.)
Don't think that works with frame buffers.
> Earlier I was trying to distinguish between /dev/console (no controlling tty),
> virtual terminals (tied to old VGA hardware although possibly usable through
> the framebuffer, I'm unclear on this), the tty layer (which is what I
> initially thought the patch was aimed at, but it seems to be the vga VT
> stuff), and having a bitmapped display (may be GUI only). Four separate
> things, I've lost track of which we're talking about here.
>
> When you imply it's stupid to think anyone will ever have a console on an
> embedded system (because we all know the embedded world is far more uniform
> than crazy diverse things like the desktop space), which of these are _you_
> referring to?
I'm talking about the virtual console stuff, which is *not* inherently
tied to VGA.
The issue is whether it makes sense to have virtual console capability
on a device which is so constrained that you want a *subset* of the
functionality in place.
-hpa
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Tim Bird @ 2008-06-06 23:47 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080604194002.GF4189@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> I think the only serious numbers would come from taking some hardware
> and feature set (file systems, network options, etc.), and then
> optimizing by hand the smallest .config possible for both cases.
>
> Do you have anything in this direction?
Not exactly. I have some automated tests which measure the
compile-time and runtime memory affect of adjusting various kernel
options. I do have, for 4 different architectures, a "smallest"
config that I've was hand-tuning for each arch.
Unfortunately, I started this some months ago and didn't
finish tuning these minimum configs. They bitrotted, and now
none of them yeild bootable kernels for their respective boards.
I suppose I could dust this off and take another stab at it to
get some more results.
I wouldn't mind seeing min-configs for some boards in the main
source tree.
I think this has been discussed before, and one problem is
agreeing on what feature set to include in such configs.
At a minimum, it would be nice to have a few nice examples
of really, really small configs for things like qemus for different
architectures (just to give embedded developers who are working
on size a starting point).
> OK, that's a visible difference.
>
> Are these 30 patches each gaining 4kB or are there a few patches that
> bring most gain?
It's a spectrum. One or two yield something over 20k, a few more
yield about 15k, then there's a long tail going down from about 8k
to very small savings (I should look at the size results more often,
some of these are not worth carrying around. I've been just
maintaining the whole group as a set, and haven't looked at
the size effect of individual patches/options for a while.)
Oh, and if anyone is wondering why I started with a 7k one,
rather than something else with more "punch", it was a
relatively simple one (and it's option name started with
a letter near the beginning of the alphabet ;-)
> And are you only measuring the kernel image size or also theruntime
> memory usage?
I also measure runtime, but my current test is not very good.
I do everything over an NFS-mount, and any network hiccups during boot
disturb the memory footprint. I'm just using a simple "free"
over telnet, and comparing that vs. a baseline.
I suppose a simple "fix" would be to boot each test kernel several
times and discard outlying data points.
A few linux-tiny patches have little effect on kernel image size,
but a nice effect on runtime memory. (e.g. There's one that changes
some mempool settings, that has only a 1k compile-time effect,
but a 12k runtime effect.)
I've been building up a table with real numbers, but I found
several problem areas with my test. I'll try to get some numbers
out early next week.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] console - Add configurable support for console charset translation
From: Rob Landley @ 2008-06-05 23:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: H. Peter Anvin, linux-embedded
In-Reply-To: <20080605004630.GA26259@linux-sh.org>
On Wednesday 04 June 2008 19:46:30 Paul Mundt wrote:
> On Wed, Jun 04, 2008 at 12:36:11PM -0500, Rob Landley wrote:
> > Actually if you ever need to diagnose early boot stuff on _any_ platform,
> > you do need a console. But it can be serial or netconsole, as long as
> > that works...
>
> Except for the minor fact that most early boot debugging happens long
> before the console subsystem is even available..
Isn't that why CONFIG_EARLY_PRINTK was written? (And I mentioned Linus's hack
using the RTC to see how far the _really_ early stuff got.)
> At the risk of perpetuating the stupidity of this thread..
I plead the fifth.
> If you ship a
> device to a customer expecting them to debug it for you, you are likewise
> not likely to be very commercially successful, either.
There are such things as field servicable devices where companies either send
people out into the wild or get hardware brought in for service.
However, looking at the message you're replying to, I was talking about during
development. (Remember how the early linksys boxes didn't have the serial
port physically wired up to the outside, but if you busted out a soldering
iron you got a shell prompt on it without even installing new software? They
didn't change it after they got it working because they didn't want to
re-validate their image? Yeah, that kind of stuff gets shipped.)
Sure if the device in the field doesn't boot, it's cheaper to just replace it,
unless you need to get data off the sucker (in which case they bring it in).
But the defective units returned to the factory sometimes get diagnosed so
they can reduce the future return rate (or resell 'em used if it was pilot
error), so once again it helps if it's possible to service 'em after the
fact. Depends on the company.
> Devices are not shipping with consoles, period.
Earlier I was trying to distinguish between /dev/console (no controlling tty),
virtual terminals (tied to old VGA hardware although possibly usable through
the framebuffer, I'm unclear on this), the tty layer (which is what I
initially thought the patch was aimed at, but it seems to be the vga VT
stuff), and having a bitmapped display (may be GUI only). Four separate
things, I've lost track of which we're talking about here.
When you imply it's stupid to think anyone will ever have a console on an
embedded system (because we all know the embedded world is far more uniform
than crazy diverse things like the desktop space), which of these are _you_
referring to?
My cable modem has a serial port that gives me a login prompt if I plug into
it, and I watched the guy at sprint bring one up last time I broke my cell
phone so he could get my number list off it. That kind of console may be
useful out in the real world, and that's the kind of console I was talking
about in the message you replied to.
I've learned that "I don't do that, therefore nobody ever will" is not always
the world's greatest assumption. Somebody out there may want a console, and
they may not want the overhead of internationalizing it because although
their customers speak mandarin, their field service people do not.
Somebody out there may also want to do something I consider a bad idea.
(Compared to shipping a device with Windows CE on it, any quibble I have
about Linux configuration is a rounding error.)
> If you disagree with this, you've
> obviously never shipped a device.
Since I haven't shipped only _one_ device, and since I used to own a tuxscreen
phone which may actually meet _all_ the above definitions of "console", I
guess it's ok for me to disagree with this?
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ 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