[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1611101729510.3501@nanos>
Date: Thu, 10 Nov 2016 17:31:10 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Al Viro <viro@...IV.linux.org.uk>
cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, rt@...utronix.de,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 01/25] fs/buffer: Convert to hotplug state machine
On Thu, 10 Nov 2016, Al Viro wrote:
> On Thu, Nov 03, 2016 at 03:49:57PM +0100, Sebastian Andrzej Siewior wrote:
> > Install the callbacks via the state machine.
>
> > diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> > index afe641c02dca..69b74fa0da60 100644
> > --- a/include/linux/cpuhotplug.h
> > +++ b/include/linux/cpuhotplug.h
> > @@ -30,6 +30,7 @@ enum cpuhp_state {
> > CPUHP_ACPI_CPUDRV_DEAD,
> > CPUHP_S390_PFAULT_DEAD,
> > CPUHP_BLK_MQ_DEAD,
> > + CPUHP_FS_BUFF_DEAD,
> > CPUHP_WORKQUEUE_PREP,
> > CPUHP_POWER_NUMA_PREPARE,
> > CPUHP_HRTIMERS_PREPARE,
>
> *ouch*
>
> So we are getting a large list of things from unrelated subsystems, maintained
> in a single place, all next to each other. All examples of that sort of
> thing I can recall had ended up biting our arses...
I rather have my arse bitten by a few merge conflicts than constantly
chasing why odering by chance, link order or magic constants in random
files make things explode or not work.
Thanks,
tglx
Powered by blists - more mailing lists