Re: DOSEMU hacker tool support and the modules package

Markus Gutschke (gutschk@uni-muenster.de)
19 Mar 1996 09:31:48 GMT


--Multipart_Tue_Mar_19_10:31:48_1996-1
Content-Type: text/plain; charset=US-ASCII

In article <m0tyTaF-000AhyC@lix.blox.se> bj0rn@blox.se (Bjorn Ekwall) writes:
> Brian R. Doherty <doherty@rice.edu> wrote:
> > Just out of curiosity: Why haven't the special DOSEMU features (i.e. the
> > resolution of symbols from /System.map) been rolled into the standard
> > modules distribution? It seems like a pretty handy feature.
>
> The "standard" answer (and it's rather good as well :-) ) is that if
> a module was allowed to use _any_ kernel symbol instead of the
> officially exported ones, we would all risk that a "popular" module
> might lock on to an internal symbol that is too low-level.
>
> This would lock the kernel development, since all modifications to the
> rest of the code would then have to be sub-optimally adapted in order
> to "preserve" this symbol.
>
> The set of officially exported symbols might not be perfect right now,
> but it is at least an attempt at an official kernel interface.

I share Bjorn's point of view, that we do not want modules to be able
to access arbitrary symbols. Fortunately, this does not seem to be
neccessary anyways; the way I understand it, dosemu's module is just a
convenience for the developers. It is expected, that emumod.o will
eventually become an official part of the kernel, when the code has
become more stable. Until then, some work-around is neccessary to load
these routines as a module. The dosemu developers chose to use a
modified version of insmod to get this work-around done, but there is
nothing that keeps you from using Bjorn's official module package. All
you need do, is add the missing symbols to linux/kernel/ksyms.c. I
prefer this approach, as it results in the least interference with
other parts of the system. Of course, we need to bear in mind, that
this is still a temporary work-around, that should *not* be part of
the official kernel distribution. Rather, it should probably be
distributed as a patch-file that is part of the dosemu
source-tree. Still, there is justification for the use of a modified
modules package, as it allows users that do not want (or know how) to
patch their kernel to still use dosemu at its current intermediate
state.

As a convenice, I include the patches that allowed me to use dosemu
with Bjorn's unmodified module package. Feel free, to do with this
file whatever you want, as long as you do not submit it to Linus for
inclusion into the mainstream kernel or to Bjorn for inclusion into
his module package :-) Actually, Bjorn might want to add this
information to his WWW page?

--Multipart_Tue_Mar_19_10:31:48_1996-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="dosemu-ksyms-1.3.71.diff"
Content-Transfer-Encoding: 7bit

--- linux-1.3.71/kernel/ksyms.c.orig Sun Mar 3 12:24:55 1996
+++ linux-1.3.71/kernel/ksyms.c Sun Mar 3 12:33:10 1996
@@ -106,6 +106,19 @@
extern void free_dma(unsigned int dmanr);
extern int (*rarp_ioctl_hook)(int,void*);

+extern die_if_kernel;
+extern do_bounds;
+extern do_debug;
+extern do_device_not_available;
+extern do_divide_error;
+extern do_int3;
+extern do_overflow;
+extern ret_from_sys_call;
+extern save_v86_state;
+extern sys_modify_ldt;
+extern sys_sigreturn;
+extern sys_vm86;
+
struct symbol_table symbol_table = {
#include <linux/symtab_begin.h>
#ifdef MODVERSIONS
@@ -319,6 +332,26 @@
X(simple_strtoul),
X(system_utsname),
X(sys_call_table),
+
+ /* dosemu needs these */
+ X(default_ldt),
+ X(die_if_kernel),
+ X(do_bounds),
+ X(do_debug),
+ X(do_device_not_available),
+ X(do_divide_error),
+ X(do_exit),
+ X(do_int3),
+ X(do_overflow),
+ X(gdt),
+ X(handle_vm86_fault),
+ X(idt),
+ X(ret_from_sys_call),
+ X(save_v86_state),
+ X(sys_modify_ldt),
+ X(sys_sigreturn),
+ X(sys_vm86),
+ X(task),

/* Signal interfaces */
X(send_sig),

--Multipart_Tue_Mar_19_10:31:48_1996-1
Content-Type: text/plain; charset=US-ASCII

--Multipart_Tue_Mar_19_10:31:48_1996-1--