linux-kernel - Re: [RFC 5/8] x86_64: Add UV specific header for MMR definitions

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:	Tue, 25 Mar 2008 22:02:26 -0500
From:	Jack Steiner <steiner@....com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andi Kleen <andi@...stfloor.org>, mingo@...e.hu,
	tglx@...utronix.de, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 5/8] x86_64: Add UV specific header for MMR definitions

On Tue, Mar 25, 2008 at 08:08:20PM -0400, Christoph Hellwig wrote:
> On Tue, Mar 25, 2008 at 11:04:22AM +0100, Andi Kleen wrote:
> > bitfields are only problematic on portable code, which this isn't.
> 
> it's still crappy to read and a bad example for others.  And last time
> I heard about UV it also included an ia64 version, but that's been
> loooong ago.

I agree that the format of the MMR definitions is not ideal. However,
the alternative of maintaining a 1-off set of MMR definitions is
not very attractive either. The definitions are auto-generated
by hardware design tools and the definitions are used by a number
of tools including diagnostics and BIOS. The definitions are still
changing. I _think_ the registers used by the OS are fairly stable
but there is no guarantee that there won't be additional changes.

The total size of the hardware generated files is over 200000 lines.
We have a tool that extracts the definition of registers used by
the OS. The tools also makes simple easy-to-debug formating
changes such as eliminating screwy type-casts and typedefs.

I would certainly like to keep the auto-generated definitions
and minimize the risk of introducing bugs by incorrectly
generating a one-off set of definitions. The number of files that
will use these definitions is small.

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