linux-kernel - Re: [Patch 04/18] include/linux/logfs.h

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]

Message-ID: <4665C9FA.5060207@tmr.com>
Date:	Tue, 05 Jun 2007 16:39:22 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Segher Boessenkool <segher@...nel.crashing.org>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Kyle Moffett <mrmacman_g4@....com>,
	John Stoffel <john@...ffel.org>, Willy Tarreau <w@....eu>,
	Evgeniy Polyakov <johnpol@....mipt.ru>, CaT <cat@....com.au>,
	Ondrej Zajicek <santiago@...reenet.org>,
	linux-kernel@...r.kernel.org,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dongjun Shin <djshin90@...il.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Arnd Bergmann <arnd@...db.de>,
	Albert Cahalan <acahalan@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	Artem Bityutskiy <dedekind@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>,
	Jamie Lokier <jamie@...reable.org>,
	Roland Dreier <rdreier@...co.com>,
	Jörn Engel <joern@...ybastard.org>,
	Pavel Machek <pavel@....cz>,
	Ulisses Furquim <ulissesf@...il.com>, akpm@...l.org,
	David Weinehall <tao@....umu.se>
Subject: Re: [Patch 04/18] include/linux/logfs.h

Segher Boessenkool wrote:
>> It would be better if GCC had a 'nopadding' attribute which gave us what
>> we need without the _extra_ implications about alignment.
>
> That's impossible; removing the padding from a struct
> _will_ make accesses to its members unaligned (think
> about arrays of that struct).
And many platforms happily support unaligned CPU access in hardware at a 
price in performance, while other support it in software at great cost 
in performance. None of that maps into impossible, Some i/o hardware may 
not support at all and require some bounce buffering, at cost in memory 
and CPU.

None of that equates with impossible. It is readily argued that it could 
mean inadvisable on some architectures, slow as government assistance 
and ugly as the north end of a south-bound hedgehog, but it's not 
impossible.

Do NOT take this to mean I think it would be a good thing in a Linux 
kernel, or that it should be added to gcc, but in some use like embedded 
applications where memory use is an important cost driver, people are 
probably doing it already by hand to pack struct arrays into minimal 
bytes. It's neither impossible nor totally useless.

-- 
bill davidsen <davidsen@....com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

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