Date: Mon, 16 Aug 2010 10:28:15 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: andrew@fubar.geek.nz Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD EABI ARM & Network boot image howto? Message-ID: <20100816.102815.72112000494883288.imp@bsdimp.com> In-Reply-To: <20100816221321.180cf466@fubar.geek.nz> References: <1281907405.27697.19.camel@xeon.thinmesh.com> <20100815.153437.722022410199781366.imp@bsdimp.com> <20100816221321.180cf466@fubar.geek.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20100816221321.180cf466@fubar.geek.nz>
Andrew Turner <andrew@fubar.geek.nz> writes:
: On Sun, 15 Aug 2010 15:34:37 -0600 (MDT)
: "M. Warner Losh" <imp@bsdimp.com> wrote:
: > There was talk about NetBSD making this move too, but I don't know
: > what became of it.
: I haven't looked at if NetBSD supports it or not. My work was mostly a
: weekend hacking to prove it is possible.
:
: > I'm guessing it won't be a huge deal to make this work, just a bunch
: > of elbow grease in the syscalls...
:
: The main problem is getting a list of syscalls that need to be changed.
: I found I could boot to single user mode by only changing stat and
: fstat. I'm currently in the process of converting my hack to using the
: same method to provide 32 bit and Linux compatability support.
Sadly, you're going to have to step through each one and see if it
changes. On MIPS, we had to do similar things for n32/n64 support
since some syscalls it mattered for. But n32 support is by far the
weirdest ABI beast in the jungle.
So we're going to have multiple image activators on ARM? Is that the
plan? Or is there some other way that you had in mind...
: We also need to decide if we follow what Linux has done where it
: changed it's syscall ABI when it moved to the EABI. They changed from
: reading the instruction from memory to get the syscall number to
: storing it in r7. The idea is to reduce the cost of the data cache miss
: as the page will be in the instruction cache. I hacked up some code to
: do the same but haven't had a chance to properly benchmark the change
: yet.
I think this is a good change as well. The compat layer can easily
cope.
Are there other ABI issues we wish to fix at the same time? And will
this also help solve the funky alignment issues we've had with ARM
elsewhere in the kernel causing problems either in structure sizes or
unaligned accesses?
Are there other implications we need to worry about? Are you going to
try to support both the current ABI and EABI in the current source
tree?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100816.102815.72112000494883288.imp>