Re: linux-next: build failure after merge of the driver-core tree

[Stephen Rothwell]

Hi Greg,

On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH <greg@xxxxxxxxx> wrote:
>
> On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote:
> > 
> > After merging the driver-core tree, today's linux-next build ()
> > failed like this on a PowerPC defconfig:
> > 
> > HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> >   GEN     /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > #
> > # configuration written to .config
> > #
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> >   sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> >   ^
> > cc1: all warnings being treated as errors
> > 
> > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
> > 
> > I reverted 774fea1a38c6a5a8 for today.
> 
> Sounds like the powerpc tree also needs to stop using this function :)

So, explain to us in detail why the old interface could not be maintained
for a release, please.  I thought we had become a bit more sophisticated
about changing core APIs i.e. introduce the new API - fix up all the
users - keep the old one around if possible for a release (or beyond
-rc1) to catch the new users.

It may be that there is a good reason not to so this in this case, but it
is not explained as far as I can see.

Alternatively, it looks as though there may be a fairly trivial transform
from using the old interface to using the new one which could be applied
as part of the merge of these two trees (in linux-next and then in Linus'
tree during the merge window).  Maybe you or Tejun should have explained
that and provided a prototype for the merge fix up.

Greg, you are doing core infrastructure changes in your trees - you need
to consider that new usages may be introduced while those changes are
ongoing.
-- 
Cheers,
Stephen Rothwell                    sfr@xxxxxxxxxxxxxxxx

Attachment: pgpgUt8TtzdLi.pgp
Description: PGP signature