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, 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 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
> > na
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
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
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 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
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 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 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:
&g
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 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
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
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
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, 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
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 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 usersp
On Mon, Apr 21, 2014 at 03:16:29PM -0400, Jeff Layton wrote:
> On Mon, 21 Apr 2014 14:48:29 -0400
> Rich Felker wrote:
>
> > On Mon, Apr 21, 2014 at 02:32:38PM -0400, Jeff Layton wrote:
> > > > > Fair enough. Assuming we kept "file-description locks" as
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
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
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
>
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*
> >
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
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 Fri, Jun 28, 2013 at 11:03:33PM +0100, James Hogan wrote:
> On 28 June 2013 20:28, Denys Vlasenko 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
> >> > start from
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 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
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
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
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 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
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 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 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 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
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
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 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
901 - 950 of 950 matches
Mail list logo
