From: Richard Weinberger <richard@nod.at>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Hajime Tazaki <thehajime@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>, cem <cem@freebsd.org>,
tavi purdila <tavi.purdila@gmail.com>,
linux-um <linux-um@lists.infradead.org>,
retrage01 <retrage01@gmail.com>,
linux-kernel-library <linux-kernel-library@freelists.org>,
pscollins <pscollins@google.com>,
sigmaepsilon92 <sigmaepsilon92@gmail.com>,
liuyuan <liuyuan@google.com>
Subject: Re: [RFC v2 17/37] lkl tools: host lib: virtio devices
Date: Tue, 26 Nov 2019 11:09:34 +0100 (CET) [thread overview]
Message-ID: <243342257.98153.1574762974057.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <4ebb14dc67ccb70543617ce1f7066f3f27cd11a8.camel@sipsolutions.net>
----- Ursprüngliche Mail -----
>> My point is that UML and LKL should try to do use the same concept/code
>> regarding virtio. At the end of day both use virtual devices which use
>> facilities from the host.
>> If this is really not possible it needs a good explanation.
>
> I think it isn't possible, unless you use vhost-user over a unix domain
> socket internally to talk between the kernel (virtio_uml) and hypervisor
> (device) components.
>
> In virtio_uml, the device implementation is assumed to be a separate
> process with a vhost-user connection. Here in LKL, the virtio device is
> part of the "hypervisor", i.e. in the same process.
Exactly, currently UML and LKL solve same things differently, but do we need to?
If we fail to agree on such a high level I might make sense to reevaluate to option
of not merging UML and LKL at all.
But this is beyond my decisional power and something I'd like to avoid.
Thanks,
//richard
next prev parent reply other threads:[~2019-11-26 10:09 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1571798507.git.thehajime@gmail.com>
2019-10-25 21:34 ` [RFC PATCH 00/47] Unifying LKL into UML Richard Weinberger
2019-10-27 2:34 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 00/37] " Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 01/37] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Hajime Tazaki
2019-11-25 22:02 ` Richard Weinberger
2019-11-26 14:02 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 02/37] arch: add __SYSCALL_DEFINE_ARCH Hajime Tazaki
2019-11-25 22:02 ` Richard Weinberger
2019-11-27 4:15 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 03/37] lkl: architecture skeleton for Linux kernel library Hajime Tazaki
2019-11-25 22:00 ` Richard Weinberger
2019-11-26 11:42 ` Octavian Purdila
2019-11-26 14:17 ` Hajime Tazaki
2019-11-26 16:02 ` Richard Weinberger
2020-02-05 7:37 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 04/37] lkl: host interface Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 05/37] lkl: memory handling Hajime Tazaki
2019-11-25 22:10 ` Richard Weinberger
2020-02-05 7:38 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 06/37] lkl: kernel threads support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 07/37] lkl: interrupt support Hajime Tazaki
2019-11-25 22:13 ` Richard Weinberger
2020-02-05 7:38 ` Hajime Tazaki
2020-02-05 10:49 ` Anton Ivanov
2020-02-05 14:24 ` Hajime Tazaki
2020-02-18 8:18 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 08/37] lkl: system call interface and application API Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 09/37] lkl: timers, time and delay support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 10/37] lkl: memory mapped I/O support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 11/37] lkl: basic kernel console support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 12/37] lkl: initialization and cleanup Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 13/37] lkl: plug in the build system Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 14/37] lkl tools: skeleton for host side library, tests and tools Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 15/37] lkl tools: host lib: add utilities functions Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 16/37] lkl tools: host lib: memory mapped I/O helpers Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 17/37] lkl tools: host lib: virtio devices Hajime Tazaki
2019-11-25 22:07 ` Richard Weinberger
2019-11-26 8:43 ` Johannes Berg
2019-11-26 8:50 ` Richard Weinberger
2019-11-26 8:52 ` Johannes Berg
2019-11-26 10:09 ` Richard Weinberger [this message]
2019-11-26 10:16 ` Johannes Berg
2019-11-26 10:42 ` Octavian Purdila
2019-11-26 10:49 ` Anton Ivanov
2019-11-27 4:06 ` Hajime Tazaki
2019-11-26 16:04 ` Richard Weinberger
2019-11-27 4:08 ` Hajime Tazaki
2019-11-27 14:28 ` Richard Weinberger
2019-11-28 9:53 ` Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 18/37] lkl tools: host lib: virtio block device Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 19/37] lkl tools: host lib: filesystem helpers Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 20/37] lkl tools: host lib: posix host operations Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 21/37] lkl tools: "boot" test Hajime Tazaki
2020-01-23 19:33 ` Brendan Higgins
2020-01-24 4:32 ` Hajime Tazaki
2020-03-02 19:51 ` Luis Chamberlain
2020-03-02 22:25 ` Brendan Higgins
2019-11-08 5:02 ` [RFC v2 22/37] lkl tools: tool that reads/writes to/from a filesystem image Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 23/37] lkl tools: tool that converts a filesystem image to tar Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 24/37] lkl tools: virtio: add network device support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 25/37] checkpatch: avoid showing BIT_ULL warnings for tools/ files Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 26/37] tools: Add the lkl host library to the common tools Makefile Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 27/37] lkl tools: add lklfuse Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 28/37] lkl: add system call hijack support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 29/37] lkl: add documentation Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 30/37] scripts: revert CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX patches Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 31/37] lkl: add support for Windows hosts Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 32/37] lkl tools: add support for Windows host Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 33/37] kallsyms: Add a config option to select section for kallsyms Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 34/37] lkl: Android ARM (arm/arm64) support Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 35/37] um lkl: add CI tests Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 36/37] um: use lkl virtio_net_tap device as UML device Hajime Tazaki
2019-11-08 5:02 ` [RFC v2 37/37] um: add lkl virtio-blk device Hajime Tazaki
2019-11-08 9:13 ` [RFC v2 00/37] Unifying LKL into UML Anton Ivanov
2019-11-08 11:17 ` Octavian Purdila
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=243342257.98153.1574762974057.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=cem@freebsd.org \
--cc=johannes@sipsolutions.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel-library@freelists.org \
--cc=linux-um@lists.infradead.org \
--cc=liuyuan@google.com \
--cc=pscollins@google.com \
--cc=retrage01@gmail.com \
--cc=sigmaepsilon92@gmail.com \
--cc=tavi.purdila@gmail.com \
--cc=thehajime@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).