diff mbox series

[v2,2/2] arm: rename tiny64.conf to tiny64_defconfig

Message ID 20190516133735.18883-2-volodymyr_babchuk@epam.com (mailing list archive)
State New, archived
Headers show
Series [v2,1/2] makefile: add support for *_defconfig targets | expand

Commit Message

Volodymyr Babchuk May 16, 2019, 1:37 p.m. UTC
As build system now supports *_defconfig rules it is good to be able
to configure minimal XEN image with

 make tiny64_defconfig

command.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
 xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename xen/arch/arm/configs/{tiny64.conf => tiny64_defconfig} (100%)

Comments

Julien Grall May 20, 2019, 1:01 p.m. UTC | #1
Hi,

First of all, please add a cover letter when you send a series. This help for 
threading and also a place to commend on general feedback.

Furthermore, please use scripts/{add, get}_maintainers.pl to find the correct 
maintainers. While I agree that CCing REST is a good idea, you haven't CCed all 
of them.

On 16/05/2019 14:37, Volodymyr Babchuk wrote:
> As build system now supports *_defconfig rules it is good to be able
> to configure minimal XEN image with

I am afraid this is not correct. tiny64 will not be able to generate a minimal 
config to boot on any platform supported by Xen.

It is meant to be used as a base for tailoring your platform where all the 
options are turned off by default.

So I think offering a direct access is likely going to be misused in most of the 
cases without proper documentation.

Cheers,
Volodymyr Babchuk May 20, 2019, 1:41 p.m. UTC | #2
Hi Julien,

Julien Grall writes:

> Hi,
>
> First of all, please add a cover letter when you send a series. This
> help for threading and also a place to commend on general feedback.
Oh, okay. That was quite simple change and I didn't wanted to spam with
extra emails. I will include cover letter next time.

> Furthermore, please use scripts/{add, get}_maintainers.pl to find the
> correct maintainers. While I agree that CCing REST is a good idea, you
> haven't CCed all of them.
Problem is that I used this script:

$ ./scripts/get_maintainer.pl -f defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap <George.Dunlap@eu.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Stefano Stabellini <sstabellini@kernel.org>
Tim Deegan <tim@xen.org>
Wei Liu <wei.liu2@citrix.com>
xen-devel@lists.xenproject.org

I was quite surprised by result myself. Honestly, I wanted to CC only
you and Stefano, but decided to play by the rules.


Also, add_maintainers.pl just ignores this patch at all:

% scripts/add_maintainers.pl -v 2 -d defconfig_v2
Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?

>
> On 16/05/2019 14:37, Volodymyr Babchuk wrote:
>> As build system now supports *_defconfig rules it is good to be able
>> to configure minimal XEN image with
>
> I am afraid this is not correct. tiny64 will not be able to generate a
> minimal config to boot on any platform supported by Xen.
>
> It is meant to be used as a base for tailoring your platform where all
> the options are turned off by default.
>
> So I think offering a direct access is likely going to be misused in
> most of the cases without proper documentation.

In the original commit message Stefano suggested to use olddefconfig:

"   Add a tiny kconfig configuration. Enabled only the credit scheduler.
    It only carries non-default options (use make menuconfig or make
    olddefconfig to produce a complete .config file). "

I don't see any significant difference between

# cp tiny64.conf .config && make olddefconfig

and

# make tiny64_defconfig

Anyways, it is up to you to accept or decline this particular patch. I
mostly interested in the first patch in the series, because our build
system depends on it. This very patch I sent out only because I wanted
to tidy up things a bit. But if you are saying that it is intended to
store minimal config in this way, I'm okay with it.

--
Best regards,Volodymyr Babchuk
Julien Grall May 20, 2019, 2:31 p.m. UTC | #3
Hi,

On 20/05/2019 14:41, Volodymyr Babchuk wrote:
> Julien Grall writes:
> 
>> Hi,
>>
>> First of all, please add a cover letter when you send a series. This
>> help for threading and also a place to commend on general feedback.
> Oh, okay. That was quite simple change and I didn't wanted to spam with
> extra emails. I will include cover letter next time.
> 
>> Furthermore, please use scripts/{add, get}_maintainers.pl to find the
>> correct maintainers. While I agree that CCing REST is a good idea, you
>> haven't CCed all of them.
> Problem is that I used this script:
> 
> $ ./scripts/get_maintainer.pl -f defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch

-f is to be used on actual file in the source tree. So the result below makes 
sense. For actual patch, you have to drop the -f.


