Re: UVM typedef struct

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Jun 16 2009 at 10:19:06 +0100, Mindaugas Rasiukevicius wrote:
> Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> > On Mon Jun 15 2009 at 20:09:56 +0100, Mindaugas Rasiukevicius wrote:
> > > I would like to typedef and replace the struct usage in UVM, so that
> > > struct vm_map would become vm_map_t, struct vm_anon - vm_anon_t, and so
> > > on. <...>
> 
> Just to make this clear, I do not want to typedef structs as pointers.
> I agree that it is confusing (although it has a good rationale for some
> cases, eg. when structure size is dynamic).

The underlying problem is that I do not see any benefit from arbitrary
typedefs such as struct x -> x_t.  Will we get u32_t next?

> > 1) obfuscates code.  there is no reason to tell if silly_t is an int,
> >    struct or pointer to something just by looking at the type
> 
> I am not sure what do you mean. Each typedef, eg. vm_page_t would be a
> structure, where vm_page_t * a pointer to it. No intention to typedef
> non-structures in UVM.

There are plenty of places in the kernel where _t is a pointer.  How are
you supposed to distinguish between them?  More specifically to this case,
when vm_page_t existed in NetBSD with the Mach vm, it was a pointer.

And, actually, opaque foo_t struct pointer is the only place where I
would agree that _t makes some sense for a struct.  However ...

> > 2) impossible to provide forward declarations for interfaces using
> >    silly_t
> 
> Why not? Note that struct declarations wont be removed (cf. struct lwp
> and lwp_t).

... see mrg's mail in this thread.