aix(powerpc64): clean up module by dybucc · Pull Request #5380 · rust-lang/libc

dybucc · 2026-08-06T15:45:50Z

Description

Stems from #5259. Is concerned only with the aix/powerpc64 module. For details
on the changes, see the relevant patch messages.

Checklist

Relevant tests in libc-test/semver have been updated
Commit messages permalink to headers for added or changed API
Placeholder or unstable values like *LAST or *MAX have the standard
doc comment
Tested locally (cargo test -p libc-test --target mytarget);
especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

tgross35

Couple notes but of course we'll need to hear from @xingxue-ibm.

@rustbot label +S-waiting-on-maintainer

View changes since this review

tgross35 · 2026-08-10T03:07:27Z

        pub fo_select: Option<
-            extern "C" fn(file: *mut file, a: c_int, b: *mut c_ushort, c: extern "C" fn()) -> c_int,
+            extern "C" fn(
+                file: *mut file,
+                a: c_int,
+                b: c_ushort,
+                c: *mut c_ushort,
+                c: extern "C" fn(),
+            ) -> c_int,


"aix(powerpc64): deprecate fileops_t type": If you're updating the fields, it would be best to also mark the function pointers unsafe. Also the commit summary should mention there's more than just a deprecation.

Done. I also split that commit into more isolated patches.

tgross35 · 2026-08-10T03:19:12Z

+extern_ty! {
+    /// This is meant to be the `file` type upstream under `sys/ldr.h`. We
+    /// currently expose the kernel definition but that is slated for removal.
+    /// This opaque type will then be renamed to `file`.
+    pub type _file;
+}


This is introduced in "aix(powerpc64): deprecate file type for _file" but used in a previous patch.

I think I'd almost say just replace file with an extern type now, rather than trying to migrate via deprecation. Somebody would have to be doing something really weird to wind up affected by the change, and we have T3 leeway.

xingxue-ibm · 2026-08-10T14:54:15Z

        pub _slockp: *mut lock_data_instrumented,
    }

+    #[deprecated(


The same as struct file. _KERNEL is intended for users implementing kernel extensions rather than the kernel itself.

View changes since the review

xingxue-ibm · 2026-08-10T15:41:36Z


