tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Emulating missing linux syscalls



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.

Joerg


Home | Main Index | Thread Index | Old Index