From: Patrick Oppenlander <pattyo.lists@gmail.com>
To: musl@lists.openwall.com
Subject: Re: vfork on ARM
Date: Mon, 4 Apr 2016 09:18:15 +1000 [thread overview]
Message-ID: <5701A4B7.9020200@gmail.com> (raw)
In-Reply-To: <20160401015301.GY21636@brightrain.aerifal.cx>
On 01/04/16 12:53, Rich Felker wrote:
> On Fri, Apr 01, 2016 at 11:42:47AM +1100, Patrick Oppenlander wrote:
>> I'm looking at what would be involved in using musl on a nommu arm system.
>>
>> As far as I know SYS_vfork is available on ARM, but musl is
>> currently falling back to fork.
>>
>> Are there any plans to support vfork on ARM and other architectures?
> It's trivial to add vfork, but the usefulness is limited without other
> changes:
vfork should also be more efficient than fork which may be motivation
for supporting it as an optimisation on mmu targets.
It's also theoretically possible to run a nommu kernel on an mmu capable
target.
> 1. To my knowledge, all nommu ARM systems are thumb[2]-only, so
> supporting them as targets requires adapting all the asm files to
> support building as thumb. This is a task in progress and, as long as
> we only care about thumb2 (available on armv7-m, i.e. Corext-M3 and
> up, I think) it's almost done.
OK that's great!
> 2. For pre-v7, there's no way to do atomics without kernel help, and
> no established kernel API for this as far as I know. For v7-m this is
> probably not a problem.
V6K has support for hardware atomics too.
v7-m supports 32-bit atomics but drops support for 64-bit (no LDREXD or
STREXD). Is a problem for musl?
Do you know if v7-m has the hardware TLS registers?
> 3. Running on nommu without shareable program text is not much fun;
> execve is really slow (memcpy of full program) and you need lots of
> memory. Some people at ST have implemented an FDPIC abi for ARM which
> solves this problem, but it's not upstream in the toolchain or kernel,
> and the relocation types it needs are not officially assigned. Getting
> it officially stabilized, supported, and forward-ported to modern tool
> versions is going to be a lot of work. Here are some slides on it:
>
> http://www.slideshare.net/linaroorg/sfo15406-arm-fdpic-toolset-kernel-libraries-for-cortexm-cortexr-mmuless-cores
Thanks for the link. I wasn't aware of this.
> Without FDPIC, it's possible to build a toolchain that produces
> static-PIE executables that will work on nommu (with my recently
> committed kernel patch for running non-FDPIC PIE ELF files on nommu,
> and some additional work still needed to hook it up to work on ARM)
> but these cannot use a shared mapping of the program.
>
> If you or anyone else is up for helping with these tasks that would be
> great.
Right now I'm working on my own small kernel which will (hopefully)
implement enough of the linux syscall interface to be useful. It's meant
for small embedded microcontrollers where 4MiB of RAM is considered
luxurious.
It's based on the now abandoned Prex operating system
(http://prex.sourceforge.net/) but is a major fork which goes back to a
traditional monolithic kernel model. I've replaced the C libary with
musl and userspace is currently toybox.
I'm planning on releasing on github (BSD or no-license) once I can boot
the first targets (arm-mmu and arm-nommu) to a working userspace and
pass some unit tests.
Maybe once I've learnt enough about how all this stuff works I'll be
able to contribute to other projects like linux/musl.
Patrick
next prev parent reply other threads:[~2016-04-03 23:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 0:42 Patrick Oppenlander
2016-04-01 1:53 ` Rich Felker
2016-04-03 23:18 ` Patrick Oppenlander [this message]
2016-04-04 0:14 ` Rich Felker
2016-04-04 2:25 ` Patrick Oppenlander
2016-04-04 3:37 ` Rich Felker
2016-04-04 6:56 ` Patrick Oppenlander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5701A4B7.9020200@gmail.com \
--to=pattyo.lists@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).