+pub type simple_lock_data = c_int;
+
+extern_ty! {


The definition of struct file is gated by the _KERNEL macro, which is intended for users implementing kernel extensions rather than the kernel itself. The libc crate also includes other items, such as functions gated by _KERNEL, that are used by popular crates. Since we do not rule out the possibility of users writing kernel extensions, and struct file is published in the sys/file.h header, I think it is reasonable to continue using it as is.

View changes since the review

So I guess file continues being exposed as a full type and not an opaque type?
Still, I may be missing something but it seems to me like the declaration in
sys/file.h does not declare a full type.

It's still opaque on the C side of things even when _KERNEL is #defined.

I did remove the deprecations, though. The only exception is
_kernel_simple_lock, for which I have left the _simple_lock type in its
stead.

So I guess file continues being exposed as a full type and not an opaque type?

I think so.

Still, I may be missing something but it seems to me like the declaration in sys/file.h does not declare a full type.
It's still opaque on the C side of things even when _KERNEL is #defined.

Which AIX level is yours? I checked AIX 7.2 and 7.3, the definition in sys/file.h is as follows.

40 #ifdef _KERNEL ... 76 __align(256) struct file { 77 long f_flag; /* see fcntl.h for definitions */ 78 int f_count; /* reference count */ 79 short f_options; /* file flags not passed through vnode layer */ 80 short f_type; /* descriptor type */ 81 82 /* The following fields are overloaded when the file struct is freed, 83 * except for the locks which must remain static. See struct freefile. 84 */ 85 86 struct vnode *f_data; /* pointer to vnode struct */ 87 #define f_vnode f_data 88 89 offset_t f_offset; /* read/write character pointer */ 90 off_t f_dir_off; /* BSD style dir offsets */ 91 struct ucred *f_cred; /* process cred at open */ 92 93 Simple_lock f_lock; /* file structure fields lock */ 94 Simple_lock f_offset_lock; /* file structure offset field lock */ 95 96 caddr_t f_vinfo; /* any info vfs needs */ 97 fileops_t *f_ops; /* operations vector */ 98 99 caddr_t f_parentp; /* the file's parent vnode or fid */ 100 caddr_t f_fnamep; /* fname pointer, may be embedded */ 101 char f_fdata[F_FDATASZ];/* embedded file data, pad to 256 */ 102 }; ...

I did remove the deprecations, though. The only exception is _kernel_simple_lock, for which I have left the _simple_lock type in its stead.

That is fine.

The definition of struct file is gated by the _KERNEL macro, which is intended for users implementing kernel extensions rather than the kernel itself. The libc crate also includes other items, such as functions gated by _KERNEL, that are used by popular crates. Since we do not rule out the possibility of users writing kernel extensions, and struct file is published in the sys/file.h header, I think it is reasonable to continue using it as is.

To clarify, you mean that people are using libc to write kernel extensions? We don't really support that on other arches and have phased it out where anything accidentally got added, I think internal kernel API is out of libc's scope.

An AIX kernel extension is a loadable module that runs within the kernel address space and extends operating system functionality, such as device drivers and communication or I/O subsystems. It can consist of any routine added to the kernel and can be dynamically loaded or unloaded by a privileged user. System calls such as sethostid, sethostname, and gethostname are guarded by _KERNEL in header net/proto_uipc.h.

So I guess file continues being exposed as a full type and not an opaque type?

I think so.

Still, I may be missing something but it seems to me like the declaration in sys/file.h does not declare a full type.
It's still opaque on the C side of things even when _KERNEL is #defined.

Which AIX level is yours? I checked AIX 7.2 and 7.3, the definition in sys/file.h is as follows.

40 #ifdef _KERNEL ... 76 __align(256) struct file { 77 long f_flag; /* see fcntl.h for definitions */ 78 int f_count; /* reference count */ 79 short f_options; /* file flags not passed through vnode layer */ 80 short f_type; /* descriptor type */ 81 82 /* The following fields are overloaded when the file struct is freed, 83 * except for the locks which must remain static. See struct freefile. 84 */ 85 86 struct vnode *f_data; /* pointer to vnode struct */ 87 #define f_vnode f_data 88 89 offset_t f_offset; /* read/write character pointer */ 90 off_t f_dir_off; /* BSD style dir offsets */ 91 struct ucred *f_cred; /* process cred at open */ 92 93 Simple_lock f_lock; /* file structure fields lock */ 94 Simple_lock f_offset_lock; /* file structure offset field lock */ 95 96 caddr_t f_vinfo; /* any info vfs needs */ 97 fileops_t *f_ops; /* operations vector */ 98 99 caddr_t f_parentp; /* the file's parent vnode or fid */ 100 caddr_t f_fnamep; /* fname pointer, may be embedded */ 101 char f_fdata[F_FDATASZ];/* embedded file data, pad to 256 */ 102 }; ...

I did remove the deprecations, though. The only exception is _kernel_simple_lock, for which I have left the _simple_lock type in its stead.

That is fine.

You're right. I double-checked and noticed I had been looking at the
extern declaration further down below. I cross-reference with AIX
7.3.

The patch making file opaque now simply forces the right alignment
requirement.

xingxue-ibm · 2026-08-10T15:42:50Z

        pub fo_fstat: Option<extern "C" fn(file: *mut file, sstat: *mut crate::stat) -> c_int>,
    }

+    #[deprecated(


ditto

View changes since the review

xingxue-ibm · 2026-08-10T16:24:06Z

+                a: c_int,
+                b: c_ushort,
+                c: *mut c_ushort,
+                c: extern "C" fn(),


Suggested change

c: extern "C" fn(),

