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

[Eduard - Gabriel Munteanu]

On Mon, 07 Jul 2008 10:16:51 -0400
Josh Boyer <jwboyer@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/