NAK: [Utopic] [PULL] UBUNTU: fix no console in case of cloud environment

[Stefan Bader]

On 02.04.2015 01:48, Dann Frazier wrote:
> On Wed, Apr 1, 2015 at 1:52 AM, Stefan Bader <stefan.bader at canonical.com> wrote:
>> On 01.04.2015 04:10, Ming Lei wrote:
>>> On Tue, Mar 31, 2015 at 5:46 PM, Stefan Bader
>>> <stefan.bader at canonical.com> wrote:
>>>> On 31.03.2015 11:18, Ming Lei wrote:
>>>>> Hi Guys,
>>>>>
>>>>> These 6 patches are backported to support 'stdout' dt proper
>>>>> for fixing no console issue when VM is started from utopic
>>>>> cloud image, see the BugLink in the following LP:
>>>>>
>>>>>       https://bugs.launchpad.net/bugs/1438585
>>>>>
>>>>> The 'console=' parameter is removed from grub in utopic
>>>>> cloud image, and it can be found in LP1419952.
>>>>>
>>>>> Please pull:
>>>>>
>>>>>     git://kernel.ubuntu.com/git/ming/ubuntu-utopic.git  console-fix_stdout
>>>>>
>>>>> 669bc9b of: support passing console options with stdout-path
>>>>> 11a7b7b of: add optional options parameter to of_find_node_by_path()
>>>>> d0cd1fa of: Add bindings for chosen node, stdout-path
>>>>> 196a2fe of: correct of_console_check()'s return value
>>>>> 996ca98 of: Enable console on serial ports specified by /chosen/stdout-path
>>>>> 7cdedc94 of: Create of_console_check() for selecting a console specified in /cho
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Ming Lei
>>>>>
>>>> https://wiki.ubuntu.com/KernelTeam/KernelUpdates
>>>> https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
>>>
>>> Could you say more words about the NAK? It is because
>>> the patchset isn't suitable as SRU? Or some patch style issue?
>>
>> I thought to provide links to _style_ guidelines would carry the message. I
>> tried "more words" last time and this time the style seems even worse.
>> I cannot understand the explanation either. So I have no way of making any
>> decision about why we should pick this up for Utopic.
> 
> As for the explanation, let me try to elaborate (as this was something
> I suggested we do).

Thanks Dann. Very appreciated.
> 
> Our ultimate goal is to enable portable LTS cloud images for ARM64
> that comply with Linaro's ARM VM specification[*]. We can boot non-EFI
> trusty/utopic cloud images today, but they are incompatible with this
> spec, and are generally a pain to manage because w/o EFI you have to
> provide a kernel external to the disk image. Today our arm64-efi
> images are not usable due to a handful of issues that we are working
> to address. The kernel related ones are:
>  1) The 3.13 kernel did not yet contain EFI support
>  2) The 3.13 and 3.16 kernels did not yet contain the code to detect
> the console from the hypervisor-provided dtb.
> 
> Utopic already has #1, but is missing #2. Obviously we don't want
> utopic (or trusty+utopic hwe) to be a regression from trusty, so
> adding that support there first before tackling 3.13 seems to make
> sense.

Ah ok. See my problem with the initial submission was not only that there was so
many style issues and we are a mean bunch of grumpy old men (though some of that
might be true as well). The whole explanation seemed to make no sense. It would
have helped to mention at all that this is about Arm instead of expecting us to
notice somehow.

Reviewing patches for SRU is one part looking at the patches itself but the
other part is to make an estimate about how likely this might cause problems and
if so, how big that impact would be. And for that one needs some context and
making that simple for us helps whoever is trying to submit something. ;)

-Stefan
> 
>   -dann
> 
> [*] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v1.0.pdf
> 
> 
>> -Stefan
>>
>>>
>>>
>>> Thanks,
>>> Ming Lei
>>>
>>
>>
>>
>> --
>> kernel-team mailing list
>> kernel-team at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20150402/c1e1aadd/attachment.sig>