From owner-freebsd-current  Sat Dec 27 19:47:50 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA12902
          for current-outgoing; Sat, 27 Dec 1997 19:47:50 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA12870
          for <freebsd-current@FreeBSD.ORG>; Sat, 27 Dec 1997 19:46:28 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA04367;
	Sun, 28 Dec 1997 14:42:55 +1100
Date: Sun, 28 Dec 1997 14:42:55 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199712280342.OAA04367@godzilla.zeta.org.au>
To: bde@zeta.org.au, grog@lemis.com
Subject: Re: Remote gdb (was: no boot: config -g and options DDB)
Cc: freebsd-current@FreeBSD.ORG, skynyrd@opus.cts.cwu.edu
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>> Yes, but fwrite() doesn't go on and talk to the device registers.  ddb
>>
>> Sure it does, if the output stream is a device.
>
>No, it calls write(2) to do it for it.

Of course.  Actually, it calls __sfvwrite() in FreeBSD, and write(2)
makes some far call, and the device driver about 5 layers below talks
to the device registers.

>>> ddb doesn't use the device driver.  It talks directly to the device
>>> with functions like:
>>>
>>> void
>>> siocnputc(dev, c)
>>
>> These functions are part of the device driver.
>
>OK, but they're only *part* of the device driver, and ddb calls them
>directly without first setting the control registers.

Of course.  Some layer in the driver sets them.

Bruce