Skip to content

posix: Clean up various headers #16626

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

Merged
merged 6 commits into from
Jul 25, 2019
Merged

Conversation

pfalcon
Copy link
Collaborator

@pfalcon pfalcon commented Jun 4, 2019

Ok, so this started as just moving open() from unistd.h to fcntl.h, but as usual, led to chain of conflicts, which however this time were tracked down to completion.


Per POSIX, open() is defined in <fcntl.h>. fcntl.h in turn comes from
the underlying libc, either newlib, or minimal libc.

Signed-off-by: Paul Sokolovsky [email protected]

@pfalcon pfalcon added the area: POSIX POSIX API Library label Jun 4, 2019
@pfalcon pfalcon force-pushed the posix-open branch 6 times, most recently from 42a480b to 6dcacd0 Compare June 5, 2019 11:59
@pfalcon
Copy link
Collaborator Author

pfalcon commented Jun 5, 2019

Ok, so this started as just moving open() from unistd.h to fcntl.h, but as usual, led to chain of conflicts, which however this time were tracked down to completion.

@pfalcon pfalcon changed the title posix: unistd.h: open() doesn't belong here posix: Clean up various headers Jun 5, 2019
@nashif nashif added the Maintainer At least 2 days before merge, maintainer review required label Jun 7, 2019
Copy link
Contributor

@mbolivar mbolivar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the goal is a cleanup, I think at least including kernel.h from a libc header ought to be addressed, as it does fall under that umbrella.

@pfalcon
Copy link
Collaborator Author

pfalcon commented Jun 7, 2019

@mbolivar: I don't understand what you mean. Please review previous comments and history of title changes regarding the goal of this PR. And perhaps, post comments without hitting -1 button right away?

@pfalcon pfalcon requested a review from mbolivar June 7, 2019 18:46
@mbolivar
Copy link
Contributor

mbolivar commented Jun 7, 2019

post comments without hitting -1 button right away?

I posted 3 comments; what are you talking about?

@pfalcon
Copy link
Collaborator Author

pfalcon commented Jun 7, 2019

I posted 3 comments; what are you talking about?

Ok, sorry, I didn't get them in email, and didn't see at once here.

@mbolivar
Copy link
Contributor

mbolivar commented Jun 7, 2019

I'm done with this PR. Dismissing my stale review.

extern "C" {
#endif

#include <kernel.h>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with @mbolivar from the perspective of minimal libc headers should not be including kernel.h. However I'll say it shouldn't have been put into the Zephyr's POSIX material in the first place, so that ship has sailed and though removing the include should happen it's not in scope for this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not be including kernel.h here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not be including kernel.h here

Again, I just moved the file around, and made minimal change to accompany that, if any. Let me try to remove that and see if it leads to cascade of unexpected CI breaks (which is very common so far with POSIX subsys stuff, and what I'm trying to fix - step by step).

@pabigot
Copy link
Collaborator

pabigot commented Jun 27, 2019

I would like to see this merged soon since it's required as the basis of reworking #17003.

@pfalcon
Copy link
Collaborator Author

pfalcon commented Jun 27, 2019

@pabigot: Thanks for approval.

@pabigot
Copy link
Collaborator

pabigot commented Jul 1, 2019

@pfalcon Thanks. My rework of #17003 is complete and waiting for this to be merged so I can submit those changes and DS3231 support. I'm hoping that'll happen soon. Enjoy your vacation.

@andrewboie
Copy link
Contributor

@nashif can you re-visit your review?

Copy link
Collaborator

@mgielda mgielda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mgielda
Copy link
Collaborator

mgielda commented Jul 25, 2019

(I know Anas is on holiday and double checked that his remark was included, so I dismissed it - hope that's OK)

@carlescufi carlescufi added the dev-review To be discussed in dev-review meeting label Jul 25, 2019
@pfalcon
Copy link
Collaborator Author

pfalcon commented Jul 25, 2019

@mgielda, Thanks for review.

Also, the PR is rebased against master, added a commit to fix issue mentioned in #17768 (comment) (cc: @PiotrZierhoffer).

Copy link
Collaborator

@galak galak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor comments, but otherwise looks good.

@galak galak removed the dev-review To be discussed in dev-review meeting label Jul 25, 2019
pfalcon added 6 commits July 25, 2019 19:28
Newlib libc already provides sys/stat.h, so trying to have sys/stat.h
on the level of POSIX subsys inevitable leads to include order and
definition conflicts. Instead (as most of other sys/* includes)
should come from the underlying libc.

While moving, made unrelated change of removing #include <kernel.h>,
to accommodate the change reviewers.

Signed-off-by: Paul Sokolovsky <[email protected]>
POSIX subsys defines struct timespec in <time.h> (as POSIX public
API requires), but newlib defines in in sys/_timespec.h, which
inevitably leads to inclusion order and redifinition conflicts.
Follow newlib way and define it in single place, sys/_timespec.h,
which belongs to libc namespace. Thus, we move current definition
to minimal libc, and will use either minlibc's or newlib's
definition, instead of trying to redefine it.

This is similar to the introduction of sys/_timeval.h done earlier.

Signed-off-by: Paul Sokolovsky <[email protected]>
Unfortunately, Zephyr SDK 0.10.0 ships with outdated Newlib 2.0.0
(from 2015 or earlier) which lacks sys/_timespec.h header, requiring
ugly workaround of defining struct timespec inline (the whole idea
was to standardize on sys/_timespec.h header for different libc's).

This is similar to earlier workaround for struct timeval definition
introduced in a6aee9b. Zephyr SDK ticket for this issue
is zephyrproject-rtos/sdk-ng#64, and it
will ve possible to remove both workarounds when Xtensa toolchain
will be upgraded to newlib version consistent with other
architectures.

Signed-off-by: Paul Sokolovsky <[email protected]>
That's the header which is supposed to define them, there was even
FIXME on that in mqueue.h.

Signed-off-by: Paul Sokolovsky <[email protected]>
Per POSIX, open() is defined in <fcntl.h>. fcntl.h in turn comes from
the underlying libc, either newlib, or minimal libc.

Signed-off-by: Paul Sokolovsky <[email protected]>
By the latest convention, libc's define struct timespec in
sys/_timespec.h. This is consistent with Newlib and ensures
about errors due to redefinitions.

Signed-off-by: Paul Sokolovsky <[email protected]>
@pfalcon
Copy link
Collaborator Author

pfalcon commented Jul 25, 2019

A few minor comments, but otherwise looks good.

Should be addressed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: C Library C Standard Library area: POSIX POSIX API Library area: Tests Issues related to a particular existing or missing test Maintainer At least 2 days before merge, maintainer review required
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants