> Most dynamic kernel modules have to have an interface with user level
> programs.
> Right now OS Linux has only three kind of such interfaces: device
> drivers,
You mean /dev/ nodes here, I assume.
> system calls and pseudo files in /proc FS.
[ I propose: ]
> int syscall_module( char *module_name, int request, void *data, int size);
> MODULE_NAME - Name of the kernel module ( in user space area ).
> REQUEST - A request number.
> DATA - Address of parameters ( in user space area )
> SIZE - Size of parameters
Tell you what, the idea of passing a string into the kernel all the
time seems a little wasteful. How about we add onther syscall to
resolve a text string into a number - that could be more efficient.
Let's call that new syscall "XXX":
int XXX(char *name);
The kernel probably doesn't need to change the name that we pass,
so let us add a "const" there. Perhaps it might also be useful to
specify some flags to XXX to warn in advance what we might be doing
(bear with me here):
int XXX(const char *name, int flags);
Now, your new module syscall can look at the number that was returned
by XXX:
int syscall_module(int d, int request, void * data, int size);
Cool, that looks nice. But wait - both the kernel and the user program
already know the size (and how to interpret) what the "data" argument
points to (the "request" argument defines the parameters), so let's get
rid of that. Now, we have.:
int syscall_module(int d, int request, void * data);
Even cleaner. But wait! What if some implementations don't actually
need to use the "data" argument? Well, let's make it optional:
int syscall_module(int d, int request, ...);
Now, if only there was a nice, easy way to determine which devices were
present.. How about we put it in a file in /proc? Even better, let's
make a directory for these "devices" - that way parsing is easier.
Now, how to ensure that only certain users can control this device? Well,
first we need a way to distinguish between multiple users of the device -
What if "XXX" returned a number which was only available to that
process? Of course, we'd need a "YYY" to free up that number, too:
int YYY(int d);
Now, since these devices look like directory entries, we can attach
"not-quite-files" to them. That'd be cool. If we give each of them an
inode, then we can attach the usual filesystem permissions to them. We
don't need any real daat attached, so lets always report st_size as zero.
They should probably go onto some sort of persistent storage, though, so
that we can change the permissions on them. We could make a "/dev"
directory to keep them in, so that we have them all in the one place.
So the XXX syscall should take a pathname, rather than just a string.
(Incidentally, all of these calls need better names - how about
opendevice, devctl and closedevice?)
Of course, we'd need a way to distinguish these "device files" from
genuine files. Maybe we could just add a new inode type..
So, I have butchered it slightly, but now your device control interface
looks like:
int opendevice(const char * pathname, int flags);
int devctl(int dd, int request, ...);
int closedevice(int dd);
Well, that looks like a rather useful interface. I think I might patent
it :-)
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/