On Fri, Jul 6, 2018, 18:15 Rob Landley <r...@landley.net> wrote:

> On 07/06/2018 03:14 PM, enh wrote:
> > i'm not sure getrandom(2) is a good choice for a compile-time probe.
> > certainly on Android it's common for your libc to be way ahead of your
> > kernel.
> Hmmm. I didn't expect that. (libc provides a syscall wrapper for a syscall
> your
> kernel doesn't have. Ok...)

Isn't musl the same?

Hmmm... I can't compile time probe for what the syscalls return because
> cross
> compiling (and potentially deploying on a different kernel), and I don't
> want to
> make the fallback code ubiquitous because embedded. Hmmm...

Why not?

I suppose I could make the fallback code's presence depend on
> > in this specific case, on Android getrandom(2) is very likely
> > to return ENOSYS. for the arc4random functions (from BSD) we'll try
> > getrandom but fall back to open/read/close. seems like xgetrandom
> > might be better off doing that, on the assumption that folks will try
> > to use prebuilts on old devices/hosts?
> Whereas on glibc I have the exact _opposite_ problem, 'FATAL: kernel too
> old" in
> the library loader or entry code, because glibc checks the kernel version
> and
> refuses to run on one older than it was built on. (I.E. gnu/dammit
> anything is
> insane, part several thousand something.)

Oh, weird. I didn't know that. My Linux hosts usually have the opposite
problem of a kernel years newer than their libc.

Lemme try a fix... ok, how's that?

I was actually assuming you'd be best off just removing the compile time
check and using syscall(3). Wouldn't that be best for your musl prebuilts?
And still work fine for glibc.

> _______________________________________________
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
Toybox mailing list

Reply via email to