svn commit: r347484 - head/sys/kern

Bruce Evans brde at optusnet.com.au
Sun May 12 11:45:21 UTC 2019


On Sat, 11 May 2019, Doug Moore wrote:

> On 5/11/19 5:52 AM, Bruce Evans wrote:
>> On Sat, 11 May 2019, Doug Moore wrote:
>>> +#ifdef HAVE_INLINE_FFS
>>> +    case sizeof(int):
>>> +        return (ffs(mask) - 1);
>>> +#endif
>>
>> This is unreachable, since sizeof(int) is 4 on all supported arches, and
>> sizeof(mask) is 8 on all arches.
>>
> Another FreeBSD developer has expressed to me that sizeof(mask) ought to
> become 4 on some 32-bit arches before too long, and I added this case in
> anticipation of that.  I see now that I should have waited.

I also don't like the use of unsigned long for __fd_mask and bitstr_t.
This asks for a a pessimal type that is twice as wide as a machine
register, but is not so pessimal in practice since longs are rarely
implemented correctly except on systems with 16-bit machine registers.

The mask type u_daddr_t is both logically wrong (masks have nothing to
do with daddr_t's) and gives a pessimal bitstring type more often in
practice:
- in FreeBSD-4, [u_]daddr_t was 32 bits, so misusing it for bitstrings
   was pessimal on 64-bit arches
- expanding [u_]daddr_t to 64 bits in FreeBSD-5 (r96572-96851 only 17
   years ago) made it pessimal for bitstrings on 32-bit arches.

The pessimization would be smaller if ffs64() exists and is inlined to
32-bit ffs()'s.

Using the long long abomination asks for double the pessimizations and
machine dependencies as using long.  In practice, expanding long long
to larger than 64 bits would break ABIs so it is not much worse than
a spelling error for int64_t.

Bruce


More information about the svn-src-all mailing list