>> what if the module had a list of function pointers at the begining of its
>> address space? then a snippit of org 0 asm code (well, actually just
>> data) could be used within each module to set up the pointers properly in
>> a 16 bit link, and the same asm stubs in the kernel would work for any
>> module of a given type. maybe with some cleverness, there could be only
>> one stub and a bunch of macros or wrappers for accessing it, to make
>> porting to other platforms easier.
[...]
>Oops... looks like I was right, and nobody had tried to implement
>MSDOS/UMSDOS support in ELKS... I was thinking that using UMSDOS as the
>primary filesystem would make it more usable (FAT is more commonly used
>than Minix filesystem -- or am I right?). Maybe I should try again with a
>newer kernel source.
UMSDOS is h u g e. While it *would* make ELKS easier to use, it would most
likely use so much space you couldn't use it for everything. Remember you need
the UMSDOS, MSDOS and FAT modules to make it work. If you *can* fit it in,
it'd be wonderful; but I'd be surprised.
>Concerning the function pointer business... it might work for kernel
>_functions_, but I doubt that it can work with kernel _variables_... :)
You'd have to wrap the major kernel variables in get-set functions. You
probably want to do this anyway, for code niceness reasons.
I was thinking, re the modules, that you could supply a system call that
turned a user process (with stack, CS, DS) into a system module:
struct filesystem_vtable functable = {
module_open,
module_close,
module_mount,
...
};
int main(int argc, char* argv[])
{
become_system_module(MODULE_FILESYSTEM, (void*)functable);
}
This would make them really easy to load; you just run (as root) the
appropriate program. The kernel's already got all the setup code needed. You'd
need some protection to stop it being killed when the kernel wasn't expecting
it, but that would be easy (give it a negative PID or something).
--
+- David Given ---------------McQ-+
| Work: [EMAIL PROTECTED] | FNORD
| Play: [EMAIL PROTECTED] |
+- http://wired.st-and.ac.uk/~dg -+
