basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] IEEE FPU build problems

[Gwenole B. <gbe...@ma...>]

On Thu, 19 Sep 2002, Brian Johnson wrote:

> - Several of the header files declare routines as "extern inline" or
>   "PUBLIC inline".  The MIPSPro compilers don't like this, but they
>   are fine with "static inline".  (They really don't need "inline" at
>   all -- they automatically inline code as appropriate.)  core.h,
>   exceptions.h, flags.h, rounding.h

The PUBLIC/PRIVATE things are residuals from ancient time when I wanted to 
actually have C++ methods in the fpu class. Well, I will s/PUBLIC 
inline/static inline/ everywhere. The other bits should not conflict.

> - There are some #includes of "compiler/compemu.h", which doesn't seem
>   to be in CVS.  Removing them doesn't seem to hurt anything.
>   basilisk_glue.cpp, newcpu.cpp.

They are now. cvs update -d :-)

> - On IRIX, sizeof(double) == 8 and sizeof(long double) == 16.  This
>   interacts badly with fpu/types.h:  it makes types.h define both
>   USE_LONG_DOUBLE and USE_QUAD_DOUBLE, which leads to multiple
>   definitions of fpu_extended_shape in fpu/mathlib.h.  Turning off
>   either of the USE_xxx defines doesn't help; I get other errors.

OK, I will look again on a sparc host but I am not sure they had native 
sizeof(long double) == 16. I don't have any mips handy. Anyway, I will try 
to fool locally. Check cvs soon.

Bye,
Gwenole.

[B2-devel] IEEE FPU build problems

[Brian J. <bjj...@us...>]

Gwenole,

I'm having quite a bit of trouble getting the ieee fpu to build on
MIPS/IRIX:

- Several of the header files declare routines as "extern inline" or
  "PUBLIC inline".  The MIPSPro compilers don't like this, but they
  are fine with "static inline".  (They really don't need "inline" at
  all -- they automatically inline code as appropriate.)  core.h,
  exceptions.h, flags.h, rounding.h

- There are some #includes of "compiler/compemu.h", which doesn't seem
  to be in CVS.  Removing them doesn't seem to hurt anything.
  basilisk_glue.cpp, newcpu.cpp.

- On IRIX, sizeof(double) == 8 and sizeof(long double) == 16.  This
  interacts badly with fpu/types.h:  it makes types.h define both
  USE_LONG_DOUBLE and USE_QUAD_DOUBLE, which leads to multiple
  definitions of fpu_extended_shape in fpu/mathlib.h.  Turning off
  either of the USE_xxx defines doesn't help; I get other errors.

I can send you the make output if you want.  What would help?

						Brian

--------------------------------------------------------------------

   "It's OK to be stuck.  99% of the time in your own [research] work,
    you're stuck."
                                           -- Mark Lawrence

Re: [B2-devel] Integration of JIT compiler

[Gwenole B. <gbe...@ma...>]

On Tue, 17 Sep 2002, Gwenole Beauchesne wrote:

> I noticed a performance hit of about 30% wrt. the original B2/JIT tree!
> Needless to say, that's quite confusing.

Performance regression just fixed, forgot to -DSAHF_SETO_PROFITABLE. It's 
just better on P3 and similar arches.

Bye,
Gwenole.

[B2-devel] Integration of JIT compiler

[Gwenole B. <gb...@di...>]

Hi,

I have not comitted jit compiler into main tree yet as I am carrying out
some cleanups and testing first. However, though both uae_cpu/ directories 
from current B2/CVS+JIT and B2/JIT tree are almost identical but some 
unused code removed, I noticed a performance hit of about 30% wrt. the 
original B2/JIT tree! Needless to say, that's quite confusing.

Bye,
Gwenole, investigating...

Re: [B2-devel] Re: Integration of B2/JIT FPU core

[Gwenole B. <gb...@di...>]

Hi,

>> Then, what is left for a 1.0 release?
>
> I'd like to get runtime sample rate switching et. al. working for the
> Irix audio driver.  Not sure when I'll get a chance to work on it,
> though....  But it "shouldn't" take too long.

OK. While I get you, could you please test the current FPU code on 
Irix/mips, as you told me you had problems with 68040 FPU emulation? At 
least, the "ieee" core appears to have fixed the drawing problems with 
ClarisWorks Draw, unless I broke the original UAE core. ;-) However, the 
"scrollbar bug" is still there on arches that don't have sizeof(long 
double) > 8 and run MacOS 8.x.

