Introduce gauges as new types

[rscheff]

Summary

It is not uncommon to need a counter, that tracks
some initial state for various reasons. Once that task has
been performed, the counter should not overflow, to prevent
a reoccurance of those initial steps.

Currently, very often large data types are used in places
(int32_t, int64_t), and often not much thought has been
giving to effects a possible roll-over could cause.

This new header provides related type definitions and
manipulation macros.

Initial use is expected to be various places in the
tcp layer of the network stack, but a gauge type is
expected to be of universal utility throughout, thus
the prominent placement of this header file.

[tuexen]

The reason I suggested the types was to use functions with these types and allow the compiler to do some tests. So why not have type specific routines? But this is generic stuff and I guess Rodney is much better on this than I am.

[tuexen]

sys/sys/gauges.h

68

Don't you need 1ULL instead of 1? And isn't the type then unsigned long long?

70

Don't you need 1LL instead of 1? And isn't the result then of type long long?

[• hselasky]

This could much more elegantly be implemented using a C++ class! Which would remove the need for the macros:

See for example:
https://github.com/zynaddsubfx/zynaddsubfx/commit/0c54493208d5e61bac82eca6a26f232e544b9995

What about making these Gauges atomic?

[rscheff]

In D24511#539051, @hselasky wrote:

This could much more elegantly be implemented using a C++ class! Which would remove the need for the macros:

See for example:
https://github.com/zynaddsubfx/zynaddsubfx/commit/0c54493208d5e61bac82eca6a26f232e544b9995

The kernel doesn't use C++ in most places, but regular C; also, I don't want to use a typeof() which is gcc specific (I assume there may be other compiler tool chains out there, which get to compile FBSD, where typeof() is not available.

What about making these Gauges atomic?

like "typedef _Atomic(uint8_t) gauge8_t"

[• hselasky]

@rscheff : I was just thinking about using the regular atomic_() functions.

The macros refer the input arguments multiple times, so for example SUBFLOOR() cannot be used with atomics!
The values might have changed between the greater equal and minus.

Why do you need to declare own types for gauge usage? Do they provide any additional protection?

[• hselasky]

It might be better to extend the current atomic_xxx() set of functions with these additions:

atomic_ceil_u32(a,b)
atomic_floor_u32(a,b)
atomic_add_ceil_u32(a,b)
atomic_sub_floor_u32(a,b)

Should all be implemented using the existing atomic_cmpset_32() .

[rpokala]

Please don't submit without a manpage!

[rpokala]

sys/sys/gauges.h

70

Both of these need a comment explaining the magic. Some of it is fairly obvious, like converting the number of bytes returned by sizeof() to bits and then subtracting 1 or 2 for unsigned or signed. But the subsequent -1) * 2) + 1) is not at all obvious.