Add sockaddr_vm definition for Fuchsia

[jamesr]

Description

This adds a definition of struct sockaddr_vm for Fuchsia

Sources

man vsock documents this type on most platforms. The Fuchsia definition matches
Linux except that we do not (currently) have support for flags.

Checklist

libc-test does not have support for Fuchsia currently.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tgross35 (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

[tgross35]

Usually we use the c_* types if that is how they are defined in the source.

Suggested change

	pub svm_reserved: u16,
	pub svm_port: crate::in_port_t,
	pub svm_cid: u32,
	pub svm_reserved: c_short,
	pub svm_port: crate::in_port_t,
	pub svm_cid: c_int,

Do you have a link to relevant header for fuchsia?

[tgross35]

This should also get added to libc-test/semver/fuchsia.txt

[tgross35]

This lgtm but I'm not sure what to compare it against. Is the relevant fuchsia header public?

[jamesr]

This lgtm but I'm not sure what to compare it against. Is the relevant fuchsia header public?

https://cs.opensource.google/fuchsia/fuchsia/+/main:src/paravirtualization/lib/vsock/vm_sockets.h;drc=4050ee185f9701a852d764e120bc0886917e3c1a is the most relevant header today. It's public but it is not in the best location - we are still debating exactly where to put it. Regardless of where it is, I don't expect the definition to change (and if it does, I'll update the bindings here to match).

(I tried to reply inline but may have failed - I'm not very practiced with GitHub-ing)

[tgross35]

https://cs.opensource.google/fuchsia/fuchsia/+/main:src/paravirtualization/lib/vsock/vm_sockets.h;drc=4050ee185f9701a852d764e120bc0886917e3c1a is the most relevant header today. It's public but it is not in the best location - we are still debating exactly where to put it. Regardless of where it is, I don't expect the definition to change (and if it does, I'll update the bindings here to match).

Thanks, that works for me :) Just trying to keep everything crosslinked since it can can be difficult to find sources for everything down.

(I tried to reply inline but may have failed - I'm not very practiced with GitHub-ing)

I assume it put your comments in a review and wants you to submit them in a batch - It seems to do this sometimes but I have no clue what decides that should happen...

[tgross35]

https://cs.opensource.google/fuchsia/fuchsia/+/main:src/paravirtualization/lib/vsock/vm_sockets.h;drc=4050ee185f9701a852d764e120bc0886917e3c1a is the most relevant header today. It's public but it is not in the best location - we are still debating exactly where to put it. Regardless of where it is, I don't expect the definition to change (and if it does, I'll update the bindings here to match).

Thanks, that works for me :) Just trying to keep everything crosslinked since it can can be difficult to find sources for everything down.

(I tried to reply inline but may have failed - I'm not very practiced with GitHub-ing)

I assume it put your comments in a review and wants you to submit them in a batch - It seems to do this sometimes but I have no clue what decides that should happen...

@rustbot label +stable-nominated

[tgross35]

Oh wait, one more thing - it looks like the field is called svm_reserved1 in Linux and in the headers, but this has it as svm_reserved. Should this be updated?

[jamesr]

Oh wait, one more thing - it looks like the field is called svm_reserved1 in Linux and in the headers, but this has it as svm_reserved. Should this be updated?

That seems like a good idea - done. In practice it's rare to ever type this field but consistent is better than inconsistency.