Thanks,
Gwenole.

Re: [B2-devel] Re: Integration of B2/JIT FPU core

[Brian J. <bjj...@us...>]

> Then, what is left for a 1.0 release?

I'd like to get runtime sample rate switching et. al. working for the
Irix audio driver.  Not sure when I'll get a chance to work on it,
though....  But it "shouldn't" take too long.

						Brian J. Johnson

[B2-devel] Re: Call for memory about ancient FreeBSD configury changes

[Gwenole B. <gb...@di...>]

Hi,

configure.in rev 1.38 got some "clean-ups" for FreeBSD. In the meantime 
X86_ASSEMBLY no longer got defined on FreeBSD/i386. Does someone remember 
why?

A user reported B2/JIT compiled and ran on FreeBSD/i386 but I hadn't 
disabled X86_ASSEMBLY there.

Thanks,
Gwenole.

Re: [B2-devel] Re: Integration of B2/JIT FPU core

[Christian B. <cb...@th...>]

Hi!

On Fri, Sep 13, 2002 at 03:18:38PM +0200, Gwenole Beauchesne wrote:
> I would like feedback on how things go now. Especially if I broke things. ;-)

MacOS 7.6.1 still appears to work... :)

> Then, what is left for a 1.0 release?

The BeOS video code is not updated for run-time mode/depth switching yet.
(Maybe I should ditch the BeOS port... My BeOS usage has dropped to zero.
Is anyone interested in taking over?)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Large File support and portability

[Gwenole B. <gb...@di...>]

On Sat, 16 Mar 2002, Christian Bauer wrote:

> Hi!
> 
> On Sat, Mar 16, 2002 at 12:03:32PM +0100, Gwenole Beauchesne wrote:
> > Would it be OK for all of you to switch to autoconf-2.5+ ?
> 
> Yup.

Done. AC_SYS_LARGEFILE is now available everywhere. Check for exit()  
prototype should now be functional among various architectures and
compilers sets.

Bye,
Gwenole.

[B2-devel] Re: Integration of B2/JIT FPU core

[Gwenole B. <gb...@di...>]

Hi,

I have just integrated the FPU emulation architecture that was used in the 
Basilisk II/JIT tree. I will merge the latter some time next week. I would 
like feedback on how things go now. Especially if I broke things. ;-)

Notes:

- An attempt is made to have an implementation relying on IEEE arithmetics
and data formats for float, double, and contants like NAN et al. It only
works on ix86 for now. Actually on arches where sizeof(long double) == 12,
which is not true everywhere. It will probably work on those where
sizeof(long double) == 16 but I don't have them to test.

- Ideally, we could even get rid of the x86 assembly core as it no longer 
brings anything wrt. to the "ieee" one. In other words, I don't have the 
"scrollbar bug" there.

- The "ieee" core features lazy evaluation of FPU condition codes, some 
68040-specific additions (FSMOVE et al.) and is used for the JIT compiler.

I will clean/play a little with that FPU core on my Powerbook this
weekend.

Then, what is left for a 1.0 release?

Bye,
Gwenole.

Re: [B2-devel] Better patch: subprocess as serial port

[Christian B. <cb...@th...>]

Hi!

On Thu, Jul 25, 2002 at 04:40:49PM -0500, Brian Johnson wrote:
> > Impressive. I can now edit B2 source files from within the emulation
> > using ZTerm. :-)
> 
> So, there's no reason ever to leave full-screen mode....

I'm considering removing QuitEmulator() for the 1.0 release. It is a pretty
obsolete function now, after all... ;-)

> [CVS]
> Sure, if you do.

Done.

> Could you add a note to the documentation saying how to use it, while
> you're at it?

I forgot. :-)

> Or would you like me to?

Yes. :-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Unix Video problems... still.

[[RSU]G-Lite <g-...@cl...>]

Well, I really couldn't be bothered doing the GUI thing again, so I took 
another look at the unix gfx problem.

First of all, afaik vidmode can't switch depth nor visual class, right? 
Just resolution. So my question is, why are we testing against all 
visual classes in find_visual_for_depth()? Seems to me you can use: ...

