Replaces the outdated (e.g., `ENOIOCTLCMD` is in the
`srctree/include/linux/errno.h` file) and overly specific
description referring to a single C header with a more generic
one.

Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 rust/kernel/error.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/error.rs b/rust/kernel/error.rs
index 3dee3139fcd4..a98dcf88d63e 100644
--- a/rust/kernel/error.rs
+++ b/rust/kernel/error.rs
@@ -2,7 +2,7 @@

 //! Kernel errors.
 //!
-//! C header: [`include/uapi/asm-generic/errno-base.h`](srctree/include/uapi/asm-generic/errno-base.h)
+//! Provides Rust representations of kernel error codes derived from `bindgen` bindings.

 use crate::{
     alloc::{layout::LayoutError, AllocError},
--
2.50.0

On Tue, Jul 29, 2025 at 4:36 PM Onur Özkan <work@onurozkan.dev> wrote:
>
> Replaces the outdated (e.g., `ENOIOCTLCMD` is in the
> `srctree/include/linux/errno.h` file) and overly specific
> description referring to a single C header with a more generic
> one.

Yeah, we should have the other headers there, but I would avoid
removing the links entirely (the links are meant to be there as a
reference and get converted to actual links on render).

Thanks!

Cheers,
Miguel

On Tue, 29 Jul 2025 21:35:06 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Tue, Jul 29, 2025 at 4:36 PM Onur Özkan <work@onurozkan.dev> wrote:
> >
> > Replaces the outdated (e.g., `ENOIOCTLCMD` is in the
> > `srctree/include/linux/errno.h` file) and overly specific
> > description referring to a single C header with a more generic
> > one.
> 
> Yeah, we should have the other headers there, but I would avoid
> removing the links entirely (the links are meant to be there as a
> reference and get converted to actual links on render).
> 
> Thanks!
> 
> Cheers,
> Miguel

I thought with that approach the documentation can become outdated
again at some point, but I can still do it and send over v2 if you
would prefer.

Regards,
Onur

On Wed, Jul 30, 2025 at 12:00 PM Onur Özkan <work@onurozkan.dev> wrote:
>
> I thought with that approach the documentation can become outdated
> again at some point, but I can still do it and send over v2 if you
> would prefer.

That is fine -- documentation is never perfect, but it is all about
the chance of being outdated/wrong vs. the benefits.

In this case, I think the files getting renamed and this line not
getting updated is low (and it would be still clear), and we can
eventually check if the files exist on generation.

Cheers,
Miguel