On Wednesday 04 June 2008 05:33:53 Adrian Bunk wrote:
Does the linux-tiny approach of adding a kconfig variable for each 5kB
of code actually make sense? I'm asking since an exploding amount of
kconfig variables and their interdependencies have a not so small
maintainance impact in the long
On Wednesday 11 June 2008 14:46:55 Tim Bird wrote:
Adrian Bunk wrote:
Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since
April 2006.
Well, dangit there it is!
The patch I googled had it going into Documentation/kbuild. It
somehow escaped my attention in the README.
On Thursday 12 June 2008 12:52:44 Shaz wrote:
Hi,
I have been following Re: [PATCH 0/1] Embedded Maintainer(s) and
felt like asking that is there one good way to get a cross compiler
work. I tried buildroot, scratchbox and even openMoko with
openEmbedded but all of them had lots of issues
On Thursday 12 June 2008 12:14:32 Bill Gatliff wrote:
Paul Mundt wrote:
Yes, that's the easy case. It's things like perl that are the corner
cases, and my objection comes from the fact that people think we ought to
not have the kernel depend on perl rather than just fixing the package
On Friday 13 June 2008 04:06:18 Alexander Neundorf wrote:
And the above are not really a big problem -
checking if something builds is no problem, this just works. Running
something is a problem, as in it doesn't just work (...because you cannot
run it).
Noticing 2 weeks after deployment
On Friday 13 June 2008 15:05:54 Tim Bird wrote:
Rob,
This is an excellent and concise description of the open
source perspective on the problem. I'll add just one note below.
Rob Landley wrote:
1) Try to reproduce the bug under a current kernel. (Set up a _test_
system.)
This sounds
On Sunday 15 June 2008 10:39:43 Leon Woestenberg wrote:
Hello all,
On Thu, Jun 12, 2008 at 2:41 AM, Rob Landley [EMAIL PROTECTED] wrote:
Most packages don't cross compile at all. Debian has somewhere north of
30,000 packages. Every project that does large scale cross compiling
On Thursday 12 June 2008 13:18:07 Enrico Weigelt wrote:
* Rob Landley [EMAIL PROTECTED] schrieb:
Hi,
There's also qemu. You can native build under emulation.
did you ever consider that crosscompiling is not only good for
some other arch, but a few more things ?
Sure, such as building
On Tuesday 05 August 2008 12:30:45 Grant Likely wrote:
On Tue, Aug 5, 2008 at 11:28 AM, Mihaela Grigore
[EMAIL PROTECTED] wrote:
If I intend to run a 2.6 linux kernel under a powerpc emulator, what
is needed to make a minimal bootable system? I mean, apart from the
kernel itself and
From: Rob Landley r...@landley.net
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script
is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003.
Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
required perl to build.
Signed-off
From: Rob Landley r...@landley.net
Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh.
This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h.
Peter Anvin added this perl to 2.6.28.
Signed-off-by: Rob Landley r...@landley.net
---
arch/x86/kernel/cpu/Makefile
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2
) building a Linux kernel never required perl to be installed on the
build system. (Various development
On Friday 02 January 2009 04:16:53 Alejandro Mery wrote:
Christoph Hellwig escribió:
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building
On Friday 02 January 2009 03:04:39 Sam Ravnborg wrote:
Hi Rob.
On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote:
From: Rob Landley r...@landley.net
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell
script is much simpler, about 1/4 the size, and runs on Red
On Friday 02 January 2009 03:50:23 Paul Mundt wrote:
On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote:
The perl checkin for 2.6.25 was the camel's nose under the tent flap, and
since then two more instances of perl have shown up in the core kernel
build. This patch series removes
On Friday 02 January 2009 03:49:34 Christoph Hellwig wrote:
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel
never
On Friday 02 January 2009 10:04:08 Matthieu CASTET wrote:
Rob Landley a écrit :
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Heh,
I believe all three scripts run under dash and busybox ash. (The
timeconst.sh one
On Friday 02 January 2009 12:01:34 Sam Ravnborg wrote:
But the serie rased anohter topic: shall we ban use of perl
for generating a kernel.
I dunno about ban, but every time somebody adds perl to the hot path of
the kernel build it breaks my build system, and I write a removal patch
anyway.
Here's an updated set of patches to remove use of perl from the kernel build's
hot path (roughly defined as make allnoconfig; make; make
headers_install).
This update incorporates feedback from Sam Ravnborg, Ted Tso, Joe Perches,
Ingo Oeser, and others. It also fixes an integer overflow error
From: Rob Landley r...@landley.net
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script
is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003.
It requires a shell which can do 64 bit math, such as bash, busybox ash,
or dash running on a 64 bit host.
Changes
From: Rob Landley r...@landley.net
Remove perl from make headers_install by replacing a perl script (doing
a simple regex search and replace) with a smaller and faster shell script
implementation. The new shell script is a single for loop calling sed and
piping its output through unifdef
On Friday 02 January 2009 10:04:08 Matthieu CASTET wrote:
Rob Landley a écrit :
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
On Friday 02 of January 2009, Rob Landley wrote:
Heh,
I believe all three scripts run under dash and busybox ash. (The
timeconst.sh one
On Friday 02 January 2009 13:33:02 H. Peter Anvin wrote:
Rob Landley wrote:
You mean The new shell script is much simpler, about 1/4 the size, runs
on Red Hat 9 from 2003, and isn't perl? :)
And introduces unclear environment dependencies depending on how
external utilities are implemented
On Friday 02 January 2009 13:27:45 H. Peter Anvin wrote:
Sam Ravnborg wrote:
Hi Wookey.
Given the
simplicitly of these patches I can't see any reason not to put them
in
Please do NOT do the mistake and think this the same thing.
Rob's patch simplyfy the timecost stuff - and will
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does the same
+ PERIOD=$(echo $i | awk '{print $2}')
cut -d' ' -f2 does the same
From a standards perspective
On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote:
Leon Woestenberg wrote:
I agree with Rob that the amount of required dependencies should be
kept to a minimum.
If we only use 0.5% of a certain language (or: dependent package),
then rather implement that 0.5% in the existing
On Friday 02 January 2009 08:04:09 Theodore Tso wrote:
Sounds like though modulo dealing with 64-bit arithmetic, your patches
are mostly dash/POSIX.2 comformant, so you're probably mostly good on
that front once you address the 32/64-bit issues. I'd also suggest
explicitly add a reminder to
On Saturday 03 January 2009 21:38:13 Markus Heidelberg wrote:
Rob Landley, 04.01.2009:
Now that you mention this the second time, I have to ask where you have
this information from. Since I use Gentoo, I was always able to compile
OpenOffice (version 1, 2 and now 3) myself.
The gentoo panel
On Saturday 03 January 2009 20:14:44 H. Peter Anvin wrote:
Rob Landley wrote:
The new patches have *more* environmental
dependencies than that ever did.
Could you please be a little more specific?
In this case, you're assuming that every version of every shell this is
going to get
On Saturday 03 January 2009 23:07:55 valdis.kletni...@vt.edu wrote:
On Sat, 03 Jan 2009 19:36:04 CST, Rob Landley said:
On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote:
+for i in MSEC 1000 USEC 100
+do
+ NAME=$(echo $i | awk '{print $1}')
cut -d' ' -f1 does
On Sunday 04 January 2009 06:07:35 Alan Cox wrote:
I note that sed and printf and such are all susv3. I have an explicit
test for 32 bit math in the script that cares, and this worked in Red Hat
9 circa 2003.
If you are trying to do arbitary precision maths using standard posix
tools
On Saturday 03 January 2009 20:48:21 David Vrabel wrote:
Rob Landley wrote:
From: Rob Landley r...@landley.net
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell
script is much simpler, about 1/4 the size, and runs on Red Hat 9 from
2003.
It requires a shell which
On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote:
On Son, 2009-01-04 at 22:13 +, Jamie Lokier wrote:
Rob Landley wrote:
In a private email, Bernd Petrovitsch suggested set -- $i and then
using NAME=$1; PERIOD=$2. (I keep getting private email responses
to these sort
On Sunday 04 January 2009 18:41:15 Ray Lee wrote:
On Fri, Jan 2, 2009 at 12:13 AM, Rob Landley r...@landley.net wrote:
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell
script is much simpler, about 1/4 the size, and runs on Red Hat 9 from
2003.
Peter Anvin added
On Monday 05 January 2009 09:01:56 Jamie Lokier wrote:
Bernd Petrovitsch wrote:
I assume that the NFS-mounted root filesystem is a real distribution.
Not unless you call uClinux (MMU-less) a real distribution, no.
I want things to be orthogonal. The following should be completely separate
On Monday 12 January 2009 02:27:32 Peter Korsgaard wrote:
Mark == Mark A Miller m...@mirell.org writes:
Mark And for H. Peter Anvin, before you refer to such uses as compiling
the Mark kernel under a native environment as a piece of art, please be
aware Mark that the mainstream embedded
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
On Thursday 17 December 2009 02:31:36 Matt Hsu wrote:
Summary: Refactoring Qi, lightweight bootloader.
Proposer: Matt Hsu
Description:
Qi (named by Alan Cox on Openmoko kernel list) is a minimal bootloader that
breathes life into Linux. Its goal is to stay close to the minimum
needed
On Sunday 20 December 2009 23:51:23 Matt Hsu wrote:
Rob Landley wrote:
However, if that's your minimum then you can't use the bootloader to
re-flash the device, which is kind of handy. (It gives you an
un-bricking fallback short of pulling out a jtag.)
Hi Rob,
Well, Boot from
On Tuesday 22 December 2009 16:23:37 Andy Green wrote:
On 12/22/09 11:12, Somebody in the thread at some point said:
Hi Robert -
(Personally I used Fedora ARM port and RPM, but any distro and
packagesystem like Debian workable on ARM would be fine).
Until now, we are using the build it
On Wednesday 23 December 2009 03:29:22 Andy Green wrote:
On 12/23/09 08:56, Somebody in the thread at some point said:
Hi -
yourself because it's the buildroot mindset, that whole task
disappears with a distro basis.
If you don't step into for example toolchain problems or other crazy
On Sunday 27 December 2009 03:54:51 Andy Green wrote:
On 12/27/09 07:17, Somebody in the thread at some point said:
Hi Rob -
Before replying, I note that Mark Miller and I gave a presentation entitled
Developing for non-x86 targets using QEMU Ohio LinuxFest in October.
On Sunday 27 December 2009 04:09:23 Andy Green wrote:
I agree it's nice to have a build environment compatible with your
deployment environment, and distros certainly have their advantages, but
you may not want to actually _deploy_ 48 megabytes of /var/lib/apt from
Ubuntu in an embedded
On Monday 28 December 2009 04:27:04 Andy Green wrote:
I wasn't suggesting you don't have firsthand experience all over the
place, eg, busybox, I know it. What I do suggest in the principles I
have been bothering your Christmas with here can really pay off and are
in the opposite direction to
From: Rob Landley rland...@parallels.com
Move an assert under DEBUG_KERNEL.
Signed-off-by: Rob Landley rland...@parallels.com
---
Saves about 3k from x86-64 defconfig according to scripts/bloat-o-meter.
include/linux/rtnetlink.h |4
1 file changed, 4 insertions(+)
diff --git
, but couldn't find one.
I can add one, but this seems a bit small to have its own symbol, and
DEBUG_KERNEL is already used in a few *.c files.)
From: Rob Landley rland...@parallels.com
Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
Signed-off-by: Rob Landley rland
On 01/20/2011 03:57 AM, Jacob Avraham wrote:
Hi,
I have a system with several USB disks, each of them is boot-capable.
Each such device has a kernel and initrd in its filesystem.
I want to be able to determine in initrd from which USB device it (and the
kernel) were
loaded from, so I can
On 02/14/2011 06:33 PM, Darren Hart wrote:
I'm looking to build a bare minimum x86 kernel that will boot and run
busybox, nothing else (and eventually less than that). Assuming I do
need USB-HID, IDE, and basic TCP/IP, what should I expect to be the
least RAM I could get away with just to boot
On 01/16/2013 02:17:39 AM, zhaoyilong wrote:
When I open the macro DEBUG in the front of file
arch/arm/boot/decompressed/head.S,the kernel runs and stops
atUncompressing
Linux... done, booting the kernel.
No, that's just the last thing it output.
I seldom find other people's debug code
On 09/09/2013 09:11:44 PM, Rob Landley wrote:
On 09/09/2013 06:04:49 PM, OSJ wrote:
I have a client looking for a remote ARM Embedded Developer with the
following skills:
The balsa email client is kind of annoying. Removing an email from the
cc: list doesn't actually take effect until you
It's reasonably standlone useful at this point, so I thought you might
want to know:
http://landley.net/aboriginal/about.html
It's a tiny Linux system (9 packages total but they boil down to
busybox, uClibc, and the last gplv2 release of gcc) all cross compiled
to several different targets (arm,
On 05/05/14 10:40, Dirk Behme wrote:
Hi,
regarding boot time optimization, on an embedded ARM Cortex-A9 based
system with 512MB or 1GB main memory, we found that initializing this
main memory takes a somehow large amount of time.
Initializing 512MB takes = ~100ms, the additional 512MB on
On 10/21/14 14:58, Nicolas Pitre wrote:
On Tue, 21 Oct 2014, Bird, Tim wrote:
I'm going to respond to several comments in this one message (sorry for the
likely confusion)
On Tuesday, October 21, 2014 9:31 AM, Nicolas Pitre [n...@fluxnic.net] wrote:
On Tue, 21 Oct 2014, Grant Likely
On 10/23/14 12:21, Bird, Tim wrote:
On Wednesday, October 22, 2014 8:49 AM, Nicolas Pitre [n...@fluxnic.net]
wrote:
On Wed, 22 Oct 2014, Rob Landley wrote:
Otherwise the standard hotplug notification mechanism is already
available.
I'm not sure why this attention to reading the status
On 10/23/14 14:05, Nicolas Pitre wrote:
On Thu, 23 Oct 2014, Alexandre Belloni wrote:
On 23/10/2014 at 13:56:44 -0400, Nicolas Pitre wrote :
On Thu, 23 Oct 2014, Bird, Tim wrote:
Why a trigger? I'm suggesting no trigger at all is needed.
Let all initcalls start initializing whenever they
On 10/23/14 15:50, Nicolas Pitre wrote:
On Thu, 23 Oct 2014, Bird, Tim wrote:
On Thursday, October 23, 2014 12:05 PM, Nicolas Pitre wrote:
On Thu, 23 Oct 2014, Alexandre Belloni wrote:
On 23/10/2014 at 13:56:44 -0400, Nicolas Pitre wrote :
On Thu, 23 Oct 2014, Bird, Tim wrote:
I'm not
On 10/23/14 19:36, Nicolas Pitre wrote:
On Thu, 23 Oct 2014, Rob Landley wrote:
3) You, too, conveniently avoided to define the initial problem so far.
That makes for rather sterile conversations about alternative
solutions that could score higher on the mainline acceptance scale
On 02/12/2015 06:56 PM, Tim Bird wrote:
On 02/12/2015 02:30 PM, K Richard Pixley wrote:
On 2/12/15 14:01 , Tim Bird wrote:
On 02/12/2015 11:33 AM, K Richard Pixley wrote:
I'm having trouble figuring out how to embed a dtb file into my kernel.
I'm thinking that there should be a standard,
On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
frank.row...@sonymobile.com wrote:
In recent years there have been proposed tools to aid in the creation of valid
device trees and in debugging device tree issues. An example of this is the
various approaches proposed (with source code provided)
59 matches
Mail list logo
