From: Richard Weinberger <richard@nod.at> Date: 2016-03-31 22:33:56
Recent happenings in the node.js community showed how fragile software is when
it comes to dependencies of fundamental algorithms like leftpad[1].
A node.js package which provided ledpad vanished and broke a lot of software.
This raised our attention and we came to the conclusion that it is the kernel's
job to provide such functionality such that node.js based applications can in future
rely in Linux's "don't break userspace" rule.
We hope that glibc and Andoid's bionic will soon offer wrapper functions for this
new leftpad system call.
We put leftpad into the kernel not only because of Linux's stable ABI,
also for performance reasons.
As everyone knows, within the kernel everything is faster and better.
Leftpad has millions of users, so it has to be as fast as possible.
This new system call will also help making services like left-pad.io[2]
faster and more reliable. If the leftpad() system call gets adopted by a wider user base
it might also make sense to add a generic npm() system call which acts like ioctl()
where kernel modules can register new functions that are often used by node.js.
Such functions might be, is_array(), is_int(), etc.
Enjoy,
//richard
[1] http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[2] http://left-pad.io/
[PATCH] Implement leftpad syscall
[PATCH] leftpad.2: Document new syscall
From: Richard Weinberger <richard@nod.at> Date: 2016-03-31 22:33:58
From: David Gstir <david@sigma-star.at>
Implement the leftpad() system call such that userspace,
especially node.js applications, can in the near future directly
use it and no longer depend on fragile npm packages.
Signed-off-by: David Gstir <david@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/syscalls.h | 1 +
kernel/sys.c | 35 ++++++++++++++++++++++++++++++++++
kernel/sys_ni.c | 1 +
4 files changed, 38 insertions(+)
@@ -0,0 +1,55 @@+.\" Copyright (c) 2016 sigma-star gmbh+.\" (office@sigma-star.at)+.\"+.\" %%%LICENSE_START(GPLv2+_DOC_FULL)+.\" This is free documentation; you can redistribute it and/or+.\" modify it under the terms of the GNU General Public License as+.\" published by the Free Software Foundation; either version 2 of+.\" the License, or (at your option) any later version.+.\"+.\" The GNU General Public License's references to "object code"+.\" and "executables" are to be interpreted as the output of any+.\" document formatting or typesetting system, including+.\" intermediate and printed output.+.\"+.\" This manual is distributed in the hope that it will be useful,+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the+.\" GNU General Public License for more details.+.\"+.\" You should have received a copy of the GNU General Public+.\" License along with this manual; if not, see+.\" <http://www.gnu.org/licenses/>.+.\" %%%LICENSE_END+.\"+.THLEFTPAD22016-04-01"Linux""Linux Programmer's Manual"+.SHNAME+leftpad+.SHSYNOPSIS+.nf+.B#include<sys/types.h>++.BI"intleftpad(char*src,charpad,char*dst,size_tdst_len);+.fi+.SHDESCRIPTION+This function provides left padding for strings.+.LP+The string in+.Isrc+will be left padded with the chosen padding character+.Ipad+and stored in+.Idst+ .+.SHRETURNVALUE+On success, returns the number of padding characters added.+.SHERRORS+.TP+.BEINVAL+The size of the destination buffer+.Idst+is shorter than the source string+.Isrc+ . Or the destination string is longer than 4096 bytes.+.SHSEEALSO+.BRsnprintf(3)
From: Michael Kerrisk (man-pages) <hidden> Date: 2016-03-31 22:46:38
On 04/01/2016 11:33 AM, Richard Weinberger wrote:
From: David Gstir <redacted>
Implement the leftpad() system call such that userspace,
especially node.js applications, can in the near future directly
use it and no longer depend on fragile npm packages.
Works can't express the importance of adding this system call!
Thanks so much for proposing and implementing it!
Acked-by: Michael Kerrisk <redacted>
Cheers,
Michael
From: Randy Dunlap <hidden> Date: 2016-03-31 23:36:31
Please be more careful in your description...
On 03/31/16 15:33, Richard Weinberger wrote:
Recent happenings in the node.js community showed how fragile software is when
it comes to dependencies of fundamental algorithms like leftpad[1].
A node.js package which provided ledpad vanished and broke a lot of software.
leftpad
This raised our attention and we came to the conclusion that it is the kernel's
job to provide such functionality such that node.js based applications can in future
rely in Linux's "don't break userspace" rule.
We hope that glibc and Andoid's bionic will soon offer wrapper functions for this
Android's
new leftpad system call.
We put leftpad into the kernel not only because of Linux's stable ABI,
also for performance reasons.
As everyone knows, within the kernel everything is faster and better.
Leftpad has millions of users, so it has to be as fast as possible.
This new system call will also help making services like left-pad.io[2]
faster and more reliable. If the leftpad() system call gets adopted by a wider user base
it might also make sense to add a generic npm() system call which acts like ioctl()
where kernel modules can register new functions that are often used by node.js.
Such functions might be, is_array(), is_int(), etc.
On Fri, Apr 01, 2016 at 12:33:32AM +0200, Richard Weinberger wrote:
quoted hunk
From: David Gstir <david@sigma-star.at>
Implement the leftpad() system call such that userspace,
especially node.js applications, can in the near future directly
use it and no longer depend on fragile npm packages.
Signed-off-by: David Gstir <david@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/syscalls.h | 1 +
kernel/sys.c | 35 ++++++++++++++++++++++++++++++++++
kernel/sys_ni.c | 1 +
4 files changed, 38 insertions(+)
From: Richard Cochran <richardcochran@gmail.com> Date: 2016-04-01 06:56:47
On Fri, Apr 01, 2016 at 12:33:32AM +0200, Richard Weinberger wrote:
From: David Gstir <redacted>
Implement the leftpad() system call such that userspace,
especially node.js applications, can in the near future directly
use it and no longer depend on fragile npm packages.
Signed-off-by: David Gstir <redacted>
Signed-off-by: Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/syscalls.h | 1 +
kernel/sys.c | 35 ++++++++++++++++++++++++++++++++++
kernel/sys_ni.c | 1 +
4 files changed, 38 insertions(+)
This is okay as far as it goes, but you need to add the other archs
and put the relevant maintainers onto CC.
Thanks,
Richard
From: David Gstir <david@sigma-star.at>
Implement the leftpad() system call such that userspace,
especially node.js applications, can in the near future directly
use it and no longer depend on fragile npm packages.
Signed-off-by: David Gstir <david@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
---
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
include/linux/syscalls.h | 1 +
kernel/sys.c | 35 ++++++++++++++++++++++++++++++++++
kernel/sys_ni.c | 1 +
4 files changed, 38 insertions(+)
This looks good, but since we want this to be as fast as possible we might just want to eliminate all
branches (Pesky bounds checks), and write directly into user memory to eliminate the pesky copy_from/copy_to. The second
idea would eliminate that slow kmalloc as well.
What do you think?
From: Richard Weinberger <richard@nod.at> Date: 2016-04-01 08:06:14
Am 01.04.2016 um 01:36 schrieb Randy Dunlap:
Please be more careful in your description...
I'm very sorry. Will do a v2 soon. ;-)
On 03/31/16 15:33, Richard Weinberger wrote:
quoted
Recent happenings in the node.js community showed how fragile software is when
it comes to dependencies of fundamental algorithms like leftpad[1].
A node.js package which provided ledpad vanished and broke a lot of software.
leftpad
quoted
This raised our attention and we came to the conclusion that it is the kernel's
job to provide such functionality such that node.js based applications can in future
rely in Linux's "don't break userspace" rule.
We hope that glibc and Andoid's bionic will soon offer wrapper functions for this
Android's
quoted
new leftpad system call.
We put leftpad into the kernel not only because of Linux's stable ABI,
also for performance reasons.
As everyone knows, within the kernel everything is faster and better.
Leftpad has millions of users, so it has to be as fast as possible.
This new system call will also help making services like left-pad.io[2]
faster and more reliable. If the leftpad() system call gets adopted by a wider user base
it might also make sense to add a generic npm() system call which acts like ioctl()
where kernel modules can register new functions that are often used by node.js.
Such functions might be, is_array(), is_int(), etc.
@@ -0,0 +1,55 @@+.\" Copyright (c) 2016 sigma-star gmbh+.\" (office-S6VGOU4v5edDinCvNWH78Q@public.gmane.org)+.\"+.\" %%%LICENSE_START(GPLv2+_DOC_FULL)+.\" This is free documentation; you can redistribute it and/or+.\" modify it under the terms of the GNU General Public License as+.\" published by the Free Software Foundation; either version 2 of+.\" the License, or (at your option) any later version.+.\"+.\" The GNU General Public License's references to "object code"+.\" and "executables" are to be interpreted as the output of any+.\" document formatting or typesetting system, including+.\" intermediate and printed output.+.\"+.\" This manual is distributed in the hope that it will be useful,+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the+.\" GNU General Public License for more details.+.\"+.\" You should have received a copy of the GNU General Public+.\" License along with this manual; if not, see+.\" <http://www.gnu.org/licenses/>.+.\" %%%LICENSE_END+.\"+.THLEFTPAD22016-04-01"Linux""Linux Programmer's Manual"+.SHNAME+leftpad+.SHSYNOPSIS+.nf+.B#include<sys/types.h>++.BI"intleftpad(char*src,charpad,char*dst,size_tdst_len);+.fi+.SHDESCRIPTION+This function provides left padding for strings.+.LP+The string in+.Isrc+will be left padded with the chosen padding character+.Ipad+and stored in+.Idst+ .+.SHRETURNVALUE+On success, returns the number of padding characters added.+.SHERRORS+.TP+.BEINVAL+The size of the destination buffer+.Idst+is shorter than the source string+.Isrc+ . Or the destination string is longer than 4096 bytes.
Why should the call be limited to an arbitrary number of 4096 bytes?
There is no such limit in malloc so why should we need one here?
NAK
Best regards
Heinrich Schuchardt
@@ -0,0 +1,55 @@+.\" Copyright (c) 2016 sigma-star gmbh+.\" (office@sigma-star.at)+.\"+.\" %%%LICENSE_START(GPLv2+_DOC_FULL)+.\" This is free documentation; you can redistribute it and/or+.\" modify it under the terms of the GNU General Public License as+.\" published by the Free Software Foundation; either version 2 of+.\" the License, or (at your option) any later version.+.\"+.\" The GNU General Public License's references to "object code"+.\" and "executables" are to be interpreted as the output of any+.\" document formatting or typesetting system, including+.\" intermediate and printed output.+.\"+.\" This manual is distributed in the hope that it will be useful,+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the+.\" GNU General Public License for more details.+.\"+.\" You should have received a copy of the GNU General Public+.\" License along with this manual; if not, see+.\" <http://www.gnu.org/licenses/>.+.\" %%%LICENSE_END+.\"+.THLEFTPAD22016-04-01"Linux""Linux Programmer's Manual"+.SHNAME+leftpad+.SHSYNOPSIS+.nf+.B#include<sys/types.h>++.BI"intleftpad(char*src,charpad,char*dst,size_tdst_len);+.fi+.SHDESCRIPTION+This function provides left padding for strings.+.LP+The string in+.Isrc+will be left padded with the chosen padding character+.Ipad+and stored in+.Idst+ .+.SHRETURNVALUE+On success, returns the number of padding characters added.+.SHERRORS+.TP+.BEINVAL+The size of the destination buffer+.Idst+is shorter than the source string+.Isrc+ . Or the destination string is longer than 4096 bytes.
Why should the call be limited to an arbitrary number of 4096 bytes?
There is no such limit in malloc so why should we need one here?
NAK
Sorry, the review window for this patch is now closed.
Please resend your comments on April 1st 2017.
Thanks,
//richard