Just a lurker with a question and idea...
How big is the minix code (x86 not source)? If it is big (relative to a
_plain_ FAT) maybe the minix fs is not necessary? and memory could be
freed by simplifying the filesystem? I understand the many limitations of
FAT but it appears that elks is going to be able to make an x86 a
relatively powerful workstation (kinda)... but a true multiuser box? are
ownership and permissions going to be as useful as the additional
workstation like functionality that can be added with the saved memory?
If the mem taken up by the minix code is relatively small forgive my
ignorance. Just wondering.
On Wed, 10 Feb 1999, David Given wrote:
> >> 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 -+
>
>
