Subject: Re: freezing the scsi bus
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
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 ?
> 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
- 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
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.)
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B