Re: lib/libufs: build regressed after b366ee486
> dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and Err, the right commit: https://github.com/DankBSD/base/commit/52ff26f21
Re: lib/libufs: build regressed after b366ee486
> It appears that your build environment does not have the b366ee486 version > of /usr/src/sys/ufs/ffs/fs.h installed in /usr/include/ufs/ffs/fs.h. > > That would normally happen after your did a buildworld and installworld. > You should be able to fix your current compile failure by doing: > > cp /usr/src/sys/ufs/ffs/fs.h /usr/include/ufs/ffs/fs.h. > > Let me know if this fails to correct your problem. > > Kirk McKusick Thanks, Kirk. I was bisecting local enironment, and my issue was related due to dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and overriding sys.mk variables in make.conf instead, which led to include bootstrap being skipped for some reason.
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On Fri, 03 Dec 2021 05:54:37 -0800 (PST) "Jeffrey Bouquet" wrote: > > > On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote: > > > On 03/12/2021 12:52, Yetoo Happy wrote: > > > > [...] > > > > > Quick Start* and follow the instructions and get to step > > > 7 and may think that even though etcupdate is different from mergemaster > > > from the last time they used the handbook they have faith that following > > > the instructions won't brick their system. This user will instead find > > > that > > > faith in general is just a very complex facade for the pain and suffering > > > of not following *24.5.6.1 Merging Configuration Files* because the user > > > doesn't know that step exists or relevant to the current step and ends up > > > unknowingly having etcupdate append " yours ... > new" to the top > > > of the user's very important configuration files that they didn't expect > > > the program to actually modify that way when they resolved differences nor > > > could they predict easily because the diff format is so unintuitive and > > > different from mergemaster. Now unable to login or boot into single user > > > mode because redirections instead of the actual configuration is parsed > > > the > > > user goes to the handbook to find out what might have happened and scrolls > > > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. > > > > [...] > > > > That's why I think etcupdate is not so intuitive as tool like this > > should be and etcupdate is extremely dangerous because it intentionally > > breaks syntax of files vital to have system up and running. > > If anything goes wrong with mergemaster automatic process then your have > > configuration not updated which is almost always fine to boot the system > > and fix it. But after etcupdate? Much worse... > > > > I maintain about 30 machines for 2 decades and had problems with > > etcupdate many times. I had ti use mergemaster as fall back many times. > > Mainly because of etcupdate said "Reference tree to diff against > > unavailable" or "No previous tree to compare against, a sane comparison > > is not possible.". And sometimes because etcupdate cannot automatically > > update many files in /etc/rc.d and manual merging of a lot of files with > > " " is realy painful while with mergemaster only simple > > keyboard shortcuts will solve it. > > All of this must be very stressful for beginners. > > > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like , , . > > > > Kind regards > > Miroslav Lachman > > > Agree. I fell back to mergemaster this Nov on 13-stable when the /var files > pertaining to etcupdate were all missing current /etc data, and no study of > man etcupdate was clear enough to rectify such a scenario, and suspect my > initial use of etcupdate will or may require a planned reinstall, not having > had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and > I am just hoping mergemaster stays in /usr/src and updated > for system changes, even if moved to 'tools' or > something, since its use seems intuitive and much less of a black box. > Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) option of etcupdate is now quite harmful. Maybe by any commit done in this april on main (MFC'ed to stable/13 in june). *I got busy manually checking and applying changes to /etc, and forgot to file PR. Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does NOT do anything, hence nothing is actually updated. The only workaround I have is NOT to try dry-run. It would be because the same trees are used for dry-run and actual run. (Not looked into the code. Just a thought.) Maybe using dedicated trees (older one is copied from actual current one, building current tree on dedicated place and delete them every time the dry-run finishes) for dry-run would fix. And copying /etc to some temporary place and applying changes to it, copy back to /etc may be help for your issue, I think. -- Tomoaki AOKI
lib/libufs: build regressed after b366ee486
I was updating from
commit 20aa359773befc8182f6b5dcb5aad7390cab6c26
Author: Dimitry Andric
Date: Sat Nov 13 21:02:29 2021 +0100
Bump __FreeBSD_version for llvm-project 13.0.0 merge
PR: 258209
MFC after: 2 weeks
to
commit b366ee4868bca2b3ebe4bb29c9590a29b6cecc29 (main)
Author: Kirk McKusick
Date: Sun Nov 14 22:09:06 2021 -0800
Consolodate four copies of the STDSB define into a single place.
The STDSB macro is passed to the ffs_sbget() routine to fetch a
UFS/FFS superblock "from the stadard place". It was identically defined
in lib/libufs/libufs.h, stand/libsa/ufs.c, sys/ufs/ffs/ffs_extern.h,
and sys/ufs/ffs/ffs_subr.c. Delete it from these four files and
define it instead in sys/ufs/ffs/fs.h. All existing uses of this macro
already include sys/ufs/ffs/fs.h so no include changes need to be made.
No functional change intended.
Sponsored by: Netflix
$ cd lib/libufs
$ make
[...]
/usr/local/llvm13/bin/clang -O2 -pipe -fno-common -D_LIBUFS
-I/usr/src/lib/libufs -g -gz=zlib -MD -MF.depend.sblock.o -MTsblock.o
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch
-Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments-c sblock.c
-o sblock.o
sblock.c:59:38: error: use of undeclared identifier 'STDSB'
if ((errno = sbget(disk->d_fd, , STDSB)) != 0) {
^
1 error generated.
*** Error code 1
Stop.
make: stopped in /usr/src/lib/libufs
[...]
My environment is custom (hard to bisect at the moment), but the most
major local modification to base that I have is devel/llvm13 as toolchain.
make.conf:
LLVM=/usr/local/llvm13/bin
ADDR2LINE=${LLVM}/llvm-addr2line
AR=${LLVM}/llvm-ar
AS=${LLVM}/llvm-as
CC=${LLVM}/clang
CPP=${LLVM}/clang-cpp
CPPFILT=${LLVM}/llvm-cxxfilt
CXX=${LLVM}/clang++
DTRACEFLAGS+=-x cpppath=${CPP} -x ldpath=${LD}
LD=${LLVM}/ld
LLVM_LINK=${LLVM}/llvm-link
NM=${LLVM}/llvm-nm
OBJC=${LLVM}/clang
OBJCOPY=${LLVM}/llvm-objcopy
OBJDUMP=${LLVM}/llvm-objdump
RANLIB=${LLVM}/llvm-ranlib
READELF=${LLVM}/llvm-readelf
SIZE=${LLVM}/llvm-size
STRINGS=${LLVM}/llvm-strings
STRIPBIN=${LLVM}/llvm-strip
STRIP_CMD=${STRIPBIN}
src.conf:
WITHOUT_CLANG=yes
WITHOUT_CLANG_BOOTSTRAP=yes
# elftoolchain utils manually deleted, todo: have a knob to turn off build
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=yes
WITHOUT_LLD=yes
WITHOUT_LLDB=yes
WITHOUT_LLD_BOOTSTRAP=yes
WITHOUT_LLVM_COV=yes
Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ?????
On 2021-Dec-3, at 07:58, Mark Johnston wrote: > On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm wrote: >> For: >> >> uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 >> main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 >> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1400042 1400042 >> >> building a variant of itself (producing a debug build instead of a >> non-debug), it generated a bunch of messages of the form: >> >> ctfconvert: failed to get mapping for tid ? >> >> in the buildkernel part of the build. > > Can you share the kernel configuration GENERIC-NODBG-CA72? > Sure. The environment doing the building was built using: # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72 include "GENERIC-NODBG" ident GENERIC-NODBG-CA72 makeoptions CONF_CFLAGS="-mcpu=cortex-a72" and . . . # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #optionsKDB_TRACE # Print a stack trace for a panic options DDB # Enable the kernel debugger # Extra stuff: #optionsVERBOSE_SYSINIT=0 # Enable verbose sysinit messages #optionsBOOTVERBOSE=1 #optionsBOOTHOWTO=RB_VERBOSE #optionsKTR #optionsKTR_MASK=KTR_TRAP ##options KTR_CPUMASK=0xF #optionsKTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING As for the variant being built: # more /usr/main-src/sys/arm64/conf/GENERIC-DBG-CA72 include "GENERIC-DBG" ident GENERIC-DBG-CA72 makeoptions CONF_CFLAGS="-mcpu=cortex-a72" # more /usr/main-src/sys/arm64/conf/GENERIC-DBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-DBG makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a panic options DDB # Enable the kernel debugger # Extra stuff: #optionsVERBOSE_SYSINIT=0 # Enable verbose sysinit messages #optionsBOOTVERBOSE=1 #optionsBOOTHOWTO=RB_VERBOSE #optionsKTR #optionsKTR_MASK=KTR_TRAP|KTR_PROC ##options KTR_CPUMASK=0xF #optionsKTR_VERBOSE # Enable any extra checking for. . . options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed nooptions DIAGNOSTIC options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ?????
On Mon, Nov 29, 2021 at 06:45:19PM -0800, Mark Millard via freebsd-arm wrote: > For: > > uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 > main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400042 1400042 > > building a variant of itself (producing a debug build instead of a > non-debug), it generated a bunch of messages of the form: > > ctfconvert: failed to get mapping for tid ? > > in the buildkernel part of the build. Can you share the kernel configuration GENERIC-NODBG-CA72?
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote: > On 03/12/2021 12:52, Yetoo Happy wrote: > > [...] > > > Quick Start* and follow the instructions and get to step > > 7 and may think that even though etcupdate is different from mergemaster > > from the last time they used the handbook they have faith that following > > the instructions won't brick their system. This user will instead find that > > faith in general is just a very complex facade for the pain and suffering > > of not following *24.5.6.1 Merging Configuration Files* because the user > > doesn't know that step exists or relevant to the current step and ends up > > unknowingly having etcupdate append " yours ... > new" to the top > > of the user's very important configuration files that they didn't expect > > the program to actually modify that way when they resolved differences nor > > could they predict easily because the diff format is so unintuitive and > > different from mergemaster. Now unable to login or boot into single user > > mode because redirections instead of the actual configuration is parsed the > > user goes to the handbook to find out what might have happened and scrolls > > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. > > [...] > > That's why I think etcupdate is not so intuitive as tool like this > should be and etcupdate is extremely dangerous because it intentionally > breaks syntax of files vital to have system up and running. > If anything goes wrong with mergemaster automatic process then your have > configuration not updated which is almost always fine to boot the system > and fix it. But after etcupdate? Much worse... > > I maintain about 30 machines for 2 decades and had problems with > etcupdate many times. I had ti use mergemaster as fall back many times. > Mainly because of etcupdate said "Reference tree to diff against > unavailable" or "No previous tree to compare against, a sane comparison > is not possible.". And sometimes because etcupdate cannot automatically > update many files in /etc/rc.d and manual merging of a lot of files with > " " is realy painful while with mergemaster only simple > keyboard shortcuts will solve it. > All of this must be very stressful for beginners. > > So beside the update of documentation I really would like to see some > changes to etcupdate workflow where files are modified in temporary > location and moved to destination only if they do not contain any syntax > breaking changes like , , . > > Kind regards > Miroslav Lachman Agree. I fell back to mergemaster this Nov on 13-stable when the /var files pertaining to etcupdate were all missing current /etc data, and no study of man etcupdate was clear enough to rectify such a scenario, and suspect my initial use of etcupdate will or may require a planned reinstall, not having had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and I am just hoping mergemaster stays in /usr/src and updated for system changes, even if moved to 'tools' or something, since its use seems intuitive and much less of a black box. Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still.
Re: [REVIEW] Hide BIT_* macros from userland code
On Fri, Dec 03, 2021 at 11:03:54AM +0100, Stefan Esser wrote: > Am 02.12.21 um 17:46 schrieb Shawn Webb: > > Hey Stefan, > > > > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > >> I have created > >> > >>https://reviews.freebsd.org/D33235 > >> > >> to remove the BIT_* macros used in the kernel from the userland API. > >> > >> They conflict with differing definitions in some 3rd party code and > >> lead to compile issues in a number of ports (via CPU_* macros based > >> on the BIT_* macros). > >> > >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787 > >> for an example of such a problem. > > > > I recently was in a position to evaluate BIT_* macros for userland > > use. It was around the time when the conversation regarding hiding > > BIT_* from userland, which conversation caused me to find another > > solution. > > > > I think such an API is incredibly useful, so I wonder if there's a way > > to satisfy both. For example, maybe prefix the userland side with a > > USERLAND_ or something similar? Kernel would use BIT_* and userland > > would use USERLAND_BIT_* (just spitballing, not actually advocating > > for "USERLAND_BIT_*" but rather just the idea of it.) > > Hi Shawn, > > I have updated the patch set in review D33235 and have added you to > the reviewer list. > > IMHO the approach proposed by Konstantin Belousov is better than the > introduction of prefixed macro names for the userland. > > A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available > by their traditional names, no other changes are required in the code. > > This does not solve the potential case of a program that wants to use > both the BSD and GLIBC variants of the macros in a single source file. > But I think that such a case is constructed and does not occur in > actual code. > > And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* > names you suggest (and I understand that you did not want that specific > name - therefore a prefix of __ might be considered to match what you > proposed ;-) ). > > And you are of course free to map __BIT* to any other prefixed name in > a header file in your code ... > > An update of the bitset(9) man page might be a good idea, explaining > the visibility rules and _WANT_FREEBSD_BITSET for system utilities that > need to work with kernel style bitsets. Awesome. kib's suggestion makes sense here. And thanks for adding me to the review. I'll make sure to pay attention as it progresses. :-) Thanks again, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On 03/12/2021 12:52, Yetoo Happy wrote: [...] Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append " yours ... > new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. [...] That's why I think etcupdate is not so intuitive as tool like this should be and etcupdate is extremely dangerous because it intentionally breaks syntax of files vital to have system up and running. If anything goes wrong with mergemaster automatic process then your have configuration not updated which is almost always fine to boot the system and fix it. But after etcupdate? Much worse... I maintain about 30 machines for 2 decades and had problems with etcupdate many times. I had ti use mergemaster as fall back many times. Mainly because of etcupdate said "Reference tree to diff against unavailable" or "No previous tree to compare against, a sane comparison is not possible.". And sometimes because etcupdate cannot automatically update many files in /etc/rc.d and manual merging of a lot of files with " " is realy painful while with mergemaster only simple keyboard shortcuts will solve it. All of this must be very stressful for beginners. So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like , , . Kind regards Miroslav Lachman
Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that at* 24.5.6.1 Merging Configuration Files* are instructions to bootstrap etcupdate if switching from mergemaster. This is really convenient and really useful, *EXCEPT* for that fact that it is placed in a part of the handbook a little ways after installation would complete. The critical issue here being that, due to this information not being higher up, a user who is looking at the handbook to update from source and are trusting the handbook because they have faith that it won't play any dirty tricks on them, because all the documentation and all the user groups speak so highly of the handbook being complete and thorough and authoritative, are just going to* 24.5.1. Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append " yours ... > new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. Completing the Update*. What a mocking section? Completing the update? How could I have completed the update if I was on Step 7 of Quick Steps? The user now may feel cheated, jaded, or insulted and wonder what the fuss is all about with this hyped documentation. Here's a solution: Make a red warning notice at the very top of *24.5.1. Quick Start* and refer to *24.5.6.1 Merging Configuration Files *and make clear this is for step 7. Another solution is, if possible, put that red warning notice next to step 7 or step 7 in the grey section or red/pink section of the quick start box area, I personally would prefer a warning with text right next to step 7 in the red/pink part of the quick start box, but I'm not sure if that's possible or respecting the documentation design paradigm. The next best option is a warning at the top because it reduces the chance of a user following instructions and missing that step because they haven't scrolled to that point yet. I'm sorry if this comes across as an angry potentially combative message, but I just wanted to make clear where and what the problem is and my frustration with this problem.
Re: [REVIEW] Hide BIT_* macros from userland code
Am 02.12.21 um 17:46 schrieb Shawn Webb: > Hey Stefan, > > On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: >> I have created >> >> https://reviews.freebsd.org/D33235 >> >> to remove the BIT_* macros used in the kernel from the userland API. >> >> They conflict with differing definitions in some 3rd party code and >> lead to compile issues in a number of ports (via CPU_* macros based >> on the BIT_* macros). >> >> See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259787 >> for an example of such a problem. > > I recently was in a position to evaluate BIT_* macros for userland > use. It was around the time when the conversation regarding hiding > BIT_* from userland, which conversation caused me to find another > solution. > > I think such an API is incredibly useful, so I wonder if there's a way > to satisfy both. For example, maybe prefix the userland side with a > USERLAND_ or something similar? Kernel would use BIT_* and userland > would use USERLAND_BIT_* (just spitballing, not actually advocating > for "USERLAND_BIT_*" but rather just the idea of it.) Hi Shawn, I have updated the patch set in review D33235 and have added you to the reviewer list. IMHO the approach proposed by Konstantin Belousov is better than the introduction of prefixed macro names for the userland. A simple #define _WANT_FREEBSD_BITSET makes the __BIT* macros available by their traditional names, no other changes are required in the code. This does not solve the potential case of a program that wants to use both the BSD and GLIBC variants of the macros in a single source file. But I think that such a case is constructed and does not occur in actual code. And in any case, the IMHO __BIT* names are as good as the USERLAND_BIT* names you suggest (and I understand that you did not want that specific name - therefore a prefix of __ might be considered to match what you proposed ;-) ). And you are of course free to map __BIT* to any other prefixed name in a header file in your code ... An update of the bitset(9) man page might be a good idea, explaining the visibility rules and _WANT_FREEBSD_BITSET for system utilities that need to work with kernel style bitsets. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
