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

[Josh Boyer]

On Mon, 2008-07-07 at 10:00 -0400, Jinkai Gao wrote:
> On Mon, Jul 7, 2008 at 5:35 AM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote:
> >
> > On Monday 2008-07-07 07:09, Jinkai Gao wrote:
> >
> >>LKM(loadable kernel module) was first introduced for drivers. Users
> >>rarely need to talk to the modules directly. If does, several methods
> >>are available now, such as /proc file, interruption, etc. However,
> >>these interfaces are predefined, which makes the communication between
> >>user space and kernel space quite restricted.
> >
> > And that is good -- I certainly do not want something to step out of
> > bounds by accident or intention.
> >
> >>Of course, for driver modules, these mechanisms are enough. But as
> >>long as it is called Loadable Kernel Module instead of Loadable Kernel
> >>Driver, I think it should be able to do more than that. For example,
> >>LSM(linux security module),most of which(selinux, apparmor, etc.) use
> >>policy files as their core. Users write policy files, LSM make access
> >>control decision based on the files. Seems like users don't need to
> >>talk to LSM directly. But what if user want to temporarily disable a
> >>role or capability he is holding ? Not much he can do, isn't
> >>it(although nothing is impossible, making a new system call makes much
> >>more sense).
> >
> > I do not see what a syscall will buy over a "switch file" in procfs or
> > sysfs.
> >
> >>So The LKM should be able to define its own user interface
> >>by adding new system call for itself.
> >
> > And the point is? Why cannot it use, say, a character device?
> 
> Please refer to my reply to Bart.
> 
> >>And actually,  it is not hard to
> >>implement such kind of dynamic system call table as I thought it
> >>through.
> >
> > It is. You do not know what number your syscall will get. And if
> > you knew, it might just happen that this specific number is taken
> > in the next iteration in the Linux kernel.
> 
> 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

--
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/