Skip to content
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.

Sign up for GitHub

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

Jump to bottom

FreeBSD: add evdev structures #3756

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

FreeBSD: add evdev structures #3756

wants to merge 1 commit into from

Conversation

Awoonyaa
Copy link

No description provided.

@rustbot
Copy link
Collaborator

rustbot commented Jun 21, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@arrowd
Copy link

arrowd commented Jun 24, 2024

Some context: On FreeBSD the evdev headers are not part of the base system, but come from a package named evdev-proto. It seems this package should be installed to make this PR compile.

@devnexen You did some FreeBSD PRs already, could you please look at this one too?

@devnexen
Copy link
Contributor

Some context: On FreeBSD the evdev headers are not part of the base system, but come from a package named evdev-proto. It seems this package should be installed to make this PR compile.

Just quick response here: by definition if it is not part of the system thus has no place in this crate, e.g. libutil is still part of builtin libraries. my 2 cents :)

@arrowd
Copy link

arrowd commented Jun 24, 2024

Yes, but on Linux these data types are part of libc. Because of this, the consumers of this library that are using these types will fail to compile on FreeBSD. This is the case for the new release of https://github.com/mqudsi/syngesture

I think that putting these types here is the most correct solution, but I know nothing of Rust ecosystem.

@devnexen
Copy link
Contributor

I get it, but Linux is Linux. However though, nothing is stopping you define those types in the requested project (or to publish a crate dedicated to those sort of things ?). But hey, I m not the maintainer of libc :) I do not get to decide.

@arrowd
Copy link

arrowd commented Jun 24, 2024

nothing is stopping you define those types in the requested project

This would require patching for each project that depends on these types in libc.

or to publish a crate dedicated to those sort of things ?

This would probably require patching too, although much less? Maybe it is a way to go then?

@devnexen
Copy link
Contributor

Regardless, to make CI work here you would need to add the related dependency. CI at the moment only install what necessaty, it appears, for rustup nothing else. The decision to merge it or not is more @JohnTitor call :)

@devnexen
Copy link
Contributor

devnexen commented Jul 5, 2024

I think you need to declare the appropriate evdev-proto header in libc-test/build.rs in the freebsd's list.

@Awoonyaa Awoonyaa force-pushed the libc_upd branch 3 times, most recently from 5d44a74 to 6a00f38 Compare July 10, 2024 08:14
devnexen
devnexen reviewed Jul 10, 2024
View reviewed changes
libc-test/build.rs Outdated Show resolved Hide resolved
@devnexen
Copy link
Contributor

Also note you need to treat struct field such as input_event::type_ as it is for sure not its real name, see other example how it is done in libc-test/build.rs.

@Awoonyaa
Copy link
Author

Awoonyaa commented Jul 12, 2024 •
edited
Loading

@devnexen thank you for the comments! Maybe you can advise me how to create a flag for checking file in /usr/local/include ?

@devnexen
Copy link
Contributor

@devnexen thank you for the comments! Maybe you can advise me how to create a flag for checking file in /usr/local/include ?

Are you able to run tests locally ?

@Awoonyaa
Copy link
Author

@devnexen thank you for the comments! Maybe you can advise me how to create a flag for checking file in /usr/local/include ?

Are you able to run tests locally ?

Yes

@Awoonyaa Awoonyaa force-pushed the libc_upd branch 2 times, most recently from ac3af67 to f2fb2da Compare July 16, 2024 14:01
arrowd
arrowd reviewed Jul 16, 2024
View reviewed changes
libc-test/build.rs
@@ -1990,6 +1990,9 @@ fn test_freebsd(target: &str) {
cfg.define("_WITH_GETLINE", None);
// Required for making freebsd11_stat available in the headers
cfg.define("_WANT_FREEBSD11_STAT", None);
cfg.define("LIBICONV_PLUG", None);

cfg.flag("-I/usr/local/include");
Copy link

Choose a reason for hiding this comment

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

Ideally, we should use the value of sysctl -n user.localbase here instead of hardcoding "/usr/local", but I don't know how to do it in Rust.

arrowd
arrowd reviewed Jul 16, 2024
View reviewed changes
libc-test/build.rs Outdated Show resolved Hide resolved
@tgross35 tgross35 changed the title Add structures for freebsd FreeBSD: add evdev structures Aug 16, 2024
@tgross35 tgross35 mentioned this pull request Aug 16, 2024
Open
@tgross35
Copy link
Contributor

I asked about this as a policy question in #3839. Until then:

@rustbot blocked

@bors
Copy link
Contributor

bors commented Aug 29, 2024

☔ The latest upstream changes (presumably #3889) made this pull request unmergeable. Please resolve the merge conflicts.

@jbeich
Copy link

jbeich commented Oct 23, 2024 •
edited
Loading

On FreeBSD the evdev headers are not part of the base system, but come from a package named evdev-proto.

<linux/input.h> is also available as <dev/evdev/input.h> (ditto input-event-codes.h and uinput.h). For static platform bindings it may be fine to test against FreeBSD headers which are subset of Linux. This should help unblock progress here by sidestepping #3839.

CC @wulf7 who implemented evdev on FreeBSD and defined evdev-proto policy.

@wulf7
Copy link

wulf7 commented Oct 27, 2024 •
edited
Loading

On FreeBSD the evdev headers are not part of the base system, but come from a package named evdev-proto.

<linux/input.h> is also available as <dev/evdev/input.h> (ditto input-event-codes.h and uinput.h). For static platform bindings it may be fine to test against FreeBSD headers which are subset of Linux. This should help unblock progress here by sidestepping #3839.

CC @wulf7 who implemented evdev on FreeBSD and defined evdev-proto policy.

If this code is FreeBSD-only, you can rely on <dev/evdev/input.h>
If some chunks of it are shared with Linux, then <linux/input.h> is preferable to not use extra #ifdef-s in shared sections

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

@devnexen devnexen devnexen left review comments

@arrowd arrowd arrowd left review comments

Assignees

@JohnTitor JohnTitor

Labels
S-blocked
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
9 participants
@Awoonyaa @rustbot @arrowd @devnexen @tgross35 @bors @jbeich @wulf7 @JohnTitor