David Laight wrote:
> A quick look at the ras code shows that the p_nras (of struct proc) is a
> pointless field.  Nothing actually needs to know the number of items on
> p_raslist.  All the checks for (p->p_nras [!]= 0) can be replaced by
> ([!]ISEMPTY(&p->p_raslist)) which is an equivalent test [1].

This would be good. The smaller the struct the better :)

> The overlap check in ras_install is also over-complicated:
> 
> 	nras = 0;
> 	LIST_FOREACH(rp, &p->p_raslist, ras_list) {
> 		if (++nras >= ras_per_proc ||
> 		    (addr < rp->ras_endaddr && endaddr > rp->ras_startaddr)) {
> 			simple_unlock(&p->p_raslock);
> 			return (EINVAL);
> 		}
> 	}

This only catches if new range is within existing range, not
if it partially overlaps start or end of other range.

> Is adequate here.
> 
> I also see no reason to have both p_lwplock and p_raslock, and propose
> replacing both with a single p_lock.

This would probably be good. What are they used for? Just to prevent
simultaneous access to the struct proc by several it's lwps? If that
is the case, having only 'p_lwplock' would be adequate IMO.

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