4 ms·
> It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. I would disagree with that assertion:
by estebank 5y ago
> It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide.
I would disagree with that assertion: the kernel is a service that end user applications interact with through an API. Using anyhow in a Rust library that Rust applications use is a very bad idea. Using anyhow in the kernel might be a bad idea, but not for that stated reason.
> Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that.
The uuid crate can be modified to support the kernel infrastructure as its backend. This would allow the same API to be available within the kernel and in the rest of the ecosystem. That's beneficial to everyone involved.
- duckerude 5y ago> the kernel is a service that end user applications interact with through an API. My thinking is that that API has to distinguish between many strictly defined error codes, while anyhow homogenizes errors and focuses on human-readable information. How would you tell whether an anyhow::Error means EINVAL or EFAULT? It's the same fundamental design tradeoff that makes it unsuitable for Rust libraries, even if anyhow wouldn't be visible in the public API. > The uuid crate can be modified to support the kernel infrastructure as its backend Fair enough, using a modified version seems reasonable.