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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 06 Jan 2022 10:01:54 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     bmeng.cn@...il.com
CC:     anup@...infault.org, linux-riscv@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, anup@...infault.org,
        heinrich.schuchardt@...onical.com, bin.meng@...driver.com,
        sagar.kadam@...ive.com, damien.lemoal@....com, axboe@...nel.dk,
        linux-kernel@...r.kernel.org, atishp@...shpatra.org
Subject:     Re: [PATCH 0/12] RISC-V: Clean up the defconfigs

On Sun, 21 Nov 2021 18:45:24 PST (-0800), bmeng.cn@...il.com wrote:
> On Sat, Nov 20, 2021 at 12:32 PM Anup Patel <anup@...infault.org> wrote:
>>
>> On Fri, Nov 19, 2021 at 10:14 PM Palmer Dabbelt <palmer@...osinc.com> wrote:
>> >
>> > It's been a while since updating the defconfigs, so I figured it would
>> > be good to go through all the diff to make sure nothing was lurking.  It
>> > turns out there were two minor issues, which I've fixed with the first
>> > two patches.  The rest of these are just cleanups that should have no
>> > functional change.
>> >
>> > I don't have a K210 (I might somewhere, but I've yet to boot it) so I
>> > can't test this to make sure, but I think patch 2 is the reason we have
>> > a special !MMU PAGE_OFFSET config.  If someone does have one it'd be
>> > nice to be able to remove that special case.
>> >
>> >
>>
>> Using savedefconfig, I used to always get a huge diff so thanks for
>> doing this cleanups. Going forward, I suggest that we insiste everyone
>> to always use "make savedefconfig" for creating defconfig patches.
>
> Yep, using "savedefconfig" is always required by U-Boot maintainers. I
> thought that's always the case for the Linux kernel but it seems it is
> not the case.

It's actually a bit more complicated than that, as the results of
savedefconfig change to track Kconfig updates.  I'd mostly been running
savedefconfig and tossing the extra diff for people, but that led to a
bit of a mess here.

There's no way we can require everyone to run savedefconfig on our tree 
(and even if we could, it'd be a merge nightmare).  IIUC what most folks 
do is regularly re-spin the defconfigs, now that they're clean that 
should be easy.  I'm going to start doing that, the best I can come up 
with is in the second week of the merge window -- that way we'll have 
both fixes and for-next based on the newer defconfigs, along with all 
the WIP branches that folks base on rc1.  If anyone's got a better 
scheme then I'm all ears, though.

This patch set is on for-next.

Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