Consistent errno values

[dpgeorge]

On my linux box, native compilation has ETIMEDOUT with a value 110. But cross compiling using arm-none-eabi gives ETIMETOUT a value of 116. What to do here? Which value to use?

[dhylands]

Aside: I know system call indexes are different on different architectures as well.

On my raspberry pi (which is running an ARM processor), errno.ETIMEDOUT has the value 110.

I looked on cygwin, and in python there, errno.ETIMEDOUT == 116 (and ETIMEDOUT is defined as 116 in /usr/include/sys/errno.h)

posix only defined the name of the error and not its value.

So I think that the right thing to do is to use whatever value of ETIMEDOUT is defined for the platform.

[pfalcon]

On my linux box, native compilation has ETIMEDOUT with a value 110. But cross compiling using arm-none-eabi gives ETIMETOUT a value of 116. What to do here? Which value to use?

That sucks. Linux ABI is very inconsistent ;-(

I assume the question is either:

1. Which value to use for stmhal errno emulation? - apparently, we should decide what platform use as a reference, and stick to it (apparently, x86 is a good choice, hope x86_64 is 99% compatible with it).

2. What to do with Python-level usage, like errno.py from micropython-lib? Well, dunno. I tried hard sticking to "system interface in Python" idea, but on few occasions already had to move stuff to C, to avoid this ABI vs API problem, but more cases pop up. So, apparently need to move even more stuff to C, but that means unconditional growth of space (even if flash space), so apparently need to think seriously about Supporting dynamically loaded native (machine code) modules #583.

[pfalcon]

I hit this today with #1533 . It gave error 116, and I had to go to compiler includes to find that it's ETIMEDOUT.

[dpgeorge]

Yeah, it's super annoying.

I want to provide a built-in errno module for stmhal. Either as frozen module, persistent-bytecode or implemented in C, it doesn't matter, as long as "import errno" works on pyboard out-of-the-box without needing anything in the filesystem.

But, regardless of having built-in errno, we still need to decide whether to use port-specific errno values, or go for a fixed one.

[pfalcon]

Yeah, it's super annoying.

Well, I forgot to add to my previous comment that I still find it mildly annoying ;-). Otherwise, just was doing bug triaging and found what to add to this old issue.

I don't think it's big priority, but I'd give +0.5 for having a MICROPY_* config value, which, being defined, causes py/mpconfig.h to define typical error constants to standard values (either taken from Linux, or in the range beyond usual used by OS errors, to let differentiate them if they ever may be mixed in one port).

[danicampora]

+1 for builtin errno, and I vote for fixed values.

On Oct 25, 2015, at 10:19 PM, Damien George notifications@github.com wrote:

Yeah, it's super annoying.

I want to provide a built-in errno module for stmhal. Either as frozen module, persistent-bytecode or implemented in C, it doesn't matter, as long as "import errno" works on pyboard out-of-the-box without needing anything in the filesystem.

But, regardless of having built-in errno, we still need to decide whether to use port-specific errno values, or go for a fixed one.

—
Reply to this email directly or view it on GitHub.

[dpgeorge]

If we're going to have a builtin module then it would need to be named "uerrno" with weak link called "errno".

[danicampora]

Yes, good point.

On Oct 26, 2015, at 12:48 PM, Damien George notifications@github.com wrote:

If we're going to have a builtin module then it would need to be named "uerrno" with weak link called "errno".

—
Reply to this email directly or view it on GitHub.

[dpgeorge]

uPy now provides its own errno's in py/mperrno.h. From now on all errno symbols in code should use the MP_Exxx version. A uerrno module is also provided, disabled by default.