Re: [PATCH 05/86] x86/gart: use uapi/linux/pci_ids.h directly

[Ingo Molnar]

* Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:

> On Mon, Mar 30, 2015 at 07:29:36AM +0200, Ingo Molnar wrote:
> > 
> > * Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
> > 
> > > Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
> > > use the new header directly so we can drop
> > > the wrapper in include/linux/pci_ids.h.
> > > 
> > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> > > ---
> > >  arch/x86/kernel/aperture_64.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> > > index 76164e1..3b52a56 100644
> > > --- a/arch/x86/kernel/aperture_64.c
> > > +++ b/arch/x86/kernel/aperture_64.c
> > > @@ -17,7 +17,7 @@
> > >  #include <linux/init.h>
> > >  #include <linux/memblock.h>
> > >  #include <linux/mmzone.h>
> > > -#include <linux/pci_ids.h>
> > > +#include <uapi/linux/pci_ids.h>
> > >  #include <linux/pci.h>
> > >  #include <linux/bitops.h>
> > >  #include <linux/suspend.h>
> > > -- 
> > > MST
> > > 
> > 
> > NAK, it's absolutely ridiculous to send a 86 patches series for a 
> > trivial change like this!
> > 
> > Just do the rename in a single patch and avoid the churn. Even if 
> > there are conflicts, they are utmost trivial to fix up.
> > 
> > In fact the usual way to do such renames is to wait until the end of 
> > -rc1, auto-generate it and send Linus the core patch with the trivial 
> > renames straight away.
> > 
> > Thanks,
> > 
> > 	Ingo
> 
> 
> Unfortunately, vger mailing lists reject any email with more than 2k of
> email headers.  This means if I do what you suggest I can't Cc all
> maintainers for all affected files. [...]

You can Cc: linux-arch and lkml for tree-wide changes.

Also, since it's mostly trivial, there shouldn't be much (if any) 
controversy about it, right?

> [...]  I could just Cc all mailing lists I guess, but I really 
> wasn't sure about some parts of the change, deferring it until end 
> of -rc1 wouldn't be appropriate in this case, would it?

So since 90% of the patches are just a trivial:

  -#include <linux/pci_ids.h>
  +#include <uapi/linux/pci_ids.h>

you can auto-generate that simple rename and file movement into a 
single commit, at the end of -rc1, without affecting anyone, via 
something like:

  sed -i 's/linux\/pci_ids.h/uapi\/linux\/pci_ids.h/g' $(git grep -l linux/pci_ids.h)
  git mv include/linux/pci_ids.h include/uapi/linux/pci_ids.h
  git commit -a

(totally untested)

This should just work.

Any other changes, as the removal of inclusions from files that 
apparently don't need it, or cleanups like the changing of the guard 
defines in pci_id.h, can be done on top of that - on a one patch per 
change basis.

This should drastically remove the churn.

What do you think?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/