Surprising fact about STREAMS service modules

Paul Campbell paul at taniwha.UUCP
Sun Dec 25 16:32:45 AEST 1988


In article <4385 at hcr.UUCP> larry at hcr.UUCP (Larry Philps) writes:
>Well, I just learned something about the STREAMS mechanism today.  Since I
>found it quite surprising, I thought I should mention it to the world before
>some other poor sucker gets surprised also.
>...
>the spl at which the driver service modules are called.  Silly me, I just
>assumed that it would be at splstr.  However, check out the following code
>fragment from io/stream.c.

I've always known about this but then I taught myself from the sources
(no manuals aroud then ...). I've always assumed that there are only
two things one can assume:

	- that no other service routine can be called while one is running
	  (this should not apply in MP systems .... I always thought that
	  multiple service routines could/would/should be running but none
	  in the same stream [or its stream head code]).
	
	- that timeouts will not go off while service routines are being run
	  (again this will probably not apply to MP systems).

What you CAN'T assume is that put routines will not be called while a service
routine is being run, one might be called from an interrupt service routine.

Something else that's always assumed is that ISRs are all called at IPLs
<= splstr (most systems I've worked with had splstr == 6 which is >= spltty).
I have worked on one system where the device we were working with interrupted 
at > splstr (it had to - it had horrible real-time constraints). The games
we had to play to make putq() safe were pretty bad!

	Paul

PS:	has anyone done a 'real' MP streams implementation? What sort of
	scheduling policies did you use? How did code have to change?
	Which of the above assumptions still apply? (This would probably
	make a good Usenix paper).

-- 
Paul Campbell			..!{unisoft|mtxinu}!taniwha!paul (415)420-8179
Taniwha Systems Design, Oakland CA

 	"Read my lips .... no GNU taxes"



More information about the Comp.unix.wizards mailing list