Jonathan, for the last goddamned time, fix you f*cking mailer.

If it can't send mail out with correct 'from' lines, it shouldn't be
sending mail at all.


(For those of you who Don't Understand, the message below was written
by Jonathan Stone and has a bogus 'From' line.  This has happened
... many times before, and he's been told about it at least once by me
in the past.)


cgd

------- Forwarded Message

	by mail1.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id PAA18743
	for <cgd@pa.dec.com>; Thu, 21 Aug 1997 15:17:22 -0700 (PDT)
Message-Id: <199708212216.PAA00831@Pescadero.DSG.Stanford.EDU>
To: Jason Thorpe <thorpej@nas.nasa.gov>
Cc: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>, cjs@portal.ca,
        cgd@pa.dec.com, martin@rumolt.teuto.de, wrstuden@loki.stanford.edu,
        scottr@plexus.com, matt@3am-software.com, tech-kern@netbsd.org
From: "Chris G. Demetriou" <cgd@pa.dec.com>
Subject: Re: bus.h style question 
Date: Thu, 21 Aug 1997 15:16:12 -0700


>So, thinking about the names makes me want something like:
>
>	bus_space_read_region_*s
>

I was thinking about better names, too; even i hated  my ones
Jason objected to.

I'd like the method names to use a consistent and `mnemonic'/obvious
ordering for the following attributes:

   + direction (read/write/copy),
   + datum size (currently bytes)
   + byteorder ( integer datum vs bytestream datum)
   + multiplicity (for _multi_ methods)

Not necessarily in that order, but (like cgd) I do think read/write is
the most signficant attribute and should be first.

My idea is to redesign the names for datum size and byteorder by using
int and byte prefixes:

	bus_space{read,write}_N ->   bus_space_{read,write}_int{8,16,32,64}

where the _intN names suggest (to me, anyway) translation to CPU
byteorder for ints. I think these names are a good implicit reminder
of the alignment restrictions, too.

The new `bytestream' methods would be

	bus_space_{read,write}_byte{1,2,4,8}

where the byteN suffix indicates bytestream access.  Maybe Jason's
stream would be better here; I don't know.

Multi (if desired) gets tacked in between read/write and the datum
type/size, just as we do now.. 

The _copy_ and _region_ routines would follow the same naming pattern,
with _region_ and _copy_ going in the same place as _multi_ (as we do now).

Comments??

------- End of Forwarded Message