> Andrew Cooper <andrew.cooper3@citrix.com>
> George Dunlap <George.Dunlap@eu.citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Julien Grall <julien.grall@arm.com>
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Stefano Stabellini <sstabellini@kernel.org>
> Tim Deegan <tim@xen.org>
> Wei Liu <wei.liu2@citrix.com>
> xen-devel@lists.xenproject.org
> 
> I was quite surprised by result myself. Honestly, I wanted to CC only
> you and Stefano, but decided to play by the rules.
> 
> 
> Also, add_maintainers.pl just ignores this patch at all:
> 
> % scripts/add_maintainers.pl -v 2 -d defconfig_v2
> Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
> Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
> ./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?

I have just tried it and can't find the same error. Could you provide more 
details? Such as where to do call from the exact content of each patches...

> 
>>
>> On 16/05/2019 14:37, Volodymyr Babchuk wrote:
>>> As build system now supports *_defconfig rules it is good to be able
>>> to configure minimal XEN image with
>>
>> I am afraid this is not correct. tiny64 will not be able to generate a
>> minimal config to boot on any platform supported by Xen.
>>
>> It is meant to be used as a base for tailoring your platform where all
>> the options are turned off by default.
>>
>> So I think offering a direct access is likely going to be misused in
>> most of the cases without proper documentation.
> 
> In the original commit message Stefano suggested to use olddefconfig:
> 
> "   Add a tiny kconfig configuration. Enabled only the credit scheduler.
>      It only carries non-default options (use make menuconfig or make
>      olddefconfig to produce a complete .config file). "
> 
> I don't see any significant difference between

Did you actually try the two approach and see how they differ?

> 
> # cp tiny64.conf .config && make olddefconfig

This one will ask you details on the configuration you want while...

> 
> and
> 
> # make tiny64_defconfig

... this one will hide the questions.

> 
> Anyways, it is up to you to accept or decline this particular patch. I
> mostly interested in the first patch in the series, because our build
> system depends on it. This very patch I sent out only because I wanted
> to tidy up things a bit. But if you are saying that it is intended to
> store minimal config in this way, I'm okay with it.

The point of review is to discuss on the approach and find a common agreement.

If you read my previous e-mail, I didn't completely reject the approach in my 
previous e-mail. I pointed out that the user may be misled of the name and hence 
documentation would be useful.

But


Cheers,
Volodymyr Babchuk May 20, 2019, 2:57 p.m. UTC | #4
Julien Grall writes:

> Hi,
>
> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>
>>> Hi,
>>>
>>> First of all, please add a cover letter when you send a series. This
>>> help for threading and also a place to commend on general feedback.
>> Oh, okay. That was quite simple change and I didn't wanted to spam with
>> extra emails. I will include cover letter next time.
>>
>>> Furthermore, please use scripts/{add, get}_maintainers.pl to find the
>>> correct maintainers. While I agree that CCing REST is a good idea, you
>>> haven't CCed all of them.
>> Problem is that I used this script:
>>
>> $ ./scripts/get_maintainer.pl -f defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
>
> -f is to be used on actual file in the source tree. So the result
> below makes sense. For actual patch, you have to drop the -f.
Ah, I see. Without -f I'm getting the same message as with
add-maintainers.pl:

% ./scripts/get_maintainer.pl defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?

[...]

>>
>> % scripts/add_maintainers.pl -v 2 -d defconfig_v2
>> Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
>> Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
>> ./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?
>
> I have just tried it and can't find the same error. Could you provide
> more details? Such as where to do call from the exact content of each
> patches...

My basic flow:

% git format-patch -v2 -2 -o defconfig_v2
% scripts/add_maintainers.pl -v 2 -d defconfig_v2
Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?
Then perform:
git send-email -to xen-devel@lists.xenproject.org defconfig_v2/v2-*.patch


HEAD (prior to my patches) is at
278c64519c661c851d37e2a929f006fb8a1dcd01

git version 2.21.0

Contents of the patch is the exactly the same as in my original
email. You can find both patches at [1].

>>
>>>
>>> On 16/05/2019 14:37, Volodymyr Babchuk wrote:
>>>> As build system now supports *_defconfig rules it is good to be able
>>>> to configure minimal XEN image with
>>>
>>> I am afraid this is not correct. tiny64 will not be able to generate a
>>> minimal config to boot on any platform supported by Xen.
>>>
>>> It is meant to be used as a base for tailoring your platform where all
>>> the options are turned off by default.
>>>
>>> So I think offering a direct access is likely going to be misused in
>>> most of the cases without proper documentation.
>>
>> In the original commit message Stefano suggested to use olddefconfig:
>>
>> "   Add a tiny kconfig configuration. Enabled only the credit scheduler.
>>      It only carries non-default options (use make menuconfig or make
>>      olddefconfig to produce a complete .config file). "
>>
>> I don't see any significant difference between
>
> Did you actually try the two approach and see how they differ?

