linux-kernel - Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error

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: <20190314110413.GA32277@zn.tnic>
Date:   Thu, 14 Mar 2019 12:04:13 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Arnd Bergmann <arnd@...db.de>, "Luck, Tony" <tony.luck@...el.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        James Morse <james.morse@....com>,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>, linux-edac@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] EDAC, {skx|i10nm}_edac: Fix randconfig build error

On Thu, Mar 14, 2019 at 08:09:06AM +0100, Arnd Bergmann wrote:
> > So where should we go. Proposed solutions are piling up:
> >
> > 1) Make skx_common a module
> >         [downside: have to EXPORT everything in it]
> > 2) Move module-ish bits out of skx_common
> >         [downside: perhaps fragile]
> > 3) #include skx_common.c into {skx,i10nm}_edac.c
> >         [downside: no patch yet, bigger code size]
> 
> Sorry to add on to the already long list, but one more idea after
> looking at the two files:
> 
> 4) Have a single driver module, with the skx_common.c containing
>     the top-level module_init/module_exit functions that call into the
>     hardware specific versions.
> 
> This is the opposite of the usual recommendation (the driver
> is already structured nicely otherwise), but it would be cheap
> way out here.

This is what I think right now: if this is going to become such a pain,
then we better keep those two drivers completely separate. Who cares if
there's some code duplication?! Better that than some obscure randconfig
build breakages and fixes introducing more ugliness. IOW, we should keep
it simple.

Unless, Tony, you want to be able to make changes to the common code in
one place and don't want to patch both. Then I'd librarize the common
functionality, i.e., do something along the lines of 2).

But having two completely separate drivers is the most robust variant,
IMO.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.