d: Option<unsafe extern "C" fn()>,

*[View changes since the review](https://triagebot.infra.rust-lang.org/gh-changes-since/rust-lang/libc/5380/74e58cc7294fa594b205a33f8235a2b264455b13..c6f59e4cd1d367b4341e6055b9ad3f0b7bc9f592)*

Tweak padding fields in records where they were public or not using the dedicated `Padding` type. Simplify item paths to use module-level paths instead of crate-relative paths. Rename `pollfd_ext` into using the `typedef`fed identifier instead of the `struct` tag. Rename the anonymous union for `ld_info`'s `_file` field to fit the skipping pattern in the test suite.

Add deprecation attribute to `_kernel_simple_lock` and change uses of it to use the `_simple_lock` type. This type doesn't exist in AIX 7.3 header files.

Change field of `fileops_t` using a function pointer to take one more parameter. AIX 7.3 headers under `sys/file.h` use an additional field.

Add `unsafe` annotations to function pointer fields of `fileops_t`. Make one non-`Option` function pointer passed as an argument to one of the above function pointer fields use an `Option`. This should slightly improve the chances of UB from null function pointers.

Add `repr(align = 256)` to type `file` to fit the upstream definition under `sys/file.h` in an AIX 7.3 machine. This is the version that has been checked against.

rustbot · 2026-08-12T12:08:37Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot added O-powerpc O-unix S-waiting-on-review stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Aug 6, 2026

tgross35 reviewed Aug 10, 2026

View reviewed changes

rustbot added the S-waiting-on-maintainer label Aug 10, 2026

xingxue-ibm reviewed Aug 10, 2026

View reviewed changes

dybucc force-pushed the aix-powerpc64-cleanup branch from c6f59e4 to 588fdee Compare August 11, 2026 06:24

This comment has been minimized.

Sign in to view

dybucc force-pushed the aix-powerpc64-cleanup branch 2 times, most recently from 4660460 to 1a26eeb Compare August 11, 2026 06:41

dybucc added 6 commits August 12, 2026 13:55

aix(powerpc64): deprecate _kernel_simple_lock

6c6fcfa

Add deprecation attribute to `_kernel_simple_lock` and change uses of it to use the `_simple_lock` type. This type doesn't exist in AIX 7.3 header files.

aix(powerpc64): correct fileops_t field

04f5c3e

Change field of `fileops_t` using a function pointer to take one more parameter. AIX 7.3 headers under `sys/file.h` use an additional field.

aix(powerpc64): add align. req. to type file

32c3eba

Add `repr(align = 256)` to type `file` to fit the upstream definition under `sys/file.h` in an AIX 7.3 machine. This is the version that has been checked against.

aix(powerpc64): add system header comments

00d56b2

dybucc force-pushed the aix-powerpc64-cleanup branch from 1a26eeb to 00d56b2 Compare August 12, 2026 12:08

-                c: extern "C" fn(),
+                d: Option<unsafe extern "C" fn()>,
+*[View changes since the review](https://triagebot.infra.rust-lang.org/gh-changes-since/rust-lang/libc/5380/74e58cc7294fa594b205a33f8235a2b264455b13..c6f59e4cd1d367b4341e6055b9ad3f0b7bc9f592)*

Uh oh!

Conversation

dybucc commented Aug 6, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xingxue-ibm Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xingxue-ibm Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xingxue-ibm Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xingxue-ibm Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xingxue-ibm Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dybucc commented Aug 6, 2026 •

edited by rustbot

Loading

tgross35 left a comment •

edited by rustbot

Loading

xingxue-ibm Aug 10, 2026 •

edited by rustbot

Loading

xingxue-ibm Aug 10, 2026 •

edited by rustbot

Loading

xingxue-ibm Aug 11, 2026 •

edited

Loading

xingxue-ibm Aug 10, 2026 •

edited by rustbot

Loading

xingxue-ibm Aug 10, 2026 •

edited by rustbot

Loading