Yes. I did the following:

% cp arch/arm/configs/tiny64_defconfig .config
% make olddefconfig
make -f /home/lorc/work/xen/xen/tools/kconfig/Makefile.kconfig ARCH=arm64 SRCARCH=arm HOSTCC="gcc" HOSTCXX="g++" olddefconfig
make[1]: Entering directory '/home/lorc/work/xen/xen'
gcc -Wp,-MD,tools/kconfig/.conf.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE   -c -o tools/kconfig/conf.o tools/kconfig/conf.c
gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -Itools/kconfig -c -o tools/kconfig/zconf.tab.o tools/kconfig/zconf.tab.c
gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o  
tools/kconfig/conf -s --olddefconfig Kconfig
make[1]: Leaving directory '/home/lorc/work/xen/xen'

And

% make tiny64_defconfig
make -f /home/lorc/work/xen/xen/tools/kconfig/Makefile.kconfig ARCH=arm64 SRCARCH=arm HOSTCC="gcc" HOSTCXX="g++" tiny64_defconfig
make[1]: Entering directory '/home/lorc/work/xen/xen'
gcc -Wp,-MD,tools/kconfig/.conf.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE   -c -o tools/kconfig/conf.o tools/kconfig/conf.c
gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -Itools/kconfig -c -o tools/kconfig/zconf.tab.o tools/kconfig/zconf.tab.c
gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o  
make[1]: Leaving directory '/home/lorc/work/xen/xen'

Then I compared both .config files and found no difference at all:

% diff -u .config1 .config2
(displayed nothing)

>>
>> # cp tiny64.conf .config && make olddefconfig
>
> This one will ask you details on the configuration you want while...

But it does not, while "make oldconfig" does. Are you sure you are not
confusing oldconfig and olddefconfig targets?

>>
>> and
>>
>> # make tiny64_defconfig
>
> ... this one will hide the questions.
>
>>
>> Anyways, it is up to you to accept or decline this particular patch. I
>> mostly interested in the first patch in the series, because our build
>> system depends on it. This very patch I sent out only because I wanted
>> to tidy up things a bit. But if you are saying that it is intended to
>> store minimal config in this way, I'm okay with it.
>
> The point of review is to discuss on the approach and find a common agreement.
>
> If you read my previous e-mail, I didn't completely reject the
> approach in my previous e-mail. I pointed out that the user may be
> misled of the name and hence documentation would be useful.

I'm okay with this. Any ideas how to document it?

[1] https://github.com/lorc/xen/commits/defconfig_v2
Julien Grall May 28, 2019, 4:21 p.m. UTC | #5
Hi Volodymyr,

Sorry for the late reply.

On 5/20/19 3:57 PM, Volodymyr Babchuk wrote:
> 
> Julien Grall writes:
> 
>> Hi,
>>
>> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
>>> Julien Grall writes:
>>>
>>>> Hi,
>>>>
>>>> First of all, please add a cover letter when you send a series. This
>>>> help for threading and also a place to commend on general feedback.
>>> Oh, okay. That was quite simple change and I didn't wanted to spam with
>>> extra emails. I will include cover letter next time.
>>>
>>>> Furthermore, please use scripts/{add, get}_maintainers.pl to find the
>>>> correct maintainers. While I agree that CCing REST is a good idea, you
>>>> haven't CCed all of them.
>>> Problem is that I used this script:
>>>
>>> $ ./scripts/get_maintainer.pl -f defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
>>
>> -f is to be used on actual file in the source tree. So the result
>> below makes sense. For actual patch, you have to drop the -f.
> Ah, I see. Without -f I'm getting the same message as with
> add-maintainers.pl:
> 
> % ./scripts/get_maintainer.pl defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
> ./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?
> 
> [...]
> 
>>>
>>> % scripts/add_maintainers.pl -v 2 -d defconfig_v2
>>> Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
>>> Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
>>> ./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?
>>
>> I have just tried it and can't find the same error. Could you provide
>> more details? Such as where to do call from the exact content of each
>> patches...
> 
> My basic flow:
> 
> % git format-patch -v2 -2 -o defconfig_v2
> % scripts/add_maintainers.pl -v 2 -d defconfig_v2
> Processing: v2-0001-makefile-add-support-for-_defconfig-targets.patch
> Processing: v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
> ./scripts/get_maintainer.pl: file 'defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch' doesn't appear to be a patch.  Add -f to options?
> Then perform:
> git send-email -to xen-devel@lists.xenproject.org defconfig_v2/v2-*.patch
> 
> 
> HEAD (prior to my patches) is at
> 278c64519c661c851d37e2a929f006fb8a1dcd01
> 
> git version 2.21.0
> 
> Contents of the patch is the exactly the same as in my original
> email. You can find both patches at [1].

It looks like the problem is because the second patch only contains 
renaming. Linux recently fixed it with the following commit:

0455c74788fd "get_maintainer: improve patch recognition"

I guess we need to port the patch in Xen. Volodymyr, would you mind to 
send a patch for it?

> 
>>>
>>>>
>>>> On 16/05/2019 14:37, Volodymyr Babchuk wrote:
>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>> to configure minimal XEN image with
>>>>
>>>> I am afraid this is not correct. tiny64 will not be able to generate a
>>>> minimal config to boot on any platform supported by Xen.
>>>>
>>>> It is meant to be used as a base for tailoring your platform where all
>>>> the options are turned off by default.
>>>>
>>>> So I think offering a direct access is likely going to be misused in
>>>> most of the cases without proper documentation.
>>>
>>> In the original commit message Stefano suggested to use olddefconfig:
>>>
>>> "   Add a tiny kconfig configuration. Enabled only the credit scheduler.
>>>       It only carries non-default options (use make menuconfig or make
>>>       olddefconfig to produce a complete .config file). "
>>>
>>> I don't see any significant difference between
>>
>> Did you actually try the two approach and see how they differ?
> 
> Yes. I did the following:
> 
> % cp arch/arm/configs/tiny64_defconfig .config
> % make olddefconfig
> make -f /home/lorc/work/xen/xen/tools/kconfig/Makefile.kconfig ARCH=arm64 SRCARCH=arm HOSTCC="gcc" HOSTCXX="g++" olddefconfig
> make[1]: Entering directory '/home/lorc/work/xen/xen'
> gcc -Wp,-MD,tools/kconfig/.conf.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE   -c -o tools/kconfig/conf.o tools/kconfig/conf.c
> gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -Itools/kconfig -c -o tools/kconfig/zconf.tab.o tools/kconfig/zconf.tab.c
> gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o
> tools/kconfig/conf -s --olddefconfig Kconfig
> make[1]: Leaving directory '/home/lorc/work/xen/xen'
> 
> And
> 
> % make tiny64_defconfig
> make -f /home/lorc/work/xen/xen/tools/kconfig/Makefile.kconfig ARCH=arm64 SRCARCH=arm HOSTCC="gcc" HOSTCXX="g++" tiny64_defconfig
> make[1]: Entering directory '/home/lorc/work/xen/xen'
> gcc -Wp,-MD,tools/kconfig/.conf.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE   -c -o tools/kconfig/conf.o tools/kconfig/conf.c
> gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d    -D_GNU_SOURCE -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -Itools/kconfig -c -o tools/kconfig/zconf.tab.o tools/kconfig/zconf.tab.c
> gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o
> make[1]: Leaving directory '/home/lorc/work/xen/xen'
> 
> Then I compared both .config files and found no difference at all:
> 
> % diff -u .config1 .config2
> (displayed nothing)
> 
>>>
>>> # cp tiny64.conf .config && make olddefconfig
>>
>> This one will ask you details on the configuration you want while...
> 
> But it does not, while "make oldconfig" does. Are you sure you are not
> confusing oldconfig and olddefconfig targets?

I am confusing both :(. Sorry for the noise.

> 
>>>
>>> and
>>>
>>> # make tiny64_defconfig
>>
>> ... this one will hide the questions.
>>
>>>
>>> Anyways, it is up to you to accept or decline this particular patch. I
>>> mostly interested in the first patch in the series, because our build
>>> system depends on it. This very patch I sent out only because I wanted
>>> to tidy up things a bit. But if you are saying that it is intended to
>>> store minimal config in this way, I'm okay with it.
>>
>> The point of review is to discuss on the approach and find a common agreement.
>>
>> If you read my previous e-mail, I didn't completely reject the
>> approach in my previous e-mail. I pointed out that the user may be
>> misled of the name and hence documentation would be useful.
> 
> I'm okay with this. Any ideas how to document it?

We don't seem to have a place today where we document the defconfig. I 
am thinking to put that in docs/misc/arm.

I would document the purpose of each config. The documentation could be 
in a separate patch.

Cheers,

> 
> [1] https://github.com/lorc/xen/commits/defconfig_v2
>
Volodymyr Babchuk May 29, 2019, 11:40 a.m. UTC | #6
Hi Julien,

Julien Grall writes:

> Hi Volodymyr,
>
> Sorry for the late reply.
It's okay, no worries.

> On 5/20/19 3:57 PM, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> Hi,
>>>
>>> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
>>>> Julien Grall writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> First of all, please add a cover letter when you send a series. This
>>>>> help for threading and also a place to commend on general feedback.
>>>> Oh, okay. That was quite simple change and I didn't wanted to spam with
>>>> extra emails. I will include cover letter next time.
>>>>
>>>>> Furthermore, please use scripts/{add, get}_maintainers.pl to find the
>>>>> correct maintainers. While I agree that CCing REST is a good idea, you
>>>>> haven't CCed all of them.
>>>> Problem is that I used this script:
>>>>
>>>> $ ./scripts/get_maintainer.pl -f defconfig_v2/v2-0002-arm-rename-tiny64.conf-to-tiny64_defconfig.patch
[...]
>>
>> Contents of the patch is the exactly the same as in my original
>> email. You can find both patches at [1].
>
> It looks like the problem is because the second patch only contains
> renaming. Linux recently fixed it with the following commit:
>
> 0455c74788fd "get_maintainer: improve patch recognition"
>
> I guess we need to port the patch in Xen. Volodymyr, would you mind to
> send a patch for it?
Yes, I have sent it. It is the first time I'm sending ported patches. I
hope, I did it in the right way :)


