lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Jan 2011 18:55:16 -0800
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, torvalds@...ux-foundation.org,
	San Mehat <san@...gle.com>, Aaron Durbin <adurbin@...gle.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>
Subject: Re: [PATCH v1 3/6] driver: Google EFI SMI

On Thu, Jan 27, 2011 at 11:22:55AM -0800, Mike Waychison wrote:
> On Thu, Jan 27, 2011 at 2:43 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> >> I understand that type widths change in a compat setting.  So what?
> >> Code in each environment is written to it's own namespace anyhow.
> >
> > So you ned up with a pile of extra crap in the kernel to handle 32bit
> > userspace on 64bit and the like. If instead the structs are carefully
> > laid out this doesn't occur.
> >
> >> Here's what *I* think *you* think about __u32 vs u32 vs uint32_t.
> >> Correct me if I'm totally off-base here:
> >
> > And the __aligned_ ones for things like u64 in ioctls and structs...
> >
> > It's also a style and consistency thing, its trivialto use the same style
> > as the rest of the kernel, it's trivial to tweak and it helps keep
> > coherency of style, even if you are sitting at the keyboard mumbling
> > "bunch of morons if you ask me" while doing it ;)
> 
> I'm always mumbling and cursing at my desk :p
> 
> I've already changed the series to not use C99 types.  I understand
> the value in style consistency :)
> 
> I'm still trying to understand if there is any actual technical merit
> to avoid standard types though, of which there doesn't seem to be any.

Yes there is, it is subtle and prone to get wrong.  Linus wrote it all
up in detail a few years ago and I was going to document it in the
kernel tree somewhere but got busy.

You can dig through the lkml archives for the details but basically
always remember to use them in the following manner:
	u32 - in kernel usage
	__u32 - when the data crosses the kernel/user boundry
	uint32_t - never use

that will ensure you get your code right and no one will complain.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