> On Fri, Feb 14, 2025 at 11:59:33AM +0100, Havard Eidnes wrote: >> Now, backing off that for a bit, and returning to the original >> question, the "90" suffix used with statvfs*() appears to me to >> indicate that this rename was done in the era leading up to the >> NetBSD 9.0 release. Since we do not support any older release than >> 9.0 (and barely that...) with rust, we should perhaps take steps to >> adopt the new ABI instead. This means the struct above needs to be >> amended/extended and we need to ensure that we call the right >> version of the libc function. > > No, it means that the symbol is the version from NetBSD 9 - the change > to the extended struct statvfs was done between NetBSD 9 and 10.
Ah, OK. So .. getmntinfo() had already gone through one symbol renaming cycle. The netbsd-9-0-RELEASE version of sys/sys/statvfs.h header has this "cvs annotate" output: 1.1 (christos 21-Apr-04): #ifndef __LIBC12_SOURCE__ 1.7 (christos 13-Sep-05): int getmntinfo(struct statvfs **, int) __RENAME(__getmntinfo13); 1.1 (christos 21-Apr-04): #endif /* __LIBC12_SOURCE__ */ So to me it looks like the rename to __getmntinfo13() is already present in the 9.0 release, so retaining the 9.0 definiton of the struct matches up with using __getmntinfo13(). >> [...] and then we need to get the rust folks to adopt >> the modification, so that we eventually down the road can stop >> maintaining that as a diff in our package. > > On it! At least for the getmntinfo fix: > > https://github.com/rust-lang/libc/pull/4265 Excellent! Looking at getvfsstat(), it doesn't look like it's versioned in 9.2; the statvfs.h header has just int getvfsstat(struct statvfs *, size_t, int); whereas in -current it is int getvfsstat(struct statvfs *, size_t, int) __RENAME(__getvfsstat90); So ... it actually doesn't need a similar treatment, as long as with stick with the 9.0 ABI? Regards, - Håvard
