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

[Borislav Petkov <bp@alien8.de>]

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.