Hi,
At present, one of the few interface-level conformance issues for
Linux against POSIX 2008 is lack of O_SEARCH and O_EXEC. I am trying
to get full, conforming support for them both into musl libc (for
which I am the maintainer) and glibc (see the libc-alpha post[1]).
At this point, I believe
On Mon, Jul 29, 2013 at 08:22:56AM +0200, Michal Simek wrote:
Microblaze was assign to CLONE_BACKWARDS type where
parent tid was passed via 3rd argument.
Microblaze glibc is using 4th argument for it.
Create new CLONE_BACKWARDS3 type where stack_size is passed
via 3rd argument, parent
On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:
Btw, FreeBSD has an extension to shm_open to create unnamed but fd
passable segments. From their man page:
As a FreeBSD extension, the constant SHM_ANON may be used for the path
argument to shm_open(). In this case,
On Fri, Jun 28, 2013 at 11:03:33PM +0100, James Hogan wrote:
On 28 June 2013 20:28, Denys Vlasenko vda.li...@googlemail.com wrote:
On Monday 17 June 2013 12:36, James Hogan wrote:
On 14/06/13 17:03, James Hogan wrote:
MIPS has 128 signals, the highest of which has the number 128 (they
On Wed, Jul 24, 2013 at 07:34:07AM +0200, Michal Simek wrote:
Microblaze was assign to CLONE_BACKWARDS type where
parent tid was passed via 3rd argument.
Microblaze glibc is using 4th argument for it.
Create new CLONE_BACKWARDS3 type where stack_size is passed
via 3rd argument, parent
On Wed, Jul 24, 2013 at 08:48:27AM +0200, Michal Simek wrote:
Create new CLONE_BACKWARDS3 type where stack_size is passed
via 3rd argument, parent thread id pointer via 4th,
child thread id pointer via 5th and tls value as 6th
argument
I believe this also affects us in musl. What is
On Wed, Jul 24, 2013 at 09:16:03AM +0200, Michal Simek wrote:
BTW: Where to get musl package
Source is available from http://www.musl-libc.org/. We also have cross
compilers and binaries for a number of archs here:
https://bitbucket.org/GregorR/musl-cross
However, microblaze was not included
While looking to add support for the recvmmsg and sendmmsg syscalls in
musl libc, I ran into some disturbing findings on the kernel side. In
the struct mmsghdr, the field where the result for each message is
stored has type int, which is inconsistent with the return type
ssize_t of
On Tue, Jun 10, 2014 at 10:50:08PM -0700, Eric Dumazet wrote:
On Wed, 2014-06-11 at 07:24 +0200, Mike Galbraith wrote:
(CCs network wizard hangout)
On Wed, 2014-06-11 at 00:12 -0400, Rich Felker wrote:
While looking to add support for the recvmmsg and sendmmsg syscalls in
musl libc
On Thu, Jun 12, 2014 at 08:04:54AM +0200, Michael Kerrisk (man-pages) wrote:
Rich,
On Wed, Jun 11, 2014 at 5:15 PM, Rich Felker dal...@libc.org wrote:
On Tue, Jun 10, 2014 at 10:50:08PM -0700, Eric Dumazet wrote:
On Wed, 2014-06-11 at 07:24 +0200, Mike Galbraith wrote:
(CCs network
On Sat, Jun 14, 2014 at 11:16:42AM -0700, Andy Lutomirski wrote:
The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
implements __vdso_findsym.
This would make it easier for runtimes that don't otherwise implement
ELF loaders to use the vdso.
Thoughts?
If people like
On Sun, Jun 15, 2014 at 04:25:37PM +0200, Mikael Pettersson wrote:
Andy Lutomirski writes:
The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This
implements __vdso_findsym.
This would make it easier for runtimes that don't otherwise implement
ELF loaders to use the
On Sun, Jun 15, 2014 at 12:14:04PM -0700, H. Peter Anvin wrote:
If it doesn't, then you incur an additional indirection penalty. The
strong __vdso symbol allows the libc wrapper to fall back to the
vdso implementation, the weak symbol allows three to be no wrapper
at all. This is good.
No it
On Sun, Jun 15, 2014 at 10:05:47AM -0700, H. Peter Anvin wrote:
On 06/15/2014 07:35 AM, Rich Felker wrote:
Arguably, it was a mistake for the kernel to expose a virtual ELF to
begin with, and it should just have exposed a lookup function by
name operation to begin with. Yes this can
On Mon, Jun 16, 2014 at 04:36:04AM +0200, Andi Kleen wrote:
At least versioning is always useful to have, just to have
another tool for compatibility if changes are needed.
I disagree. Just like syscalls, vdso functions with new APIs/ABIs
should have new names. For example if a version of
On Sun, Jun 15, 2014 at 11:22:48AM -0700, Andy Lutomirski wrote:
[1] The only comprehensible description of the GNU hash extension that
I could find is on Oracle's blog (!)
Curious about this blog. We do have a GNU hash implementation in Syslinux,
too, for another reference.
On Mon, Jun 16, 2014 at 07:08:50AM -0700, Ian Lance Taylor wrote:
On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen a...@firstfloor.org wrote:
I haven't looked into this in detail, but my initial assumption would
be that it wouldn't be useful to add new vdso interfaces just for Go.
After all
On Mon, Jun 16, 2014 at 04:38:01PM +0200, Andi Kleen wrote:
I think this issue started when some of the Go developers questioned
why the kernel needed to provide a very complex interface--parsing an
ELF shared shared library--for very simple functionality--looking up
the address of a magic
On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen a...@firstfloor.org wrote:
I think this issue started when some of the Go developers questioned
why the kernel needed to provide a very complex interface--parsing an
ELF shared
On Mon, Aug 12, 2013 at 10:42:03AM -0700, Andy Lutomirski wrote:
You'll have the same problem that O_TMPFILE had: the kernel currently
ignores unrecognized flags. I wonder if it's time to add a new syscall
(or syscalls) with more sensible semantics.
That's not a problem here. In fact, in the
On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
File-private locks have been merged into Linux for v3.15, and *now*
people are commenting that the name and macro definitions for the new
file-private locks suck.
and I can't even disagree. The names and command macros do suck.
On Mon, Apr 21, 2014 at 04:23:54PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 04:02 PM, Rich Felker wrote:
On Mon, Apr 21, 2014 at 09:45:35AM -0400, Jeff Layton wrote:
File-private locks have been merged into Linux for v3.15, and *now*
people are commenting that the name
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
On 04/21/2014 06:10 PM, Rich Felker wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file descriptor and
NEVER means file description
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
Fair enough. Assuming we kept file-description locks as a name, what
would you propose as new macro names?
I assume you meant, assume we kept the term 'file-private locks'...
In that case, at least make the constants
On Mon, Apr 21, 2014 at 02:48:41PM -0400, Theodore Ts'o wrote:
On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote:
So, can you *please* answer this question: what do you call (i.e.,
what everyday technical language term do use for) the thing
that sits between a
On Mon, Apr 21, 2014 at 03:16:29PM -0400, Jeff Layton wrote:
On Mon, 21 Apr 2014 14:48:29 -0400
Rich Felker dal...@libc.org wrote:
On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
Fair enough. Assuming we kept file-description locks as a name, what
would you propose
On Mon, Apr 21, 2014 at 03:04:10PM -0400, Theodore Ts'o wrote:
On Mon, Apr 21, 2014 at 02:51:44PM -0400, Rich Felker wrote:
I don't think struct file has any meaning to any userspace
developers, and as such doesn't belong in documentation for userspace
programming. It's an implementation
On Tue, Apr 22, 2014 at 05:45:31PM +0300, Boaz Harrosh wrote:
On 04/22/2014 03:23 PM, Jeff Layton wrote:
We're going to have to live with these for a long time, so it's
important that we be happy with the names before we're stuck with them.
The consensus on the lists so far is that
On Fri, Jun 20, 2014 at 08:55:01AM -0700, Andy Lutomirski wrote:
On Mon, Jun 16, 2014 at 8:42 AM, Rich Felker dal...@libc.org wrote:
On Mon, Jun 16, 2014 at 08:31:39AM -0700, Ian Lance Taylor wrote:
On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen a...@firstfloor.org wrote:
I think this issue
On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
the out-of-line execution trick, but do it somewhere other than in
stack memory.
How do you answer Andy Lutomirski's question about what happens when a
signal handler interrupts execution while the program counter is
pointing at
On Tue, Oct 07, 2014 at 09:13:22AM +, Matthew Fortune wrote:
From what I can see the out-of-line execution of delay slot instructions
will break micromips R3 addiupc, and all MIPS32r6 and MIPS64r6 PC-relative
instructions (inc load/store) as they will have the wrong base. Is there
anything
On Tue, Oct 07, 2014 at 11:44:35AM -0700, Andy Lutomirski wrote:
4) The voice for doing any instruction emulation in kernel - it is not a
MIPS business model to force customer to put details of all Coprocessor 2
instructions public. We provide an interface and the rest is a customer
On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:
On 10/07/2014 12:09 PM, Rich Felker wrote:
I agree completely here. We should not break things (or, as it
seems, leave them broken) for common usage cases that affect
everyone just to coddle proprietary vendor-specific
On Tue, Oct 07, 2014 at 07:18:33PM -0500, Chuck Ebbert wrote:
On Tue, 7 Oct 2014 16:59:03 -0700
David Daney dda...@caviumnetworks.com wrote:
On 10/07/2014 04:20 PM, Ralf Baechle wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
As an alternative, if the space of
On Mon, Oct 06, 2014 at 01:23:30PM -0700, David Daney wrote:
From: David Daney david.da...@cavium.com
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for executing emulated branch delay slot instructions.
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats the
purpose of fpu emulation.
That is certainly one way of looking at it. Really it is opinion,
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
On 10/06/2014 02:31 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
Userspace should play no part in this; requiring userspace to help
make special accomodations for fpu emulation largely defeats
On Mon, Oct 06, 2014 at 03:17:03PM -0700, David Daney wrote:
Furthermore the
userspace code has to be very careful in its use of the $sp
register, so that it doesn't store data in places that will be
used/clobbered by the kernel.
This is not being careful. The stack pointer can never become
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
[...]
This is a huge ill-designed mess.
Amen.
Can the kernel not just
On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote:
On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker dal...@libc.org wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
On 10/06/2014 05:05 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM
On Mon, Oct 06, 2014 at 06:02:20PM -0700, Kevin D. Kissell wrote:
On 10/06/2014 01:23 PM, David Daney wrote:
From: David Daney david.da...@cavium.com
In order for MIPS to be able to support a non-executable stack, we
need to supply a method to specify a userspace area that can be used
for
On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
I don't know if this has been discussed on libc-alpha yet or not, but
I think we need to open a discussion of how it relates to open glibc
bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
On Wed, Feb 11, 2015 at 10:33:32AM -0800, H.J. Lu wrote:
On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker dal...@libc.org wrote:
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version with all of the requested
On Wed, Feb 11, 2015 at 05:39:19PM +, Catalin Marinas wrote:
(adding Marcus)
On Tue, Feb 10, 2015 at 06:13:02PM +, Rich Felker wrote:
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version
On Wed, Feb 11, 2015 at 11:34:23AM -0800, H.J. Lu wrote:
On Wed, Feb 11, 2015 at 11:25 AM, Rich Felker dal...@libc.org wrote:
On Wed, Feb 11, 2015 at 11:16:58AM -0800, H.J. Lu wrote:
I don't know if this has been discussed on libc-alpha yet or not, but
I think we need to open
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
At least for AArch64 ILP32 we are still free to change the user/kernel
ABI, so we could add wrappers for the affected syscalls to fix this up.
yes, afaik on x32 the 64bit kernel expects 64bit layout,
arm64 can fix this
On Wed, Feb 11, 2015 at 10:02:55PM +0100, a...@arndb.de wrote:
Rich Felker dal...@libc.org hat am 11. Februar 2015 um 21:12 geschrieben:
On Wed, Feb 11, 2015 at 08:50:06PM +0100, a...@arndb.de wrote:
At least for AArch64 ILP32 we are still free to change the user/kernel
ABI, so we
On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote:
Would it really be that hard to do:
if (ILP32_on_64_process) tv_nsec = (int)tv_nsec;
or similar? That's all that's needed.
In some cases, there may also be a measurable performance penalty
in interpreting a
On Mon, Feb 16, 2015 at 03:40:54PM +0100, Arnd Bergmann wrote:
On Friday 13 February 2015 13:37:07 Rich Felker wrote:
On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
The data structure definition is a little bit fragile, as it
depends on
user space not using
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
I'm not proposing code because I'm a libc developer not a kernel
developer. I know what's needed for userspace to provide a conforming
fexecve to applications, not how to implement
On Sat, Jan 10, 2015 at 03:03:00AM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 11:36:44PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 06:12:48PM -0500, Rich Felker wrote:
I'm not sure where you're disagreeing with me. open of procfs symlinks
does not resolve the symlink and open
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
_After_ the traversal it's too late to do this sort of thing - after all,
how do you tell if your current position had been set by the traversal of
your symlink
On Sat, Jan 10, 2015 at 09:27:46AM +0100, Michael Kerrisk (man-pages) wrote:
On 01/09/2015 06:46 PM, David Drysdale wrote:
On Fri, Jan 9, 2015 at 4:13 PM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages)
wrote:
On 11/24/2014 12:53
On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
etc.) before bothering with open(2), you'll get
On Fri, Jan 09, 2015 at 03:24:12PM -0800, Andy Lutomirski wrote:
On Fri, Jan 9, 2015 at 3:12 PM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
Here's a very simple way it could
On Mon, Jan 12, 2015 at 11:33:49AM +, David Drysdale wrote:
On Sat, Jan 10, 2015 at 1:33 AM, Rich Felker dal...@aerifal.cx wrote:
On Fri, Jan 09, 2015 at 07:17:41PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
I'm not proposing code because I'm a libc
On Fri, Jan 09, 2015 at 04:47:31PM +0100, Michael Kerrisk (man-pages) wrote:
On 11/24/2014 12:53 PM, David Drysdale wrote:
Signed-off-by: David Drysdale drysd...@google.com
---
man2/execveat.2 | 153
1 file changed, 153
On Fri, Jan 09, 2015 at 04:13:27PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
The magic open-once magic symlink approach is really the cleanest
solution I can find. In the case where the interpreter does
On Fri, Jan 09, 2015 at 10:33:00PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:17:28PM -0500, Rich Felker wrote:
Back then the procfs-free environments had been pushed as a serious
argument
in favour of merging the damn thing. Now you guys turn around and say
that
we
On Fri, Jan 09, 2015 at 09:50:42PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 04:28:52PM -0500, Rich Felker wrote:
The magic open-once magic symlink approach is really the cleanest
solution I can find. In the case where the interpreter does not open
the script, nothing terribly bad
On Fri, Jan 09, 2015 at 10:57:43PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 05:42:52PM -0500, Rich Felker wrote:
Here's a very simple way it could work -- it could put the O_PATH fd
on a previously-unused fd number, and put a special flag on the fd,
like FD_CLOEXEC, but that causes
On Fri, Jan 09, 2015 at 05:46:28PM +, David Drysdale wrote:
It's AT_EXECFN,
/proc/self/exe, and filenames shown elsewhere in /proc that may be
derived in odd ways.
I would also move the text about O_CLOEXEC to a BUGS or NOTES section
rather than the main description. The long-term
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
I think this is a case that needs to be fixed, though it's hard. The
normal correct usage for fexecve is to always pass an O_CLOEXEC file
descriptor, and the caller can't
On Fri, Jan 09, 2015 at 03:20:04PM -0600, Eric W. Biederman wrote:
Rich Felker dal...@aerifal.cx writes:
On Fri, Jan 09, 2015 at 08:56:26PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:48:15PM -0500, Rich Felker wrote:
I think this is a case that needs to be fixed, though it's hard
On Fri, Jan 09, 2015 at 09:09:41PM +, Al Viro wrote:
On Fri, Jan 09, 2015 at 03:59:26PM -0500, Rich Felker wrote:
For fsck sake, folks, if you have bloody /proc, you don't need that shite
at all! Just do execve on /proc/self/fd/n, and be done with that.
The sole excuse
On Fri, Feb 13, 2015 at 01:33:56PM +, Catalin Marinas wrote:
On Thu, Feb 12, 2015 at 07:59:24PM +0100, Arnd Bergmann wrote:
Catalin Marinas catalin.mari...@arm.com hat am 12. Februar 2015 um 19:17
geschrieben:
On Wed, Feb 11, 2015 at 02:21:18PM -0500, Rich Felker wrote:
On Wed
On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote:
The data structure definition is a little bit fragile, as it depends on
user space not using the __BIT_ENDIAN symbol in a conflicting way. So
far we have managed to keep that outside of general purpose headers, but
it
On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
New version with all of the requested changes. Updated to the
latest sources.
Notable changes from the previous versions:
VDSO code has been factored out to be
On Thu, Feb 12, 2015 at 03:50:24PM +, Catalin Marinas wrote:
On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
On 02/11/2015 11:57 AM, H.J. Lu wrote:
trivially satisfied if you consider x32 and x86_64 separate
compilation environments, but it's not related to the core
On Thu, Feb 12, 2015 at 08:30:10AM -0800, H.J. Lu wrote:
On Thu, Feb 12, 2015 at 7:50 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Wed, Feb 11, 2015 at 12:15:56PM -0800, Andy Lutomirski wrote:
On 02/11/2015 11:57 AM, H.J. Lu wrote:
trivially satisfied if you consider x32 and
On Fri, Jun 19, 2015 at 04:07:52AM +0200, Matthias Schiffer wrote:
Hi,
I've come across the issue that applications with detached threads
(using pthread_detach or a pthread_attr_t with
pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as
soon as the detached thread exits. As
On Fri, Jun 19, 2015 at 12:06:26PM +0200, Ralf Baechle wrote:
On Thu, Jun 18, 2015 at 10:50:32PM -0400, Rich Felker wrote:
This is kernel ABI breakage that should be fixed -- people running old
kernel versions with old musl binaries might suffer a regression when
upgrading, and perhaps
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
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 b
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 regul
Ping.
On Tue, Sep 29, 2015 at 07:16:49PM -0400, 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
On Tue, Aug 25, 2015 at 09:18:44AM +0200, Geert Uytterhoeven wrote:
Hi Rich,
On Tue, Aug 25, 2015 at 5:03 AM, Rich Felker dal...@libc.org wrote:
From: Rich Felker dal...@libc.org
Historically SH-2 Linux (and originally uClinux) used a syscall
calling convention incompatible
From: Rich Felker dal...@libc.org
Historically SH-2 Linux (and originally uClinux) used a syscall
calling convention incompatible with the established SH-3/4 Linux ABI.
This choice was made because the trap range used by the existing ABI,
0x10-0x17, overlaps with the hardware exception/interrupt
On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker <dal...@libc.org> wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker <dal...@libc.org
On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker <dal...@libc.org> wrote:
> > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker <dal...@libc.org
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker <dal...@libc.org> wrote:
> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> Hi all-
> >>
> >> Linux has a handful
From: Rich Felker dal...@libc.org
Historically SH-2 Linux (and originally uClinux) used a syscall
calling convention incompatible with the established SH-3/4 Linux ABI.
This choice was made because the trap range used by the existing ABI,
0x10-0x17, overlaps with the hardware exception/interrupt
On Wed, Aug 26, 2015 at 11:26:02AM +1000, Greg Ungerer wrote:
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
On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote:
> 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
On Mon, Sep 14, 2015 at 10:17:50PM -0500, Rob Landley wrote:
> On 08/25/2015 04:23 PM, Rich Felker wrote:
> > From: Rich Felker <dal...@libc.org>
> >
> > Historically SH-2 Linux (and originally uClinux) used a syscall
> > calling convention incompatible with
Ping?
On Tue, Aug 25, 2015 at 05:23:11PM -0400, Rich Felker wrote:
> From: Rich Felker <dal...@libc.org>
>
> Historically SH-2 Linux (and originally uClinux) used a syscall
> calling convention incompatible with the established SH-3/4 Linux ABI.
> This choice was made becaus
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 b
Ping.
On Tue, Sep 15, 2015 at 12:11:24AM -0400, Rich Felker wrote:
> Ping?
>
> On Tue, Aug 25, 2015 at 05:23:11PM -0400, Rich Felker wrote:
> > From: Rich Felker <dal...@libc.org>
> >
> > Historically SH-2 Linux (and originally uClinux) used a syscall
&g
On Wed, Jan 06, 2016 at 03:32:18PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 06, 2016 at 01:52:17PM +0200, Michael S. Tsirkin wrote:
> > > > Peter, what do you think? How about I leave this patch as is for now?
> > >
> > > No, and I object to removing the single byte implementation too. Either
>
On Wed, Jan 06, 2016 at 10:23:12PM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 06, 2016 at 01:23:50PM -0500, Rich Felker wrote:
> > On Wed, Jan 06, 2016 at 03:32:18PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 06, 2016 at 01:52:17PM +0200, Michael S. Tsirkin wrote:
>
On Thu, Dec 31, 2015 at 09:09:47PM +0200, Michael S. Tsirkin wrote:
> At the moment, xchg on sh only supports 4 and 1 byte values, so using it
> from smp_store_mb means attempts to store a 2 byte value using this
> macro fail.
>
> And happens to be exactly what virtio drivers want to do.
>
>
sh: make time.c explicitly non-modular
sh: make mm/asids-debugfs explicitly non-modular
sh: make board-secureedge5410 explicitly non-modular
sh: make heartbeat driver explicitly non-modular
Rich Felker (6):
sh: add support for linking a builtin device tree blob in th
On Wed, May 25, 2016 at 10:54:44AM +0100, Mark Brown wrote:
> On Wed, May 25, 2016 at 05:43:02AM +0000, Rich Felker wrote:
>
> > As arch/sh co-maintainer my intent is to include as much as possible
> > in my pull request for the linux-sh tree. If there are parts outside
>
On Fri, May 20, 2016 at 09:15:56AM +0100, Marc Zyngier wrote:
> On 20/05/16 03:53, Rich Felker wrote:
> > Signed-off-by: Rich Felker <dal...@libc.org>
> > ---
> > My previous post of the patch series accidentally omitted omitted
> > Cc'ing of subsystem maintain
The J-Core project (j-core.org) produces open source cpu and SoC
peripheral cores synthesizable as FPGA bitstreams or ASICs.
Signed-off-by: Rich Felker <dal...@libc.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documen
Signed-off-by: Rich Felker <dal...@libc.org>
---
arch/sh/include/uapi/asm/cpu-features.h | 1 +
arch/sh/kernel/cpu/sh2/probe.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/sh/include/uapi/asm/cpu-features.h
b/arch/sh/include/uapi/asm/cpu-features.h
index 694abe4..2
extended to support future versions of the J-Core
SPI controller with DMA transfers when they become available.
Signed-off-by: Rich Felker <dal...@libc.org>
---
This version of the SPI patch eliminates USE_MESSAGE_MODE (the open
coding of transfer_one_message logic) and makes severl other
Signed-off-by: Rich Felker <dal...@libc.org>
---
arch/sh/boot/dts/j2_mimas_v2.dts | 87
1 file changed, 87 insertions(+)
create mode 100755 arch/sh/boot/dts/j2_mimas_v2.dts
diff --git a/arch/sh/boot/dts/j2_mimas_v2.dts b/arch/sh/boot/dts/j2_mimas_
1 - 100 of 950 matches
Mail list logo
