linux-kernel - Adding syscalls (was: Re: [GIT PULL] Namespace file descriptors for 2.6.40)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 22 May 2011 10:15:23 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Linux Containers <containers@...ts.osdl.org>,
	netdev@...r.kernel.org,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	linux-arch@...r.kernel.org
Subject: Adding syscalls (was: Re: [GIT PULL] Namespace file descriptors for 2.6.40)

On Sun, May 22, 2011 at 02:33, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Linus Torvalds <torvalds@...ux-foundation.org> writes:
>> On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>> In a hopeless quest to avoid conflicts when merging a new system call
>>> and wiring it up I have pulled in bits of net-next and the parisc tree.
>>> You have already pulled the net-next bits.  The parisc bits in my tree
>>> are:
>>
>> Ok, this just means that I won't pull from you.
>
> Sure.  I will try to be a little more patient and resend the pull
> request after James has sent the pull request for the parisc tree.
> At which point the only unique changes in my tree will be mine.
>
>> It's that simple. We don't do this. Ever.
>
> Hah. I seem to remember bits of pulling from non-rebasing trees being ok
> in well defined contexts.  This seems like one.  Especially when you
> have checked with the maintainers.
>
> Plus all of the parisc bits in addition to being in the linux-next
> are trivially correct.
>
>> Why the hell did you even worry about wiring up parisc system calls?
>> That's not your job.
>
> Because in general it is the job of he who changes something to fix up
> every possible place.
>
> Now maybe I went a little too far in trying to resolve the conflicts,
> but I did check with the David Miller and James Bottomley and they knew
> what I was doing.
>
> Quite honestly adding system calls is a mess that know one seems to
> know how to do right.  So I flipped a coin and took a stab at it.

At first, I was delighted to see that somebody took care of adding
syscalls to the
non-popular architectures.

At second, I saw the conflicts in e.g. parisc and m68k due to this.

Hence now I think it's better to leave the wiring up to the
architecture maintainers, as
before.
I'm even thinking to suggest to first let go in the syscall (without
any wiring up, not
even on x86), and let all wiring up be handled afterwards. This would
enforce that
syscalls numbers are not cast in stone, until they hit mainline.

This does mean that scripts/checksyscalls.sh needs to be changed, as initially
new syscalls aren't wired up there neither. The implementation of the
syscalls needs
to announce somehow that it's there and that it's a syscall.

What do you think?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/