Messages in this thread | | | Subject | Re: Suggestion: LKM should be able to add system call for itself | From | Josh Boyer <> | Date | Mon, 07 Jul 2008 10:16:51 -0400 |
| |
On Mon, 2008-07-07 at 10:00 -0400, Jinkai Gao wrote: > On Mon, Jul 7, 2008 at 5:35 AM, Jan Engelhardt <jengelh@medozas.de> 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
| |