Implement Trenameat and Tunlinkat

[JJL772]

Implements Tunlinkat and Trenameat, ironically not using either of those syscalls.

[garlick]

Nice, thank you!

Couple of things:

• could you update the src/libnpfs/test/encoding.c to make sure we're checking serialize/deserialize for these operations
• would you mind expanding the commit message to provide any back story or references that might be useful for context? (Why were you motivated to add this, what problem does this solve for you, etc)
• The test framework in tests needs an overhaul (and I have a partial branch doing that on the back burner) so I don't want to ask you to add another test, but perhaps if you have an idea of how we would test this with the kernel 9p client we could open an issue to add a test later with your notes.

I'll try to do a proper review in the next couple of days, including refreshing my memory on how those syscalls work and what's going on in the linux kernel 9p side. Any pointers/context you can share in the mean time would be appreciated.

[garlick]

could you update the src/libnpfs/test/encoding.c to make sure we're checking serialize/deserialize for these operations

Duh! Never mind, already there.

[JJL772]

Thanks for the initial feedback!

would you mind expanding the commit message to provide any back story or references that might be useful for context? (Why were you motivated to add this, what problem does this solve for you, etc)

My motivation was that I implemented Trenameat/Tunlinkat in a 9p client before realizing that diod returns ENOTSUPP for both. Since the boilerplate was already there for these calls, I figured that I'd try to implement them. I had chosen Trenameat/Tunlinkat because they were well suited for implementing a couple file system operation handlers on RTEMS, which is ultimately where this 9p client will be deployed.

The test framework in tests needs an overhaul (and I have a partial branch doing that on the back burner) so I don't want to ask you to add another test, but perhaps if you have an idea of how we would test this with the kernel 9p client we could open an issue to add a test later with your notes.

Kernel 9p client function v9fs_vfs_remove looks like it tries Tunlinkat first, and falls back to Tremove if not supported. The existing tests might cover this already in that case, at the cost of overlapping with Tremove. Same situation with v9fs_vfs_rename; it first tries Trenameat and uses Trename if it returns -EOPNOTSPP

I'll play around with the tests and update the commit message a bit later this week.

[JJL772]

After running sudo make check, tests/kern/t31.diod shows a bunch of Trenameat and Tunlinkat calls.