Digging into a QEMU problem of slow data copying
linus.schreibt.jetzt
linus.schreibt.jetzt
To each their own, I just don’t understand why anyone would prefer this method.
I wonder how many C projects use linear scans instead of hash maps simply because C doesn't have it in its standard library.
It almost feels like the people who keep churning out new standards of C just gave up and decided that part of it couldn't be improved any further.
Why would C cease to be lightweight if it added default libraries with lots of capability?
I think this kind of library should generally be in user space, not standard lib as "standard lib is where libraries go to die" (they can't really be modified after because of backward compatibility) but I'm confused about your argument.
[*] aside from those targeting niche, embedded systems for which C++ is unavailable
https://gitlab.com/virtio-fs/virtiofsd
On NixOS: https://github.com/astro/microvm.nix
Having a nice maintainer to guide you through the process is really encouraging and brings more nice and bright people to the comunity. Kudos
For example I went to check and in crosvm we use a BTreeMap already for Fids for our p9 implementation (thankfully): https://github.com/google/crosvm/blob/main/common/p9/src/ser...
On WSL you would be using the “hyperv 9p server”.
Same Linux 9p client in both cases but that’s not where the fix was.
Reasonable question but the answer is still no.
Windows's file handling also is very slow at times (especially Windows Explorer has frustrating UX).
We can ask MS to release all their source and we will then fix all O(n) issues for them.
You have any suggestions for getting a foothold in the QEMU codebase?
Submitters: "Please use the original title, unless it is misleading or linkbait;" - this one was linkbait, so should not have been used. https://news.ycombinator.com/newsguidelines.html