Re: [PATCH] build: sync Kconfig with Linux v4.17

From: Wei Liu <wei.liu2@citrix.com>
To: Douglas Goldstein <dougtrav@icloud.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] build: sync Kconfig with Linux v4.17
Date: Mon, 25 Jun 2018 08:57:44 +0100	[thread overview]
Message-ID: <20180625075744.bkknca47j6alqob3@citrix.com> (raw)
In-Reply-To: <20180621222453.GA29089@MacBook-Air.local>

On Fri, Jun 22, 2018 at 06:24:54AM +0800, Douglas Goldstein wrote:
> > >>> Working patch by patch isn't feasible because of the renames.
> > >> 
> > >> I don't understand - how does path/file naming conflict with working
> > >> patch by patch? Surely a relatively simple sed command could be used
> > >> to change the paths in each patch according to our tree layout. That's
> > >> basically what I'm doing with the MWAIT idle driver; granted, that's just
> > >> a single file.
> > > 
> > > Its 106 commits between the last time I got this in sync. We also don’t have 
> > > kbuild and we have a little shim file to map things to our build system so 
> > > for each patch I would have to implement some of those regressions.
> > 
> > Well, I still don't understand: You had to make those 106 commits apply
> > to your tree as well in order to have create the patch you've submitted.
> > Whatever you did (even if you created a giant patch first and massaged
> > that one), the same could have been done for the individual commits. If
> > this indeed takes more than a simple sed invocation, perhaps it would be
> > worth adding a little script to our repo doing just that?
> 
> So I didn't take those 106 commits individually as it was indicated that
> would have been NACKed. I didn't even use git proper, I ultimately checked
> out the tag in my linux.git and used cp to copy the files over that I
> mentioned in the commit message. Then I removed the files that went away
> in Linux. I then attempted to build it and fixed up paths and other
> snippets until it all worked. Its a manual process in its very nature.
> 
> Originally when I proposed bringing in Kconfig I had used a script
> that maintained things in the same paths as Linux and indeed allowed us
> to just pull in patches from Linux. I believe the original RFC for
> adding Kconfig started with Linux v4.1 or v4.2 and I had used that
> script to update the final version to v4.3. This was ultimately not used
> because the Xen-specific changes we make (e.g. paths changed, removal of
> tests, use of Config.mk) that ultimately this a manual process.
> 
> Ultimately are you looking for v2 to be which of the following:
> - a series of 106 patches where each one is editted with the necessary
>   changes to make it work standalone (e.g. paths fixed, removal of
>   tests)

This is too much work with too little gain.

> - a series of 107 patches where I merely sed each patch to put the files
>   in the right place and then include a final commit with all the
>   various fixups

This will break bisection.

> - a series of 2 patches where the 106 as squashed into one commit and
>   then the 2nd patch does the various fixups

Same.

> - the current patch with details about the process documented in
>   README.source (which is a Xen specific file) and an expanded commit
>   message

I think this is the best of all the options mentioned.  You can include
the range of commits in the commit message.

Ultimately you're the maintainer I think you have the final say here.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel