CTLTYPE_UINT?

[Justin Cormack]

Back in the sysctl discussion a while back, core group said:

http://mail-index.netbsd.org/tech-kern/2014/03/26/msg016779.html

a) What types are needed? Currently, CTLTYPE_INT is a signed
32-bit type, and CTLTYPE_QUAD is an unsigned 64-bit type.
Perhaps all four possible combinations of signed/unsigned and
32 bits/64 bits should be supported.

I noticed today that there are some cases where a CTLTYPE_INT is being
fed a uint32_t, for example in sys/netinet6/ip6_input.c this is the
case for ip6_temp_preferred_lifetime and similar values that are
uint32_t.

It seems to make sense to add a CTLTYPE_UINT for these types, although
there are other options. FreeBSD introduced them way back. We could
continue to ignore the signedness differences though...

Thoughts?

Justin

[Alan Barrett]

Post by Justin Cormack
http://mail-index.netbsd.org/tech-kern/2014/03/26/msg016779.html
a) What types are needed? Currently, CTLTYPE_INT is a signed
32-bit type, and CTLTYPE_QUAD is an unsigned 64-bit type.
Perhaps all four possible combinations of signed/unsigned and
32 bits/64 bits should be supported.

If you add new sysctl types, please use names that describe
the size and signedness. For example, rename CTLTYPE_INT to
CTLTPE_INT32, keep CTLTYPE_INT as a backward compatible alias
for CTLTYPE_INT32, and add CTLTYPE_UINT32. Similarly, rename
CTLTYPE_QUAD to CTLTYPE_UINT64, keep CTLTYPE_QUAD as an alias,
and add CTLTYPE_INT64. Please don't add a CTLTYPE_UINT with no
indication of its size.

A survey of what other OSes do would also be useful.

--apb (Alan Barrett)

[Justin Cormack]

Post by Justin Cormack
http://mail-index.netbsd.org/tech-kern/2014/03/26/msg016779.html
a) What types are needed? Currently, CTLTYPE_INT is a signed
32-bit type, and CTLTYPE_QUAD is an unsigned 64-bit type.
Perhaps all four possible combinations of signed/unsigned and
32 bits/64 bits should be supported.

If you add new sysctl types, please use names that describe the size and
signedness. For example, rename CTLTYPE_INT to CTLTPE_INT32, keep
CTLTYPE_INT as a backward compatible alias for CTLTYPE_INT32, and add
CTLTYPE_UINT32. Similarly, rename CTLTYPE_QUAD to CTLTYPE_UINT64, keep
CTLTYPE_QUAD as an alias, and add CTLTYPE_INT64. Please don't add a
CTLTYPE_UINT with no indication of its size.
A survey of what other OSes do would also be useful.

Freebsd (and Dragonfly):
CTLTYPE_NODE This is a node intended to be a parent for other nodes.
CTLTYPE_INT This is a signed integer.
CTLTYPE_STRING This is a nul-terminated string
CTLTYPE_S64 This is a 64-bit signed integer.
CTLTYPE_OPAQUE This is an opaque data structure.
CTLTYPE_STRUCT Alias for CTLTYPE_OPAQUE.
CTLTYPE_UINT This is an unsigned integer.
CTLTYPE_LONG This is a signed long.
CTLTYPE_ULONG This is an unsigned long.
CTLTYPE_U64 This is a 64-bit unsigned integer.

OpenBSD has the same types as NetBSD, ie CTLTYPE_INT and CTLTYPE_QUAD
as the int32 and uint64 types.

I agree about being explicit with the 32 bitness, but using S64 and
U64 as the 64 bit names to be consistent with FreeBSD might make
sense. long types seems best avoided if possible, you can see the
temptation to use them for memory amounts, but you could be running on
32 bit userspace on a 64 bit kernel.

Justin

[matthew green]

i think having various different types (that often alias to other
types, depending on the platform) is the right thing.

we have data represented in signed/unsigned int/long/32/64 bit,
and i think the only really safe way to do that is to provide the
explicit types used. ie, give me a type-specific name as the
base definition, and provide aliases as necessary.

supporting the fbsd/dfbsd names as aliases for compat seems like
a reasonable idea, as well.


.mrg.

[Alan Barrett]

Post by Justin Cormack
I agree about being explicit with the 32 bitness, but using S64
and U64 as the 64 bit names to be consistent with FreeBSD might
make sense.

The S64 and U64 names are fine. I'd also add S32 and U32.

Post by Justin Cormack
long types seems best avoided if possible, you can see the
temptation to use them for memory amounts, but you could be
running on 32 bit userspace on a 64 bit kernel.

One of the reasons that I like user/kernel interfaces to use
types with explicit bit width is to simplify running 32-bit
userland on 64-bit kernels. If you use a type whose actual size
changes between 32 bits and 64 bits, then the kernel has to have
a compatibility layer to copy and adjust the data, and tools like
kdump or ktruss should also translate (it's a bug that they don't
do so today). If you use a type that's always 64 bits, then it's
much easier to deal with. Occasionally, an argument for run-time
efficiency in a 32-bit userland will outweigh this argument for
ease of coding, and then a type whose size changes should be
used.

--apb (Alan Barrett)