tech-kern archive

[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:06AM +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).

I'm not convinced, but that's a different argument :-)

 > > 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.

Historically, *_t types are primitive types, which means essentially
integers. Some exceptions that currently exist (e.g. in the pthreads
API and some inappropriate typedefs of pointers in the kernel) are
bugs.

Historically also structures are always used as "struct foo"; but
preserving this convention is not as important as not treading on
other related conventions.

So, if we want to do this, which I don't have a strong opinion about,
can we use some naming convention other than _t?

My suggestion would be to just do

   typedef struct vm_page vm_page;

and leave it at that.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index