[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] .xif module load problem
Hi!
Well, I have tried to make dummy.xif driver_init() with empty body and
it still did the same thing - kept stalling the boot process. When
modifying the module.c code to not to call the init() at all it doesn't
stall.
... calling external .xif module's init() function corrupts the stack as
I mentioned earlier. It seems a little weird when it looks like the code
below. When I toggle the #if 1 in the xif_load which employs the
xif_module_init() which is an adaptation of module.c:module_init() for
the .xif modules the problem disappears. But doesn't touch the stack
except for store/restore of all registers...
More thoughts?
STanda
/* dummy.xif ::: from sys/socket/xif/main.c */
long init (struct kerinfo *ker, struct netinfo *net);
long driver_init (void);
struct kerinfo *KERNEL;
struct netinfo *NETINFO;
long
init (struct kerinfo *k, struct netinfo *n)
{
KERNEL = k;
NETINFO = n;
return (driver_init () != 0) ? 1 : 0;
}
/* dummy.xif ::: from sys/socket/xif/dummyeth.c */
long driver_init(void) {
return 0;
}
/* inet.xdd ::: from sys/socket/inet4/ifload.c */
static long
load_xif (struct basepage *b, const char *name)
{
long (*init)(struct kerinfo *, struct netinfo *);
long r;
DEBUG (("load_xif: enter (0x%lx, %s)", b, name));
DEBUG (("load_xif: init 0x%lx, size %li", (void *) b->p_tbase,
(b->p_tlen + b->p_dlen + b->p_blen)));
/* pass a pointer to the drivers file name on to the
* driver.
*/
netinfo.fname = name;
#if 1
init = (long (*)(struct kerinfo *, struct netinfo *))b->p_tbase;
r = (*init)(KERNEL, &netinfo);
#else
r = xif_module_init((void*)b->p_tbase, KERNEL, &netinfo);
#endif
netinfo.fname = NULL;
return r;
}
Konrad Kokoszkiewicz wrote:
Also I don't understand why this workaround fixes the problem. Because
the actual problem is a stack corruption. After the dummy.xif module
successful load the load_modules() dirh.fs contains invalid filesystem
pointer... This happens for any .xif module I have tried.
IIRC, the workaround was introduced because the routine didn't otherwise
want to load anything except the first module it met. So maybe the
problem is inside the module's init() code - or rather inside kernel
functions it possibly calls - and not inside the loading routine.