[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: UVM typedef struct
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.
Main Index |
Thread Index |