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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.06.18 at 10:11, <julien.grall@xxxxxxx> wrote:
> On 06/22/2018 08:42 AM, Jan Beulich wrote:
>>>>> On 22.06.18 at 00:24, <dougtrav@xxxxxxxxxx> 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.
>> 
>> Interesting. Were there any reasons indicated why that would be?
> 
> I could see few reasons to be grumpy with such a series in my inbox. 
> Sending a series with 106 is just insane, more that probably no-one is 
> going to look at patches one by one (they are imported from Linux).

I can see the spam effect of such a patch bomb, sure.

> This is very similar to when a file is imported or update files from 
> Linux (e.g usban, SMMU). We don't backport one by one the commit. 
> Instead we batch in a single commit.
> 
> So why does it have to be different here?

Initial importing is one thing: You either want it, or you don't.
Subsequent updating is another, as explained in the original reply
already. Do we _need_ any of this (bug fixes, new features)? Or is
this _just_ to keep things somewhat in sync? After all, another
option after the initial import is also to solely pull in changes we
actually care about. And obviously there is a myriad of options
somewhere in the middle between the two extremes.

>>> 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 what I personally would prefer. But seeing that you say others
>> objected to this approach already, I'm not sure what to suggest.
>> 
>>> - the current patch with details about the process documented in
>>>    README.source (which is a Xen specific file) and an expanded commit
>>>    message
> 
> I am not sure what would the README.source would give you here? Will it 
> give a mapping with Linux commit for copyright reasons?

Doug said "details about the process documented", which I consider
helpful for future sync-ing steps (which may end up be done by others
than Doug).

Jan


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