;
> 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-b
On Montag, 3. Oktober 2022 14:50:04 CEST Daniel P. Berrangé wrote:
> On Mon, Oct 03, 2022 at 02:46:04PM +0200, Christian Schoenebeck wrote:
> > On Montag, 3. Oktober 2022 12:06:12 CEST Daniel P. Berrangé wrote:
> > > The current message when using '-net user...&
On Montag, 3. Oktober 2022 12:06:12 CEST Daniel P. Berrangé wrote:
> The current message when using '-net user...' with SLIRP disabled at
> compile time is:
>
> qemu-system-x86_64: -net user: Parameter 'type' expects a net backend type
> (maybe it is not compiled into this binary)
Is this inten
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
> > >
> > &
hat slirp was not installed
- then I installed 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 ver
functionality. 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
ed 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 v
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 reclaiming/re
ion that's
> already been used 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
ut 10.
>
> 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-of
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 made
bumped the
refcount for above already.
> +}
> 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 fi
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 O(n) comple
ed 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
6..7 here! 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
/sockets.h | 18 ++
> util/oslib-posix.c | 19 +++
> 4 files changed, 40 insertions(+), 2 deletions(-)
Reviewed-by: Christian Schoenebeck
; 0) {
>
> I noticed 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.
> Chris
> +GHashTableIter iter;
> +g_hash_table_iter_init(&iter, s->fids);
>
> -fidp = QSIMPLEQ_FIRST(&s->fid_list);
> - if (!fidp) {
> -return 0;
> -}
>
> /*
> * v9fs_reopen_fid() can yield : a reference on the
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_wi
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
> ---
>
> fsdev/v
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 sligh
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() a
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 refactoring. (The
#x27;s version is
>
># 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
e arguments"
> 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,
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.
>
>
ts and use 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.
e people 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
ts and use 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 proba
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.
he 1st path component
is valid, 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: Christi
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.
Sign
ctual fix is patch 5, 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/9
' request should
return an 'Rlerror' 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-
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 ove
already existing variable 'err' only reflects
the 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 Sch
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 an
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
ould
still work for 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
> > >
s) So we can not create symbolic 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
good idea to insert 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 fr
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 implemente
_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
ned ENOATTR==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/202
7;Tgettattr' is exclusive to protocol version 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:
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
n QEMU 7.0) 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_I
hC07K@silver/
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 insertion
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
QIDs
(which are derived by 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-
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
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
ned ENOATTR==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/202
hC07K@silver/
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 insertion
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
QIDs
(which are derived by 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-
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
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
7;Tgettattr' is exclusive to protocol version 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:
n QEMU 7.0) 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_I
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
> > >
> > > Christ
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
7;Tgettattr' is exclusive to protocol version 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.5ab1e7e
hC07K@silver/
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-ut
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
ned ENOATTR==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/202
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 client
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_IFSOC
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
ned ENOATTR==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/202
hC07K@silver/
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-ut
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
7;Tgettattr' is exclusive to protocol version 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.5ab1e7e
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
201 - 300 of 1001 matches
Mail list logo