Date: Tue, 19 Nov 2002 14:02:36 -0800 (PST) From: Nate Lawson <nate@root.org> To: Bruce Evans <bde@zeta.org.au> Cc: Jake Burkholder <jake@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/sab sab.c Message-ID: <Pine.BSF.4.21.0211191355420.61484-100000@root.org> In-Reply-To: <20021119203208.U30290-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Nov 2002, Bruce Evans wrote: > On Mon, 18 Nov 2002, Nate Lawson wrote: > > > > Modified files: > > > sys/dev/sab sab.c > > > Log: > > > - Add support for ALT_BREAK_TO_DEBUGGER; this is the only reliable way > > > to trigger a breakpoint with this chip. > > > > When I put together the GDB_AUTO_ENTER patch, I made a decision to > > abstract out the state machine. You pass it a char and it returns 1 if it > > has reached a match or zero otherwise. If multiple state machines were > > needed (say sio + sab) then the caller would pass in static storage for > > the state (say from the softc). Since you've duplicated the > > ALT_BREAK_TO_DEBUGGER state machine now, it should probably get moved into > > its own function as well. > > > > One question I had was where such state machines should go. Since they're > > dependent on DDB, I put mine in db_trap.c. Ideas? I think this is a > > useful move since there are UDP-based gdb stubs as well. > > The duplication is ugly, but so is looking at the data as it passes by > siointr() is supposed to do only pseudo-dma (*bufptr++ = read_ioreg() > for input, etc.) and everything else in it is a wart at best. But > we really do want to look at the data at pseudo-dma time for at least > the *BREAK_TO_DEBUGGER cases, since the higher-level interrupt or whatever > that finishes the input may be blocked forever (due to bugs). Exactly. I don't see a way around this except to: 1. Make any state machines lightweight 2. Put them under a kernel option (and sysctl if possible) > There may also be locking problems with a generic routine. Fast interrupt > handlers need different locking for (the closeure of) everything that > accesses the state. Since the state would be stored in the softc of a device (say, so two serial ports wouldn't stomp on each other's state), I assume that siointr would properly serialize input char handling anyway. Otherwise you'd be gettings chars out of order even in normal operation on an SMP box. The state machines are very lightweight -- merely an int read, switch, and store. Any answers to the question of where to put them or what interface they should use? -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0211191355420.61484-100000>