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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 21.06.18 at 10:44, <dougtrav@icloud.com> wrote:

> 
>> On Jun 21, 2018, at 4:37 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> 
>>>>> On 21.06.18 at 10:28, <andrew.cooper3@citrix.com> wrote:
>>> On 21/06/18 16:13, Jan Beulich wrote:
>>>>>>> On 21.06.18 at 04:10, <dougtrav@icloud.com> wrote:
>>>>> From: Doug Goldstein <cardoe@cardoe.com>
>>>>> 
>>>>> From: Doug Goldstein <cardoe@cardoe.com>
>>>>> 
>>>>> Import the following files and directories from the Linux v4.17 tag
>>>>> (commit id 29dcea88779c856c7dc92040a0c01233263101d4):
>>>>> - scripts/kconfig/ -> xen/tools/kconfig/
>>>>> - scripts/Makefile.host -> xen/tools/kconfig/Makefile.host
>>>>> - Documentation/kbuild/kconfig{,-language}.txt ->
>>>>>  docs/misc/kconfig{-language}.txt
>>>>> - include/linux/kconfig.h -> xen/include/xen/kconfig.h
>>>>> 
>>>>> Pulled in parts of scripts/Makefile.lib into
>>>>> xen/tools/kconfig/Makefile.kconfig
>>>>> 
>>>>> Side effect of this change is that flex and bison are required to build
>>>>> Kconfig. Linux has switched from shipping the pre-generated files to
>>>>> always generating them with flex and bison.
>>>>> 
>>>>> Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
>>>> What I'm missing (and what I think is a requirement for this to go in) is
>>>> the "why" part: What do we gain from doing the update? Besides that
>>>> I think that in general it would be better to pull in Linux commits one
>>>> by one, rather than combining everything into a giant patch. That
>>>> might even already address part of my question, as it could highlight
>>>> bug fixes and/or enhancements which are of interest to us.
>>> 
>>> As a first pass, "because multiple people specifically asked about when
>>> we were going to update the version of Kconfig".
>> 
>> Okay, I must have missed every one of these. And hence I'm unaware
>> of the "why" parts of these requests.
> 
> It was asked during multiple sessions at the Xen Developer Summit in Nanjing 
> by audience members.

Meaning I can't possibly know. Even more of a reason to supply this
information when submitting the patch.

>>> 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?

Jan


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