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