On Wed, 28 Jul 1999, Colin Wood wrote:

> > Well I managed to reliably hang my system with them.  Some spl frobing and
> > setting the "completion variable" to zero has solved most of the problems. 
> 
> you've really gotta watch mucking with the spl in the ADB code.  you can
> easily hang things that way, and rather screw up over interrupt latency as
> well if you're not careful.

Sure, but that's why we have splx, right?

It just seems as if something was disabling interrupts, thus hanging
(well, you can break out of this and go on your merry way with the
debugger switch) the machine while the actual ADB command was being sent. 

Wrapping the "busy wait" loop with splsoft/splx seems to have alievated
this, and cause no ill effects (I pounded on the caps lock key while the
system was booting up and didn't notice anything).

> yeah, we probably don't have something quite right.  and it's also
> probably worse on some machines than on others :-)

There's nothing like trying to debug the ADB code, with an ADB keyboard. :^)

Just out of curiosity, what macines are supported with the direct code,
that aren't supported with the MRG?  Me, personally, I see less weirdness
with the MRG code. 

> > Ahh, and I figured I could get away with being extra lazy :^)
> 
> ah, but we'll have to train you out of that, won't we :-)

LOL

> well, the intention was to add a set of ioctl()'s to do it.  i doubt that
> i've got it in there right now, but my local code has something like this:

Righto, but I've left this disabled (untouched).

> keep in mind that a lot of the driver will need to change slightly when
> we go to wscons (including a shared ADB driver between the macppc and
> mac68k ports, i hope). 

qThis would be udoubtedly cool.  As long as the ADB driver is going to be
re-organized, perhaps it would be a good idea to move adb_direct.c (say
closer to macrom*), and split it up into a few different files.

- alex