u source or should I just write to this mailing list or in
irc's #qemu channel (I'm both in freenode and oftc)?
* Do I need care of any license agreement stuff? If I'm right all
files which I need to work with are GPL2, which is fine for me.
Best regards and thanks,
Michael Frits
a 777 on all files if security modell "NONE"
* test everything - on Windows and Linux
Signed-off-by: Michael Fritscher
---
Many thanks to Stefan Weil for supporting me!
This is a resend, because I forgot the fact that this mail is sent from another
mail address than I
a 777 on all files if security modell "NONE"
* test everything - on Windows and Linux
Signed-off-by: Michael Fritscher
---
Many thanks to Stefan Weil for supporting me!
Makefile.objs | 1 +
configure | 15 +++-
fsdev/9p-iov-marshal.c | 2 +
f
't have to
have local function stubs in the 9p-local.c anymore.
To the licence: I asked because I know that other projects have a formal
process to cope with this - like a written agreement to be bound to the
license.
Best regards,
Michael
--
ZfT - Zentrum für Telematik e.V.
Michael Frit
end success for compatibility)
State of v1:
What works:
* mount
* stat
* chdir
* readdir (aka ls)
* read of small files (<10k)
* overwrite
What does not work:
* create new files (in 90% problems with path handling (old path occurs)
* read / probably write big fi
> It is broken since commit c619644067f98098dcdbc951e2dda79e97560afa.
>
> Reported-by: Michael Fritscher
> Signed-off-by: Stefan Weil
> ---
>
> Networking with QEMU for Windows is currently not usable,
> see bug report https://bugs.launchpad.net/qemu/+bug/1569988.
>
Hello Samuel,
> Michael, what do you mean by "slow", the bandwidth, or the time to
> connect? Does it help if you disable ipv6?
@Ipv6: I'll test it tomorrow.
I tested with wget http://www.heise.de.
On the guest program point of view, it seems to hang at waiting at the
first patch of data after
ve MSYS build + Ubuntu + Wine = ok
My MingW build + Ubuntu + Wine = ok
My MingW build + Windows 7 = (not testable)
You find my builds under
http://mifritscher.de/austausch/qemu/qemu_msys2.zip and
http://mifritscher.de/austausch/qemu/qemu-linux-mingw64.tar.gz .
Best regards,
Michael Fritscher
Which looking mechanism should I use?
Best regards,
Michael
P.S. is there a nice tool to edit / split patchfiles?
> More comments.
>
> On Tue, 12 Apr 2016 09:52:00 +0200
> Michael Fritscher wrote:
>
>> It was tested on Windows & Linux hosts, on the later no obvious
>
checked their current readdir implementation...)
No I haven't because "VirtFS is supported only on Linux" at the moment.
But thanks for raising the flag: it reminds me that there's ongoing
work to support VirtFS on win32 hosts and I should also Cc Michael
Fritscher.
Hi,
thanks
0×2160 (the standard 4k resolution, also known as 2160(p) or UHDTV)
7680x4320 (the standard 8k resolution, also known as 4320p, is also
defined as UHDTV)
I assume that you left out the common CGA/EGA resolution intentionally?
Best regards,
Michael Fritscher
--
ZfT - Zentrum für Telematik e.
Am 16.09.2016 um 10:56 schrieb Benjamin Herrenschmidt:
On Fri, 2016-09-16 at 10:37 +0200, Michael Fritscher wrote:
I assume that you left out the common CGA/EGA resolution
intentionally?
It's not because a resolution exists somewhere that we need it in the
driver's menu :-)
C
he
second. Meanings? If so I'll clean up the first patch series a bit
(History cleaning) and send it to the list.
Best regards,
Michael Fritscher
> On 29/09/2017 16:14, Michael Fritscher wrote:
>>> Yes, that's pretty much the only way to do it; it's not the easiest
>>> thing because you have to use NT kernel APIs (NtCreateFile) rather than
>>> e.g. CreateFile. Likewise for NtQueryAttribu
six function again and avoid using the NT*
> Functions directly which is not soooo nice for various reasons.
>
> Best regards,
> Michael Fritscher
>
Hi again,
I see one thing: symlinks somewhere in the path (which seemed to be the
reason introducing the *at family). But I think that thi
in.
This approach seems to work in general, but somehow I get stack
corrumption or something like that after returning from a function which
makes the relativ NTOpenFile call. But should be fixable. Then the big
work piece is to emulate posix behavior with NT* functions *g*
Michael Fritscher
>> I see one thing: symlinks somewhere in the path (which seemed to be the
>> reason introducing the *at family). But I think that this can be handled
>> by canonlizing the path, too. realpath should do the job quite well.
>>
>
> Unfortunately now because we have TOCTOU condition here: some path el
is to support 9p one day).
>>
>> Signed-off-by: Greg Kurz
>
> Acked-by: Cédric Le Goater
Acked-by: Michael Fritscher
Yes, I still plan to upstream the win32 9p support in the next weeks, when
my stress level goes down a bit ;-)
Best regards,
Michael Fritscher
>> ---
>
valents.
Yes, the code is a bit dirty (very WIP). Additionally, I seem to destroy
the stack, because after running this function qemu exists. Fixing this is
my next step.
Best regards,
Michael Fritscher#include
#include
typedef NTSTATUS (__stdcall *NT_OPEN_FILE)(_Out_ PHANDLE FileHandle, _
> On Fri, 29 Sep 2017 13:13:08 +0200
> Michael Fritscher wrote:
>> Signed-off-by: Michael Fritscher
>
> What's the justification for this patch ?
It had too much linuxisms in it to fix compiling - so I disabled the proxy
variant altogether. Reactivating it could b
ly.
I decribed these options a moment ago in the other mail in more detail.
For me both way are fine.
Best regards,
Michael Fritscher
21 matches
Mail list logo
