Re: UVM typedef struct

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

[seebs, replying to dholland]
>> That is not a benefit.
> It can be.

Not quite.  Rather, it can lead to a benefit.

> In particular, it encourages you to use the API, rather than trying
> to outsmart it.

Yes.  But that benefit can be obtained in other, arguably, better ways.
In particular, incomplete structs enforce API use, without hiding what
is and isn't a pointer (which is the thing I most dislike about the _t
paradigm as outlined upthread).

To pick on sys/proc.h as a possibly-inappropriate example, this
paradigm has sys/proc.h containing

struct proc;
...API declarations...

and then something else - perhaps a .c file if there's just one, or if
not then sys/proc-impl.h or some such - includes sys/proc.h and adds

struct proc {
        ...details, private to the implementation...
};

But this depends on having a well-defined API in the first place, and
that is something that is woefully lacking in most of the kernel.  I'd
put effort into creating well-defined APIs at all before worrying about
how to encourage/enforce use of them.  (Actually, it's not quite that
bad; there are some moderately well-defined APIs in the kernel, such as
the whole bus-space infrastructure.  But there are a lot of cases,
mostly historical from what I've seen, where the "API" is ill-defined
and consists of a struct which is exposed to a whole lot of code.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B