Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
Hi Rich,
On 14/10/15 01:49, Rich Felker wrote:
> On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote:
>> Hi Rich,
>>
>> On 09/10/15 02:38, Rich Felker wrote:
>>> From: Rich Felker <dal...@libc.org>
>>>
>>> The ELF binary loader in binfmt_elf.c requires an MMU, making it
>>> impossible to use regular ELF binaries on NOMMU archs. However, the
>>> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
>>> for plain ELF, which requires constant displacements between LOAD
>>> segments, since it already supports FDPIC ELF files flagged as needing
>>> constant displacement.
>>>
>>> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
>>> on NOMMU archs. They are treated identically to FDPIC ELF files with
>>> the constant-displacement flag bit set, except for personality, which
>>> must match the ABI of the program being loaded; the PER_LINUX_FDPIC
>>> personality controls how the kernel interprets function pointers
>>> passed to sigaction.
>>>
>>> Files that do not set a stack size requirement explicitly are given a
>>> default stack size (matching the amount of committed stack the normal
>>> ELF loader for MMU archs would give them) rather than being rejected;
>>> this is necessary because plain ELF files generally do not declare
>>> stack requirements in theit program headers.
>>>
>>> Only ET_DYN (PIE) format ELF files are supported, since loading at a
>>> fixed virtual address is not possible on NOMMU.
>>>
>>> Signed-off-by: Rich Felker <dal...@libc.org>
>>
>> I have no problem with this, so from me:
>>
>> Acked-by: Greg Ungerer <g...@uclinux.org>
>
> Thanks!
>
>>> ---
>>>
>>> This patch was developed and tested on J2 (SH2-compatible) but should
>>> be usable immediately on all archs where binfmt_elf_fdpic is
>>> available. Moreover, by providing dummy definitions of the
>>> elf_check_fdpic() and elf_check_const_displacement() macros for archs
>>> which lack an FDPIC ABI, it should be possible to enable building of
>>> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
>>> binary support, but I have not yet tested this.
>>
>> There is a couple of other details that will currently stop this from
>> working on other arches too.
>>
>> .. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
>> .. arch specific mm_context_t may not have members
>> ‘interp_fdpic_loadmap' or 'exec_fdpic_loadmap'
>>
>> Should be easy to fix those.
>
> I see. For archs that lack an FDPIC ABI, I'm not sure it makes sense
> to add these things unless/until someone developes an FDPIC ABI. Would
Ok. I was looking at it from the point of view of supoporting ELF
on m68k/coldfire, that doesn't currently support FDPIC. So bypassing
FDPIC support completely.
> it instead make sense to add a new kconfig switch
> CONFIG_BINFMT_ELF_NOMMU ("NOMMU ELF loader") that's implied-on by
> CONFIG_BINFMT_ELF_FDPIC but that can also be enabled independently on
> archs where CONFIG_BINFMT_ELF_FDPIC is not available?
Yes that may be the only answer here.
> Right now these are just ideas. Unless there's a quick and easy
> decision to be made, I'd like it if we could move forward with the
> current patch (which only offers the feature on archs where
> CONFIG_BINFMT_ELF_FDPIC is already available) first and continue to
> explore options for making this available to other archs separately.
Oh, yes. No problem with that. Looks like Andrew has picked it
up. So all good there.
>> It would be good to get some testing and verification on other
>> fdpic supported arches (frv or blackfin or microblaze for example).
>
> I wasn't aware Microblaze had an FDPIC ABI; are you sure it does?
Sorry, my mistake. No microblaze FDPIC as far as I know.
Regards
Greg
> Testing to make sure these aren't broken by the patch shouldn't be
> hard to do; I'll start looking into getting a setup for it or finding
> someone who has one. If you want to also test non-FDPIC ELF binaries,
> I think just using the ELF output of a bFLT toolchain without running
> elf2flt may work as a test case, but I'm not sure. Alternatively, any
> FDPIC binary linked with -pie that doesn't use signals can run as a
> non-FDPIC one just by clearing the FDPIC bit in the header.
>
> Rich
>
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
Hi Rich,
On 09/10/15 02:38, Rich Felker wrote:
From: Rich Felker <dal...@libc.org>
The ELF binary loader in binfmt_elf.c requires an MMU, making it
impossible to use regular ELF binaries on NOMMU archs. However, the
FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader
for plain ELF, which requires constant displacements between LOAD
segments, since it already supports FDPIC ELF files flagged as needing
constant displacement.
This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files
on NOMMU archs. They are treated identically to FDPIC ELF files with
the constant-displacement flag bit set, except for personality, which
must match the ABI of the program being loaded; the PER_LINUX_FDPIC
personality controls how the kernel interprets function pointers
passed to sigaction.
Files that do not set a stack size requirement explicitly are given a
default stack size (matching the amount of committed stack the normal
ELF loader for MMU archs would give them) rather than being rejected;
this is necessary because plain ELF files generally do not declare
stack requirements in theit program headers.
Only ET_DYN (PIE) format ELF files are supported, since loading at a
fixed virtual address is not possible on NOMMU.
Signed-off-by: Rich Felker <dal...@libc.org>
I have no problem with this, so from me:
Acked-by: Greg Ungerer <g...@uclinux.org>
---
This patch was developed and tested on J2 (SH2-compatible) but should
be usable immediately on all archs where binfmt_elf_fdpic is
available. Moreover, by providing dummy definitions of the
elf_check_fdpic() and elf_check_const_displacement() macros for archs
which lack an FDPIC ABI, it should be possible to enable building of
binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF
binary support, but I have not yet tested this.
There is a couple of other details that will currently stop this from
working on other arches too.
. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC)
. arch specific mm_context_t may not have members ‘interp_fdpic_loadmap'
or 'exec_fdpic_loadmap'
Should be easy to fix those.
It would be good to get some testing and verification on other
fdpic supported arches (frv or blackfin or microblaze for example).
Regards
Greg
The motivation for using binfmt_elf_fdpic.c rather than adapting
binfmt_elf.c to NOMMU is that the former already has all the necessary
code to work properly on NOMMU and has already received widespread
real-world use and testing. I hope this is not controversial.
I'm not really happy with having to unset the FDPIC_FUNCPTRS
personality bit when loading non-FDPIC ELF. This bit should really
reset automatically on execve, since otherwise, executing non-ELF
binaries (e.g. bFLT) from an FDPIC process will leave the personality
in the wrong state and severely break signal handling. But that's a
separate, existing bug and I don't know the right place to fix it.
The previous version of this patch had a bug which broke loading of
non-ET_DYN FDPIC binaries that slipped through my testing. This
version fixes the regression and has been tested with both FDPIC and
non-FDPIC ELF files.
--- fs/binfmt_elf_fdpic.c.orig 2015-09-29 22:13:06.716412478 +
+++ fs/binfmt_elf_fdpic.c 2015-10-07 05:11:33.702236056 +
@@ -103,19 +103,36 @@
core_initcall(init_elf_fdpic_binfmt);
module_exit(exit_elf_fdpic_binfmt);
-static int is_elf_fdpic(struct elfhdr *hdr, struct file *file)
+static int is_elf(struct elfhdr *hdr, struct file *file)
{
if (memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0)
return 0;
if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN)
return 0;
- if (!elf_check_arch(hdr) || !elf_check_fdpic(hdr))
+ if (!elf_check_arch(hdr))
return 0;
if (!file->f_op->mmap)
return 0;
return 1;
}
+#ifndef elf_check_fdpic
+#define elf_check_fdpic(x) 0
+#endif
+
+#ifndef elf_check_const_displacement
+#define elf_check_const_displacement(x) 0
+#endif
+
+static int is_constdisp(struct elfhdr *hdr)
+{
+ if (!elf_check_fdpic(hdr))
+ return 1;
+ if (elf_check_const_displacement(hdr))
+ return 1;
+ return 0;
+}
+
/*/
/*
* read the program headers table into memory
@@ -191,8 +208,18 @@
/* check that this is a binary we know how to deal with */
retval = -ENOEXEC;
- if (!is_elf_fdpic(_params.hdr, bprm->file))
+ if (!is_elf(_params.hdr, bprm->file))
goto error;
+ if (!elf_check_fdpic(_params.hdr)) {
+#ifdef CONFIG_MMU
+ /* binfmt_elf handles non-fdpic elf except on nommu */
+ goto error;
+#else
+ /* nommu can only load ET_DYN (PIE) ELF */
+ if (exec_params.hdr.e_type != ET_D
Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
Hi Rich, On 26/08/15 11:26, Greg Ungerer wrote: On 21/08/15 05:11, Rich Felker wrote: From: Rich Felker <dal...@libc.org> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to overlap with all but the last PAGE_SIZE bytes of the stack. This leads to catastrophic memory reuse/corruption if brk is used. Fix by setting the brk area to zero size to disable its use. Signed-off-by: Rich Felker <dal...@libc.org> It would make sense to run this by David Howells <dhowe...@redhat.com>, I think he wrote this code (added to CC list). I have no problem with it, so: Acked-by: Greg Ungerer <g...@uclinux.org> Has anybody picked this up to push to Linus? If not I can take it via the m68knommu tree. Regards Greg --- There is no reason for the kernel to be providing a brk area at all on NOMMU; the bFLT loader does not provide one, uClibc never uses brk on NOMMU targets, and musl libc goes out of its way to avoid using brk that might run into the stack. I recall a long time back someone was playing with the idea of setting the brk to the unused parts of the last data area page. (Somewhat like this code seems to be trying). That scheme still allocated the full requested stack size (IIRC) though. And that would have been on bFLT executables. Anyway, just some historical reference, not really relevant now. Regards Greg --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 + +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 + @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct PAGE_ALIGN(current->mm->start_brk); #else - /* create a stack and brk area big enough for everyone -* - the brk heap starts at the bottom and works up -* - the stack starts at the top and works down -*/ + /* create a stack area and zero-size brk area */ stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK; if (stack_size < PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct current->mm->brk = current->mm->start_brk; current->mm->context.end_brk = current->mm->start_brk; - current->mm->context.end_brk += - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0; current->mm->start_stack = current->mm->start_brk + stack_size; #endif -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
Hi Rich, On 15/09/15 01:17, Rich Felker wrote: > On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote: >> On 26/08/15 11:26, Greg Ungerer wrote: >>> On 21/08/15 05:11, Rich Felker wrote: >>>> From: Rich Felker <dal...@libc.org> >>>> >>>> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to >>>> overlap with all but the last PAGE_SIZE bytes of the stack. This leads >>>> to catastrophic memory reuse/corruption if brk is used. Fix by setting >>>> the brk area to zero size to disable its use. >>>> >>>> Signed-off-by: Rich Felker <dal...@libc.org> >>> >>> It would make sense to run this by David Howells <dhowe...@redhat.com>, >>> I think he wrote this code (added to CC list). >>> >>> I have no problem with it, so: >>> >>> Acked-by: Greg Ungerer <g...@uclinux.org> >> >> Has anybody picked this up to push to Linus? >> If not I can take it via the m68knommu tree. > > As far as I know, no. If you can do it that would be great. Patch applied to m68knommu git tree (for-next branch). (https://git.kernel.org/cgit/linux/kernel/git/gerg/m68knommu.git/) Regards Greg >>>> --- >>>> >>>> There is no reason for the kernel to be providing a brk area at all on >>>> NOMMU; the bFLT loader does not provide one, uClibc never uses brk on >>>> NOMMU targets, and musl libc goes out of its way to avoid using brk >>>> that might run into the stack. >>> >>> I recall a long time back someone was playing with the idea of setting >>> the brk to the unused parts of the last data area page. (Somewhat like >>> this code seems to be trying). That scheme still allocated the full >>> requested stack size (IIRC) though. And that would have been on bFLT >>> executables. Anyway, just some historical reference, not really >>> relevant now. >>> >>> Regards >>> Greg >>> >>> >>> >>>> --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 + >>>> +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 + >>>> @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct >>>>PAGE_ALIGN(current->mm->start_brk); >>>> >>>> #else >>>> - /* create a stack and brk area big enough for everyone >>>> - * - the brk heap starts at the bottom and works up >>>> - * - the stack starts at the top and works down >>>> - */ >>>> + /* create a stack area and zero-size brk area */ >>>>stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK; >>>>if (stack_size < PAGE_SIZE * 2) >>>>stack_size = PAGE_SIZE * 2; >>>> @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct >>>> >>>>current->mm->brk = current->mm->start_brk; >>>>current->mm->context.end_brk = current->mm->start_brk; >>>> - current->mm->context.end_brk += >>>> - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0; >>>>current->mm->start_stack = current->mm->start_brk + stack_size; >>>> #endif >>>> >>>> >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
Hi Rich, On 21/08/15 05:11, Rich Felker wrote: From: Rich Felker dal...@libc.org On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to overlap with all but the last PAGE_SIZE bytes of the stack. This leads to catastrophic memory reuse/corruption if brk is used. Fix by setting the brk area to zero size to disable its use. Signed-off-by: Rich Felker dal...@libc.org It would make sense to run this by David Howells dhowe...@redhat.com, I think he wrote this code (added to CC list). I have no problem with it, so: Acked-by: Greg Ungerer g...@uclinux.org --- There is no reason for the kernel to be providing a brk area at all on NOMMU; the bFLT loader does not provide one, uClibc never uses brk on NOMMU targets, and musl libc goes out of its way to avoid using brk that might run into the stack. I recall a long time back someone was playing with the idea of setting the brk to the unused parts of the last data area page. (Somewhat like this code seems to be trying). That scheme still allocated the full requested stack size (IIRC) though. And that would have been on bFLT executables. Anyway, just some historical reference, not really relevant now. Regards Greg --- fs/binfmt_elf_fdpic.c.orig2015-08-20 18:05:19.089888654 + +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 + @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct PAGE_ALIGN(current-mm-start_brk); #else - /* create a stack and brk area big enough for everyone - * - the brk heap starts at the bottom and works up - * - the stack starts at the top and works down - */ + /* create a stack area and zero-size brk area */ stack_size = (stack_size + PAGE_SIZE - 1) PAGE_MASK; if (stack_size PAGE_SIZE * 2) stack_size = PAGE_SIZE * 2; @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct current-mm-brk = current-mm-start_brk; current-mm-context.end_brk = current-mm-start_brk; - current-mm-context.end_brk += - (stack_size PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0; current-mm-start_stack = current-mm-start_brk + stack_size; #endif -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
Jamie Lokier wrote:
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 with somewhat
differing requirements (or not). But that is much less than a general
purpose system IMHO.
It is, but the idea that small embedded systems go through a 'all
components are known, drivers are known, test and if it passes it's
shippable' does not always apply.
I'm seriously thinking of forwarding porting the 4 year old firmware
from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
That sounds reasonable (and I never meant maintaining the old system
infinitely.
Sounds reasonable, but it's vetoed for anticipated time and cost,
compared with backporting on demand. Fair enough, since 2.6.current
doesn't support ARM no-MMU last I heard ('soon'?).
On the other hand, the 2.6 anti-fragmentation patches, including
latest SLUB stuff, ironically meant to help big machines, sound really
appealing for my current problem and totally unrealistic to
backport...
ACK. We avoid MMU-less hardware too - especially since there is enough
hardware with a MMU around.
I can't emphasise enough how much difference MMU makes to Linux userspace.
It's practically: MMU = standard Linux (with less RAM), have everything.
No-MMU = lots of familiar 'Linux' things not available or break.
And lots of things work in the usual way...
Of course the flip side is that for people who have platforms
without MMU they can run something more than the mostly toy
like operating systems typically available. There are plenty of
problem domains that the non-MMU limitations are not a problem for.
(Yours doesn't sound like one of them :-)
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
Jamie Lokier wrote: 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 in my line of embedded device. 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. I'm seriously thinking of forwarding porting the 4 year old firmware from 2.4.26 to 2.6.current, just to get new drivers and capabilities. Backporting is tedious, so's feeling wretchedly far from the mainline world. A usual approach is to run stress tests on several (or all) subsystems/services/... in parallel and if the device survives it functioning correctly, it is at least good enough. Per application. Some little devices run hundreds of different applications and customers expect to customise, script themselves, and attach different devices (over USB). The next customer in the chain expects the bits you supplied to work in a variety of unexpected situations, even when you advise that it probably won't do that. Much like desktop/server Linux, but on a small device where silly little things like 'create a process' are a stress for the dear little thing. (My biggest lesson: insist on an MMU next time!) But given you have hardware you can't change would you choose to not run Linux, even with the limitations of non-MMU? Hell no :-) Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
Paul Mundt wrote: On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote: On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote: On Wed, 27 Aug 2008, Adrian Bunk wrote: When did we get callpaths like like nfs+xfs+md+scsi reliably working with 4kB stacks on x86-32? XFS may never have been usable, but the rest, sure. And you seem to be making this whole argument an excuse to SUCK, adn an excuse to let gcc crap even more on our stack space. Why? Why aren't you saying that we should be able to do better? Instead, you seem to asking us to do even worse than we do now? My main point is: - getting 4kB stacks working reliably is a hard task - having an eye on gcc increasing the stack usage, and fixing it if required, is relatively easy If we should be able to do better at getting (and keeping) 4kB stacks working, then coping with possible inlining problems caused by gcc should not be a big problem for us. Out of the architectures you've mentioned for 4k stacks, they also tend to do IRQ stacks, which is something you seem to have overlooked. In addition to that, debugging the runaway stack users on 4k tends to be easier anyways since you end up blowing the stack a lot sooner. On sh we've had pretty good luck with it, though most of our users are using fairly deterministic workloads and continually profiling the footprint. Anything that runs away or uses an insane amount of stack space needs to be fixed well before that anyways, so catching it sooner is always preferable. I imagine the same case is true for m68knommu (even sans IRQ stacks). Yep, definitely true for m68knommu in my experience. I haven't had any problems with 4k stacks recently. But yes the workloads do tend to be constrained - and almost never use any of the more exotic filesystems or drivers. Things might be more sensitive on x86, but it's certainly not something that's a huge problem for the various embedded platforms to wire up, whether they want to go the IRQ stack route or not. In any event, lack of support for something on embedded architectures in the kernel is more often due to apathy/utter indifference on the part of the architecture maintainer rather than being indicative of any intrinsic difficulty in supporting the thing in question. Most new features on the lesser maintained architectures tend to end up there either out of peer pressure or copying-and-pasting accidents rather than any sort of design. ;-) Indeed :-) Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
Linus Torvalds wrote: On Tue, 26 Aug 2008, Parag Warudkar wrote: This is something I never understood - embedded devices are not going to run more than a few processes and 4K*(Few Processes) IMHO is not worth a saving now a days even in embedded world given falling memory prices. Or do I misunderstand? Well, by that argument, 1% of kernel size doesn't matter either.. 1% of a kernel for an embedded device is roughly 10-30kB or so depending on how small you make the configuration. If that matters, then so should the difference of 3-8 processes' kernel stack usage when you have a 4k/8k stack choice. And they _all_ will have at least 3-8 processes on them. Even the simplest ones will tend to have many more. I have some simple devices (network access/routers) with 8MB of RAM, at power up not really being configured to do anything running 25 processes. (Heck there is over 10 kernel processes running!). Configure some interfaces and services and that will easily push past 40. I'd be happy with a 160k saving :-) The init memory being freed at the end of the kernel boot is 88k, 4k stacks could save more than that. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
Hi Jared, Jared Hulbert wrote: That would be enough I think. If you could manually select which files are contiguous-and-uncompressed that would be useful for some too here. So If you don't have an MMU when do you call -fault? Does the noMMU code just loop through -fault()ing all the pages in an mmap()? 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 big enough to hold the entire file. 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 factors :-) True. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
Hi Jamie, Jamie Lokier wrote: 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 big enough to hold the entire file. That's unfortunate, if you're using FDPIC-ELF or BFLT-XIP, you really want to kmalloc() one region for code (i.e. mmap not the whole file), and one separate for data. That is what the BFLT loader does. For the XIP case it mmap()s the text directly from the file, and then mmap()s a second region for the data/bss (reading the data into that region). I was referring to general mmap() of a file case above, not the exec path. Asking for a single larger region sometimes creates much higher memory pressure while kmalloc() attempts to defragment by evicting everything. Sure. But that's fiddly to do right in general. The natural thing for AXFS to do to support no-MMU FDPIC-ELF or BFLT-XIP is store the code segment uncompressed and contiguous, and the data segment however the filesystem prefers, and the profiling information to work out where these are is readily available from the mmap() calls, which are always the same when an executable is run. Yep. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] AXFS: Advanced XIP filesystem
Hi Jared, Jared Hulbert wrote: How does it fare with no MMU? Can the profiler and image builder lay out the XIP pages in such a way that no-MMU mmaps can map those regions? No complaint if not, it would be a nice bonus though. Sorry. I don't believe it will work on no-MMU as is. That said you _could_ tweak the mkfs tool to lay mmap()'ed regions down contiguously but then if you mmap() an unprofiled region, well that would be bad. I suppose you could make axfs_mmap smart enough to handle that. I guess the cleanest way would be to just make files lay down contiguously, you lose some of the space saving but it would work. That would be enough I think. If you could manually select which files are contiguous-and-uncompressed that would be useful for some too here. I'm not plannin to get to this anytime soon. But I'd be willing merge patches. Can anybody convince me offline that working on no-MMU this makes financial sense for my employer? This is getting to be a common question. How many noMMU users are out there and why are you so interested? One of those unknown factors, how many are there? Who knows, pretty much impossible to tell. 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 factors :-) Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel boot problem on IXP422 Rev. A
Hi Marcus, Marcus Tangermann wrote: Kernel dying, not just no console? To be honest I don't know ;-) Maybe it's only an issue with the console. It should be ttyS0 as this works with 2.6.19-uc1. The snapgear kernel works when I use the settings for the MonteJade board. Today I took a look at the sources of the snapgear kernel where the CONFIG_MARCH_MONTEJADE is used, and there are some modifications within the 8250 serial driver for this board. I will take a closer look at it tomorrow. Over the years there have been some changes to the serial setup on those boards. Some setups leave out the first serial port definition, and so what is otherwise considered ttyS1 will be ttyS0. Something to look out for anyway. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cross Compiler and loads of issues
hoping linux-embedded@vger.kernel.org might help catalyse it - perhaps by creating the perception of it to people like me. It only really works if lots of people do that together, and it seems to be particularly _not_ the culture in some segments of the embedded development community. I base this on Google leading to lots of pages with old announcements of compilers, cross-compilation scripts and so on. Why aren't those pages links to a few standard good places which are actively kept up to date? It appears to be (or have been) a fragmented community - and so who to work with, that's a question. Perhaps current versions (e.g. from Codesourcery?) are more dependable for embedded architectures, but I don't have the time to thoroughly test them, and my last experience warns me to be careful. I know from experience, having worked for CodeSourcery that their toolchains are exhaustively tested. And any problems reported to their public mailing lists are fixed, if legitimate. These fixes are typically submitted upstream to the FSF very quickly when the bugs exist in mainline as well. I know from experience that bugs are fixed, but feature requests like reliable C++, shared libraries and NPTL threads are long in coming to some architectures, if they ever will be before those architectures are no longer manufactured. It seems people release tools, release patches, publish on an obscure web page, then forget about the page. More authoritative-sounding uclinux web pages tend to be out of date. Google isn't finding good current authorities in this area, which suggests the space is rather fragmented with people pulling in different directions and not working together enough to create stable, common places for these things. But isn't the FSF repositories for the GNU Tools, and the uClinux projects repositories the stable, common place for these things? You can't even build an ARM-nommu executable with GNU tools from FSF! Thats true of any of the non-mmu architectures that rely on elf2flt. So arm is no different. Like many open source projects uClinux isn't a finished thing. It is actively being developed. Not everything works, not everything works well. The quality of what is there now depends very much on the amount of effort input... It needs an extra tool. I'm not even sure which version of that is the recommended one - the C one or the shell script both have issues outstanding. By the way, neither work with some C++ programs on ARM-nommu: they crash with messages about unfixable relocations. More often with GCC 4 than GCC 3. See what I mean about things not being in great shape? Well, what can I say, you are welcome to fix them :-) Sometimes you need to be the one to step up and make things better, especially if you want to use them :-) 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. IMHO, the same is true for the GNU tool. If that's true for ARM-nommu support, it has improved dramatically. I will try again, in time, but prior experience tells me not to spend too long on it. It's much better use of time to find some patched combination that is working well for someone else. But who to ask/trust? Even the pre-built toolchains don't always work right. (See my earlier mention of undebuggable thread problems in executables built with a googd-distributed.) Regards Greg -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