[...]
>>>>
>>>> and
>>>>
>>>> # make tiny64_defconfig
>>>
>>> ... this one will hide the questions.
>>>
>>>>
>>>> Anyways, it is up to you to accept or decline this particular patch. I
>>>> mostly interested in the first patch in the series, because our build
>>>> system depends on it. This very patch I sent out only because I wanted
>>>> to tidy up things a bit. But if you are saying that it is intended to
>>>> store minimal config in this way, I'm okay with it.
>>>
>>> The point of review is to discuss on the approach and find a common agreement.
>>>
>>> If you read my previous e-mail, I didn't completely reject the
>>> approach in my previous e-mail. I pointed out that the user may be
>>> misled of the name and hence documentation would be useful.
>>
>> I'm okay with this. Any ideas how to document it?
>
> We don't seem to have a place today where we document the defconfig. I
> am thinking to put that in docs/misc/arm.
>
> I would document the purpose of each config. The documentation could
> be in a separate patch.
Okay. Will it be okay, if I'll send it as a separate patch? You can
commit all three patches in a row. Or should I sent another version with
all three patches?
Julien Grall May 29, 2019, 3:27 p.m. UTC | #7
Hi Volodymyr,

On 29/05/2019 12:40, Volodymyr Babchuk wrote:
>>>> On 20/05/2019 14:41, Volodymyr Babchuk wrote:
>>>>> Julien Grall writes:
>>>> If you read my previous e-mail, I didn't completely reject the
>>>> approach in my previous e-mail. I pointed out that the user may be
>>>> misled of the name and hence documentation would be useful.
>>>
>>> I'm okay with this. Any ideas how to document it?
>>
>> We don't seem to have a place today where we document the defconfig. I
>> am thinking to put that in docs/misc/arm.
>>
>> I would document the purpose of each config. The documentation could
>> be in a separate patch.
> Okay. Will it be okay, if I'll send it as a separate patch? You can
> commit all three patches in a row. Or should I sent another version with
> all three patches?

Please resend the series.

Cheers,
Jan Beulich June 5, 2019, 3:58 p.m. UTC | #8
Julien,

>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
> As build system now supports *_defconfig rules it is good to be able
> to configure minimal XEN image with
> 
>  make tiny64_defconfig
> 
> command.
> 
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

you had objections here, and the first patch makes little sense
without the 2nd. May I ask what the verdict is, i.e. whether I should
drop these two from my list of pending patches?

Jan
Julien Grall June 5, 2019, 4:01 p.m. UTC | #9
Hi Jan,

On 05/06/2019 16:58, Jan Beulich wrote:
> Julien,
> 
>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>> As build system now supports *_defconfig rules it is good to be able
>> to configure minimal XEN image with
>>
>>   make tiny64_defconfig
>>
>> command.
>>
>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
> 
> you had objections here, and the first patch makes little sense
> without the 2nd. May I ask what the verdict is, i.e. whether I should
> drop these two from my list of pending patches?

Volodymyr was going to resend the series with documentation (as a separate 
patch). But I would be happy to take #1 and #2 assuming that documentation patch 
is going to be sent.

You can consider this as an acked:

Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.


Cheers,
Julien Grall June 10, 2019, 8:03 p.m. UTC | #10
Hi,

On 6/5/19 5:01 PM, Julien Grall wrote:
  > On 05/06/2019 16:58, Jan Beulich wrote:
