Re: syslogd and redirection of the debug output

[Wolfgang Lux <lux@heidelbg.ibm.com>]

> > Further I allways get very irritated when som program crashes and MiNT reports
> > it to the console, screwing up the entire GEM-console. Is it possible to 
> > redirect those error and debug messages to a virtual console? How?
> 
> At the moment, I don't think it's possible. You can only redirect it 
> to some BIOS device like the printer or serial port, and vcons aren't 
> BIOS devices. But it would be very good to have some more possibilities 
> like some type of core dump.
> 

This is only half of the story. Actually MiNT tries to write out its
error messages (and also messages passed to the kernel via the Salert
system call) to the pipe U:\pipe\alert. Only if there is no reader for
that pipe, error messages will written to the console. It should
therefore be possible to write a nice little program which opens
U:\pipe\alert and forward all data from the pipe to the standard
output. This program then could be run in a separate virtual
console.

Another possibility is to read the error information from
U:\pipe\alert and display it an alert box using an accessory (if you
run the old TOS) or a background program if you are under
MultiTOS. (Actually there is some such thing for MultiTOS, I vaguely
remember). This is especially easy because the kernel already formats
the error messages it writes to U:\pipe\alert as alert box strings. I
have an accessory at home which does excatly this thing.

However all this is true only for alerts from MiNT. The debug and
trace output from MiNT are always written to the console (which might
have been redirected in MINT.CNF to some other BIOS device).

> > 
> > Finally, is there any possibilities of taking GEM down (after bootgem), log out
> > and then start all over again (without rebooting the system)?
> 
> I didn't find one, but I didn't search very far... :(
> GEM (actually the AES) can't uninstall itself (at least older versions, 
> how is it about MultiAES?). So you would need a program that unhooks GEM 
> from its vectors and closes its workstation. 
> 

There are two problems with stopping the old AES (can't tell for the
MultiTOS AES, but I suspect the same is true for it). First, when you
start the AES via its boot vector, a small little driver will be
started, that will in turn start the actual AES code from the
ROM. If the AES finishes it will jump back and restart the AES
again. So when killing the AES, you have to kill the driver as
well. Second, the AES won't clean up its resources when it gets
killed. Especially it will not close its VDI handles. And the VDI will
behave very badly if you try to open a new real workstation, while
there is still an open workstation. (May be this is due to event
handlers which the AES installs at the VDI, I really don't know much
about VDI and AES internals.) I have written an extended version of
bootgem, which tracks all open workstations and closes them when the
AES gets killed (and also will terminate the driver process).

However, even then not all resources will get freed. A (necessary)
hack in the malloc code, marks all memory allocated from the ROM with
M_KEEP. This memory won't get freed when the AES is terminated, so you
end with --- in my setup --- around 100k of unusable memory after
terminating the AES.


Wolfgang

----
Wolfgang Lux
WZH Heidelberg, IBM Germany             Internet: lux@heidelbg.ibm.com
+49-6221-59-4546                        VNET:     LUX at HEIDELBG
+49-6221-59-3200 (fax)	                EARN:     LUX at DHDIBMIP