document-portal: Make possible to use on systems without splice support #1318
Conversation
| @@ -2010,7 +2012,7 @@ xdp_fuse_read (fuse_req_t req, | |||
| buf.buf[0].fd = file->fd; | |||
| buf.buf[0].pos = off; | |||
|
|
|||
| fuse_reply_data (req, &buf, FUSE_BUF_SPLICE_MOVE); | |||
There was a problem hiding this comment.
From the docs it sounds like FUSE_BUF_SPLICE_MOVE should be able to fall back to not using splice. Why is this needed?
There was a problem hiding this comment.
From what I understand, the docs mean that a splice move may decay to copying in some circumstances, but it still requires that the splice feature is supported by the FUSE server.
A FUSE client should not assume that the server supports some features. The FreeBSD implementation of FUSE doesn't implement that splice stuff which makes the code fail at the early initialization step. |
That seems like information that should be in the commit message and PR description, and/or in an issue report of the form "document-portal: Doesn't start on FreeBSD" that's closed by this PR. |
|
Code LGTM but I can't judge the details of the FUSE changes. |
|
Turns out that I'm thinking of a meson option that will set this compile time. Would that be acceptable? |
|
I made Meson check for |
|
Bump. Can we get this in? |
| @@ -260,6 +260,10 @@ typedef struct { | |||
| char name[0]; | |||
| } XdpInvalidateData; | |||
|
|
|||
| typedef struct { | |||
| gboolean use_splice; | |||
There was a problem hiding this comment.
Is there any need for this now? Could just replace opt->use_splice with #ifdef WITH_SPLICE ?
There was a problem hiding this comment.
This would spill #ifdefs across multiple places, which I find less readable.
And we might add more options in future, so I think it is better this way.
…pport The FreeBSD implementation of FUSE doesn't have splice features, which makes the code fail at the early initialization step.
|
Can we get this in? |
No description provided.