>> Julien,
>>
>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>> As build system now supports *_defconfig rules it is good to be able
>>> to configure minimal XEN image with
>>>
>>>   make tiny64_defconfig
>>>
>>> command.
>>>
>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>
>> you had objections here, and the first patch makes little sense
>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>> drop these two from my list of pending patches?
> 
> Volodymyr was going to resend the series with documentation (as a 
> separate patch). But I would be happy to take #1 and #2 assuming that 
> documentation patch is going to be sent.
> 
> You can consider this as an acked:
> 
> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.

I was about to apply the two patches, but I don't seem to be able to 
apply it because some lines contains =20. AFAICT, it is in replacement 
of "space" in certain case.

This is similar to the OP-TEE series. Volodymyr, can you sort out your 
e-mail configuration? Andrii seems to send patches from a gmail, not 
sure if it is because of some issues with his EPAM e-mail address... You 
may want to talk with him.

Cheers,
Jan Beulich June 11, 2019, 6:43 a.m. UTC | #11
>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
> Hi,
> 
> On 6/5/19 5:01 PM, Julien Grall wrote:
>   > On 05/06/2019 16:58, Jan Beulich wrote:
>>> Julien,
>>>
>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>> As build system now supports *_defconfig rules it is good to be able
>>>> to configure minimal XEN image with
>>>>
>>>>   make tiny64_defconfig
>>>>
>>>> command.
>>>>
>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>
>>> you had objections here, and the first patch makes little sense
>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>> drop these two from my list of pending patches?
>> 
>> Volodymyr was going to resend the series with documentation (as a 
>> separate patch). But I would be happy to take #1 and #2 assuming that 
>> documentation patch is going to be sent.
>> 
>> You can consider this as an acked:
>> 
>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
> 
> I was about to apply the two patches, but I don't seem to be able to 
> apply it because some lines contains =20. AFAICT, it is in replacement 
> of "space" in certain case.

Well, independent of any formatting issues you ought to have trouble
applying them since I did so already.

Jan
Julien Grall June 11, 2019, 9:27 a.m. UTC | #12
Hi Jan,

