Emmanuel Dreyfus wrote:
> My plan was to set e_fault for all struct emul, but only use it where it
> is needed: in sys/arch/mips/mips/trap.c

Yes, this is what I would like to avoid. I'd like e_fault to behave
exactly as e.g. e_proc_{exec|fork|exit} or e_sysctl, i.e. it to be optional
part of emul interface. emuls which don't use it should not be required
to set it.

> No code change for non mips ports, but the field would be there just in
> case another emulation needs it some day.

> > I'd probably mark e_fault as either #ifdef __mips__  or with comment saying
> > where exactly it is currently used and for what purpose. Basically just
> > to avoid any confusion on whether it is or isn't needed for other compat code.
> 
> Why introducing MD conditionals in MI code? The current practice is not
> crippling struct emul with ifdefs: e_sysctl or e_nosys are defined for
> all archs, even if only arch supporting COMPAT_LINUX use it. 

OK, I'm not attached to #ifdef :) Just please add very verbose description
along the e_fault entry, to make it clear that it's usage is very special. 

> > Doesn't seem to cause any warning from compiler (not in a tiny
> > program I tested this with).
> 
> The goal of declaring the prototype for e_fault is to avoid referencing
> a wrong function. The check is a bit useless if you start cheating :o)

If the parameters wouldn't match (either vm_fault_t would change
type, or you passed something incompatible with int), you'd still
have it catched. I guess that you'd call uvm_fault() with the specified
arguments eventually anyway, so that would give compiler opportunity
to bitch about type mismatch.
I'd prefer to avoid introducing such circular dependency within headers.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-