Re: Emulating missing linux syscalls

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

On Thu, Apr 14, 2022 at 3:22 AM Christos Zoulas <christos%astron.com@localhost> wrote:
>
> 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.
>

I was under the assumption that zero-copying would be a preference.
I did go through /bin/cp and the important copy_file() function. There
mmap() is being used and then data is written to the destination using
write(2) in chunks. Thanks for this Joerg!

> You don't need two system calls because the kernel knows the type of
> the file descriptors and can dispatch to different implementations.

Yes. Therefore, I am assuming that only one general splice(2) function
will be implemented and in case it's supplied a socketfd, it will behave like
sendfile(2). (as it is also clear from the function def you have
provided under.)
Also, add the sendfile(2) functionality and have it invoke splice(2).

> 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);
>

I will be more than happy to provide the functionality
(taking reference from writev(2) for the struct iovec
and the FreeBSD implementation of sendfile(2)).

> >I was saying that the Linux system call can be implemented without a
> >kernel backend, because I don't consider zero copy a necessary part of
> >the interface contract. It's a perfectly valid, if a bit slower
> >implementation to do allocate a kernel buffer and do IO via that.
>
Right, Joerg!


As I was initially also hoping to broaden the project by actually
adding the syscall
to the NetBSD kernel as well (adds a feature) and then have the
compat_linux layer
profit from that call. Unless that is something you are trying to
avoid/steer away from.

Now the final question for me is:
The splice() prototype that you just mentioned above, Christos. Is
that for a NetBSD syscall
(as I would hope given the struct iovec parameter) and then have both
splice(2) and
sendfile(2) implemented in compat_linux layer profiting from this syscall?
Or is it just splice(2) and sendfile(2) (which will call splice(2))
both in the linux layer
only?

> Of course, but how do you make an existing binary use it? LD_PRELOAD
> a binary to override the symbol in the linux glibc? By that logic you
> don't need an in kernel linux emulation, you can do it all in userland :-)
>

Christos, if you can shine some more light on this.

I guess this will make a great proposal and I will send you something by Monday,
I hope, for a first pass.

Hope to hear from you soon.
-- 
Regards,
Piyush