From owner-freebsd-hackers Mon Aug 3 16:57:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02464 for freebsd-hackers-outgoing; Mon, 3 Aug 1998 16:57:28 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from timingpdc.timing.com (timingpdc.timing.com [208.203.137.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02457 for ; Mon, 3 Aug 1998 16:57:23 -0700 (PDT) (envelope-from chanders@timing.com) Received: from count.timing.com ([208.203.137.222]) by timingpdc.timing.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 103-49575U100L2S100) with ESMTP id AAA89; Mon, 3 Aug 1998 17:58:32 -0600 Received: from count.timing.com (localhost.timing.com [127.0.0.1]) by count.timing.com (8.8.7/8.8.7) with ESMTP id RAA02513; Mon, 3 Aug 1998 17:56:39 -0600 (MDT) (envelope-from chanders@count.timing.com) Message-Id: <199808032356.RAA02513@count.timing.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Device driver synchronization with spl? In-reply-to: Your message of "Mon, 03 Aug 1998 16:22:06 PDT." <199808032322.QAA01662@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Aug 1998 17:56:39 -0600 From: chanders@timing.com (Craig Anderson) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks, I did not see man spl(9) yet. Another question. The driver is not configured it installed as an LKM. Is spltty() still appropriate? Help again! > > > > I would like an explanation of how the spl functions are used to > > sychronize a driver that uses interrupts. Code fragments from a > > driver I'm working on are at the end of the messages. The interrupt > > handler is installed on irq 11. > > 'man 9 spl' on a -current system contains a fairly succinct answer. > > > Here are my assumptions (guesses) so far. > > > > 1) gt401read() calls splgt401() to add a mask for irq 11. > > No. I don't believe that creating new spl's is trivial anymore. In > the first instance, I would simply add the 'tty' keyword to your > device's ISA configuration entry (see eg. the 'sio' entries for > examples). > > > 2) After splgt401() the interrupt function gt401intr will not run. > > This prevents a wakeup being lost between checking the data count > > and sleeping for data to show up. > > Not exactly. After spltty(), should an interrupt masked by the 'tty' > mask occur, it will be remembered, and when the mask is cleared the > interrupt handler will be run. > > > 3) The tsleep() causes another process to run with an interrupt > > mask that will allow gt401intr() to run. > > A call to tsleep() will put the current process to sleep, preserving > the current interrupt mask. When a new process is selected to run, the > mask is set to that for the new process. > > > 4) irq 11 happens and the handler gt401intr() is run. > > Yes, although the interrupt may have happened during the peroid when > the interrupt was masked. > > > 5) gt401intr() updates the data count and issues the wakeup. > > ... and returns. The woken process won't actually run until the > interrupt handler has returned. > > > 6) gt401read() returns from the tsleep() and sees that there is now data. > > It should check to see if there is data; it may have been woken for > other reasons (timeout, signal delivery, etc.). > > > > > Some questions. > > 1) Is my understanding of the spl usage good enough? > > Geting there. 8) > > > 2) If this is correct, what should splgt401() look like? > > Don't complicate things yet; stick with spltty(). > > > My guess here, after looking at /usr/src/sys/i386/include/spl.h is > > GENSPL(splbio, cpl |= some_mask) > > where some_mask is appropriate for irq11. If this is right what should > > some_mask be? > > spl.h has been obsoleted in -current, you can find it in i386/isa/ > ipl_funcs.c. Implementing a private interrupt mask is probably not a > useful thing to do, as it's more work that necessary. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message