On 6/11/19 7:43 AM, Jan Beulich wrote:
>>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
>> Hi,
>>
>> On 6/5/19 5:01 PM, Julien Grall wrote:
>>    > On 05/06/2019 16:58, Jan Beulich wrote:
>>>> Julien,
>>>>
>>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>> to configure minimal XEN image with
>>>>>
>>>>>    make tiny64_defconfig
>>>>>
>>>>> command.
>>>>>
>>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>>
>>>> you had objections here, and the first patch makes little sense
>>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>>> drop these two from my list of pending patches?
>>>
>>> Volodymyr was going to resend the series with documentation (as a
>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>> documentation patch is going to be sent.
>>>
>>> You can consider this as an acked:
>>>
>>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
>>
>> I was about to apply the two patches, but I don't seem to be able to
>> apply it because some lines contains =20. AFAICT, it is in replacement
>> of "space" in certain case.
> 
> Well, independent of any formatting issues you ought to have trouble
> applying them since I did so already.

Hmm, I missed that. Sorry for noise.

Out of interest, how did you manage to apply it with the =20 in the patch?

Cheers,
Jan Beulich June 11, 2019, 9:41 a.m. UTC | #13
>>> On 11.06.19 at 11:27, <julien.grall@arm.com> wrote:
> Hi Jan,
> 
> On 6/11/19 7:43 AM, Jan Beulich wrote:
>>>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
>>> Hi,
>>>
>>> On 6/5/19 5:01 PM, Julien Grall wrote:
>>>    > On 05/06/2019 16:58, Jan Beulich wrote:
>>>>> Julien,
>>>>>
>>>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>>> to configure minimal XEN image with
>>>>>>
>>>>>>    make tiny64_defconfig
>>>>>>
>>>>>> command.
>>>>>>
>>>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>>>
>>>>> you had objections here, and the first patch makes little sense
>>>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>>>> drop these two from my list of pending patches?
>>>>
>>>> Volodymyr was going to resend the series with documentation (as a
>>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>>> documentation patch is going to be sent.
>>>>
>>>> You can consider this as an acked:
>>>>
>>>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
>>>
>>> I was about to apply the two patches, but I don't seem to be able to
>>> apply it because some lines contains =20. AFAICT, it is in replacement
>>> of "space" in certain case.
>> 
>> Well, independent of any formatting issues you ought to have trouble
>> applying them since I did so already.
> 
> Hmm, I missed that. Sorry for noise.
> 
> Out of interest, how did you manage to apply it with the =20 in the patch?

There are no =20 in the mail that I did receive.

Jan
George Dunlap June 11, 2019, 10:12 a.m. UTC | #14
On 6/11/19 10:41 AM, Jan Beulich wrote:
>>>> On 11.06.19 at 11:27, <julien.grall@arm.com> wrote:
>> Hi Jan,
>>
>> On 6/11/19 7:43 AM, Jan Beulich wrote:
>>>>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
>>>> Hi,
>>>>
>>>> On 6/5/19 5:01 PM, Julien Grall wrote:
>>>>    > On 05/06/2019 16:58, Jan Beulich wrote:
>>>>>> Julien,
>>>>>>
>>>>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>>>> to configure minimal XEN image with
>>>>>>>
>>>>>>>    make tiny64_defconfig
>>>>>>>
>>>>>>> command.
>>>>>>>
>>>>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>>>>
>>>>>> you had objections here, and the first patch makes little sense
>>>>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>>>>> drop these two from my list of pending patches?
>>>>>
>>>>> Volodymyr was going to resend the series with documentation (as a
>>>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>>>> documentation patch is going to be sent.
>>>>>
>>>>> You can consider this as an acked:
>>>>>
>>>>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
>>>>
>>>> I was about to apply the two patches, but I don't seem to be able to
>>>> apply it because some lines contains =20. AFAICT, it is in replacement
>>>> of "space" in certain case.
>>>
>>> Well, independent of any formatting issues you ought to have trouble
>>> applying them since I did so already.
>>
>> Hmm, I missed that. Sorry for noise.
>>
>> Out of interest, how did you manage to apply it with the =20 in the patch?
> 
> There are no =20 in the mail that I did receive.

I think `git am` knows how to deal with those actually.

 -George
Julien Grall June 11, 2019, 1:52 p.m. UTC | #15
On 11/06/2019 10:41, Jan Beulich wrote:
>>>> On 11.06.19 at 11:27, <julien.grall@arm.com> wrote:
>> Hi Jan,
>>
>> On 6/11/19 7:43 AM, Jan Beulich wrote:
>>>>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
>>>> Hi,
>>>>
>>>> On 6/5/19 5:01 PM, Julien Grall wrote:
>>>>     > On 05/06/2019 16:58, Jan Beulich wrote:
>>>>>> Julien,
>>>>>>
>>>>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>>>> to configure minimal XEN image with
>>>>>>>
>>>>>>>     make tiny64_defconfig
>>>>>>>
>>>>>>> command.
>>>>>>>
>>>>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>>>>
>>>>>> you had objections here, and the first patch makes little sense
>>>>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>>>>> drop these two from my list of pending patches?
>>>>>
>>>>> Volodymyr was going to resend the series with documentation (as a
>>>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>>>> documentation patch is going to be sent.
>>>>>
>>>>> You can consider this as an acked:
>>>>>
>>>>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
>>>>
>>>> I was about to apply the two patches, but I don't seem to be able to
>>>> apply it because some lines contains =20. AFAICT, it is in replacement
>>>> of "space" in certain case.
>>>
>>> Well, independent of any formatting issues you ought to have trouble
>>> applying them since I did so already.
>>
>> Hmm, I missed that. Sorry for noise.
>>
>> Out of interest, how did you manage to apply it with the =20 in the patch?
> 
> There are no =20 in the mail that I did receive.

Sorry, I was talking about patch #1. Interestingly the Content-Type is different 
between the e-mail received from exchange (this is a direct copy) and gmail 
(this is received from xen-devel).

The gmail version doesn't contain it, while the exchange version does... Hmmm...

Cheers,
Julien Grall June 11, 2019, 1:52 p.m. UTC | #16
Hi George,

On 11/06/2019 11:12, George Dunlap wrote:
> On 6/11/19 10:41 AM, Jan Beulich wrote:
>>>>> On 11.06.19 at 11:27, <julien.grall@arm.com> wrote:
>>> Hi Jan,
>>>
>>> On 6/11/19 7:43 AM, Jan Beulich wrote:
>>>>>>> On 10.06.19 at 22:03, <julien.grall@arm.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On 6/5/19 5:01 PM, Julien Grall wrote:
>>>>>     > On 05/06/2019 16:58, Jan Beulich wrote:
>>>>>>> Julien,
>>>>>>>
>>>>>>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>>>>>>> As build system now supports *_defconfig rules it is good to be able
>>>>>>>> to configure minimal XEN image with
>>>>>>>>
>>>>>>>>     make tiny64_defconfig
>>>>>>>>
>>>>>>>> command.
>>>>>>>>
>>>>>>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>>>>>>
>>>>>>> you had objections here, and the first patch makes little sense
>>>>>>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>>>>>>> drop these two from my list of pending patches?
>>>>>>
>>>>>> Volodymyr was going to resend the series with documentation (as a
>>>>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>>>>> documentation patch is going to be sent.
>>>>>>
>>>>>> You can consider this as an acked:
>>>>>>
>>>>>> Acked-by: Julien Grall <julien.grall@arm.com> for the two patches.
>>>>>
>>>>> I was about to apply the two patches, but I don't seem to be able to
>>>>> apply it because some lines contains =20. AFAICT, it is in replacement
>>>>> of "space" in certain case.
>>>>
>>>> Well, independent of any formatting issues you ought to have trouble
>>>> applying them since I did so already.
>>>
>>> Hmm, I missed that. Sorry for noise.
>>>
>>> Out of interest, how did you manage to apply it with the =20 in the patch?
>>
>> There are no =20 in the mail that I did receive.
> 
> I think `git am` knows how to deal with those actually.

Hrm. Yes, sorry for the noise.

Cheers,
Volodymyr Babchuk June 11, 2019, 6:52 p.m. UTC | #17
Hello Julien, Jan,

Julien Grall writes:

>>>>> On 16.05.19 at 15:37, <Volodymyr_Babchuk@epam.com> wrote:
>>> As build system now supports *_defconfig rules it is good to be able
>>> to configure minimal XEN image with
>>>
>>>   make tiny64_defconfig
>>>
>>> command.
>>>
>>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
>>
>> you had objections here, and the first patch makes little sense
>> without the 2nd. May I ask what the verdict is, i.e. whether I should
>> drop these two from my list of pending patches?
>
> Volodymyr was going to resend the series with documentation (as a
> separate patch). But I would be happy to take #1 and #2 assuming that
> documentation patch is going to be sent.

Yes, sorry for the delay. I'm going to send resend the series soon. But
I can see, that first two patches are already in the staging branch.
Should I resend the whole series in this case? Or single patch with the
missing documentation will be sufficient?

And another, slightly related question: I'm not sure what to do with my
patch to get_maintainer.pl script. Should I resend the new version? Jan
had comments only to commit message...

--
Best regards,Volodymyr Babchuk
Jan Beulich June 12, 2019, 7:44 a.m. UTC | #18
>>> On 11.06.19 at 20:52, <Volodymyr_Babchuk@epam.com> wrote:
> Julien Grall writes:
>> Volodymyr was going to resend the series with documentation (as a
>> separate patch). But I would be happy to take #1 and #2 assuming that
>> documentation patch is going to be sent.
> 
> Yes, sorry for the delay. I'm going to send resend the series soon. But
> I can see, that first two patches are already in the staging branch.
> Should I resend the whole series in this case? Or single patch with the
> missing documentation will be sufficient?

You should never send patches that have already been applied.

> And another, slightly related question: I'm not sure what to do with my
> patch to get_maintainer.pl script. Should I resend the new version? Jan
> had comments only to commit message...

Well, re-sending may make it easier, but first of all you need to
get a maintainer to ack the patch. My Perl isn't good enough
that I would feel qualified to give mine.

Jan
Julien Grall June 15, 2019, 6:27 p.m. UTC | #19
Hi,

On 6/12/19 8:44 AM, Jan Beulich wrote:
>>>> On 11.06.19 at 20:52, <Volodymyr_Babchuk@epam.com> wrote:
>> Julien Grall writes:
>>> Volodymyr was going to resend the series with documentation (as a
>>> separate patch). But I would be happy to take #1 and #2 assuming that
>>> documentation patch is going to be sent.
>>
>> Yes, sorry for the delay. I'm going to send resend the series soon. But
>> I can see, that first two patches are already in the staging branch.
>> Should I resend the whole series in this case? Or single patch with the
>> missing documentation will be sufficient?
> 
> You should never send patches that have already been applied.
> 
>> And another, slightly related question: I'm not sure what to do with my
>> patch to get_maintainer.pl script. Should I resend the new version? Jan
>> had comments only to commit message...
> 
> Well, re-sending may make it easier, but first of all you need to
> get a maintainer to ack the patch. My Perl isn't good enough
> that I would feel qualified to give mine.

Volodymyr, please resend the patch with Jan's comments addressed. I had 
a brief looked today and the patch looks correct. I will have another 
look on the next version.

Cheers,
diff mbox series

Patch

diff --git a/xen/arch/arm/configs/tiny64.conf b/xen/arch/arm/configs/tiny64_defconfig
similarity index 100%
rename from xen/arch/arm/configs/tiny64.conf
rename to xen/arch/arm/configs/tiny64_defconfig