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

Anton Ivanov anton.ivanov at cambridgegreys.com
Wed Oct 7 11:10:23 EDT 2020


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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/




More information about the linux-um mailing list