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