Xref: utzoo comp.sys.3b1:246 unix-pc.general:7504
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mauxci!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: comp.sys.3b1,unix-pc.general
Subject: Re: Device Driver For Developers and Hackers
Keywords: /dev/io, physical address access
Message-ID: <1991Feb13.134640.23984@eci386.uucp>
Date: 13 Feb 91 13:46:40 GMT
References: <1991Feb1.184009.2624@tc.fluke.COM>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Organization: Elegant Communications, Inc.
Lines: 24

In article <1991Feb1.184009.2624@tc.fluke.COM> vince@tc.fluke.COM (Craig Johnson) writes:
 [...]
|By the way, can anyone tell me the purpose of the subyte() and fubyte()
|calls in the vidram driver?  They appear to simply move a byte at a time
|in/out of the "u" user structure.  Why can't the data in the user
|structure be accessed directly like the other elements of the structure?

I apologize if I'm telling people something they already know,
especially since I haven't ever looked at the vidram driver or
any other 3b1 driver, but here goes anyway.  In other Unix kernels
that I have worked on, fubyte and subyte are used to fetch and
store a byte of data from/to the user address space.  They are
provided as routines (possibly macros) to allow enclosing the
access in protection code that will catch addressing faults without
causing a kernel panic.  Usually the user structure does not need
such protection however, unless it gets paged out to the swap area
along with the rest of the process's data (I think that this is
handled differently in different Unix implementations).  If the
driver is responding to an interrupt, then it has to allow for
the possibility that the process that it is working for might have
been swapped out.
-- 
Cure the common code...                      | John Macdonald
...Ban Basic      - Christine Linge          |   jmm@eci386