Christian Borntraeger wrote: > I know that Anthony disagrees, but _If we start over_, I still think we should > use that chance and leave the old virtio console untouched and add a new driver > for the host guest communication. IMHO it turned out that there is only a tiny > bit of commonality. (most code pathes check for use_multiport and then do two > completely different things). > 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. 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. I see no reason why that should be two separate devices. > On the other hand we all should agree on one driver vs. two drivers before we go > on. Everything else would be unfair to Amit, who had the unpleasant task to > implement conflicting review comments.... > 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. If you think it's easier, you can do a check in the virtio_probe function that checks for the feature bits and calls a completely separate virtio initialization routine so it ends up being two separate files in Linux. But that's a Linux implementation detail. > Christian > -- Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
