[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <em5816924b-3a65-4e2d-b10a-d4a5a6aefd6e@1f92019b.com>
Date: Sat, 26 Oct 2024 23:35:03 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re[2]: Prototypes without implementations
>You call the function, and if it fails, you fall back to another method
>(which includes attempting to seed a PRNG with getauxval(AT_RANDOM) or
>trying to open /dev/urandom or the like). Does it matter if it fails
>because the kernel is too old or just having a bad day?
That's exactly what I'm doing. That's why I have a C programming
library
that everything I write depends on: to wrap these excuses for interfaces
into something that an application can reasonably use. It was annoying
to
write. And the part of the library that generates random numbers was
*especially* annoying, thanks in no small part to that getrandom()
behaviour. I needed 4 attempts to make it work in a satisfying way.
And you're saying everyone should do that, for *every* interface
exposed
by the system? That is putting very unreasonable expectations on
application writers, and making C even harder than people like to say
it is.
>Failing with ENOSYS and no side effects and no wait time is conformant
>as well.
Yeah. You're right. And my point, shared with other people in this
thread, is that it's a bad thing, and we should avoid having these stub
functions wherever possible.
> (The workaround could be the self-pipe trick, which
>obviates the need for pselect() completely).
(Using a self-pipe is also better than pselect() for other reasons:
it allows you to handle signals as regular events and process them in
normal execution context rather than interruption context. So indeed
pselect() is never needed, and the self-pipe trick - also implementable
via signalfd() on Linux - should be the regular pattern, not a
workaround.)
>If the function under test fails with
>ENOSYS, you still have no idea if that is because of a stubbed out
>implementation.
Exactly. So let's not add to the list of functions that do that.
>If your binary links against musl, it does do precisely those tests. Not
>necessarily at the start of the runtime, but inside many functions
It is a very deliberate, very conscious choice in musl, and the
explicit goal is that binaries linked against musl should run on as many
kernel versions as possible, independently of the kernel version musl
was built with.
It is a reasonable design goal for a libc to avoid tying userspace to
specific kernel features. If there is ever a place to test, live,
whether
a system call is supported, and fall back to a different system call, or
sequence of, if it isn't, a libc would be that place; and I appreciate
that musl goes to these lengths to ensure independence from the kernel.
It is not, however, a reasonable expectation that *applications* should
do so with the system they're running on. Applications should be able
to rely on the system - that's why specifications exist. The ecosystem
is already in bad enough shape that extensive build-time configuration
(that works badly, and that nobody likes) is needed for most software;
claiming that the sensible way of writing applications is run-time tests
for system independence is abandoning any pretense of practicality.
>It is possible, though not effortless, to write sensible software using
>any of the aforementioned build systems.
Kudos to you for making it work. Now you should know as well as I do
that
between writing sensible software with effort, and writing half-baked
software with less effort, most of the ecosystem, including incredibly
popular projects, will choose the latter. Let's not break them even more
than they already are, please.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
