vdso feature requests from the Go people

[Andy Lutomirski]

I was talking to some of the Go people, and they have a couple of IMO
reasonable feature requests.

1. Parsing the vDSO is a PITA.  What if we bundled the reference
parser inside the vdso?  Concretely, we could have AT_VDSO_FINDENTRY
point to a function like:

void *vdso_find_entry(const char *name, const char *version)

Then things like Go and maybe even musl (and klibc?) could just call
that function.  And we'd never have to worry about maintaining
compatibility with more and more weird vdso parsers.

Implementing this could be as simple as shoving parse_vdso.c into the
vdso, although vdso2c could help and allow a really simple in-vdso
implementation.

2. Go uses a segmented stack, and the vdso is quite unfriendly for
segmented stack.  If we can get compiler support, is there a
reasonable way that we could advertise the maximum stack usage of each
vdso entry point?


If we were to implement both, maybe we'd actually want to provide
something like:

struct vdso_entry {
  unsigned long vdso_entry_struct_size;  /* so we can add fields later on */
  void *func;
  unsigned int max_stack;  /* zero if not known */
};

vdso_entry *vdso_find_entry(const char *name, const char *version);

AT_VDSO_FINDENTRY would be set to &vdso_find_entry.

This shouldn't even break CRIU :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/