Wolfgang Denk wrote:
Being unable to do this just because we now also would need a native
Perl is indeed a PITA...
You can run the Perl bit with ssh remote perl, and still do the rest
of the compile natively. It's not pretty, but workable.
-- Jamie
--
To unsubscribe from this list: send the
Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
I would be surprised if it was possible to compile Linux with gcc 4.2
with 32MiB of total system memory.
Hint: if memory really gets tight, you can use swap space. Either to
a local drive (either through PCI or
Bernd Petrovitsch wrote:
Actually the size of ints (or any other type) can be easily deduced
without running a (for the target) compiled binary:
- compile the binary (for the target) with an initialized variable with
that value.
- use cross nm (or a similar tool) to read it from there.
Or
Bill Traynor wrote:
Maybe I'm being dense, but what's specifically wrong with the current
toolchain universe?
Back in ye olde days, you could download GCC and Binutils from
gnu.org, configure for whatever is your architecture, and most times
it just worked.
For some reason, that stopped a
Enrico Weigelt wrote:
But: the question is whether you'll need such a test at all
or if just using sizeof() at the right place won't do the trick ;-P
It's best to do that if you can, and nearly always possible. There
are a few coding techniques - especially performance sensitive - where
that's
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote:
Battle of Wesnoth is currently converted to both Scons and CMake, and
in the end they will decide about the winner. (since Eric is good at
arguing I guess it will be scons).
The thing is that
Robert Schwebel wrote:
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote:
A trouble with that is some packages have hundreds of user-selectable
options - or even thousands.
I've not seen a package with thousands of user selectable options. It's
not even desirable, because
David Woodhouse wrote:
On Sat, 2008-06-14 at 10:56 +0100, Oleg Verych wrote:
I saw that. My point is pure text processing. But as it seems doing
`make` is a lot more fun than to do `sh` `sed`.
The problem is that it _isn't_ pure text processing. There's more to
building with --combine
Enrico Weigelt wrote:
Most times I've seen those checks, they silently enable some
features, eg. if it looks for certain kernel devices. Definitively
the wrong way!
Agreed. Though, you do often have to check for headers etc.,
otherwise you won't have the definitions needed to work with those
Bernd Petrovitsch wrote:
_check_ for many installed libraries. Get them wrong, and you have
the same problems of untested combinations.
As long as I can specify that libfoo support must be compiled in (and
thus libfoo must be present) and the tools throw an error if it doesn't
find it, I
Enrico Weigelt wrote:
Reality is that Kconfig front end to autotools does work - as you've
proved. It's a good idea. :-)
Now, we just need an autoconf-alike frontend for Kconfig ;-)
I agree and would support:
./configure --menu
Invokes a configuration menu / wizard for
David Woodhouse wrote:
On Mon, 2008-06-16 at 11:49 +0100, Jamie Lokier wrote:
But here's the thing: do you really want every package have code
calling every different variation on a system call, at run time, until
it finds one that works?
No. That functionality lives in libc, if you want
Alexander Neundorf wrote:
On Monday 16 June 2008 13:39:46 you wrote:
...
If you're going to rewrite Autotools using GNU Make, why not ask if
another tool would be better, perhaps a tool specially designed for
the job?
Go ahead.
The first part of going ahead is to brainstorm
Bernd Petrovitsch wrote:
If GOLD is as old and flexible (and portable?) as binutils,
The author says it will only work with ELF, and he does not
intend to add support for all the other things binutils does.
gcc and/or other huge software maintained to death, it is probably
similar complex and
Jared Hulbert wrote:
The biggest improvement is in the way AXFS allows for each page to be XIP or
not. First, a user collects information about which pages are accessed on a
compressed image for each mmap()ed region from /proc/axfs/volume0. That
'profile' is used as an input to the image
Jared Hulbert wrote:
On Fri, Aug 22, 2008 at 11:13 AM, Jamie Lokier [EMAIL PROTECTED] wrote:
Greg Ungerer wrote:
One thing for sure is that many people who do non-MMU setups
are interested in XIP to get the space savings. These are very
often small devices with very constrained RAM
Bernd Petrovitsch wrote:
If you develop an embedded system (which is partly system integration
of existing apps) to be installed in the field, you don't have that many
conceivable work loads compared to a desktop/server system. And you have
a fixed list of drivers and applications.
Hah! Not
Linus Torvalds wrote:
Most LOCs of the kernel are not written by people like you or Al Viro or
David Miller, and the average kernel developer is unlikely to do it as
good as gcc.
Sure. But we do have tools. We do have checkstack.pl, it's just that it
hasn't been an issue in a long
Bernd Petrovitsch wrote:
32MB no-MMU ARM boards which people run new things and attach new
devices to rather often - without making new hardware. Volume's too
low per individual application to get new hardware designed and made.
Yes, you may have several products on the same hardware
Jared Hulbert wrote:
What kind of NOR you using? That is not what I measure with fast
synchronous burst NOR's.
I think the fast in fast synchronous gives it away :-)
I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
By the way, what speeds do you get on
[EMAIL PROTECTED] wrote:
I'm working with a board where the power is turn on/off through a key as
in a car. Is there any design pattern to afford that? It's the first time
I have to manage a situation where the power can suddenly cut in anytime.
Hardware guys are working to get time to do a
David Woodhouse wrote:
On Sat, 2008-10-18 at 12:49 +0100, Jamie Lokier wrote:
Can you use a journalling filesystem like ext3, reiserfs, xfs, or even
UBIFS on the card, or does it have to be FAT? With a journalling
filesystem, they vary on the details but basically if you can finish
David Woodhouse wrote:
On Sat, 2008-10-18 at 13:56 +0100, Jamie Lokier wrote:
Trouble is, that's not suitable for a dashboard unit where users plug
in their own media card.
Marco didn't say if the SD card is for users to plug in their own
media, or if it's internal storage
Phillip Lougher wrote:
One-shot LZMA decoding therefore isn't going to work very well with
future versions of Squashfs, obviously a solution (as is currently done
with the Squashfs-LZMA patches) is to use separately allocated
contiguous input/output buffers, and memcpy into and out of them,
David Brownell wrote:
The reason single-bit operations don't provide error paths is twofold.
First, they started as wrappers for can't-fail register accessors.
Second, it's extremely unrealisitic to expect much code to handle any
kind of faults in the middle of bitbanging loops ... or even
Rob Landley wrote:
This doesn't _need_ bignum support. It maxes out around 72 bits and
the _result_ can't use more than about $SHIFT bits because you're
dividing by the amount you shifted, so just chop off the bottom 32
bits, do a normal 64 bit division on the top (it has to fit), and
then
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 of threads, and then getting dismissed as the only one
who cares about the issue. Less so this time around, but still...)
Bernd Petrovitsch wrote:
(I have 850 Linux boxes on my network with a bourne shell which
doesn't do $((...)). I won't be building kernels on them though :-)
Believe it or not, but there are folks out there who build the firmware
on ARM 200 MHz NFS-mounted systems natively (and not simply
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
Pádraig Brady wrote:
The $(( ... )) construct is standard POSIX shell syntax, see
http://www.opengroup.org/onlinepubs/95399/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
Alan Cox wrote:
To start with there is no reason that the
USB console can't implement a maybe we have hardware, maybe I buffer 64K
until it shows up behaviour and bind to hardware as and when USB serial
devices get inserted.
Ah, that doesn't work, when you want to use the USB serial console
Linus Torvalds wrote:
[ Actually, looking closer we should not use that particular name: we
already have something called a console_driver which is really the
current VT driver.
Speaking of names... The word console is used to mean three
different things in the kernel. Last time I had
Alan Cox wrote:
It would be a sensible though boring cleanup to change all the VC
(virtual console) stuff to use the name VT (virtual terminal)
consistently.
Then we would have two completely different meanings for virtual terminal
in the kernel.
As opposed to three meanings for console
David VomLehn wrote:
This looks like a good plan and not hard to implement. It even should
be possible to fit USB disk drives into the scheme.
That would definitely rock.
How about this, perhaps in the generic device model:
1. Whenever a device's existence is detected by its parent
David VomLehn wrote:
I think this is over-engineered. This focused on boot devices, so you really
don't care about things like buses, and I don't perceive a broader use. What
really matters is particular boot device types, wherever they came from.
I'm thinking this broader use:
- My boot
Alan Stern wrote:
On Sat, 25 Apr 2009, Jamie Lokier wrote:
I'm thinking this broader use:
- My boot _script_ is waiting for a disk which identifies as
UUID=392852908752345749857 to appear before it can mount it on
/data. If there's no such disk, it proceeds without
Alan Stern wrote:
On Sun, 26 Apr 2009, Jamie Lokier wrote:
Are you suggesting this new interface be exported to userspace somehow?
Not directly. Only in the same way that open(/dev/console) delays
until there's a console, so reading the keyboard can delay until we
know if we had
Kay Sievers wrote:
_If_ the system doesn't wait for all block devices present at boot to
be enumerated before the boot script, then when the script looks in
that directory for a specific UUID, it would be good to wait until
has everything present at boot been enumerated? says yes.
Kay Sievers wrote:
On Mon, Apr 27, 2009 at 01:12, Jamie Lokier ja...@shareable.org wrote:
Kay Sievers wrote:
_If_ the system doesn't wait for all block devices present at boot to
be enumerated before the boot script, then when the script looks in
that directory for a specific UUID
George G. Davis wrote:
On Fri, May 15, 2009 at 02:55:57PM +0100, Ben Dooks wrote:
On Fri, May 15, 2009 at 02:51:05PM +0100, Jamie Lokier wrote:
Eek, can you say a bit more about the ARM EABI mismatch?
I would like to run a shiny modern ARM EABI kernel and userspace, but
also need
Jamie Lokier wrote:
Structure packing: Isn't that basically the same set of fixups that
need to be done for 32-bit compatibility on 64-bit kernels? Could it
even use the same code - sneakily replacing 32 with OABI and 64
with EABI?
On second thoughts, I guess there may be a few fixups
Marco wrote:
Simply because the ramdisk was not designed to work in a persistent
environment.
One thing with persistent RAM disks is you _really_ want it to be
robust if the system crashes for any reason while it is being
modified. The last thing you want is to reboot, and find various
Marco wrote:
There's the checksum, but the most important feature of this fs is the
write protection. The page table entries that map the
backing-store RAM are normally marked read-only. Write operations into
the filesystem temporarily mark the affected pages as writeable, the
write operation
Grant Likely wrote:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With this approach, a driver can use a
bus_register_notifier() variant
Grant Likely wrote:
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
That would work for some cases, but a lot of cases the problem is not
module init
Marco wrote:
Second question: what happens if the system crashing _during_ a write
to a file. Does it mean that file will fail it's checksum when it's
read at the next boot?
Maybe files aren't so important. What about when you write a file,
and then rename it over an existing file
Pavel Machek wrote:
On Tue 2009-06-23 20:07:23, Marco wrote:
You are talked about journaling. This schema works well for a disk, but
what about a piece of ram? What about a crazy kernel that write in that
area for a bug? Do you remember for example the e1000e bug? It's not
I believe you
Marco Stornelli wrote:
2009/6/24 Jamie Lokier ja...@shareable.org:
Marco wrote:
Second question: what happens if the system crashing _during_ a write
to a file. Does it mean that file will fail it's checksum when it's
read at the next boot?
Maybe files aren't so important. What
Alan Cox wrote:
Or, maybe the userspace program can receive some sort of interrupt
from the TTY device when it is ready for I/O.
Perhaps there is another way to avoid continued polling?
TIOCMIWAIT ioctl for modem signals, and just using poll/select() on the
tty for I/O.
Ah yes, the
Bill Gatliff wrote:
Actually, I'd rather that drivers look at the hardware itself, and
verify that the configuration matches what the parameter specifies
before making changes. That way you could use framebuffer= to
communicate the desired setup to the driver in cases where the hardware
Tim Bird wrote:
David Miller wrote:
From: Tim Bird tim.b...@am.sony.com
Date: Mon, 17 Aug 2009 18:24:26 -0700
David Miller wrote:
I have card/switch combinations that take up to 10 seconds to
negotiate a proper link.
What types of delays are these timeouts supposed to
cover?
Johannes Stezenbach wrote:
a while ago I was working on a SoC with 200MHz ARM926EJ-S CPU
and integrated 100Mbit ethernet core, connected on internal
(fast) memory bus, with DMA. With iperf I measured:
TCP RX ~70Mbit/sec (iperf -s on SoC, iperf -c on destop PC)
TCP TX ~56Mbit/sec
Marc Andre Tanner wrote:
+ * The check with sizeof(void*) should make sure that we don't operate on
+ * pointers, which the compiler wouldn't be able to optimize out, but only
+ * on string constants.
Take a look at __builtin_constant_p in the GCC manual.
You'll probably find that wrapping
Mike Frysinger wrote:
it depends completely on how the macro is intended to be used. if you
want to maintain the this macro has a return value, then you have to
use ({...}). if you want the macro to return a void, then you have to
use do{...}while(0).
Actually no. The difference is do
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.) But doing that
requires things like a network driver, TCP/IP stack, tftp
implementation,
Andy Green wrote:
No TCP/IP, no TFTP, not even BOOTP (but it's a nice bonus), no command
line interpreter (just a GPIO on board to boot into unbrick me mode
:-), and most strikingly _no_ flash driver for flash chip du jour.
To flash it you send a kernel to boot from RAM which is capable of
Andrew Morton wrote:
I meant with the classic use of mtdoops, therefore with a flash
partition without use MTD_RAM. Using MTD_RAM, it's more or less the
same thing, with the exception of where you want deploy the log. For
example: if in your system you have got a nvram you can use it
Marco Stornelli wrote:
Il 13/03/2010 00:31, Jamie Lokier ha scritto:
That'd be fine if the kernel link scripts choose the address, as long
as it's consistent between different compiles and similar
configurations. That'd be a bit simpler than the admin having to know
the memory map well
58 matches
Mail list logo
