lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 22 Apr 2013 16:50:58 +0200
From:	Alexander Graf <agraf@...e.de>
To:	Anup Patel <anup.patel@...aro.org>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	linux-kernel@...r.kernel.org,
	"kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC] arm64: Early printk support for virtio-mmio console devices.


On 22.04.2013, at 05:10, Anup Patel wrote:

> On 22 April 2013 06:51, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> 
>> Pranavkumar Sawargaonkar <pranavkumar@...aro.org> writes:
>>> On 18 April 2013 12:21, Rusty Russell <rusty@...tcorp.com.au> wrote:
>>>> 
>>>> PranavkumarSawargaonkar <pranavkumar@...aro.org> writes:
>>>>> From: Pranavkumar Sawargaonkar <pranavkumar@...aro.org>
>>>>> 
>>>>> This patch implements early printk support for virtio-mmio console
>>>>> devices without using any hypercalls.
>>>> 
>>>> This makes some sense, though not sure that early console *read* makes
>>>> much sense.  I can see the PCI version of this being useful as well.
>>> 
>>> Read can be useful for "mach-virt" which will have only virtio console
>>> as a console device. Then if someone wants to have UEFI or any other
>>> boot-loader emulation, which expects user to input few things, in that
>>> case read might become handy.
>> 
>> But implementing virtio inside a bootloader has already been done for
>> coreboot, for example.  A bootloader probably wants a virtio block
>> device, so a console is trivial.
>> 
>> A single writable field for debugging makes sense.  Anything more is far
>> less certain.
> 
> The early read can be handy for bootloader who don't want to implement
> complete VirtIO programming.

Virtio is trivial. Seriously. Don't invent new secondary interfaces to the same thing just because you're afraid to write 5 lines of code instead of 2.


Alex

> 
> IMHO, early read would be totally optional for host and will not
> introduce any new config register so it is good to have in VirtIO
> console spec. Also, without early read the read behavior of early_rw
> field would be undefined in VirtIO console spec.
> 
>> 
>> Thanks,
>> Rusty.
> 
> Best Regards,
> Anup
> _______________________________________________
> kvmarm mailing list
> kvmarm@...ts.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