Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!stc!root44!jgh
From: jgh@root.co.uk (Jeremy G Harris)
Newsgroups: comp.unix.questions
Subject: Re: Streams device driver programming questions
Summary: Answers
Keywords: streams driver
Message-ID: <1198@root44.co.uk>
Date: 17 Jan 90 08:53:31 GMT
References: <1990Jan12.221134.15243@icc.com>
Reply-To: jgh@root44.UUCP (Jeremy G Harris)
Organization: UniSoft Ltd, London, England
Lines: 46

In article <1990Jan12.221134.15243@icc.com> wdm@icc.com (William Mulert) writes:
[...]
> I am writing a driver, and the
>interrupt routine for the device has new data which it needs
>to put in an M_DATA message and send it upstream. Can anyone
>show me the proper way to:
>
>1. Allocate the message block?

if( (mp= allocb( sizeof(rxintr_data_t), BPRI_LO )) != NULL )
{

>2. Fill in the fields in the mblk_t and dblk_t structures?

mp->b_wptr += bytes_rxd;	/* everything else done by allocb() */

>3. Attend to any other important considerations?

/* copy data into mblk starting at b_rptr */

>I am assuming the isr can simply putq() the new message on the
>read side queue, and allow the drivers read side service routine
>to respond to the upstream flow control conditions, and pass
>the message upstream when canputnext() says it's ok.

So long as you don't exceed the configured limit on your read queue size.

>What should the driver programmer do if canput() says you
>can't use putq() to enqueue a message on the drivers own
>read queue? Is this a case where data may be lost due to
>flow control?

Yup.

References:  UNIX(tm) System V Release 3  STREAMS Programmer's Guide
	     AT&T  307-227  Issue 1

(The appendix is the most useful bit once you've read the thing once.
The intro-to-streams booklet [can't recall its real title, sorry]  may
be safely reserved for management types.)


Good luck,
	Jeremy
-- 
Jeremy Harris			jgh@root.co.uk