=============================
if (XMatchVisualInfo(x_display, screen, xdepth, DefaultVisual(x_display, 
screen)->c_class, &visualInfo))

    visual_found = true;

=============================

... instead of the whole switch statement.
If, however, I'm wrong and vidmode can switch visuals, then there's 
still a problem. (XMatchVisualInfo might be returning correct 
information in that case, btw) XF86VidModeSwitchToMode() requires a 
pointer to a struct XVidModeModeInfo to be passed to it, defined as:

=============================
typedef struct {

    unsigned int    dotclock;    
    unsigned short    hdisplay;    
    unsigned short    hsyncstart;    
    unsigned short    hsyncend;    
    unsigned short    htotal;    
    unsigned short    vdisplay;    
    unsigned short    vsyncstart;    
    unsigned short    vsyncend;    
    unsigned short    vtotal;    
    unsigned int    flags;    
    int    privsize;    
    INT32    *private;    

} XF86VidModeModeInfo;
=============================

Thing is, there's no visual class anywhere in that struct, so how do we 
know it's actually switching to DirectColor? (which is what 
XMatchVisualInfo returned)

Then for something else, when forcing TrueColor (which is my default 
visual class), colors are scrambled. It might be inverted colors don't 
know for sure. (Black and white are normal, but the folder icons in Mac 
OS 8 are green instead of light blue and the background you get when 
booting from the CD (the one with the CDs on it) is green too) 
DirectColor is messed up too, but DirectColor messes up colors in the 
whole X Server, not just Basilisk II so I can't tell whether it's 
displaying them right or wrong there. :)

    -Stéphan "G-Lite" Kochen

Re: [B2-devel] Better patch: subprocess as serial port

[Brian J. <bjj...@us...>]

--- Christian Bauer <cb...@th...> wrote:
>
> On Wed, Jul 24, 2002 at 03:39:25PM -0500, Brian Johnson wrote:
> > Here's an improved version of my subprocess-as-serial-port patch.
>
> Impressive. I can now edit B2 source files from within the emulation
> using ZTerm. :-)

So, there's no reason ever to leave full-screen mode....

> ...
> > Suggestions and fixes are most welcome.
>
> I had to add the line
>
>   #define debug(x) ;
>
> after the #include "strlcpy.h" at the beginning of sshpty.c to make
> the linker stop complaining about the missing debug() function.

OK.  Not sure why I didn't run into that....

> Apart from that it seems to work fine. I also took the liberty of
> modifying the kSERDBaudRate selector function to set the actual baud
> rate with cfset[io]speed(), instead of 115200 baud regardless of the
> actual requested rate. :-)
>
> Do you consider this to be CVS-ready?

Sure, if you do.  Could you add a note to the documentation saying how
to use it, while you're at it?  Or would you like me to?

I did notice that if I open and close the serial port a couple times,
BII crashes with a bad reference of some sort.  (I'm using MacOS
7.5.5, running a shell under ClarisWorks 2.1's Comm. Toolbox-based
terminal emulator, quitting ClarisWorks between the opens.)  But I was
never able to use the serial ports at all before making my changes, so
I'm not sure if I caused it or not.

						Brian

--------------------------------------------------------------------

   Q:  How many Microsoft programmers does it take to change a lightbulb?
   A:  None.  They don't bother.  They simply change the standard
       to darkness.
                                           -- Shad Aumann

Re: [B2-devel] Better patch: subprocess as serial port

[Christian B. <cb...@th...>]

Hi!

On Wed, Jul 24, 2002 at 03:39:25PM -0500, Brian Johnson wrote:
> Here's an improved version of my subprocess-as-serial-port patch.

Impressive. I can now edit B2 source files from within the emulation using
ZTerm. :-)

> One question:  I currently call waitpid() from SERDPort::close().  Is
> waitpid() available on all supported platforms?  It's POSIX.  Does BSD
> have it these days, or does it need to use wait3()?

NetBSD 1.5.3 has a manpage for it. That's all I can say at the moment...

> Suggestions and fixes are most welcome.

I had to add the line

  #define debug(x) ;

after the #include "strlcpy.h" at the beginning of sshpty.c to make the
linker stop complaining about the missing debug() function. Apart from that
it seems to work fine. I also took the liberty of modifying the kSERDBaudRate
selector function to set the actual baud rate with cfset[io]speed(), instead
of 115200 baud regardless of the actual requested rate. :-)

