Skip to content

fix : incorrect POLLOUT def on horizonOS/armv6k-nintendo-3ds#5090

Draft
kore-signet wants to merge 1 commit into
rust-lang:mainfrom
kore-signet:horizon-os
Draft

fix : incorrect POLLOUT def on horizonOS/armv6k-nintendo-3ds#5090
kore-signet wants to merge 1 commit into
rust-lang:mainfrom
kore-signet:horizon-os

Conversation

@kore-signet

Copy link
Copy Markdown

Description

Current definition for POLLOUT is incorrect - as described here, it should be 0x08.

Unfortunately, it seems like the current definition for POLLERR is overlapping as 0x08. According to the linked docs, POLLERR is actually not a supported operation on this target (neither is POLLHUP, which is also currently defined).

I'm not super clear on what the best procedure would be here - should POLLERR & POLLHUP be deleted as definitions?

Sources

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI
    (libc-test does not currently support horizonOS, as far as I can tell?)

@tgross35

Copy link
Copy Markdown
Contributor

I'm not super clear on what the best procedure would be here - should POLLERR & POLLHUP be deleted as definitions?

Are they defined when they try to use them in C? If so, we should match that. It's fine to remove if they aren't in the platform's libc since this is a T3 target.

The existing part of this PR lgtm.

Pinging 3DS target maintainers: @Meziu @AzureMarker @ian-h-chamberlain

@kore-signet

Copy link
Copy Markdown
Author

Are they defined when they try to use them in C? If so, we should match that. It's fine to remove if they aren't in the platform's libc since this is a T3 target.

The closest thing HorizonOS has to a libc is libctru, which has the following def for POLLERR & POLLHUP:

#define POLLHUP		0x04 // unknown ???
#define POLLERR		0x08 // probably

So yes, it is technically defined in C, but not very strongly, haha. I'll defer to the platform maintainers :)

@tgross35

Copy link
Copy Markdown
Contributor

It actually has those "unknown" and "probably" comments? That's entertaining :) (I assume these are the results of reverse engineering)

Since they do exist there I'd just leave them in our libc. Feel free to add a terse doc comment indicating they may not be well supported. This PR looks fine to me either way, feel free to unmark it as a draft when you're ready.

@kore-signet

Copy link
Copy Markdown
Author

It really does have the comments, haha! I'll add the comment marking it out and open the PR for a merge tmrw :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants