On Montag, 3. Oktober 2022 12:48:35 CEST Christian Schoenebeck wrote:
> On Montag, 3. Oktober 2022 10:05:14 CEST Daniel P. Berrangé wrote:
> > On Mon, Oct 03, 2022 at 11:05:34AM +0400, marcandre.lur...@redhat.com wrote:
> > > From: Marc-André Lureau
> > >
> > &
slirp and it detected correctly that it was installed
- then I uninstalled slirp-dev and slirp and build system still said:
slirp support: YES 4.4.0
... causing ...
../net/slirp.c:41:10: fatal error: libslirp.h: No such file or directory
41 | #include
| ^~~~
Best regards,
Christian Schoenebeck
On Samstag, 1. Oktober 2022 05:48:18 CEST Bin Meng wrote:
> Hi Christian,
>
> On Tue, Sep 27, 2022 at 7:07 PM Bin Meng wrote:
> > From: Bin Meng
> >
> > Use g_mkdir() to create a directory on all platforms.
> >
> > Signed-off-by: Bin Meng
On Donnerstag, 29. September 2022 13:41:06 CEST Christian Schoenebeck wrote:
> This patch is pure refactoring, it does not change behaviour.
>
> virtio-9p-test.c grew to 1657 lines. Let's split this file up between
> actual 9p test cases vs. 9p test client, to make it easier to
&
On Donnerstag, 29. September 2022 18:32:37 CEST Marc-André Lureau wrote:
> From: Marc-André Lureau
>
> If slirp is not found during compile-time, and not manually disabled,
> print a friendly error message, as suggested in the "If your networking
> is failing after updating to the latest git
As slirp was the
default networking (i.e. not just some exotic QEMU feature), wouldn't it make
sense then to make missing libslirp a build-time error by default?
Best regards,
Christian Schoenebeck
to virtio-9p-client.c,
add a new function v9fs_set_allocator() to be used by virtio-9p-test.c
instead of fiddling with a global variable across units and libraries.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
---
v1 -> v2:
- Move osdep.h include from virtio-9p-client.h to virtio
On Dienstag, 27. September 2022 21:47:02 CEST Greg Kurz wrote:
> On Tue, 27 Sep 2022 19:14:33 +0200
>
> Christian Schoenebeck wrote:
> > On Dienstag, 27. September 2022 15:05:13 CEST Linus Heckemann wrote:
> > > One more thing has occurred to me. I think the reclaimi
d in other ways, as opposed to when the connection is
> first established. I suspect this will be very rare in general, so it
> might be good to have a test case somewhere.
Always welcome! :)
https://wiki.qemu.org/Documentation/9p#Test_Cases
If you do, then please add the test as a separate patch.
Best regards,
Christian Schoenebeck
.
>
> Signed-off-by: Linus Heckemann
> Reviewed-by: Philippe Mathieu-Daudé
> Reviewed-by: Greg Kurz
> Message-Id: <20220908112353.289267-1-...@sphalerite.org>
> [CS: - Retain BUG_ON(f->clunked) in get_fid().
> - Add TODO comment in clunk_fid(). ]
> Signed-off-by:
On Dienstag, 27. September 2022 15:05:13 CEST Linus Heckemann wrote:
> Christian Schoenebeck writes:
> > Ah, you sent this fix as a separate patch on top. I actually just meant
> > that you would take my already queued patch as the latest version (just
> > because I had ma
; +}
> put_fid(pdu, fidp);
> }
>
> +g_array_free(to_reopen, TRUE);
> +
With `g_autoptr(GArray)` you can drop both g_array_free() calls.
> return 0;
> }
Also: I noticed that your changes in virtfs_reset() would need the same 2-loop
hack to avoid hash iterator invalidation, as it would also call put_fid()
inside the loop and be prone for hash iterator invalidation otherwise.
Best regards,
Christian Schoenebeck
On Montag, 26. September 2022 16:30:53 CEST Greg Kurz wrote:
> On Sat, 10 Sep 2022 19:46:55 +0200
>
> Christian Schoenebeck wrote:
> > This patch is pure refactoring, it does not change behaviour.
> >
> > virtio-9p-test.c grew to 1657 lines. Let's split this file up
On Samstag, 10. September 2022 19:46:55 CEST Christian Schoenebeck wrote:
> This patch is pure refactoring, it does not change behaviour.
>
> virtio-9p-test.c grew to 1657 lines. Let's split this file up between
> actual 9p test cases vs. 9p test client, to make it easier to
&
On Donnerstag, 22. September 2022 13:43:56 CEST Linus Heckemann wrote:
> Christian Schoenebeck writes:
> > On Freitag, 9. September 2022 15:10:48 CEST Christian Schoenebeck wrote:
> >> On Donnerstag, 8. September 2022 13:23:53 CEST Linus Heckemann wrote:
> >> > The
On Dienstag, 20. September 2022 12:31:29 CEST Bin Meng wrote:
> From: Bin Meng
>
> Use g_mkdir() to create a directory on all platforms.
>
> Signed-off-by: Bin Meng
> ---
Reviewed-by: Christian Schoenebeck
>
> Changes in v2:
> - Change to use g_mkdir()
>
>
On Freitag, 9. September 2022 15:10:48 CEST Christian Schoenebeck wrote:
> On Donnerstag, 8. September 2022 13:23:53 CEST Linus Heckemann wrote:
> > The previous implementation would iterate over the fid table for
> > lookup operations, resulting in an operation with
to virtio-9p-client.c,
add a new function v9fs_set_allocator() to be used by virtio-9p-test.c
instead of fiddling with a global variable across units and libraries.
Signed-off-by: Christian Schoenebeck
---
As I am working on extending the previously sent RFC [1] (which will be
using function calls
And running
9p as root fs also no longer feels sluggish as before. I mean I knew that this
fid list traversal performance issue existed and had it on my TODO list, but
the actual impact exceeded my expectation by far.
Thanks!
Best regards,
Christian Schoenebeck
ets.h | 18 ++
> util/oslib-posix.c | 19 +++
> 4 files changed, 40 insertions(+), 2 deletions(-)
Reviewed-by: Christian Schoenebeck
d that the hash table may be leaked as is. I'll address this in
> the next submission.
>
> Philippe Mathieu-Daudé writes:
> > [Style nitpicking]
>
> Applied these changes and will include them in the next version of the
> patch.
> Christian Schoenebeck
st);
> -if (!fidp) {
> -return 0;
> -}
>
> /*
> * v9fs_reopen_fid() can yield : a reference on the fid must be held
> @@ -534,7 +533,13 @@ static int coroutine_fn
> v9fs_mark_fids_unreclaim(V9fsPDU *pdu, V9fsPath *path) * iteration after we
> c
On Mittwoch, 31. August 2022 10:25:27 CEST Guoyi Tu wrote:
> On 8/18/22 20:58, Christian Schoenebeck wrote:
> > On Donnerstag, 18. August 2022 14:06:04 CEST Guoyi Tu wrote:
> >> Ping...
> >>
> >> Any comments are welcome
> >>
> >> On 8/12/22
On Freitag, 26. August 2022 14:38:27 CEST Bin Meng wrote:
> On Fri, Aug 26, 2022 at 7:16 PM Christian Schoenebeck
>
> wrote:
> > On Freitag, 26. August 2022 12:30:20 CEST Bin Meng wrote:
> > > On Fri, Aug 26, 2022 at 6:09 PM Christian Schoenebeck
> > >
>
On Freitag, 26. August 2022 12:30:20 CEST Bin Meng wrote:
> On Fri, Aug 26, 2022 at 6:09 PM Christian Schoenebeck
>
> wrote:
> > On Mittwoch, 24. August 2022 11:39:47 CEST Bin Meng wrote:
> > > From: Bin Meng
> > >
> > > Use the same g_mkdir
On Mittwoch, 24. August 2022 11:39:47 CEST Bin Meng wrote:
> From: Bin Meng
>
> Use the same g_mkdir_with_parents() call to create a directory on
> all platforms.
The same would be g_mkdir(), not g_mkdir_with_parents(), so please use that
instead.
> Signed-off-by: Bin Meng
> ---
>
>
On Montag, 18. Juli 2022 16:02:31 CEST Christian Schoenebeck wrote:
> On Montag, 18. Juli 2022 15:10:55 CEST Christian Schoenebeck wrote:
> > There are currently 4 different functions for sending a 9p 'Twalk'
> > request. They are all doing the same thing, just in a slightly di
would have voted for following glibc, except that it does
> that cast-to-long thing, which is incorrect behaviour when
> long is 32 bits and the return value from the function being
> tested is 64 bits.
Then simply int64_t as a type instead, and as "our own thing"?
Best regards,
Christian Schoenebeck
On Donnerstag, 18. August 2022 14:06:04 CEST Guoyi Tu wrote:
> Ping...
>
> Any comments are welcome
>
> On 8/12/22 19:01, Guoyi Tu wrote:
> > socket_get_fd() have much the same codes as monitor_fd_param(),
> > so qemu_get_fd() is introduced to implement the common logic.
> > now socket_get_fd()
On Montag, 8. August 2022 14:52:28 CEST Christian Schoenebeck wrote:
> On Montag, 8. August 2022 10:05:56 CEST Markus Armbruster wrote:
> > Nikita Ivanov writes:
> > > Summing up the discussion above, I suggest the following patch for TFR()
> > > macro refactorin
t;
># define TEMP_FAILURE_RETRY(expression) \
> (__extension__
\
>({ long int __result;
\
> do __result = (long int) (expression);
\
> while (__result == -1L && errno == EINTR);
\
> __result; }))
>
> The difference isn't just "type casting", it's also statement
> vs. expression.
>
> Is it a good idea to have the macro expand into a statement on some
> hosts, and into an expression on others? Sure, CI should catch any uses
> as expression, but delaying compile errors to CI wastes developer time.
For consistency and simplicity, I would define exactly one version (no ifdefs)
of the macro with a different macro name than glibc's TEMP_FAILURE_RETRY(),
and use that QEMU specific macro name in QEMU code everywhere.
As for statement vs. expression: The only advantage of the statement version
is if you'd need __result as an rvalue, which is not needed ATM, right? So I
would go for the expression version (with cast) for now.
The glibc history does not reveal why they chose the statement version.
Best regards,
Christian Schoenebeck
Lureau
Message-Id: <20220323155743.1585078-17-marcandre.lur...@redhat.com>
Signed-off-by: Paolo Bonzini
Wouldn't it make sense to first rename TFR() to something like
RETRY_ON_EINTR() and then doing this consolidation here on top?
Best regards,
Christian Schoenebeck
> diff --git a/hw/9
s"
> instead.
>
> Fixes: 039a68373c ("introduce -audio as a replacement for -soundhw")
> Signed-off-by: Thomas Huth
> ---
Reviewed-by: Christian Schoenebeck
That can easily happen unfortunately, as the hierarchy syntax here, like in
MAINTAINERS BTW, is not exa
On Montag, 18. Juli 2022 15:10:55 CEST Christian Schoenebeck wrote:
> There are currently 4 different functions for sending a 9p 'Twalk'
> request. They are all doing the same thing, just in a slightly different
> way and with slightly different function arguments.
>
> Merge th
designated initializers when calling this
function to turn usage into a declarative apporach, which is better
readable and easier to maintain.
Signed-off-by: Christian Schoenebeck
---
v1 -> v2:
* Also merge low-level function v9fs_twalk().
* Lower case twalk() function name.
* Lower c
ple seem to define a variadic macro, but you would have to do that for
each new function, e.g.:
#define SomeTask(...) someTask((SomeType) __VA_ARGS__)
Not very appealing.
> On Fri, 24 Jun 2022 19:46:18 +0200
>
> Christian Schoenebeck wrote:
> > There are currently 3 d
designated initializers when calling this
function to turn usage into a declarative approach, which is better
readable and easier to maintain.
Signed-off-by: Christian Schoenebeck
---
Before working on actual new stuff, I looked at the current unit test code
and thought it's probably a good time
Send Twalk request with nwname=0. In this case no QIDs should
be returned by 9p server; this is equivalent to walking to dot.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id:
---
tests/qtest/virtio-9p-test.c | 22 ++
1 file changed, 22 insertions
Extend previously added fs_walk_none() test by comparing the QID
of the root fid with the QID of the cloned fid. They should be
equal.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id:
<5bbe9c6931b4600a9a23742f5ff2d38c1188237d.1647339025.git.qemu_...@crudebyte.
, whereas the 2nd path component transmitted to server does not
exist. The expected behaviour is that 9p server would respond by sending
a 'Rwalk' response with exactly 1 QID (instead of 'Rlerror' response).
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id
Expect ENOENT Rlerror response when trying to walk to a
non-existent directory.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Based-on:
Message-Id:
<1f5aa50ace3ba3861ea31e367518282065a6.1647339025.git.qemu_...@crudebyte.com>
---
tests/qtest/virtio-9p-test.
The local variable 'name_idx' is used in two loops in function v9fs_walk().
Let the first loop use its own variable 'nwalked' instead, which we will
use in subsequent patch as the number of (requested) path components
successfully walked by background I/O thread.
Signed-off-by: Christian
, whereas patch 4 being preparatory, all other
patches are test cases to guard this Twalk issue.
Christian Schoenebeck (7):
tests/9pfs: walk to non-existent dir
tests/9pfs: Twalk with nwname=0
tests/9pfs: compare QIDs
' response by 9p server with error code ENOENT as
that fid is basically invalid.
And as we are at it, also check that the QID returned by 'Twalk' is
not identical to the root node's QID.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id
On Dienstag, 15. März 2022 11:10:25 CEST Christian Schoenebeck wrote:
> Currently the implementation of 'Twalk' does not behave exactly as specified
> by the 9p2000 protocol specification. Actual fix is patch 5; see the
> description of that patch for details of what this overall fix a
last error.
Despite QIDs being delivered to client in a more relaxed way now, it is
important to note though that fid still must remain unaffected if any error
occurred.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Message-Id:
---
hw/9pfs
On Mittwoch, 15. Juni 2022 17:52:49 CEST Greg Kurz wrote:
> On Tue, 15 Mar 2022 11:08:39 +0100
>
> Christian Schoenebeck wrote:
> > Current implementation of 'Twalk' request handling always sends an
> > 'Rerror'
> >
> > response if any error occured. The
On Mittwoch, 11. Mai 2022 17:57:08 CEST Shi, Guohuai wrote:
> > -Original Message-
> > From: Greg Kurz
> > Sent: 2022年5月11日 20:19
> > To: Shi, Guohuai
> > Cc: Christian Schoenebeck ; qemu-devel@nongnu.org;
> > Meng, Bin ; Bin Meng
> > Subject: R
On Freitag, 22. April 2022 21:57:40 CEST Dominique Martinet wrote:
> Christian Schoenebeck wrote on Fri, Apr 22, 2022 at 08:02:46PM +0200:
> > So maybe it's better to handle case-insensitivity entirely on client side?
> > I've read that some generic "case fold" cod
guests, even if Windows host would not support native symlinks.
However insecure code is still a no go. So the issues identified so far still
need to be resolved.
And patches must be presented in a way that would allow them being reviewed.
In their current form they are not.
Best regards,
Christian Schoenebeck
On Dienstag, 10. Mai 2022 15:40:06 CEST Greg Kurz wrote:
> On Tue, 10 May 2022 13:54:46 +0200
>
> Christian Schoenebeck wrote:
> > On Dienstag, 10. Mai 2022 12:18:33 CEST Christian Schoenebeck wrote:
> > > On Dienstag, 10. Mai 2022 04:17:44
On Dienstag, 10. Mai 2022 12:18:33 CEST Christian Schoenebeck wrote:
> On Dienstag, 10. Mai 2022 04:17:44 CEST Shi, Guohuai wrote:
> [...]
>
> > > > > > I tend to agree with Christian's remarks that this patch is too
> > > > > > big
> > > >
ic link by MinGW.
A function with POSIX signature could be added to 9p-util-win.c which would
call the native Windows function to create symlinks.
> > Anyway, there is another solution: re-work whole 9PFS code: not only
> > 9p-local.c, but also every file in 9p driver.
> > Replace every MinGW/POSIX APIs (e.g. open, lseek, read, write, close),
> > by Windows Native APIs (e.g. open -> CreateFile, lseek -> SetFilePointer,
> > read -> ReadFile, write -> WriteFile, close -> CloseHandle, etc.)
> > Then 9P can use Windows symbolic link feature.
> > However, I do think it is a good idea to replace everything.
>
>
> TYPO: it NOT is a good idea to replace everything.
Right, that does not make sense. The way to go is adding and implementing
missing system functions with POSIX signatures and POSIX behaviour for
Windows. Not turning the entire code base upside down.
Best regards,
Christian Schoenebeck
so many "#ifdef _WIN32", it may
> cause this file not readable.
>
> If stick to 9p-local.c being OS-agnostic, I think it is better to create two
> new files: 9p-local-linux.c and 9p-local-win32.c
The thing is, as this is presented right now, I can hardly even see where
deviating behaviour for Windows would be, where not, and I'm missing any
explanations and reasons for the individual deviations right now. Chances are
that you are unnecessarilly adding duplicate code and unnecessary code
deviations. For me this 9p-local-win32.c approach looks overly complex and not
appropriately abstracted on first sight.
I suggest waiting for Greg to give his opinion on this as well before
continuing.
Best regards,
Christian Schoenebeck
On Montag, 25. April 2022 16:27:05 CEST Bin Meng wrote:
> From: Guohuai Shi
>
> Some of Windows error numbers have different value from Linux ones.
> For example, ENOTEMPTY is defined to 39 in Linux, but is defined to
> 41 in Windows. So deleting a directory from a Linux guest on top
> of QEMU
On Montag, 25. April 2022 16:27:01 CEST Bin Meng wrote:
> From: Guohuai Shi
>
> Add a 9p local file system backend driver to support Windows,
> including open, read, write, close, rename, remove, etc.
>
> All security models are supported. The mapped (mapped-xattr)
> security model is
_fsword_t f_flags;
> +};
> +
> +#endif /* CONFIG_WIN32 */
> +
> #define SM_LOCAL_MODE_BITS0600
> #define SM_LOCAL_DIR_MODE_BITS0700
I don't think this header file is the right place to add these missing POSIX
types. I would add them to 9p-util-windows.h or something like that.
Best regards,
Christian Schoenebeck
On Dienstag, 3. Mai 2022 05:42:03 CEST Bin Meng wrote:
> On Tue, Apr 26, 2022 at 9:41 AM Bin Meng wrote:
> > +Mark
> >
> > On Mon, Apr 25, 2022 at 10:27 PM Bin Meng wrote:
> > > At present there is no Windows support for 9p file system.
> > > This series adds initial Windows support for 9p file
qemu_mknodat() is expected to behave according to its POSIX API, and
therefore should always return exactly -1 on any error, and errno
should be set for the actual error code.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
---
hw/9pfs/9p
R==93
when client tried to retrieve POSIX ACL xattrs, because errno 93
is defined as EPROTONOSUPPORT==93 on Linux, so Linux client believed
that xattrs were not supported by filesystem on host in general.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2022042112483
9p2000.L, it should
be fair to assume that 'rdev' field is assumed to be in Linux dev_t
format by client as well.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/20220421093056.5ab1e7ed@bahia/
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
---
hw
(at least by qemu/xattr.h), it is safe to fix this issue by
simply comparing against ENOATTR instead of ENODATA.
This patch fixes e.g. a command on Linux guest like:
cp --preserve=mode old new
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2866993.yOYK24bMf6@silver
) added 9p support for macOS hosts.
* Tests: Fix inode sequencing in 'synth' driver.
Christian Schoenebeck (7):
9pfs: fix inode sequencing in 'synth' driver
9pfs: fix qemu_mknodat(S_IFREG) on macOS
9pfs: fix
er/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Will Cohen
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
<3102ca936f88bc1f79d2a325e5bc68f48f54e6e3.1651228000.git.qemu_...@crudebyte.com>
---
hw/9pfs/9p-util-darwin.c | 9 +
1 file changed, 9 insertions(+)
diff
mknod() on macOS does not support creating sockets, so divert to
call sequence socket(), bind() and fchmodat() respectively if S_IFSOCK
was passed with mode argument.
Link: https://lore.kernel.org/qemu-devel/17933734.zYzKuhC07K@silver/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
server from driver's inode numbers).
Fix this issue by using prefix-increment instead of postfix-increment
operator while generating new inode numbers for subdirectories and files.
Link: https://lore.kernel.org/qemu-devel/3859307.hTDP4D0zbi@silver/
Signed-off-by: Christian Schoenebeck
Reviewed
On Samstag, 30. April 2022 18:37:40 CEST Richard Henderson wrote:
> On 4/30/22 04:44, Christian Schoenebeck wrote:
> > The following changes since commit
731340813fdb4cb8339edb8630e3f923b7d987ec:
> >Merge tag 'pull-riscv-to-apply-20220429' of github.com:alistair23/qemu
>
On Freitag, 29. April 2022 12:26:40 CEST Christian Schoenebeck wrote:
> A bunch of fixes for recently (in QEMU 7.0) added 9p support on macOS hosts.
>
> Note: there are still issues to address with case-insensitive file systems
> on macOS hosts. I sent a separate RFC on that icase is
R==93
when client tried to retrieve POSIX ACL xattrs, because errno 93
is defined as EPROTONOSUPPORT==93 on Linux, so Linux client believed
that xattrs were not supported by filesystem on host in general.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2022042112483
er/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Will Cohen
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
<3102ca936f88bc1f79d2a325e5bc68f48f54e6e3.1651228000.git.qemu_...@crudebyte.com>
---
hw/9pfs/9p-util-darwin.c | 9 +
1 file changed, 9 insertions(+)
diff
qemu_mknodat() is expected to behave according to its POSIX API, and
therefore should always return exactly -1 on any error, and errno
should be set for the actual error code.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
---
hw/9pfs/9p
server from driver's inode numbers).
Fix this issue by using prefix-increment instead of postfix-increment
operator while generating new inode numbers for subdirectories and files.
Link: https://lore.kernel.org/qemu-devel/3859307.hTDP4D0zbi@silver/
Signed-off-by: Christian Schoenebeck
Reviewed
mknod() on macOS does not support creating sockets, so divert to
call sequence socket(), bind() and fchmodat() respectively if S_IFSOCK
was passed with mode argument.
Link: https://lore.kernel.org/qemu-devel/17933734.zYzKuhC07K@silver/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
(at least by qemu/xattr.h), it is safe to fix this issue by
simply comparing against ENOATTR instead of ENODATA.
This patch fixes e.g. a command on Linux guest like:
cp --preserve=mode old new
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2866993.yOYK24bMf6@silver
9p2000.L, it should
be fair to assume that 'rdev' field is assumed to be in Linux dev_t
format by client as well.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/20220421093056.5ab1e7ed@bahia/
Reviewed-by: Greg Kurz
Reviewed-by: Akihiko Odaki
Message-Id:
---
hw
) added 9p support for macOS hosts.
* Tests: Fix inode sequencing in 'synth' driver.
Christian Schoenebeck (7):
9pfs: fix inode sequencing in 'synth' driver
9pfs: fix qemu_mknodat(S_IFREG) on macOS
9pfs: fix
On Freitag, 29. April 2022 16:16:54 CEST Bin Meng wrote:
> On Fri, Apr 29, 2022 at 9:48 PM Christian Schoenebeck
>
> wrote:
> > On Freitag, 29. April 2022 15:29:15 CEST Greg Kurz wrote:
> > > On Fri, 29 Apr 2022 21:19:51 +0800
> > >
> > > Bin Meng wrot
On Freitag, 29. April 2022 16:35:07 CEST Greg Kurz wrote:
> On Fri, 29 Apr 2022 15:50:35 +0200
>
> Christian Schoenebeck wrote:
> > On Freitag, 29. April 2022 14:56:50 CEST Greg Kurz wrote:
> > > On Fri, 29 Apr 2022 12:25:11 +0200
> > >
> > > C
On Freitag, 29. April 2022 14:56:50 CEST Greg Kurz wrote:
> On Fri, 29 Apr 2022 12:25:11 +0200
>
> Christian Schoenebeck wrote:
> > mknod() on macOS does not support creating sockets, so divert to
> > call sequence socket(), bind() and fchmodat() respectively if S_IFSOCK
>
On Freitag, 29. April 2022 15:29:15 CEST Greg Kurz wrote:
> On Fri, 29 Apr 2022 21:19:51 +0800
>
> Bin Meng wrote:
> > On Fri, Apr 29, 2022 at 9:08 PM Greg Kurz wrote:
> > > On Fri, 29 Apr 2022 14:46:26 +0200
> > >
> > > Christian Schoenebeck wrote:
&
On Freitag, 29. April 2022 13:28:39 CEST Bin Meng wrote:
> On Fri, Apr 29, 2022 at 7:16 PM Christian Schoenebeck
>
> wrote:
> > Linux and macOS only share some errno definitions with equal macro
> > name and value. In fact most mappings for errno are completely
> > d
qemu_mknodat() is expected to behave according to its POSIX API, and
therefore should always return exactly -1 on any error, and errno
should be set for the actual error code.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util-darwin.c | 3 ++-
1 file changed, 2
9p2000.L, it should
be fair to assume that 'rdev' field is assumed to be in Linux dev_t
format by client as well.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/20220421093056.5ab1e7ed@bahia/
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util.h | 39
er/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Will Cohen
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util-darwin.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/9pfs/9p-util-darwin.c b/hw/9pfs/9p-util-darwin.c
index bec0253474..e24d09763a 100644
--- a/hw/9pfs/9p-util-darwin.
(at least by qemu/xattr.h), it is safe to fix this issue by
simply comparing against ENOATTR instead of ENODATA.
This patch fixes e.g. a command on Linux guest like:
cp --preserve=mode old new
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2866993.yOYK24bMf6@silver
R==93
when client tried to retrieve POSIX ACL xattrs, because errno 93
is defined as EPROTONOSUPPORT==93 on Linux, so Linux client believed
that xattrs were not supported by filesystem on host in general.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2022042112483
mknod() on macOS does not support creating sockets, so divert to
call sequence socket(), bind() and fchmodat() respectively if S_IFSOCK
was passed with mode argument.
Link: https://lore.kernel.org/qemu-devel/17933734.zYzKuhC07K@silver/
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p-util
eck return value of snprintf() instead of strlen(filename).
[patch 2]
Christian Schoenebeck (6):
9pfs: fix qemu_mknodat(S_IFREG) on macOS
9pfs: fix qemu_mknodat(S_IFSOCK) on macOS
9pfs: fix wrong encoding of rdev field in Rgetattr on macOS
9pfs: fix wrong errno being sent to Linux cli
On Mittwoch, 27. April 2022 22:16:12 CEST Greg Kurz wrote:
> On Wed, 27 Apr 2022 20:54:04 +0200
>
> Christian Schoenebeck wrote:
> > mknod() on macOS does not support creating regular files, so
> > divert to openat_file() if S_IFREG is passed with mode argument.
> &g
On Mittwoch, 27. April 2022 22:36:25 CEST Greg Kurz wrote:
> On Wed, 27 Apr 2022 20:54:17 +0200
>
> Christian Schoenebeck wrote:
> > mknod() on macOS does not support creating sockets, so divert to
> > call sequence socket(), bind() and fchmodat() respectively if S_
qemu_mknodat() is expected to behave according to its POSIX API, and
therefore should always return exactly -1 on any error, and errno
should be set for the actual error code.
Signed-off-by: Christian Schoenebeck
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util-darwin.c | 3 ++-
1 file changed, 2
R==93
when client tried to retrieve POSIX ACL xattrs, because errno 93
is defined as EPROTONOSUPPORT==93 on Linux, so Linux client believed
that xattrs were not supported by filesystem on host in general.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2022042112483
er/
Signed-off-by: Christian Schoenebeck
Reviewed-by: Will Cohen
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util-darwin.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/9pfs/9p-util-darwin.c b/hw/9pfs/9p-util-darwin.c
index bec0253474..e24d09763a 100644
--- a/hw/9pfs/9p-util-darwin.
(at least by qemu/xattr.h), it is safe to fix this issue by
simply comparing against ENOATTR instead of ENODATA.
This patch fixes e.g. a command on Linux guest like:
cp --preserve=mode old new
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/2866993.yOYK24bMf6@silver
9p2000.L, it should
be fair to assume that 'rdev' field is assumed to be in Linux dev_t
format by client as well.
Signed-off-by: Christian Schoenebeck
Link: https://lore.kernel.org/qemu-devel/20220421093056.5ab1e7ed@bahia/
Reviewed-by: Greg Kurz
---
hw/9pfs/9p-util.h | 39
mknod() on macOS does not support creating sockets, so divert to
call sequence socket(), bind() and fchmodat() respectively if S_IFSOCK
was passed with mode argument.
Link: https://lore.kernel.org/qemu-devel/17933734.zYzKuhC07K@silver/
Signed-off-by: Christian Schoenebeck
---
hw/9pfs/9p-util
Use fchmodat(AT_SYMLINK_NOFOLLOW_ANY) instead of chmod().
[patch 2]
Christian Schoenebeck (6):
9pfs: fix qemu_mknodat(S_IFREG) on macOS
9pfs: fix qemu_mknodat(S_IFSOCK) on macOS
9pfs: fix wrong encoding of rdev field in Rgetattr on macOS
9pfs: fix wrong errno being sent to Linux client on ma
On Mittwoch, 27. April 2022 19:37:39 CEST Greg Kurz wrote:
> On Wed, 27 Apr 2022 18:18:31 +0200
>
> Christian Schoenebeck wrote:
> > On Mittwoch, 27. April 2022 15:31:42 CEST Greg Kurz wrote:
> > > On Wed, 27 Apr 2022 14:32:53 +0200
> > >
> > > Christi
On Mittwoch, 27. April 2022 19:12:15 CEST Will Cohen wrote:
> On Wed, Apr 27, 2022 at 12:18 PM Christian Schoenebeck <
>
> qemu_...@crudebyte.com> wrote:
> > On Mittwoch, 27. April 2022 15:31:42 CEST Greg Kurz wrote:
> > > On Wed, 27 Apr 2022 14:32:53 +0200
>
On Mittwoch, 27. April 2022 15:31:42 CEST Greg Kurz wrote:
> On Wed, 27 Apr 2022 14:32:53 +0200
>
> Christian Schoenebeck wrote:
> > On Mittwoch, 27. April 2022 12:18:10 CEST Greg Kurz wrote:
> > > On Wed, 27 Apr 2022 11:27:28 +0900
> > >
> > > Akihiko
201 - 300 of 1403 matches
Mail list logo
