[sandywaffles]

I wasn't clear and am not familiar enough with the Linux FS systems to know if this Rust API would be wrapping or re-implementing the C APIs? If it's re-implementing (or rather an additional API) it seems keeping the names the same as the C API would be problematic and lead to more confusion over time, even if initially it helped already-familiar-developers grok whats going on faster.

[CGamesPlay]

> Almeida put up a slide with the equivalent of iget_locked() in Rust, which was called get_or_create_inode().

Seems like the answer is that it's reimplementing and doesn't use the same names.

[swfsql]

I'm not familiar with those functions, but I had the impression they actually shouldn't have the same name.

Since the Rust function has implicit/automatic behavior depending on how it's state is and how it's used by the callsite, and since the C one doesn't have any implicit/automatic behavior (as in, separate/explicit lifecycle calls must be made "manually"), I don't even see the reason for them to have the same name.

That is to say, having the same name would be somehow wrong since the functions do and serve for different stuff.

But it would make sense, at least from the Rust site, to have documentation referring to the original C name.