Jan Ringoš wrote:
From: Gavin Lambert gav...@compacsort.com
Quoth Jan Ringoš:
3) There is no practical distinction between process and thread in
uClinux
as there is in Windows world.
Untrue. Just as on Windows, processes have separate address spaces
(normally) while threads
have
Michael Schnell wrote:
9) Or is my approach of multiple processes otherwise flawed?
In Linux the communication between processes is really fast, cheap, easy
and versatile.
You can e.g. use pipes/queues (e.g. named pipes in the file system or
system 5 message queues).
In many cases
Michael Schnell wrote:
4) Can pthread mutexes be used across vfork/exec sub-processes?
In documentation to pthreads they say that the pthread_mutex can be
used to synchronize threads but not processes. But I see no difference
between thread and process in uClinux. What am I missing?
To do
Lennart Sorensen wrote:
You will need to disassemble a simple program and see what code is
generated. Look for differences on the same code compiled with the
older toolchain and the newer.
Yeah, although of course if it is the ABI change I am not sure how I would
recognize something
Mike Frysinger wrote:
i believe David Howells has down a lot of work to get futex's
working on no-mmu. but that doesnt mean the syscall has been added
and people have actually tested it yet ...
futex mutexes should be easy. The harder bit is TLS. Switching to
NPTL implies both, as far as I
Mike Frysinger wrote:
On Saturday 28 February 2009 14:16:30 Jamie Lokier wrote:
(I still haven't figured out if it's safe to use vfork with shared
libraries and lazy procedure lookup... doesn't apply for Jan's ARM
with no shared libraries of course).
why wouldnt it ? there isnt any
Michael Schnell wrote:
In my particular case kernel uses all available
RAM (~10MB) for disk
cache and releases it only in ~15 seconds. Other
applications cannot
Andrei's filling page cache at the rate of ~10MB in 15 seconds.
Michael Schnell wrote:
No doubt VM tunables can be adjusted in 2.6 to
release that page cache faster, but the defaults aren't fast enough.
That is why I suppose using 2.6 is the way to go here.
2.6 has a large number of very good reasons to use it, but it does
seem to have regressed
Mike Frysinger wrote:
On Wednesday 25 February 2009 07:14:30 angelo wrote:
i am wandering if i am writing in the correct list, since i written many
mails but i never had an answer. Maybe the develoment mean a branch
for the uclinux dist. developers team only, or maybe custom hardware
Andrei Martynov wrote:
Thursday, February 19, 2009, 8:57:46 PM, Jamie Lokier wrote:
2.4.37 is a bit better because it has some USB storage bug fixes and
things like that.
I've just found an old thread about different memory allocator
behavior in 2.4.17 and 2.4.24 that results in memory
Michael Schnell wrote:
I understand the Andrei sees the problem in any case, not only with high
rate traffic.
Andrei wrote:
In my particular case kernel uses all available RAM (~10MB) for disk
cache and releases it only in ~15 seconds. Other applications cannot
Andrei's filling page cache
Michael Schnell wrote:
Certainly, on 2.4, you cannot find suitable settings in a standard 2.4
kernel. Only the patched uClinux 2.4 kernel works, and I had to patch
it some more.
I suppose v2.6 offers more on that behalf.
It does, but the page_alloc2.c allocator option in 2.4 seems to
Michael Schnell wrote:
In my particular case kernel uses all available RAM (~10MB) for disk
cache and releases it only in ~15 seconds. Other applications cannot
be started if one reads large files from disk. I do not experience
this problem with 2.4.17 kernel.
AFAIK, the Kernel _should_
Michael Schnell wrote:
I'm surprised after all the effort to merge NOMMU into 2.6 as a
standard feature that it doesn't work as well as 2.4 kernels.
If this would be true no MMU-less devices with 2.6 Kernels would work
properly. But I understand that there are millions of them sold
Andrei Martynov wrote:
what 2.4.x kernel ( 2.4.17 ) can be recommended for ARM NOMMU
target? I cannot solve problems with memory fragmentation in 2.6
kernel and want to step back.
That's a disappointing result. If problems cannot be solved on ARM
NOMMU, then it's very likely they cannot be
Michael Schnell wrote:
I would like to have an SMP uClinux running on the multilple NIOS II
processors architecture (with or without cache coherence).
You might want to discuss this on the NIOS2 uCLinux mailing list:
nios2-...@sopc.et.ntust.edu.tw .
Did you already solve the appropriate
Michael Schnell wrote:
(adding support for MMU, so, PIC, and XIP).
You don't need an MMU for PIC or XIP.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by
Andrei Martynov wrote:
Tuesday, February 10, 2009, 1:27:53 PM, Jamie Lokier wrote:
The problem you have isn't really that it uses all memory for disk
cache - that's a good thing
I believe that any continuos memory (re)allocation is evil on nommu
platform with limited resources
Andrei Martynov wrote:
I'm using kernel 2.6.24 with uClinux and ARM NOMMU patches. When one
application starts reading from disk kernel uses all available memory
for caching and other applications fail to start (not enough memory).
It takes kernel up to 10 seconds to release memory after the
Jamie Lokier wrote:
Is there any way to limit disk cache size?
There was a patch posted a few weeks ago I think, to limit page cache usage.
It was on linux-kernel, I expect.
For this particular problem, you might get better answers
cross-posting to linux-ker...@vger.kernel.org as well
Robert Wessels wrote:
Just a bit more background on this. As we all know, applications
running in a nommu environment have a static stack size. although the
maximum stack size is determined by this, the stack usage grows and
shrinks. One can imagine that in a certain condition the given
Davide Zanni wrote:
Hi all,
I have an application that display the content of an USB key with
the function readdir. This work fine but with an USB key the application
crash because in the file uClibc/libc/sysdeps/linux/common/getdents.c
the compiler try to allocate about 31K of data
Chris Gray wrote:
On Monday 02 February 2009 22:01:12 Jamie Lokier wrote:
I didn't use Java because I thought it wouldn't fit, to be honest.
There's about 10MB free on my 64MB device (32 allocated to video
coprocessors, away from Linux; the rest is used by Linux, utils etc.)
I found
Jonathan Wong wrote:
Hi Jamie,
My solution is to use Sigma's GCC 2.95.3 when building a program that
links
to their libraries, but use newer GCC for other programs (that don't use
Sigma's libraries at all).
And then use JNI to call Sigma's libraries? That dashes my hopes to port
Jamie Lokier wrote:
On my video player, the control program just runs the media player in
a child process and talks over a pipe to it, in simple text commands.
So the control program can be in any language, in theory.
small
This is also quite handy when the codec crashes or gets stuck
Jonathan Wong wrote:
I won't need a web browser, just a thin client to communicate with a
central server.
You can write a client in any language. Java seems a bit heavy and
hard to get going, if you don't specifically need Java on it.
I was just told our device doesn't have RAM at all, only
Jonathan Wong wrote:
Can I use your Mika? Is the EM8623 an ARM9 or ARM7?
EM8623 is an ARM7 I believe, with no MMU.
For SMP8634 and beyond, they switched to MIPS with MMU :-)
The codesourcery toolchain uses ARM EABI, but the Sigma Designs
libraries as OABI, so watch out. You have to use the
loody wrote:
2009/1/29 Jamie Lokier ja...@shareable.org:
loody wrote:
e1a0e00fmov lr, pc
e12fff13bx r3
Actually my cpu get exception when executing this instruction not bx r3.
But lr is the destination for cpu to write, I have checked the arm
reference
make[2]: Entering directory `/home/cc/Desktop/temp/uClinux-dist/user/busybox'
LINKbusybox_unstripped^M
Trying libraries: crypt m^M
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
ucfront-gcc arm-linux-gcc -Os -g -pipe -msoft-float -fno-common -fno-builtin
-Wall
Daniel Jacobowitz wrote:
On Thu, Jan 29, 2009 at 06:12:15AM +, Jamie Lokier wrote:
I wouldn't be surprised if the Codesourcery tools (especially
pre-built libs) are targetting later ARM chips only, since people
using later ARM chips are probably paying Codesourcery for the work.
Our
loody wrote:
Try adding -mcpu=arm940t to the GCC command, and remove
-march=armv4t and -mtune=arm9tdmi from it (your example has them).
the situation is still the same when I follow the instructions you suggest.
(I use Codesourcery gcc but assign buildroot lib.)
Ah... The faulting
loody wrote:
When I use -Wl,-elf2flt,-s32768 to compile my hellow.c.
It should say -wL,-elf2flt=-s32768. Note the = (equal sign).
b.
When I use -Wl,-elf2flt to compile my hellow.c.
it will say:
arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified
for loadable section
loody wrote:
e1a0e00fmov lr, pc
e12fff13bx r3
What is the specialty of the instruction, mov lr,pc, which let
arm cpu fail?
Both of those instructions can put the CPU into Thumb mode. If it
doesn't support Thumb, you get an instruction fault.
mov lr,pc is
loody wrote:
File is not an object file
so, it seems I have to make a object relocation file to let this tool,
arm-linux-elf2flt, work.
but how?
Don't use the tool directly, use it with GCC as you found:
2. I use -Wl,-elf2flt=-s1024 with arm-linux-gcc and it says:
loody wrote:
BTW, I also find that if I want uclinux kernel to support ELF binary
file, I also have to enable the mmu option.
But the format of cross-compiled binary file like busybox is only ELF,
if there is option I can add to let busybox and other binary files
compiled in different
Glenn Henshaw wrote:
Since no one seems interested,
Sometimes you just have to post again. People are too busy to respond
to every message, so some get missed. It doesn't mean nobody cares.
This is normal on many mailing lists like this.
But note that 2.4 kernels are not supported by
Andrei Martynov wrote:
I'm porting Sigma EM85XX patches from 2.4.17 to 2.6.24 kernel. The
kernel is configured as
Very interesting. Is it an official port?
I'm porting Sigma EM86xx patches from 2.4.26 to 2.6.28.
I'd be interested in any common ground, which there might be a lot of
especially
Lin KJ wrote:
- The compiler version newer than gcc-4.x can NOT be used for XIP uClinux
because of the
R_ARM_GOTOFF32 relocation type. It will produce the R_ARM_GOTOFF32
relocation which will be resolved by adding a negative offset from the
GOT. However,
in the
Gavin Lambert wrote:
dist/vendors/config/armnommu/config.arch file?
Usually in your board-specific config.arch file (not the generic armnommu one
-- the one that you selected in the toplevel Makefile) there are three lines
like this:
# DISABLE_XIP := 1 # XIP works fine
#
Michael Schnell wrote:
(Re Futex I do know that the NIOS ISA does not have any monolithic
memory read/modify/write instructions and thus does not allow for
implementing Futex with a full Linux (using the MMU), but without
protection a thread just can do di/ei and thus no Kernel action
Michael Schnell wrote:
I'm not sure if gdbserver is working with pthreads on non-mmu at all,
because the threads are in the same address space.
I don't see this problem right now. The threads are in the same address
space with and without MMU, so this should not make a difference.
It was
Jun Sun wrote:
On Thu, Nov 27, 2008 at 02:24:48AM +0800, Lin KJ wrote:
In the ARM uClinux world, it seems that the user land XIP code should be
compiled with the -fpic and -msingle-pic-base flags.
Why not just -fpic flag?
Is it concern with the elf2flt tool?
I think it has more to do
Xin Xie wrote:
The standard way to decrease the latency for embedded system is using a
real-time kernel running alongside with uClinux and keeping the
real-time task inside the real-time kernel. Not too sure if that already
supported in the NIOS uClinux.
Yes, although nowadays the RT-PREEMPT
Arthur Wong wrote:
Not need.
Content of the compiler is not changed, it just be moved to the other
directory.
I think it's easy to swap one toolchain to another in this way.
Some toolchains don't work properly if they are moved to another
directory. It's because they have hard-coded
Grant Edwards wrote:
On 2008-11-04, Grant Edwards [EMAIL PROTECTED] wrote:
On the NIOS2 target, it works fine if I only connect to 1-2 TCP
ports, I can close the connection and then reconnect. when I
connect to more than two ports, everything works fine until I
close the connections.
Mike Frysinger wrote:
On Monday 20 October 2008, Chris Gray wrote:
On Monday 20 October 2008 19:23, Jamie Lokier wrote:
Mike Frysinger wrote:
@@ -237,9 +237,9 @@ int main(int argc, char **argv)
send_output(\n, 0, send_flag);
if (outbuf
Mike Frysinger wrote:
@@ -237,9 +237,9 @@ int main(int argc, char **argv)
send_output(\n, 0, send_flag);
if (outbuf) {
-pid = fork();
+pid = vfork();
if (pid 0) {
-perror(fork);
+perror(vfork);
David Howells wrote:
Jamie Lokier [EMAIL PROTECTED] wrote:
Fwiw, on 2.4 I use an in-house ramfs-like driver which allocates the
pages contiguously for each file, and that works nicely.
But that's not XIP. The 2.6 mmap code will attempt to do that for you for
private R/O sections
Grant Edwards wrote:
Of course you have to remember that most people using these
devices are not Linux aware at all. These are consumer level
devices.
You're right. A windows machine is the one thing that everbody
can be counted on to have.
That's a curious assumption which is
Allon Stern wrote:
Never mind NPTL - I just want Linux Threads, which don't seem to be
working for my on my NOMMU M5282 target, using 888.
I'm using uClibc 20060608
Anybody have it working? A simple example causes an illegal instruction.
I get an illegal instruction when using Linux
rwarner wrote:
Hi all,
Not sure this will be used, guess i'll wait to see if it's useful. Have
setup an irc on freenode #uC-Linux. It's not visible on the /list, but
if you /join #uC-Linux you will get in. Was wondering if this would be
a good place for quick communication when needed
rwarner wrote:
Not sure this will be used, guess i'll wait to see if it's useful. Have
setup an irc on freenode #uC-Linux. It's not visible on the /list, but
if you /join #uC-Linux you will get in. Was wondering if this would be
a good place for quick communication when needed by the
rwarner wrote:
Martin Euredjian wrote:
Why would one choose one over the other?
There is another option versus the ones above. I wrote my own as U-Boot
above appeared 'heavier-weight' then what is needed. Though i may have
missed something in the requirements of uCLinux start up.
1.
Michael Schnell wrote:
You meant -e, and that does work with msh.
Thanks a lot, Jamie. That was the trick.
(In the bash documentation -a and -e are equivalent, so I stopped
reading when I found -a.)
How did you know this ? Do you have an msh documentation ?
I did man sh, man test or
Gavin Lambert wrote:
While I admit to being mostly ignorant of signals (I don't really use them):
aren't signal handlers set by signal() single-shot handlers? So if a second
signal arrives before the signal handler itself calls signal() again then
it'll get default processing, which might be
Michael Schnell wrote:
if [ -a xy ]; then .
does not seem to work.
What am I doing wrong ?
You meant -e, and that does work with msh.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
Remco Poelstra wrote:
Mark Phillips schreef:
HI All,
Sorry to do this but usual my contacts can't give me a answer to this
question.
I have a series of switches connected in series. That is port B of
switch 1 is connected to port A of switch 2, and port B of switch 2 is
connected to
Greg Ungerer wrote:
Last time i tried it the build was broken and someone admitted it
was not maintained since the last attempt 2.6.14?
non-MMU ARM has never be in mainline, not in 2.6.14, not ever.
I have been keeping and updating patches (kept in the uClinux-dist
linux-2.6.x sources).
rwarner wrote:
Michael Schnell wrote:
I read that the now officially released Kernel 2.6.25 offers a lot of
goodies for embedded / soft-realtime systems.
Will this version included in the tools (Buildroot etc) ?
Is it recommended to use 2.6.25 for new projects ?
Did they fix the ARM
Michael Schnell wrote:
Getting DHCP working isn't trivial, since most common DHCP clients tend to
use scripts, which aren't supported by the default sash shell. But there's
probably some available that don't, or you could switch to a different
shell. Or just go with a static IP.
I just do
Greg Ungerer wrote:
Another is some handy programs (with no alternative) like iptables
don't work, because they depend heavily on loading shared libraries at
runtime. (Or does that work?)
...
It wasn't that hard to rework. Look at the code in
uClinux/dist/iptables. At the top of the
Michael Schnell wrote:
Thanks a lot for telling us your experiences.
I feel very happy that I chose an FPGA and not a dedicated hardware CPU,
so I can decide at any time if I want an MMU or not. :)
Yes, FPGAs are nice in that way. I like being able to add
special instructions and
Michael Schnell wrote:
You forgot that the text segment may contain
references to data or bss.
Ah, I did not suppose that there would be such absolute references,
which would mean that that loader needs to modify the content of the
text segment according to where it allocates the data
rwarner wrote:
Michael Schnell wrote:
I suppose due to hardware improvements, in the future even small systems
will have MMUs, so I thinks there is not too much priority on these
nommu issues. The NIOS will definitively get one, optionally , too, but
in the moment I don't consider to
rwarner wrote:
Perhaps. The biggest problem with not having an MMU is memory
fragmentation. Basically, you can't keep allocating large contiguous
segments, but you need that to run ordinary executables and other
things.
On my application, I need to keep about 8MB free out of 32MB total
rwarner wrote:
For headless systems and ones semi-stagnant in memory
allocation/reallocation an MMU-less system has many advantages.
However, what they also do is run an ssh command every 30 seconds to
report home. That's enough to start the fragmentation problems.
This is in effect a new
rwarner wrote:
Video streaming i would consider a large scale system. Why was a non
MMU processor selected for a video streaming application?
Price and availability of a chip that did good video (HDTV even), and
we didn't know the no-MMU penalty at the time.
We did compare with some other
Andrew Kohlsmith (lists) wrote:
On April 17, 2008 12:43:37 pm Jamie Lokier wrote:
Video streaming i would consider a large scale system. Why was a non
MMU processor selected for a video streaming application?
Price and availability of a chip that did good video (HDTV even), and
we
Michael Schnell wrote:
Thanks for the explanation.
I did come to this conclusion when thinking about the issue :).
What I find astonishing, is that some (seemingly many) non-MMU
architectures don't support XIP (completely position independent code
segment) and don't support using a
Robin Getz wrote:
Can someone clarify which uClinux ports are currently supported in the
mainline?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch;hb=HEAD
Ones that I am aware : arm, blackfin, frv, m68knommu, sh
Really? The last thing I read on this
Michael Schnell wrote:
Some architectures can do execute in place (XIP), some can't. (I did not
yet find out the exact reasons.)
RAM usually is a lot faster than Flash, so XIP might be not desirable.
However, XIP is possible in RAM too. If RAM is fast but you don't
have a lot of it, or if
Michael Schnell wrote:
Without an MMU, userland constructs such as fork()s and certain kinds of
mmap() won't work. So unless bash has been patched to use alternate
constructs in the absence of an MMU, it won't work either.
Right you are.
But as with uCLinux, the Kernel does not provide
Mike Frysinger wrote:
On Wednesday 02 April 2008, Jamie Lokier wrote:
But it won't work with
no-MMU targets until they support proper shared libs, which rules out
ARM-nommu and MIPS-nommu for the moment.
there are no-mmu targets which support FDPIC ELF just fine.
arm/mips however
Gavin Lambert wrote:
However this is also mitigated a bit if you can get XIP to work.
Fwiw, you can also do XIP in RAM, to reduce the footprint with
multiple instances of the same executable. I do this and it's a great
saving with several Busybox instances.
-- Jamie
Xin Xie wrote:
For NPTL implementation, here is a paper about the implementation on the
uClibc http://www.kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf.
Lovely. Seems that it will be included in the 0.9.30 release of
uClibc, though nobody knows when that will be. But it won't work with
Basically we have parent that
1. blocks all signals
2. spawns a thread (SigHandler)
3. vforks()
- child does execve(/bin/ls,NULL)
- parent sleep() loops forever
The SigHandler thread
1. blocks all signals
2. does a sigwait() loop
if SIGCHLD delivered,
_exit()
Greg Ungerer wrote:
By the way, should i use the linux-2.6.24-uc0.patch from uclinux as my
kernel porting start point?
Or use the linux-2.6.14-hsc0.patch from the uClinux/ARM2.6
project(http://opensrc.sec.samsung.com/)?
In fact, the two projects confuse me.
Up to you :-)
Putting the stand alone apps in the uClinux-dist to compile is easy
but seems not very convenient. How about the arm-elf toolchain?
Is it the same? Can i use the arm-elf toolchain to compile my own
application directly?
As I've seen, the arm-elf toolchain is older than arm-uclinux. They
Valentin Manea wrote:
there is very little information available, but from what I know until
they are using an RTOS for Starcore which runs either independently or
with a Linux on a ARM core,
but I guess if they would have ported
Linux to Starcore they should have released the code under
叶剑君 wrote:
pthread_create a new thread need how much memory resources?
does the new thread need new stack?
Yes, it allocates a new stack and some small data block.
The data is quite small, but will be larger if you use a lot of
thread-specific data. (E.g. using recent GCC and __thread).
The
Michael Schnell wrote:
No, that is a common misunderstanding.
But that would hold for nearly any software written for (not embedded)
Linux, as you need to use the gLibC header files provided and, AFAIK,
same are LGPL as well.
No, firstly there is explicit exemption for header files in
Gavin Lambert wrote:
Quoth Jamie Lokier:
A small note about licensing. uClibC is copyright licensed under the
LGPL.
If you have shared libraries on the target, it's easy to meet the LGPL
requirements. If you don't have shared libraries (e.g. ARM without
MMU), and some of your
Gavin Lambert wrote:
Still, I don't think that's much more complicated, especially since it's not
likely to come up too often (although I guess that depends on what kind of
software it is).
It's not actually hard, but you do have to pay it some attention.
Typical app Makefiles etc. don't
advan wrote:
I have one embedded device(mips R4000) with Kernel-2.4.25, it boots
with a root filesystem in JFFS2 format (/dev/mtdblock1), I would like
to switch the root filesystem to another in a RAMDISK with an ext2
filesystem, but I can't umount the JFFS2 root
Harry Gunnarsson wrote:
I thought that this was the point of the SLAB allocator, i.e.
avoiding fragmentations with fixed size pre-allocated blocks.
Well, I'm not entirely certain how the SLAB allocator operates,
since I haven't really looked at its code at all. But I do
Felipe Uderman wrote:
Is there a document that explains how does uClinux works on
providing the drivers and abstracts the hardwares? Maybe it is just to
target specific?
It's nearly all the same as standard Linux - at least, the basic
features. The major difference is things to do
Gavin Lambert wrote:
Quoth Jamie Lokier:
But this part of the kernel will relocate incorrectly in border
cases with XIP:
if (r text_len) /* In text segment */
addr = r + start_code;
else
Bob Grimes wrote:
On 9/25/07, David Wu [EMAIL PROTECTED] wrote:
From our experience, when you get BINFMT_FLAT: reloc outside program
nomally the stack is overflow and reached the memory of another process.
The newer compiler seems more likely needing larger stack.
I tried that on my
[EMAIL PROTECTED] wrote:
What does BINFMT_FLAT: reloc outside program mean, and how do I fix
it?
It means pretty much what it says. A relocation is pointing out
program text and data areas and the kernel is erroring out over it.
The fix is to remove this test from the binfmt_flat
chris brooke wrote:
I'm working on an embedded uClinux project. I am struggling to come
up with a clean way to upgrade the kernel in a system in the field.
The goal is to allow the users to easily upgrade the kernel using FTP
or HTTP (from a PC) without ever having the
wang9736 wrote:
i work on redhat linux 7.3 kernel 2.418-33
You really need to use a newer version of GNU/Linux. Red Hat Linux
7.3 is _very_ old indeed.
now i want to install a high version glibc glibc-2.6.3 by RPM, but
result is below
[EMAIL PROTECTED] wang]# rpm -i
David McCullough wrote:
for the kernel, I seem to remember that it doesn't compile with
optimization turned off, due to some macros. I think it was with the i/o
instructions...
Yeah, inlines don't like -O0 IIRC, something along those lines :-)
I also seem to remember that most of the
Greg Ungerer wrote:
An update of the uClinux (MMU-less) code against 2.6.22.
Quite a few changes, some cleanup, some bug fixes.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.22-uc0.patch.gz
And by popular request here is a big patch that will bring a
stock 2.6.22 kernel up to
Thanks for your reply, Doug.
Doug Kehn wrote:
The subtle difference is with '*big*'. The link
without '*big*' is for non-MMU targets. The link with
'*big*' is for MMU targets (it may also have non-MMU
in it too).
That is subtle. I have to wonder why not '-nommu' and '-mmu' if
that's the
David T. L. Wong wrote:
So far it is. But how about Samba NTFS-3g? Any component we used in
our product changes to GPLv3 would give us a headache.
Not a problem, surely? You are already distributing the source for
your version of Samba etc., right?
How does them changing to GPLv3 change
David T. L. Wong wrote:
I think so. SMP863X is an highly integrated System on Chip. You need
their kernel patch for IDE driver,PCI driver,Serial port driver, Flash
interface driver, Network interface driver and USB driver.
All SMP863X set-top box vendors are suppose to release the kernel
Ahan Hsieh 謝武漢 wrote:
After system call vfork() is called, the parent is suspended and
cannot continue executing until the child exits or calls exec(),
the system call used to start a new application.
The child, directly after returning from vfork(),
is running on the parent's
Aristotelis Iordanidis wrote:
We've run into the same problem, working with an armnommu platform.
We tracked down the root of the high cpu load to the function
kswapd_balance_pgdat() in linux-2.4.x/mmnommu/vmscan.c.
The problem occurs only when using the non-power-of-2 memory allocator
David Spain wrote:
I forgot to add the obligatory:
uclinux-2.4.32-uc0 from the 20060803 drop.
Compiled with the gcc 2.95.3 binutils.
page_alloc2.c is better for reducing fragmentation and also being less
sensitive to it, but it doesn't interact with kswapd's wakeup logic in
quite the way
Greg Ungerer wrote:
Is there a (good :) ) reason why uClinux-dist/Makefile clean: target now
deletes the $(LINUX)/include/asm symlink?
This means that after a make clean you have to make oldconfig to get the
symlink back. Perhaps this should be in distclean rather than clean?
It sure
101 - 200 of 200 matches
Mail list logo
