dal@syntel.UUCP (Dale Schumacher) (06/15/89)
The fast kernel copy routine I posted recently works quite well. However,
the associated modification that allows the filesystem to copy data directly
to/from the user's data space (which also uses the fast copy) has a nasty
gotcha in it. In almost all cases, on the ST, the virtual address is the
same as the physical address, ie. umap() does nothing. However, this is
not the case if a process is shadowed. Unfortunately, the information which
indicates that a process is shadowed is in the kernel process table, which
the filesystem does not have access to. Thus, when including the fast copy
modifications, you should either not apply the filesystem changes, or
#define HAVE_DCOPY 0.
I ran my system for a couple of days (during heavy development use) with
direct copying turned on and didn't have any problems. When I tried to
use the 'tos' program to move my changes over to the tos side, where my
mailer runs, I created a mess. I attributed my 'tos' troubles to some
further kernel changes I had been working on and used an older kernel to
get 'tos' to work, allowing me to post my changes to the net. Now I
must apologize for posting this mistake. Thanks to Howard Johnson and
Todd Inglett for helping me find this bug. Remember, however, that the
fast implementation of phys_copy() DOES WORK. It's just the HAVE_DCOPY
that must be avoided. Also keep in mind that there is a factor of 16
improvement in floppy performance just around the corner if someone can
find another way of feeding data to the floppy task more efficiently!
--
Dale Schumacher 399 Beacon Ave.
(alias: Dalnefre') St. Paul, MN 55104-3527
...bungia!midgard.mn.org!syntel!dal United States of America
"I may be competitive, but I'm never ruthless"