From owner-cvs-sys  Sun Dec 15 04:46:36 1996
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA23971
          for cvs-sys-outgoing; Sun, 15 Dec 1996 04:46:36 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA23966;
          Sun, 15 Dec 1996 04:46:22 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id XAA03824; Sun, 15 Dec 1996 23:43:25 +1100
Date: Sun, 15 Dec 1996 23:43:25 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199612151243.XAA03824@godzilla.zeta.org.au>
To: bde@zeta.org.au, peter@spinner.DIALix.COM
Subject: Re: cvs commit: src/sys/i386/boot/rawboot Makefile
Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org, nate@mt.sri.com
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>My complaint is that they are hidden under i386/isa/ic/* making access to 
>them rather difficult.  There is nothing isa-specific about the i8042.h 
>file, except the two IO port control/data addresses (which are duplicated 
>from isa.h).  IMHO, the "chip defines" should have gone under 
>i386/include/ic so they could be accessable as #include 
><machine/ic/i8042.h> without having to obsuscate the code with -I paths or 
>bogus #include lines.

They shouldn't go in i386/include either.  There's nothing i386-specific
about them.

NetBSD now has them in in /sys/dev/ic.  I might prefer /sys/ic.  i8042.h
got renamed to i8042reg.h.  I don't like this.  An `ic' may have more
attributes than registers - it may have an instruction set..., and if
you think of registers as being their bus addresses, then the registers
aren't part of the ic.

Bruce