Subject: Re: freezing the scsi bus
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 07/13/1999 12:44:34
>>>>> (1) How do I find all the address ranges I need to lock?
>>>> "man end", I'd say.
>>> And what about pte's, u./proc, etc ?
>> Huh?
> What mouse is saying is that "reasonably" should be removed from your
> last question and assume that anything which can be paged will be.

Actually, what I was concerned about was more

- the stack (how do I tell where it starts and how far I need it to
	extend)

- finding the beginning of the segments (etext, edata, and end give the
	*ends* of them, but what for the beginnings? end(3) says
	nothing of the sort exists.)

- other areas (mmapped space, such as shared libraries and malloc heap
	space, if malloc is ever made to use MAP_ANON rather than sbrk)

It does occur to me that the freeze-the-bus ioctl could do the locking,
which makes the whole problem vanish.  The only remaining problem is,
what if userland allocates more VM after freezing the bus (eg, a stdio
input buffer) and then sits idle long enough for the kernel to toss the
page?

Besides which, this works only if you do it from the console.  I don't
consider that acceptable, because it would mean shutting down my X
session every time I want to add or remove a device.  I'd rather drop
into ddb or the ROMs, which scribbles on the display but doesn't force
me to exit X.  (I want this mostly for use on Suns; much of the hair
comes from trying to do something that's reasonably portable, or at
least not unreasonably nonportable.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B