Richard Lowe wrote:
> Frank Hofmann wrote:
>> On Wed, 21 Feb 2007, Brian Utterback wrote:
>>
>>> Because of the design of streams, it is sometimes the case that one
>>> would like to increase the stream head queue size. Streams modules
>>> can do this, but there is no way to do it outside the stream, except
>>> by increasing the default value.
>>>
>>> The defaults are controlled by a struct called "strm_info". If I print
>>> this out I get:
>>>
>>>> strm_info::print
>>> {
>>>    mi_idnum = 0
>>>    mi_idname = 0x18640f0 "strrhead"
>>>    mi_minpsz = 0
>>>    mi_maxpsz = 0xffffffffffffffff
>>>    mi_hiwat = 0x1400
>>>    mi_lowat = 0x400
>>> }
>>>>
>>>
>>> The time honored incantation that services uses to set this for
>>> customers is:
>>>
>>> echo strm_info+0x2c/W 3e030 | /usr/bin/mdb -kw  /dev/ksyms
>>>
>>> This bothers me for several reasons. First, the use of the constant
>>> offset 0x2c. Second, that the location specified by strm_info+0x2c
>>> is the lower half of the mi_lowat member, which I think will be
>>> a problem on x86.
>>>
>>> However, I can't seem to find a way to specify symbolically the
>>> mi_lowat location for writing. It didn't work to specify
>>> strm_info.mi_lowat as the address. Is there something I'm missing?
>>
>> Well, using:
>>
>>> strm_info::print -a mi_lowat
>> fffffffffbc76360 mi_lowat = 0x400
>>
>> you get the address. It is possible to shellscript this into an 
>> automatism; but I don't know if it's possible with one mdb pipe. 
>> Extracting just the address from above works via e.g.:
>>
>>> ::eval 'strm_info::print -a mi_lowat ! cut -d" " -f1'
>> fffffffffbc76360
>>
>> but mdb doesn't accept a pipe '|' after ::eval anymore, I.e. what 
>> would've been obvious for me to try:
>>
>>> ::eval 'strm_info::print -a mi_lowat ! cut -d" " -f1' | /W 3e030
>>
>> doesn't work, anything after the last '|' on this line is just ignored.
> 
> strm_info::print -a mi_lowat | /W 0x401
> 
> Seems to work.

Except I'm told that may not always be the case... so ignore that, at least 
until I figure out why :)

-- Rich


Reply via email to