Do you consider this to be CVS-ready?

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Better patch: subprocess as serial port

[Brian J. <bjj...@us...>]

Folks,

Here's an improved version of my subprocess-as-serial-port patch.  It
lets you pipe serial input/output to programs instead of actual ports,
as requested in the second-to-last item of the "TODO" file.  Here's
the URL:

  ftp://ftp.frontiernet.net/pub/users/brianj1/B2_pty_020724.patch

As before, just put a pipe character ("|") at the beginning of the
port device file name, and BII will allocate a pseudoterminal, connect
the master side to the BII serial infrastructure, and run the rest of
the port device file name as a program using "/bin/sh -c", with the
slave side of the pty as its standard input, output, and error.
I.e. BII will treat the process as a serial port, and the process will
think it's talking to a normal terminal.

This seems to work rather well on Irix:  I can run a Unix shell,
complete with command line editing, job control, and curses.  I can
even run a PPP daemon and get TCP/IP networking via PPP (see
Irix/README.networking)!  I could also imagine using this facility to
pipe data to lpr... I'm sure people will come up with lots of other
creative uses.

I replaced the awfully ugly GNU screen pty code with a much cleaner
version from openssh.  I also had to add openssh's strlcpy()
implementation, for platforms (like Irix) which don't have it in libc.
The configure changes should take care of selecting which one to use.

I also moved the pipe open code into a subroutine, and now clean up
the subprocess when closing the serial port.  (If the process exits
before the serial port closes, it will sit around as a zombie until
the close happens.  This is a bit ugly, but I couldn't easily figure
out a way to detect child process termination without using SIGCHLD.
And using signals would be way too much per-platform porting work.)

One question:  I currently call waitpid() from SERDPort::close().  Is
waitpid() available on all supported platforms?  It's POSIX.  Does BSD
have it these days, or does it need to use wait3()?

I'd appreciate it if people could try it out on different platforms.
I *think* I got all the configure stuff copied over from openssh
properly....  Suggestions and fixes are most welcome.

Thanks,

						Brian J. Johnson

--------------------------------------------------------------------

   "Computer, end program."
                                           -- Mr. Barclay

Re: [B2-devel] Simple fix for sheep_net module on Linux

[Christian B. <cb...@th...>]

Hi!

On Mon, Jul 22, 2002 at 08:05:30PM -0400, Steven N. Hirsch wrote:
> This lets sheep_net.o build with versioned symbols (if necessary) and 
> makes newer kernels stop griping about kernel pollution.

Thanks! :-)

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] Simple fix for sheep_net module on Linux

[Steven N. H. <sh...@ad...>]

All,

This lets sheep_net.o build with versioned symbols (if necessary) and 
makes newer kernels stop griping about kernel pollution.

Steve


--- sheep_net.c.orig	Tue Jan 15 09:58:39 2002
+++ sheep_net.c	Fri Jul 19 07:54:37 2002
@@ -18,6 +18,26 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#ifndef __KERNEL__
+#define __KERNEL__
+#endif
+
+#ifndef MODULE
+#define MODULE
+#endif
+
+/* determine whether to use checksummed versions of kernel symbols */
+#include <linux/config.h>
+#ifdef CONFIG_MODVERSIONS
+#define MODVERSIONS
+#include <linux/modversions.h>
+#endif
+
+/* modversions.h redefines kernel symbols.  Now include other headers */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/version.h>
@@ -626,3 +646,5 @@
 	kfree_skb(skb);
 	return 0;
 }
+
+MODULE_LICENSE("GPL");

[B2-devel] Re: Basilisk II MacOS X addressing modes

[Nigel P. <ni...@in...>]

