linux-kernel - Re: Suggestion: LKM should be able to add system call for itself

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 7 Jul 2008 16:42:13 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Jinkai Gao <mickeygjk@...il.com>
cc:	Bart Van Assche <bart.vanassche@...il.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Suggestion: LKM should be able to add system call for itself

On Monday 2008-07-07 14:36, Jinkai Gao wrote:
>
>Yes, all kinds of alternatives exist. But they are alternatives
>anyway, which are tricky ways to do things when you can't find a
>reasonable ways. Actually,to communication between userspace and
>kernel modules, all I need is a interface with two parameters, all the
>system calls can be implemented out of that. So basically you can
>write every system call using something like ioctl. But ioctl is not
>designed for generic purpose after all.

Two parameters? (I take it, syscall number and a pointer to data.)
ioctl can do the same. It takes a number and an unsigned long
(sufficent for a pointer) to data. I could do the same over a cdev, a
32-bit quantity serving as a number and a 64-bit quantity as a
pointer. The same holds for netlink. There are endless ways to pass
on bits into the kernel, and be it an ICMP packet. Once you have the
addresses, you can use copy_from_user(), and be done. That still
does not say why syscalls are better than ioctl or netlink.

Well, nl and cdevs become especially handy when passing on more data
than just a pointer... usually you can do away with the pointer
indirection, e.g.

	struct timespec n;
	syscall(123, &n);
vs	ioctl(somefd, 123, &n);
vs	write(cdevfd, &n, sizeof(n));
vs	nlmsg_write(it's not so easy in NL after all);

hooray. Win = 0.

>Why the number of system calls is growing?

It is not. The reiser4() system call was just as heavily debated
because it just did not seem to fit. 

>because the kernel is
>growing. why we don't use the alternatives to implement the new need
>for system calls? Because it doesn't make any sense.

It does not make any sense to discuss here. Each task to achieve has
a specific preferred method (syscalls, cdev, libnl, ioctl) to do it
over.

Maybe syscalls have been ok 20+ years ago. Maybe people still don't 
know cdevs or netlink because they are submerged in teaching DOS 
semantics only.
If syscalls were so übergreat, then /dev would be a lot less populated:
Where's my nvidiactl() syscall?
--
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/