linux-kernel - Re: linux-next: kbuild tree build failure

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>] [day] [month] [year] [list]

Date:	Mon, 14 Jul 2008 11:53:44 -0500
From:	Milton Miller <miltonm@....com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	ppcdev <linuxppc-dev@...abs.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Michael Ellerman <michael@...erman.id.au>,
	Paul Mackerras <paulus@...ba.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: linux-next: kbuild tree build failure

Hi Roman.

I saw your reply on the list archives but can not find
it in my inbox.

On Sun Jul 13 at 09:21:08 EST 2008, Roman Zippel wrote:
> On Sat, 12 Jul 2008, Milton Miller wrote:
>
>> (1) #define PAGE_OFFSET    (ASM_CONST(CONFIG_PAGE_OFFSET) << 32)
>>
>> It creates unreadable code, where two defines with almost the same
> name (the
>> only difference being
>> the CONFIG_ prefix, which is often ignored when scanning) contains
> radically
>> different values.
>>
>> (2)  #define PAGE_OFFSET    ASM_CONST(CONFIG_PAGE_OFFSET)
>
> Giving it different names is not really difficult. Any objections to
> CONFIG_PAGE_HIGH_OFFSET?

Once you remove the symmetry and add the ifdef to page.h, we need to
reevaluate its presence in Kconfig.   I can't think of a reason to
have a partial value, and therefore would instead say take out the
config variable on PPC64 as the PPC32 address split reason is moot.

>
>> On a seperate note,
>>>>>>  config PINT3_ASSIGN
>>>>>>         hex "PINT3_ASSIGN"
>>>>>>         depends on PINTx_REASSIGN
>>>>>> -       default 0x02020303
>>>>>> +       default 0x2020303
>>
>> is harder to read.   The value is a list of 4 1 byte values, but you
>> have hidden the first nibble making parsing the rest of the value 
>> hard.
>
> Sam mentioned that already, but that's a situation where the warning 
> can
> be relaxed.

The warning can be relaxed?   What are you talking about?

I was trying to make a case for leading zeros without actually stating
what I was asking for.

You changes did s/(0x)?0*/0x/, y/A-F/a-f/ -- that is you made all hex
constants conform to "0x%x".   I was arguing for 0x%8.8x, or just 
leaving
them as formatted.

>
>> If you are worried about users tring to set values that are too high,
>> then make the types be hex8, hex16, hex32, and hex64.
>
> It's not this, I value consistency as much as you and the values are
> sometimes used as integers, so a working range is needed. Using simple
> integers keeps things much simpler and as the ASM_CONST example shows 
> any
> bigger values are not necessarily directly usable anyway.

How many places want to range check hex numbers?   Is it just setting
the number of digits input?  If strtoull is to hard, can we just do
the check as strings of digits?

If we keep this new restriction on hex numbers, it needs to be in
the Documentation, even if its prefixed by "currently".

milton

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