I said:
> 2) The Mac OS X port of Basilisk II is built with an
>     addressing mode that does not support 24bit emulation.
>     (i.e. Direct Addressing, or Mode 2, in

Gwenole asked/stated:
> It really does work now? That's nice, thanks.

	Yes. Sorry, I think that I must have forgot to report that.
It has been working since March.

	Real addressing, however, is not yet possible.

--
| Nigel Pearson, ni...@in...    | "Reality is that which,   |
| Telstra iDevelopments, Sydney, Australia |  when you stop believing  |
|   Office: 9206 3468    Fax:  9212 6329   |  in it, doesn't go away." |
|   Mobile: 0408 664435  Home: 9792 6998   |  Philip K. Dick - 'Valis' |

Re: [B2-devel] Re: Basilisk II MacOS X addressing modes

[Gwenole B. <gb...@di...>]

On Tue, 2 Jul 2002, Nigel Pearson wrote:

> 2) The Mac OS X port of Basilisk II is built with an
>     addressing mode that does not support 24bit emulation.
>     (i.e. Direct Addressing, or Mode 2, in

It really does work now? That's nice, thanks.

Bye,
Gwenole.

[B2-devel] Re: Basilisk II MacOS X addressing modes

[Nigel P. <ni...@in...>]

On Tuesday, July 2, 2002, at 08:19  AM, Adrian Taylor wrote:

> Hi,
>
> I was wondering if you could tell me whether it's possible to get 
> Basilisk
> II into 24-bit addressing mode. I have some *very* old ZBasic 
> programmes I
> want to run on a modern Mac, and they won't work with 32-bit addressing.
> When I try to turn off 32-bit addressing from the memory control panel, 
> the
> setting does not "stick".


	Hi Adrian. This is something I actually don't know a lot about,
so I have copied it to the developer's mailing list. The other guys
can correct my mistakes!


> I'm using a Quadra ROM with a 68030 Mac IIci settings, and System 7.5.3.

	I think that you have two problems here:

1) You are using a 32bit ROM, which will probably
    never allow you to boot in 24bit mode, and

2) The Mac OS X port of Basilisk II is built with an
    addressing mode that does not support 24bit emulation.
    (i.e. Direct Addressing, or Mode 2, in
http://iphcip1.physik.uni-mainz.de/~cbauer/BasiliskII/TECH
    )


	If you are able to get an older ROM, I can try to
build you a version of the Mac OS X port with virtual
addressing so that it can use 24bit mode.



> Is the source for the MacOS X port available anywhere, so I can 
> investigate
> myself?

	Certainly. An old tarball of my code is at my mac.com homepage,
and the latest version is in the Basilisk II CVS archive.

--
| Nigel Pearson, ni...@in...   | "Now the world has gone to 
bed,
| Telstra iDevelopments, Sydney Australia |  Darkness won't engulf my 
head,
|   Office: 9206 3468    Fax:  9212 6329  |  I can see by infrared,
|   Mobile: 0408 664435  Home: 9792 6998  |  How I hate the night." 
-Marvin

[B2-devel] Multiple-monitor rewrite problem

[Nigel P. <ni...@in...>]

	I have just got the "native" Mac OS X implementation of
the multiple monitor stuff working. (though not checked in yet)

1) The user_data field came in very handy. Thanks

2) I had to do something pretty nasty to actually get it to work
    in fullscreen mode, and I would like to discuss that with you.



	Using OS X's CoreGraphics API:

a) bytes_per_row is very different to what you would expect, and

b) there is no documented way of getting the number of bytes per row
    of a given screen mode until _after_ you have actually changed to
    that mode. At the moment, I have a horrible hack:

// Nasty hack. CGDisplayAvailableModes() does not provide bytes per row,
// so we use a lot of magic numbers here.
// This will probably fail on anything but my G4 powerbook 400

static int CGBytesPerRow(const uint16 width, const video_depth depth)
{
     if ( depth == VDEPTH_8BIT )
         switch ( width ) {
             case 640: case 720:  return 768;
             case 800: case 896:  return 1024;
             case 1152:           return 1280;
         }

     if ( width == 720  && depth == VDEPTH_16BIT)    return 1536;
     if ( width == 720  && depth == VDEPTH_32BIT)    return 3072;
     if ( width == 800  && depth == VDEPTH_16BIT)    return 1792;
     if ( width == 800  && depth == VDEPTH_32BIT)    return 3328;

     return TrivialBytesPerRow(width, depth);
}


	Like I said, a horrible hack. The thing is that this sort of
hack was not necessary before the "multiple monitor" rewrite of
video.h and video.cpp, because:

i)  I was modifying mode.bytes_per_row in video_open(),
     which was then being used (as part of VideoModes)
     by the slot_rom stuff

ii) The new code uses VideoModes in the monitor_desc constructor,
     which I assume means that it is copied, and thus my OS X
     monitor->video_open() cannot correct the bytes_per_row field




	Does this all make sense?

	Can anyone think of a nicer way to do this,
