[DTrace-devel] [PATCH 2/7] types: populate intrinsics from the kernel if possible

[Nick Alcock]

On 17 May 2023, Nick Alcock uttered the following:

> On 15 May 2023, Kris Van Hees verbalised:
>
>> How does this patch fit in the way the type system for D is described in the
>> DTrace guide:
>
> Describing the type system for D in this much detail was, frankly, a
> mistake (well, it wasn't in the Solaris days, because the Solaris people
> controlled the kernel and platform and could make sure the two always
> matched, but we don't and never will be able to: can you imagine us
> saying to the kernel people that they must change back from using
> unsigned char because we have a hardwired list of types in our tracer
> that they must conform to? They'd laugh at us, and rightly so).
>
> The type system for D is always, necessarily, the type system of the
> underlying kernel: if it's not, you've got a DTrace in which you can't
> *use* any types from the kernel, and D is useless (see below). That type
> system is not a constant and can change at the whim of kernel developers
> and platform ABIs. We should never have hardwired it -- or, rather, we
> could certainly hardwire new types, but not types that the kernel
> already knows by the same names.

Thinking about this some more, we can certainly use the hardwired list
to do some *validation* of the kernel types we copy in. The D type
system is unlikely to work if the kernel types are too different, e.g.
if char is somehow a pointer or something :) this seems most unlikely
but is an easy assertion: we just refuse to start if the type kind of
named types in the kernel differs from the kind of the same type in the
hardwired list. That way, we adjust to boring minor compatibility-
breaking changes (like, say, the signedness of char or other minor
encoding alterations) without allowing the kernel to make changes so
severe that D isn't going to look like D any more. (You'd probably see
errors shortly afterwards from the translators refusing to compile
anyway, which is just what we see from the unsigned char mess, but at
least you'd get a more comprehensible error.)