the way I was thinking to do it before I had the idea below would have
impacted performance in all cases.  with this new idea there should be
no performance penalty to return EIO for i/o errors, so I'm planning
on doing that now.  sorry if that wasn't clear.

presetting this new field (pcb_faulterrno? maybe pcb_onfault_errno?)
to EINVAL would be fine since that will the most common error, let's do that.
kcopy() and the like can then just return pcb_onfault_errno when a fault
occurs.

-Chuck


Bill Studenmund writes:
> On Wed, 16 Jun 1999, Chuck Silvers wrote:
> 
> > I'm guessing the performance difference would be noticable, yea.
> 
> Is this a performance hit in all cases, or only in EIO cases?
> 
> > now that I think about this a moment, it's actually not that hard to solve.
> > we can add a new "p_faulterror" field to struct proc, which is cleared
> > at the top of the page-fault handler and set to an errno when a fault is
> > not going to be resolved.  then the users of pcb_onfault can check
> > p_faulterror to get a real errno, falling back on EFAULT if p_faulterror
> > is 0.  I haven't thought thru all the details, but I think this would work.
> 
> Given that pcb_onfault would know when to return the error code - the fact
> that p_faulterror == 0 doesn't indicate an error-free situation - why not
> just initialize it to EFAULT, and let other faulters change the error as
> appropriate?
> 
> AFAICT in the general case, all we've added is a store (init to EFAULT)
> and the extra int in the struct (and any copies of this int).
> 
> Take care,
> 
> Bill