Messages in this thread | | | Date | Mon, 7 Jul 2008 19:33:09 +0300 | From | Eduard - Gabriel Munteanu <> | Subject | Re: Suggestion: LKM should be able to add system call for itself |
| |
On Mon, 07 Jul 2008 10:16:51 -0400 Josh Boyer <jwboyer@gmail.com> wrote:
> > You are right. So we can use ascii name instead of number to > > identify the system call. Kernel will match the function with the > > name.To have backward compatibility, number should still be > > supported. Yes, it is not as easy as I thought, but as long as it > > is valuable and doable, we should have a try, right? > > So you have to search a list of strings using strcmp to determine what > syscall is being called? That would be horrible for performance. > > josh >
Actually it isn't that bad if you do it like dlsym()/dlopen() do it in userspace. That is, have the system linker fill in dynamic syscalls, possibly in a separate ELF section. This way you could version syscalls.
Furthermore, it may make sense to implement all syscalls through glibc, so that the burden of maintaining obsolete/modified syscalls does not fall onto the kernel. This already happens for most syscalls, but the rest (mostly those Linux-specific) still rely on syscall numbers defined as macros.
But that still will _not_ solve the problem, because: - there are users which will only use older libc versions - there are statically linked executables - the modified/new syscall might not provide the same behavior, even when used through a compatibility (glibc) wrapper
IOW, this problem can be reduced to any other instance where protocols or APIs get changed. This usually isn't a problem, but the kernel can't afford bloat to maintain compatibility.
I hope this makes the issue more clear.
Cheers, Eduard
| |