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.

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

Avoid extra ioctl by allowing control query by description #62

Merged
merged 6 commits into from
Nov 10, 2023

Conversation

donkeyteethUX
Copy link
Contributor

Changes based on discussion on #60, specifically comments from @MarijnS95.

  • Add get_control which takes a &Description and requires only 1 ioctl.
  • Deprecate control getter in favor of more explicit get_control_from_id (and document preference for get_control).
  • Bump minor version.

Cargo.toml Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
@raymanfx
Copy link
Owner

I am not entirely convinced increasing the API surface is worth it just to avoid a single ioctl. This might very well be a case of premature optimization. Are you running into some actual issues that motivate this change?

@MarijnS95
Copy link
Collaborator

I am not entirely convinced increasing the API surface is worth it just to avoid a single ioctl. This might very well be a case of premature optimization. Are you running into some actual issues that motivate this change?

I only suggested this to be able to pass an &Description instead of an untyped u32 which seemed a bit more clear to me. It's not premature optimization as much as it is removing unnecessary code that shouldn't have run/been there in the first place, IMO.

@donkeyteethUX
Copy link
Contributor Author

@raymanfx agreed that it's not a huge difference. Still, my app calls control() for each available control inside an egui render loop. This might seem excessive, but it's simpler and safer to keep the driver as the single source of truth rather than caching anything. strace shows around 1000 ioctl / second before, and 600 after, and the code is slightly more explicit as @MarijnS95 points out.

src/device.rs Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
remove old control getter
@donkeyteethUX
Copy link
Contributor Author

Bump, after addressing old comment & rebasing this.

src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
src/device.rs Outdated Show resolved Hide resolved
@MarijnS95
Copy link
Collaborator

@donkeyteethUX reverse bump: this is close to ready if you address the minor but remaining isuses.

@donkeyteethUX
Copy link
Contributor Author

@donkeyteethUX reverse bump: this is close to ready if you address the minor but remaining isuses.

Thanks -- will-do when I get a chance. I'm swamped at work but haven't forgotten about it.

@raymanfx
Copy link
Owner

raymanfx commented Feb 7, 2023

Looks good to me. Any objections?

Copy link
Collaborator

@MarijnS95 MarijnS95 left a comment

Choose a reason for hiding this comment

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

I'm not fond of conflating PRs with unrelated new-Rust-version clippy fixes as it takes away from the main semantic change, but will leave it to @raymanfx to decide to split that out to a separate PR (i.e. do we use rebase merges?).

EDIT: fwiw I've been told inlining format args will be demoted to pedantic.

src/device.rs Outdated Show resolved Hide resolved
@MarijnS95
Copy link
Collaborator

Ping again, we still have two comments open and shouldn't conflate this PR with unrelated clippy changes.

@MarijnS95 MarijnS95 requested a review from raymanfx November 1, 2023 10:24
src/device.rs Outdated
/// # Arguments
///
/// * `id` - Control identifier
pub fn control_from_id(&self, id: u32) -> io::Result<Control> {
Copy link
Owner

Choose a reason for hiding this comment

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

IMO, this can be removed. We don't need backwards compatibility here, no need to inflate the API surface when the new function does the same thing, but better.

Copy link
Collaborator

@MarijnS95 MarijnS95 Nov 5, 2023

Choose a reason for hiding this comment

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

Agreed if we're pushing to land this in a breaking release.

EDIT: Which is needed anyway because the signature of the existing fn control() changed rather than leaving it untouched and introducing a new fn control_from_description() instead. We probably discussed this a while ago but I forgot.

The new implementation of `control()` takes a `&Description` directly,
and callers have enough means to get that `Description` such that we
shouldn't cater to the "slower" use-case of letting `libv4l-rs` query
it again.
@MarijnS95 MarijnS95 requested a review from raymanfx November 5, 2023 23:21
Copy link
Owner

@raymanfx raymanfx left a comment

Choose a reason for hiding this comment

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

Looks good to me. I still think the API is a touch too close to the raw C v4l2 API, but we can do iterative improvements. It's something I need to think about and sketch out separately.

@MarijnS95
Copy link
Collaborator

@raymanfx do you mean the API added by this PR specifically, or the control API in general? If anything it seems this function is now more high-level by taking something typed instead of a generic i32.

@raymanfx
Copy link
Owner

raymanfx commented Nov 9, 2023

I was talking about the API in general. This change is fine and I agree with its premises.

@raymanfx raymanfx merged commit dfbb778 into raymanfx:master Nov 10, 2023
4 of 5 checks passed
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.

3 participants