linux-kernel - Re: [PATCH v10 1/1] virtio_console: Add support for multiple ports for generic guest and host communication

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:	Fri, 6 Nov 2009 15:12:40 +0100
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	Anthony Liguori <aliguori@...ibm.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Amit Shah <amit.shah@...hat.com>, linux-kernel@...r.kernel.org,
	virtualization@...ux-foundation.org,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v10 1/1] virtio_console: Add support for multiple ports for generic guest and host communication

Am Freitag 06 November 2009 14:00:32 schrieb Anthony Liguori:
> > I like simplicity. According to David A. Wheeler's SLOCCount, the old
> > console has 141 lines of code and the I truly believe that a separate
> > guest-host comm vehicle would also be a lot simpler if it must not take
> > care of the old virtio_console interface.
> 
> It's the wrong metrics for evaluating a device ABI.  We should consider
> device ABIs based on whether they make sense--not about how many lines
> of code it takes to implement the Linux driver.

Well, code size is often related to complexity of the interface and affects 
maintainability. But if that does not convince you, what about intended use and 
semantics?

> Fundamentally speaking, right now, virtio-console is a single stream
> that acts as an interactive terminal.  What we're looking to add here is
> to support multiple terminals that can be enumerated in a rationale way.

Right, that is a point where I disagree. The original purpose and intent of the 
multiple port thing was to have a generic guest/host comm channels and *NOT* to 
have multiple console devices. Having multiple console devices is just a fall-
out of the current implementation.

Following your argument about single-streaming, we could also merge virtio-rng, 
no? 
If a common interface for stream workload is desired I would have preferred a 
write/read virtqueue_op besides or on top of add_buf/getbuf. I think that would 
have been the right level of abstraction.

>I agree and there are multiple maintainers on the qemu side who feel the
>same way I do.  I'm really strongly opposed to making this separate devices.

As a maintainer you sometimes have to make a controversial decision. If you made 
this final decision (and Rusty agrees) I am fine, even if I disagree.

(If it turns out to be a wrong decision you have been warned.  ;-) )

Christian
--
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/