linux-kernel - Re: [Question] x86,APIC: In apicdef.h dfr,svr,...... shouldn't be const?

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: <20090901194154.GB19964@lenovo>
Date:	Tue, 1 Sep 2009 23:41:54 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Rakib Mullick <rakib.mullick@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
	Ingo Molnar <mingo@...e.hu>, Yinghai Lu <yinghai@...nel.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [Question] x86,APIC: In apicdef.h dfr,svr,...... shouldn't be
	const?

[Cyrill Gorcunov - Tue, Sep 01, 2009 at 12:43:06PM +0400]
| On 9/1/09, Rakib Mullick <rakib.mullick@...il.com> wrote:
| > Hello guys, Intel System programmers guide says - dfr, svr, esr - this
| > registers should be readonly. So shouldn't they use const? Or is it
| > anything else?
| 
| Hi Rakib, i dont have sources under my hands at moment, but iirc there
| were situations we nees to poke esr register.
| 
| >
| > And apicdef.h also contains a style problem, checkpatch warns about
| > following style:
| >
| >               u32	spurious_vector	:  8
| >
| > Check patch wants as:
| >
| >                          u32	spurious_vector:8
| >
| > Shouldn't this issues be fixed?
| >
| > Thanks,
| > --
| 
| i dont see reason why not ;)
| though i wonder why we need this structure at all. We may have
| extended amd entries.
| Yinghai cced.
| 

Ingo, Yinghai, Suresh,

is there any particular reason we keep apicdef.h:struct local_apic at all?

Was there some plan on this structure usage in future? If take into
account amd extended registers this structure doesn't cover all
possible cases. And at moment we do poke apic registers via APIC_
macros mostly and it seems that is the more convenient
and flexible approach. The only thing I may imagine where we
could (possibly) use it in future is suspend/resume cases.

But perhaps I miss something?

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