lkml.org 
[lkml]   [2008]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-07-07 18:35    [W:0.035 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site