On Fri, Aug 05 2022, Sebastien Marie <[email protected]> wrote: > Hi, > > When initially ported blist from DragonFlyBSD, we used custom type bsblk_t > and > bsbmp_t instead of the one used by DragonFlyBSD (swblk_t and u_swblk_t). > > The reason was swblk_t is already defined on OpenBSD, and was incompatible > with > blist (int32_t). It is defined, but not used (outside some regress file which > seems to be not affected by type change). > > This diff changes the __swblk_t definition in sys/_types.h to be 'unsigned > long', and switch back blist to use swblk_t (and u_swblk_t, even if it isn't > 'unsigned swblk_t'). > > It makes the diff with DragonFlyBSD more thin. I added a comment with the git > id > used for the initial port. > > I tested it on i386 and amd64 (kernel and userland). > > By changing bitmap type from 'u_long' to 'u_swblk_t' ('u_int64_t'), it makes > the > regress the same on 64 and 32bits archs (and it success on both). > > Comments or OK ?
This seems fair, but maybe we should just zap the type from sys/types.h and define it only in sys/blist.h, as done in DragonflyBSD? https://reviews.freebsd.org/D23666 That would make your diff to DragonflyBSD even shorter. :) Also it looks like FreeBSD removed their swblk_t definition in 2020: https://reviews.freebsd.org/D23666 I'm building a release on amd64 with the type removed (also from regress). I don't expect fallout in ports (and I can take care of it if there is any). -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
