[RFC v7 18/21] um: host: add utilities functions

[Hajime Tazaki]

On Thu, 08 Oct 2020 00:10:23 +0900,
Anton Ivanov wrote:
> 
> 
> 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.

Those variables are based on tools/um/include/lkl/asm-generic/errno.h,
which is generated from include/uapi/asm-generic/errno.h, which LKL
kernel eats for its values.

This is the part of patch 12/21.

> >>> 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.

So, this particular code does not contain arch specific part I
believe.
# Tavi, correct me if I'm wrong.

> >>>> +
> >>>> +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.

So, this is not for the error values which underlying host generates,
but the ones kernel generates.  And the values should be tied with
uapi/asm-generic/errno.h.

One possible failure that I can see is if
uapi/asm-generic/errno{-base}.h are changed.  In that case, yes, the
way Johannes proposed would be the right way to handle.  The outlook
would be with the prefix and errno name (as follows).

 [0] = "Success",
 [LKL_EPERM] = "Operation not permitted",

-- Hajime