Page MenuHomeFreeBSD

Make linux_errtbl[] more readable
ClosedPublic

Authored by trasz on Oct 27 2020, 3:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Jan 26, 1:03 PM
Unknown Object (File)
Sat, Jan 25, 7:42 PM
Unknown Object (File)
Sat, Jan 25, 7:40 PM
Unknown Object (File)
Sat, Jan 25, 7:39 PM
Unknown Object (File)
Fri, Jan 24, 7:16 PM
Unknown Object (File)
Thu, Jan 23, 12:57 PM
Unknown Object (File)
Wed, Jan 22, 5:26 PM
Unknown Object (File)
Tue, Jan 21, 9:16 AM
Subscribers

Details

Summary

Add defines for Linux errno values and use them to make linux_errtbl[] more readable. While here, add linux_check_errtbl()
function to make sure we don't leave holes.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 34451
Build 31553: arc lint + arc unit

Event Timeline

trasz requested review of this revision.Oct 27 2020, 3:03 PM

I think this is good, I'm not sure the /* [80, 89] */ range markers are really needed

sys/compat/linux/linux_errno.c
31

do you want to make this < 0 instead

sys/compat/linux/linux_errno.h
82

could we indicate what makes these XXX-worthy?

lwhsu added inline comments.
sys/compat/linux/linux_errno.h
6

We don't really need this line anymore. :-)

I think this is good, I'm not sure the /* [80, 89] */ range markers are really needed

I'd prefer to leave them in; they were quite useful when writing this, and are still useful if you want to look up errno by value.

sys/compat/linux/linux_errno.c
31

I'd like to get rid of the minus signs in subsequent commit.

sys/compat/linux/linux_errno.h
6

Thanks, I'll remove it :-)

82

Sure, something like "/* XXX: in Linux this errno value is not defined */"?

sys/compat/linux/linux_errno.h
82

Actually, with that said why do we provide a define for it? What about e.g. /* XXX errno 41 unused in Linux */

sys/compat/linux/linux_errno.inc
122

These comments were necessary before because it wasn't clear which FreeBSD and Linux errnos are involved, but now it just repeats what the code clearly shows. I think it is still useful to call out discrepancies, but IMO we ought to instead explain why we chose the mapping.

EPROCLIM Too many processes.

EAGAIN Resource temporarily unavailable. This is a temporary condition

and later calls to the same routine may complete normally.
trasz marked an inline comment as done and an inline comment as not done.Oct 28 2020, 2:21 PM
trasz added inline comments.
sys/compat/linux/linux_errno.h
82

It will be required for subsequent commit which adds Linux->FreeBSD mapping.

sys/compat/linux/linux_errno.inc
122

In this particular case I have no idea why the mapping is like this. I just preserved the comments, and added them to point out discrepancies which were previously undocumented. In other words: I agree we should revisit them, but for now it's just maintaining status quo.

Okay, actually emaste@ is right, drop the fake defines.

sys/compat/linux/linux_errno.h
82

Ah, so you are going to make an inverse table using the same defines.

SEEMSUNUSED and ALSOUNUSED seem odd though.

How about LINUX_EUNUSED_41 and LINUX_EUNUSED_58

sys/compat/linux/linux_errno.inc
122

Sure, but you can drop the "X -> Y" from the comment, just leave an XXX to highlight it

trasz added inline comments.
sys/compat/linux/linux_errno.h
82

I think I'd prefer to just use raw numerical values instead of "fake" Econstants.

sys/compat/linux/linux_errno.inc
122

Done. I've added a comment at the top of the file to explain what the 'XXX's mean.

Ok no objections to this version

trasz marked an inline comment as done.

Try to fix tinderbox.

lib/libsysdecode/errno.c
40

the static seems odd there

This revision was not accepted when it landed; it landed in state Needs Review.Oct 29 2020, 2:24 PM
This revision was automatically updated to reflect the committed changes.

Isn't errno different in linux on different architectures? I know that at least alpha had a very different errno than x86..

It is; at some point we might need to move this into architecture-specific include. Unless Linux folks managed to fix it for newer architectures, in which case we won’t.