On 07/10/2020 16:03, Johannes Berg wrote:
On Wed, 2020-10-07 at 17:02 +0200, Johannes Berg wrote:
On Wed, 2020-10-07 at 15:53 +0100, Anton Ivanov wrote:
These are actually different on different architectures. These look
like the x86 values.
IMHO a kernel strerror() would be the right way of dealing with this
in the long term (i understand that we cannot call the platform one,
because it may be different from the internal Linux errors). It will
be useful in a lot of other places.
If we leave it as is, we need to make this arch specific at some
point.
+
+static const char * const lkl_err_strings[] = {
+ "Success",
+ "Operation not permitted",
Might be possible to more or less address this (except for arch-specific
errors that don't always exist) but using C99 initializers?
[0] = "Success",
[EPERM] = "Operation not permitted",
..
But, on the other hand, is it needed at all? I don't think the kernel
ever prints out the actual string ...
I can see the use case for a library in a multi-arch environment (which IMHO is the intended use case). It saves the user the effort of digging into the build and figuring out what does this error mean today :)
It is nice to have :)
If we will have it, however, it should be done as you suggested - C99 or some other way where it maps correctly to actual underlying error codes as they may end up being different depending on build config.
johannes
_______________________________________________
linux-um mailing list
linux-um@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-um
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
