Message ID | 20211013230405.32170-1-wwcohen@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | 9p: Add support for Darwin | expand |
Hi Will, It is strongly recommended that you Cc maintainers to increase the odds they notice your patches in the flood of qemu-devel. FYI I only noticed them because git-send-email Cc'd me thanks to the Reviewed-by: tags and my address didn't change in the meantime. I'm thus Cc'ing Christian who is the primary maintainer now (i.e. the person that can merge your patches and send a PR for upstream inclusion). FWIW git-publish [1] can Cc the relevant people for free. [1] https://github.com/stefanha/git-publish On Wed, 13 Oct 2021 19:03:54 -0400 Will Cohen <wwcohen@gmail.com> wrote: > This is a continuation of a patch series adding 9p server support for Darwin, > originally submitted by Keno Fischer in mid-2018 > (https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg04643.html). In > some sense, this could be considered [PATCH v4] of that process, but I assume > that the multi-year gap merits a fresh start.. > This makes sense. For consistency with that assumption, it would also make sense to clear all preexisting Reviewed-by: tags. > It has since been updated and rebased for NixOS by Michael Roitzsch > (https://github.com/NixOS/nixpkgs/pull/122420) with a goal of resubmitting > upstream. I am submitting his patch set as suggested, as developed by Michael, > with his Signed-off-by headers included in full. > QEMU cares about tracking of who did what and follows a policy inspired from the linux kernel [2] [3]. Michael's Signed-off-by: should then appear on all patches, with a mention of the extra changes that he made, e.g. Signed-off-by: Keno Fischer <keno@juliacomputing.com> [Michael Roitzsch: - rebased for NixOS - some other change] Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> If no changes were made, you still need to add a Signed-off-by: tag. [2] https://wiki.qemu.org/Contribute/SubmitAPatch [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297 > Additionally, I have run the patches through checkpatch.pl and adjusted coding > style accordingly (with the exception of ignoring warnings about avoid Good ! If you have an account on gitlab, you can also push a branch there. It will be submitted to gitlab CI and maybe give you the opportunity to polish the patches some more before submission. > architecture specific defines in hw/9pfs/9p-util-darwin.c, where they seem > unavoidable), and have signed off on those modified commits. > As explained above, your Signed-off-by: is also needed in all patches, even if you didn't change them. Cheers, -- Greg > >
Many thanks for all the clarifications — it’s my first time using git-send-email and first time with mailing-list-based devel workflows. Will adjust accordingly, work through gitlab, and eventually resend via git-publish as v2. On Thu, Oct 14, 2021 at 3:04 AM Greg Kurz <groug@kaod.org> wrote: > Hi Will, > > It is strongly recommended that you Cc maintainers to increase the odds > they notice your patches in the flood of qemu-devel. FYI I only noticed > them because git-send-email Cc'd me thanks to the Reviewed-by: tags and > my address didn't change in the meantime. I'm thus Cc'ing Christian > who is the primary maintainer now (i.e. the person that can merge > your patches and send a PR for upstream inclusion). > > FWIW git-publish [1] can Cc the relevant people for free. > > [1] https://github.com/stefanha/git-publish > > On Wed, 13 Oct 2021 19:03:54 -0400 > Will Cohen <wwcohen@gmail.com> wrote: > > > This is a continuation of a patch series adding 9p server support for > Darwin, > > originally submitted by Keno Fischer in mid-2018 > > (https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg04643.html). > In > > some sense, this could be considered [PATCH v4] of that process, but I > assume > > that the multi-year gap merits a fresh start.. > > > > This makes sense. For consistency with that assumption, it would also > make sense to clear all preexisting Reviewed-by: tags. > > > It has since been updated and rebased for NixOS by Michael Roitzsch > > (https://github.com/NixOS/nixpkgs/pull/122420) with a goal of > resubmitting > > upstream. I am submitting his patch set as suggested, as developed by > Michael, > > with his Signed-off-by headers included in full. > > > > QEMU cares about tracking of who did what and follows a policy inspired > from the linux kernel [2] [3]. > > Michael's Signed-off-by: should then appear on all patches, with a > mention of the extra changes that he made, e.g. > > Signed-off-by: Keno Fischer <keno@juliacomputing.com> > [Michael Roitzsch: - rebased for NixOS > - some other change] > Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> > > If no changes were made, you still need to add a Signed-off-by: tag. > > [2] https://wiki.qemu.org/Contribute/SubmitAPatch > [3] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297 > > > Additionally, I have run the patches through checkpatch.pl and adjusted > coding > > style accordingly (with the exception of ignoring warnings about avoid > > Good ! If you have an account on gitlab, you can also push a branch there. > It will be submitted to gitlab CI and maybe give you the opportunity to > polish the patches some more before submission. > > > architecture specific defines in hw/9pfs/9p-util-darwin.c, where they > seem > > unavoidable), and have signed off on those modified commits. > > > > As explained above, your Signed-off-by: is also needed in all patches, > even if you didn't change them. > > Cheers, > > -- > Greg > > > > > > >
On Donnerstag, 14. Oktober 2021 12:48:55 CEST Will Cohen wrote: > Many thanks for all the clarifications — it’s my first time using > git-send-email and first time with mailing-list-based devel workflows. Will > adjust accordingly, work through gitlab, and eventually resend via > git-publish as v2. So the intended use case is macOS being host. Has this been tested, and if yes, using which 9p client and which macOS version? Best regards, Christian Schoenebeck
Correct. It's been tested and functions when applied to QEMU master, with host running macOS Big Sur 11.6 (personal machine) using client 9p2000.L (taking a cue from the guest mounting instructions on https://wiki.qemu.org/Documentation/9psetup). On Thu, Oct 14, 2021 at 7:57 AM Christian Schoenebeck < qemu_oss@crudebyte.com> wrote: > On Donnerstag, 14. Oktober 2021 12:48:55 CEST Will Cohen wrote: > > Many thanks for all the clarifications — it’s my first time using > > git-send-email and first time with mailing-list-based devel workflows. > Will > > adjust accordingly, work through gitlab, and eventually resend via > > git-publish as v2. > > So the intended use case is macOS being host. > > Has this been tested, and if yes, using which 9p client and which macOS > version? > > Best regards, > Christian Schoenebeck > > >
On Donnerstag, 14. Oktober 2021 14:22:19 CEST Will Cohen wrote: > Correct. It's been tested and functions when applied to QEMU master, with > host running macOS Big Sur 11.6 (personal machine) using client 9p2000.L > (taking a cue from the guest mounting instructions on > https://wiki.qemu.org/Documentation/9psetup). So it was the Linux kernel's 9p client on guest side with 9p 'local' fs driver and 9p transport driver was 'virtio-pci'. I was just wondering if somebody already bothered for macOS being the guest, because that use case is a bit more challenging, especially with macOS 11 and higher. But I see that's nothing you were into. > On Thu, Oct 14, 2021 at 7:57 AM Christian Schoenebeck < > > qemu_oss@crudebyte.com> wrote: > > On Donnerstag, 14. Oktober 2021 12:48:55 CEST Will Cohen wrote: > > > Many thanks for all the clarifications — it’s my first time using > > > git-send-email and first time with mailing-list-based devel workflows. > > > > Will > > > > > adjust accordingly, work through gitlab, and eventually resend via > > > git-publish as v2. > > > > So the intended use case is macOS being host. > > > > Has this been tested, and if yes, using which 9p client and which macOS > > version? > > > > Best regards, > > Christian Schoenebeck
Correct, sorry for the imprecise language. The use case being contemplated is limited to Linux as the guest side, specifically for cross-platform tools where the macOS implementation consists of integrating a Linux VM via QEMU. NixOS (updater of the original patch, https://github.com/NixOS/nixpkgs/pull/122420) would be able to use this to provide macOS support via a VM. Lima and Podman as containerization alternatives to Docker would like to performantly mount volumes between macOS users and their respective VMs. Lima currently accomplishes this via sshfs, but would like to move to 9p for stability/performance reasons (https://github.com/lima-vm/lima/issues/20). Podman has yet to fully settle on an implementation at all due to similar outstanding concerns, but the furthest along proposed implementation choice has been 9pfs as well (https://github.com/containers/podman/pull/11454), pending adoption of such functionality in QEMU upstream. On Thu, Oct 14, 2021 at 8:55 AM Christian Schoenebeck < qemu_oss@crudebyte.com> wrote: > On Donnerstag, 14. Oktober 2021 14:22:19 CEST Will Cohen wrote: > > Correct. It's been tested and functions when applied to QEMU master, with > > host running macOS Big Sur 11.6 (personal machine) using client 9p2000.L > > (taking a cue from the guest mounting instructions on > > https://wiki.qemu.org/Documentation/9psetup). > > So it was the Linux kernel's 9p client on guest side with 9p 'local' fs > driver > and 9p transport driver was 'virtio-pci'. > > I was just wondering if somebody already bothered for macOS being the > guest, > because that use case is a bit more challenging, especially with macOS 11 > and > higher. But I see that's nothing you were into. > > > On Thu, Oct 14, 2021 at 7:57 AM Christian Schoenebeck < > > > > qemu_oss@crudebyte.com> wrote: > > > On Donnerstag, 14. Oktober 2021 12:48:55 CEST Will Cohen wrote: > > > > Many thanks for all the clarifications — it’s my first time using > > > > git-send-email and first time with mailing-list-based devel > workflows. > > > > > > Will > > > > > > > adjust accordingly, work through gitlab, and eventually resend via > > > > git-publish as v2. > > > > > > So the intended use case is macOS being host. > > > > > > Has this been tested, and if yes, using which 9p client and which macOS > > > version? > > > > > > Best regards, > > > Christian Schoenebeck > > >
On Donnerstag, 14. Oktober 2021 15:23:25 CEST Will Cohen wrote: > Correct, sorry for the imprecise language. The use case being contemplated > is limited to Linux as the guest side, specifically for cross-platform > tools where the macOS implementation consists of integrating a Linux VM via > QEMU. > > NixOS (updater of the original patch, > https://github.com/NixOS/nixpkgs/pull/122420) would be able to use this to > provide macOS support via a VM. > > Lima and Podman as containerization alternatives to Docker would like to > performantly mount volumes between macOS users and their respective VMs. > Lima currently accomplishes this via sshfs, but would like to move to 9p > for stability/performance reasons > (https://github.com/lima-vm/lima/issues/20). Podman has yet to fully settle > on an implementation at all due to similar outstanding concerns, but the > furthest along proposed implementation choice has been 9pfs as well > (https://github.com/containers/podman/pull/11454), pending adoption of such > functionality in QEMU upstream. I only had a glimpse on the patches so far. From what I've seen, I don't expect much of a problem to bring this series through. I will have a closer look on v2 though. I also have to read the old discussions where I was not involved yet. Soft freeze for QEMU 6.2 is close BTW (November 2nd): https://wiki.qemu.org/Planning/6.2 Best regards, Christian Schoenebeck