-
Notifications
You must be signed in to change notification settings - Fork 3k
fatfs: Update error code mapping #6120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
A lot of the error codes in fatfs were mapped incorrectly. This patch revisits the error code mapping to try to correct these mistakes
Should FR_TIMEOUT be tied to try again (EAGAIN) or timer expired (ETIME)? It's not really a timer expiring so not a great match either but ¯\(ツ)/¯ |
I was thinking EAGAIN to align with the netsocket APIs. But it looks like this error comes from the possibility of failing to get a mutex. If we base this off open group's Will update to ETIMEDOUT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Non blocking comment: Operation rejection is because of access permissions, should it be EACCES? |
I'm glad you asked. I think some of the ChanFS error descriptions are a bit misleading. I ended up looking at their use in the codebase which helped clarify things:
|
case FR_TIMEOUT: /* (15) Could not get a grant to access the volume within defined period */ | ||
default: /* Bad file number */ | ||
return -EBADF; | ||
case FR_OK: return 0; // (0) Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you fix the formatting (as it was)
case FR_OK:
return 0;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of like the new style, makes it more compressed and a bit easier to read. Not sure of the precedence here though just my 2 cents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geky Just because a PR fixes style issues, doesn't mean we now get to freely make them ;)
@kegilbert I believe the new line is already a precedent. I also think that if someone were doing a quick scan of the code, the indented new line sticks out, whereas this formatting is easy to miss (imo).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cmonr Feel free to update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b40ff8a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (although could use a squash)
/morph build |
Build : SUCCESSBuild number : 1236 Triggering tests/morph test |
Test : SUCCESSBuild number : 1036 |
Exporter Build : SUCCESSBuild number : 903 |
Do you have a label for API breakages? You should have. |
Thanks @kjbracey-arm From a different conversation #6072 (comment):
The key here was changing error codes to match documentation. It's a gray area, but we were under the impression this was acceptable. Let us know if we're wrong though. I'm fine with holding error code fixes until minor releases to keep dependencies moving smoothly. |
I didn't see that discussion. I agree it's a grey area, but in this case I did get my ear pulled by the client guys - this did break their apps. I'd be inclined to try to make the change asap on a patch if I thought it was unlikely anyone was relying on the broken behaviour (or if we knew someone was already relying on correct behaviour due to using another FS, and this would stop them using our FS). This late in the 5.7 cycle though, and given that it did trip them, I think we should wait for 5.8.0. If the documentation was clear, I'm not sure why they wouldn't write to cope with the documented values as well as the incorrect ones they must have found by inspection/testing. Did we actually specify it locally, or are we just deferring to POSIX? |
Yes, it is in the PR type template and that should signal this is for a minor version. It is now labeled for the next upcoming minor
@geky Looking at this change, where are tests that would need to be fixed? |
This specific pr landing on 5.7 was a mistake, I was more asking about future changes of this sort. It sounds like the answer is to only allow change on patch if there's a good reason. I did note this should be on a minor release in the original pr. See the pr message. I wasn't following the merge closely enough to notice it landed on a patch:
@kjbracey-arm, We are just defering to POSIX. Though this was raised as a concern elsewhere and I'm planning on adding error codes to the FileSystem doxygen when I can. @0xc0170, This pr is a part of the work required to run the filesystem tests on FAT. The tests expect the correctly error codes. Currently we aren't running FAT filesystem tests in CI. |
Yup, I missed that.
Sounds like quite the chicken and egg problem. Does this mean we're close to being able to run the tests in CI? @kjbracey-arm Do we have an idea of what features client is/are depending on and/or contact we could ping with PRs that might affect them? I wasn't expecting a change like this would have tripped anyone up. |
Not sure what specifically tripped the client guys - I expect it was some sort of device update initialisation code doing something like Basically this sort of change could trip up anyone who actually cares about return values (but not enough to actually check for standard POSIX ones as well as what fatfs was currently returning). Code tends not to inspect error values, but sometimes they matter. Client code is maybe a bit more susceptible to error return changes due to having the "PAL" glue layer using conversions from native error codes to PAL_XXX values. That gives an extra layer that can make an error mapping mistake. Often seems to need updating for a different network interface/stack/filing system - this effectively starts acting like a different filing system. |
This is in response to #6072
A lot of the error codes in fatfs were mapped incorrectly. This patch revisits the error code mapping to try to correct these mistakes. I'm open to feedback on these.
EBADFENOENTENOENTEFAULTENOENTENXIOENOENTEBADFEBADFEACCESENOEXECcc @kegilbert, @deepikabhavnani
intended for minor release
should resolve #6072
note, #5653 is related but not fixed by this pr (requires changes in ChanFS).