public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Cedric Blancher <cedric.blancher@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Qemu packages for Cygwin?
Date: Wed, 3 Jan 2024 10:10:09 +0100	[thread overview]
Message-ID: <CALXu0UfAg8eFFePUdhM7MZ40xEPO6rnesaH66LLssAbckycS0Q@mail.gmail.com> (raw)
In-Reply-To: <92531229-4810-4c9c-89d2-67ee710a7863@SystematicSW.ab.ca>

On Mon, 18 Dec 2023 at 18:33, Brian Inglis via Cygwin <cygwin@cygwin.com> wrote:
>
> On 2023-12-18 00:14, Dan Shelton via Cygwin wrote:
> > On Mon, 18 Dec 2023 at 07:54, Marco Atzeri via Cygwin wrote:
> >> On 18/12/2023 07:42, Dan Shelton via Cygwin wrote:
> >>> Does Cygwin come with qemu packages?
>
> >> why should an "Unix Emulation layer" that run in "User Space"
> >> trying to run a "Full-system emulation" (https://www.qemu.org/) ?
> >> It seems like using square wheels
>
> > Nope. The Qemu packages on LInux have a much more wider functionality,
> > and more features, compared to the TUSBTADI "The User Should Be
> > Treated As Dumb Idiot" versions on Windows. It absolutely makes sense.
>
> Cygwin has trouble providing some POSIX features under Windows due to its API
> limitations, using "documented" Windows APIs, allowing it to run under ReactOS,
> Wine, and similar emulators, with which there is some interchange.
>
> It does not provide or support much in the way of privileged Unix or Windows
> features or access, except for providing emulation for running daemons as
> services, and some caching of SAM, AD, and process info.
>
> It is totally inadequate as a platform to provide or support any x86
> virtualization or even virtual machine management features, as it can not
> provide access to any machine features that do not have "documented" Windows APIs.
> Look at the /proc filesystem emulation limitations for examples of where Windows
> lacks APIs to get information available under Linux.
>
> You complain elsewhere about performance:

I am also complaining about performance, but it is NOT "performance in
general": What really sucks is the filesystem inode operations and
file name lookup, e.g. /bin/find&friends are absurdly slow because of
the link emulation and the inflation of syscalls caused by it - just
up to five times more accesses just to handle filename, filename.lnk,
filename.lnk.exe, filename.lnk.bat etc
Other areas have adequate performance, e.g. read/write performance is OK

> can you imagine how bad it would be,
> compared to Hyper-V, WSL, VirtualBox, etc.

No, qemu is called the "quick emulator", and has more functionality
than just being a hypervisor, like being able to emulate ARM and SPARC
platforms. Even if the x86 hypervisor cannot be used, there is still
lots of functionality.

If there are bugs in the POSIX emulation layer, then those bugs should
be 1) documented and 2) fixed.
Also please do not shoot down package proposals out of the FEAR that
"something" might not work.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

  reply	other threads:[~2024-01-03  9:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-18  6:42 Dan Shelton
2023-12-18  6:54 ` Marco Atzeri
2023-12-18  7:14   ` Dan Shelton
2023-12-18 17:33     ` Brian Inglis
2024-01-03  9:10       ` Cedric Blancher [this message]
2024-01-03 12:27         ` Brian Inglis
2024-01-03 18:41         ` matthew patton
2024-01-03 20:29           ` Richard Campbell

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=CALXu0UfAg8eFFePUdhM7MZ40xEPO6rnesaH66LLssAbckycS0Q@mail.gmail.com \
    --to=cedric.blancher@gmail.com \
    --cc=cygwin@cygwin.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 read-only IMAP folder(s) and NNTP newsgroup(s).