apart from modifying the monitor_desc class and constructor?

--
| Nigel Pearson, ni...@in...   | "Now the world has gone to 
bed,
| Telstra iDevelopments, Sydney Australia |  Darkness won't engulf my 
head,
|   Office: 9206 3468    Fax:  9212 6329  |  I can see by infrared,
|   Mobile: 0408 664435  Home: 9792 6998  |  How I hate the night." 
-Marvin

[B2-devel] FreeBSD/x86 odd behavior

[Gwenole B. <gb...@di...>]

Hi,

I wanted to add support for the "ignoresegv" feature on FreeBSD/x86. 
SourceForge.net compile farm has FreeBSD 4.5. What doesn't look right is 
why testing that feature would hang the configure script whereas it 
passes well [*] as a standalone application outside the configure 
script??

[*] That even caused me to add decoders for movzbl and movzwl during the 
test/debug process to get it right.

I am really clueless here. :-( Idea anyone?

Thanks,
Gwenole

Re: [B2-devel] "ignoresegv" feature added

[Gwenole B. <gb...@di...>]

Hi,

> Actually, I'd hope this "fixes"  my APD-won't-work-on-MacOS-8.0 
> problem. Though Apple Personal Diagnostics  works nicely with the very 
> same hard file but updated to MacOS 8.1.

It does fix that problem.

> Linux/ppc will be supported as well some time this week.

Done.

AFAIK, there is just one non-user-friendly "bug" remaining: fullscreen 
DGA won't work if the requested visual in DGA mode doesn't match the 
actuall root visual. Actually, that's the case for me where a 
DirectColor visual is requested whereas the current visual is TrueColor. 
This is weird as in windowed mode, I can get a DirectColor visual 
however.

Bye,
Gwenole.

[B2-devel] "ignoresegv" feature added

[Gwenole B. <gb...@di...>]

Hi,

I have just added the SheepShaver "ignoresegv" feature to Basilisk II. I got 
inspired by Lauri's, UAE-JIT, SheepShaver altogether code. I hope users could 
use this feature though I reckon it might hide a real bug.

Linux/x86 is supported so far. Also, only MOV instructions are decoded.I will 
add other decoder-bits as bugs come in. ;-) Actually, I'd hope this "fixes" 
my APD-won't-work-on-MacOS-8.0 problem. Though Apple Personal Diagnostics 
works nicely with the very same hard file but updated to MacOS 8.1.

Linux/ppc will be supported as well some time this week. In the future, 
sigsegv.cpp will be yet another file shared with Basilisk II too.

Bye,
Gwenole

Re: [B2-devel] patch: subprocess as serial port

[Christian B. <Chr...@un...>]

Hi!

On 2002.05.06 20:11 Brian Johnson wrote:
> Just put a pipe character ("|") at the beginning of the port device
> file name, and BII will allocate a pseudoterminal, connect the master
> side to the BII serial infrastructure, and run the rest of the port
> device file name as a program using "/bin/sh -c", with the slave side
> of the pty as its standard input, output, and error.

That's cool. When I wrote the TODO entry, I only had something simple with
popen() in mind... :-)

This might actually work on BeOS, too.

> - How should BII call wait() to clean up after the subprocess exits?
>   From the serial port close handler?  From a separate pthread (so it
>   can block)?

From SERDPort::close(), I think.

> - Should I automatically drop privileges in the subprocess if BII is
>   running setuid?  What's the philosophy for making BII
>   security-conscious vs. just documenting the issues and saying, "if
>   you install BII as setuid, you do so at your own risk"?

"Dropping privileges"? "Security philosophy"? Um... ;-)

> - Is the current code structure OK, or would you prefer that I move
>   the PTY setup/fork/exec/etc. into a subroutine?

This might make it more readable.

> I also added a hook for midi support:  if the device name is "midi",
> it's treated specially (returns an error for now).  I have no idea if
> Mac MIDI drivers actually use the serial manager, or if this is the
> best way to add MIDI to BasiliskII.

Apple's original (and long obsolete) MIDI driver poked the hardware
directly. I'm not sure about QuickTime and OMS (and there's one other
Mac MIDI API whose name escapes me at the moment). They probably do
the same. This needs further research...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/