Re: Emulating missing linux syscalls

[Piyush Sachdeva <piyushsachdeva245%gmail.com@localhost>]

On Tue, Apr 19, 2022 at 4:38 AM Joerg Sonnenberger <joerg%bec.de@localhost> 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 <joerg%bec.de@localhost> wrote:
> > >
> > > Am Wed, Apr 13, 2022 at 09:51:31PM -0000 schrieb Christos Zoulas:
> > > > In article <Ylcr/ndudNE2AeHK%bec.de@localhost>, Joerg Sonnenberger  <joerg%bec.de@localhost> 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