vsock: Use PathBuf for socket paths instead of Strings

[bilelmoussaoui]

Summary of the PR

For reasons I ignore, String was used all over the place where a PathBuf makes more sense.

cc @Ablu, similar to yesterday's discussion regarding vhost-video

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR are signed (with git commit -s), and the commit
  message has max 60 characters for the summary and max 75 characters for each
  description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[bilelmoussaoui]

Before I do the same for the rest of the crates, is there any reason behind such pattern?

[Ablu]

Before I do the same for the rest of the crates, is there any reason behind such pattern?

I am all for PathBuf/Path. Makes the type clear and provides all the useful path manipulation functions.

[stefano-garzarella]

Before I do the same for the rest of the crates, is there any reason behind such pattern?

I don't think so, thanks for fixing that.

[Ablu]

Found a few cases where we turn an existing (and unneeded PathBuf) into a ref only to turn it back into a PathBuf. But maybe thats just against my own taste, so I do not see it as blocker.

[stefano-garzarella]

@bilelmoussaoui I'd suggest updating the PR title, since we are now covering multiple crates

[bilelmoussaoui]

@bilelmoussaoui I'd suggest updating the PR title, since we are now covering multiple crates

Right, will do once I figured out how to handle the tests situation & migrate scmi to use clap directly.

[epilys]

This change is definitely necessary. Path names are not guaranteed to be UTF-8 hence why Path/OsStr exists.

[epilys]

@bilelmoussaoui are you interested in picking this up again? We started doing this on the other device crates (see latest PRs)

[bilelmoussaoui]

@bilelmoussaoui are you interested in picking this up again? We started doing this on the other device crates (see latest PRs)

it took me too long, but i finally did!

[bilelmoussaoui]

Although a test is failing with the following

thread 'backend::tests::test_gpio_fail_listener_mock' panicked at vhost-device-gpio/src/backend.rs:350:9:
assertion failed: `CouldNotOpenDevice(GpiodFailed(OperationFailed(ChipOpen, Errno { code: 2, description: Some("No such file or directory") })))` does not match `Error::ServeFailed(_)`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I suppose that is kind of expected, could I change the expected error in the test?

[epilys]

Path::join does not append the suffix to the file name component, but pushes a new component (e.g. "foo.sock0" vs "foo.sock/0")

[bilelmoussaoui]

I guess something like let socket = config.socket_path.with_extension(format!("sock{i}")); would work better? but that hardcodes the extension though.

[epilys]

vhost-device/vhost-device-i2c/src/main.rs

Lines 239 to 256 in 1e6667f

	pub fn generate_socket_paths(&self) -> Vec<PathBuf> {
	let socket_file_name = self
	.socket_path
	.file_name()
	.expect("socket_path has no filename.");
	let socket_file_parent = self
	.socket_path
	.parent()
	.expect("socket_path has no parent directory.");
	let make_socket_path = |i: usize| -> PathBuf {
	let mut file_name = socket_file_name.to_os_string();
	file_name.push(std::ffi::OsStr::new(&i.to_string()));
	socket_file_parent.join(&file_name)
	};
	(0..self.socket_count).map(make_socket_path).collect()
	}
	}