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
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 u
Matt Mackall wrote:
> On Mon, 2010-02-08 at 21:46 +0800, Wu Fengguang wrote:
> > Chris,
> >
> > Firstly inform the linux-embedded maintainers :)
> >
> > I think it's a good suggestion to add a config option
> > (CONFIG_READAHEAD_SIZE). Will update the patch..
>
> I don't have a strong opinion he
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 c
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
> implementatio
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
Marc Andre Tanner wrote:
> Thanks, so if I understood it correctly this should be used like this:
>
> #define PRINTK_FILTER(fmt) (
> \
> (((const char *)(fmt))[0] != '<' && CONFIG_PRINTK_VERBOSITY >= 4) ||
> \
> (((const char *)(fmt
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
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
Tim Bird wrote:
> David Miller wrote:
> > From: Tim Bird
> > 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?
>
Zan Lynx wrote:
> Or maybe its cheap and slow flash. In that case I think your only hope
> is to make all the code as small as possible and/or find a different
> flash filesystem that does not have to read so much of the device to
> mount. Perhaps use a read-only compressed filesystem for the sy
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
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
Marco Stornelli wrote:
> 2009/6/24 Jamie Lokier :
> > 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 n
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 beli
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 exis
Grant Likely wrote:
> On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier 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
>
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 w
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 opera
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
direct
Robin Getz wrote:
> - late crash analysis - Sometimes - even after the kernel is up
>and running properly - a device driver does a bad thing.
>Normally - complete kernel dumps can come out a serial
>console, and you can you your favourite serial application
>to scroll back and det
Marco wrote:
> Linux traditionally had no support for a persistent, non-volatile
> RAM-based filesystem, persistent meaning the filesystem survives a
> system reboot or power cycle intact. The RAM-based filesystems such as
> tmpfs and ramfs have no actual backing store but exist entirely in the
> p
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
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 moder
David Woodhouse wrote:
> On Fri, 2009-05-15 at 13:50 +0200, muzu...@gmx.net wrote:
> > Questions:
> > - Can I run an application compiled with gcc ABI 2.95 on a kernel
> > compiled with gcc ABI 3.4?
>
> Yes. The kernel ABI never changes in a backward-incompatible fashion.
> Unless you try switchin
Kay Sievers wrote:
> On Mon, Apr 27, 2009 at 01:12, Jamie Lokier 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
> &g
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.
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 con
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
> >
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 boo
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 par
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
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
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 cons
Ingo Molnar wrote:
> * Arjan van de Ven wrote:
> > But more importantly... USB *CANNOT* do this fundamental
> > operation. USB does not have the capability to know when you have
> > seen all devices that are connected. Devices just show up a random
> > amount of time after you turn the power on
Robin Getz wrote:
> I'm just wondering what people using on standard embedded/headless/diskless
> targets (which do not have hw random number generators) as a source of
> entropy - since networking was removed as an entropy source circa 2.6.26
You might not have much real entropy to use. I gues
Rob Landley wrote:
> On Friday 16 January 2009 08:54:42 valdis.kletni...@vt.edu wrote:
> > On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> > > P.S. I still hope autoconf dies off and the world wakes up and moves
> > > away from that. And from makefiles for that matter. But in the
> > > mea
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 thi
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 remembe
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.
> > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add
> > proper shared libs. Feel free to fund this :-)
>
> The
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
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...)
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
> th
Theodore Tso wrote:
> perl is actually quite portable.
Portability aside, Perl has another fun issue. The number of times
I've had a Perl script break when copied to a newer system which had a
newer version of Perl is... noticable.
> I'd also suggest explicitly add a reminder to the shell script
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
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 th
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
&
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 basica
[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
Jared Hulbert wrote:
> > I think the "fast" in "fast synchronous" gives it away :-)
>
> Yes, I suppose it does.
>
> > I'm using Spansion MirrorBit S29GL128N, which reads at about 0.6 MByte/s.
>
> I think you should get more like an order of magnitude higher Get
> an expert to look at your ti
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,
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 hardw
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
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!
Linus Torvalds wrote:
> The inline-functions-called-once thing is what causes even big functions
> to be inlined, and that's where you find the big downsides too (eg the
> stack usage).
That's a bit bizarre, though, isn't it?
A function which is only called from one place should, if everything
Greg Ungerer wrote:
> Sort of. It actually just uses a single ->read to bring in
> the entire file contents. There is a few limitations on the use
> of mmap() for non-mmu. Documentation/nommu-mmap.txt gives
> more details. With no MMU it does rely on being able to kmalloc()
> a single RAM region bi
Jamie Lokier wrote:
> 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
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
&
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 and flash. (For
> whatever it is worth single NOR flash only boards are common in
> these smaller form
Greg Ungerer wrote:
>
> Jamie Lokier wrote:
> >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
> >
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
Adrian Bunk wrote:
> On Fri, Aug 01, 2008 at 12:42:22AM +0200, Bernhard Fischer wrote:
> > On Thu, Jul 31, 2008 at 01:12:19PM +0300, Adrian Bunk wrote:
> > >On Thu, Jul 31, 2008 at 12:09:29PM +0200, Bernhard Fischer wrote:
> > >> On Thu, Jul 31, 2008 at 11:27:04AM +0200, Thomas Petazzoni wrote:
> >
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
Haavard Skinnemoen wrote:
> "Bart Van Assche" <[EMAIL PROTECTED]> wrote:
> > I looked through the gold sources a bit. I wish everything in the GNU
> > toolchain were written this way. It is very clean code, nicely
> > commented, and easy to follow. It shows pretty clearly, I think, the
> > ways in
Bart Van Assche wrote:
> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
> <[EMAIL PROTECTED]> wrote:
> > If you're embedded device has a window system, than a language like C++
> > is fine...But...
>
> C++ is suited for much more than just windowing systems. A good
> example is the GOLD project
Leisner, Martin wrote:
> I've found you can understand spaghetti C code with some effort -- its
> nearly impossible to understand spaghetti C++ code. Much professional
> programming is "kitchen sink mentality" -- if there's a feature, use it.
>
> I find it interesting K&R is about 200 pages, Stro
Matt Mackall wrote:
> The typical embedded NFS-based devices are NAS servers and media players
> and are going to be more concerned about things like page cache
> balancing.
Oh, those.
It would be really annoying to buy a home NAS and find it doesn't
support NFS locks or SMB oplocks. NASes are v
Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
I'm avoiding it, because of reports of occasional elf2flt relocation
errors when using C++ a few months ago, on this list.
However, some of the libraries I'm using have some C++ in them,
Bernhard Fischer wrote:
> On Mon, Jun 16, 2008 at 02:32:01PM +0100, Jamie Lokier wrote:
>
> >No, I'm talking about improving Autotools to handle some things better
> >than they do now. Passing the high hurdles required to become part of
> >Autotools - especially c
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
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
Enrico Weigelt wrote:
> > Imho, Kconfig would be good for more programs than it's currently used for,
> > and could be made to work with those --enable/--with options: you'd be
> > able to configure them entirely on the command line, or interactively
> > with "./configure --menu" (runs menuconfig),
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
Robert Schwebel wrote:
> We have once tried to write our automated test system for embedded
> boards with python and xml; the idea was to have something fancy, new
> and with good code-reuse. In the end it failed because the pexpect
> package we used to do the pattern matching bitrotted so quickly
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
> fin
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 tho
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 --c
Bill Traynor wrote:
> > For some reason, that stopped a while ago, and you had to go to
> > different places to get working basic tools. And often, the place to
> > go wasn't clear. Different people advertised their "ARM toolchain",
> > "m68k toolchain" etc. and they were slightly different sets
Enrico Weigelt wrote:
> > Contrast with kernel.org: everyone knows where to get a good working
> > Linux kernel for the mainstream architectures, and the quality work
> > tends to be quite good at reaching mainline there nowadays.
>
> ACK. But you perhaps remember the discussions on LKML where som
Enrico Weigelt wrote:
> * Alexander Neundorf <[EMAIL PROTECTED]> schrieb:
>
> > E.g. in python there are tests which call functions and check
> > their result to see if we are currently on a platform where
> > that function is broken (I think there was such a test for
> > poll() and some other
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.
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 th
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'
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 whi
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.
Rob Landley 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
> (buildroot, gentoo embedded, timesys making fedora cross compile, etc) tends
> to have about 200 packages that cross compile mor
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
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 t
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 t
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
H. Peter Anvin wrote:
> Tim Bird wrote:
> >With CONSOLE_TRANSLATIONS turned off, this saves about 6K
> >on my kernel configured for an ARM development board (OMAP
> >5912 OSK). In embedded products I'm familiar with,
> >console translations are not needed.
>
> On most embedded products I'm famili
91 matches
Mail list logo
