On Tue, Apr 19, 2022 at 4:38 AM Joerg Sonnenberger <jo...@bec.de> wrote: > > Am Tue, Apr 19, 2022 at 02:39:44AM +0530 schrieb Piyush Sachdeva: > > On Sat, Apr 16, 2022 at 2:06 AM Joerg Sonnenberger <jo...@bec.de> wrote: > > > > > > Am Wed, Apr 13, 2022 at 09:51:31PM -0000 schrieb Christos Zoulas: > > > > In article <Ylcr/ndudne2a...@bec.de>, Joerg Sonnenberger > > > > <jo...@bec.de> wrote: > > > > >Am Tue, Apr 12, 2022 at 04:56:05PM -0000 schrieb Christos Zoulas: > > > > > > > > >splice(2) as a concept is much older than the current Linux > > > > >implementation. > > > > >There is no reason why zero-copying for sockets should require a > > > > >different system call for zero-copying from/to pipes. There are valid > > > > >reasons for other combinations, too. Consider /bin/cp for example. > > > > > > > > You don't need two system calls because the kernel knows the type of > > > > the file descriptors and can dispatch to different implementations. > > > > One of the questions is do you provide the means to pass an additional > > > > header/trailer to the output data like FreeBSD does for its sendfile(2) > > > > implementation? > > > > > > > > int > > > > splice(int infd, off_t *inoff, int outfd, off_t *outoff, size_t len, > > > > const struct { > > > > struct iov *head; > > > > size_t headcnt; > > > > struct iov *tail; > > > > size_t tailcnt; > > > > } *ht, int flags); > > > > > > There are essentially two use cases here: > > > (1) I want a simple interface to transfer data from one fd to another > > > without extra copies. > > > > > > (2) I wanto avoid copies AND I want to avoid system calls. > > > > > > For the former: > > > int splice(int dstfd, int srcfd, off_t *len); > > > > > > is more than good enough. "Transfer up to [*len] octets from srcfd to > > > dstfd, updating [len] with the actually transferred amount and returning > > > the first error if any. > > > > > > For the second category, an interface more like the posix_spawn > > > interface (but without all the extra allocations) would be useful. > > > > > > > Therefore, having the above const struct *ht to support > > mmap() will be a good option I guess. > > It covers a very limited subset of the desired options. Basically, what > you want in this case is something like: > > int splicev(int dstfd, struct spliceop ops[], size_t *lenops, off_t > *outoff); > > where spliceops is used to specify the supported operations: > - read from a fd with possible seek > - read from memory > - seek output > and maybe other operations I can't think of right now. lenops provides > the number of operations in input and the remaining operations on > return, outoff is the remaining output in the current block. Some > variant of this might be possible.
Thank you Joerg and Christos for helping me with this. I have successfully submitted a proposal for this project through the GSoC portal. Hope to make the cut this time :) -- Regards, Piyush