Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!think!ames!aurora!labrea!decwrl!decvax!tektronix!reed!nscpdc!djg
From: djg@nscpdc.UUCP
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: Streams development tools
Message-ID: <934@nscpdc.NSC.COM>
Date: Thu, 24-Sep-87 11:43:57 EDT
Article-I.D.: nscpdc.934
Posted: Thu Sep 24 11:43:57 1987
Date-Received: Sat, 26-Sep-87 16:05:07 EDT
References: <123@mentat.UUCP> <1313@mtune.ATT.COM>
Organization: National Semiconductor, Portland Development Center, Portland, OR
Lines: 37
Xref: utgpu comp.unix.wizards:4158 comp.unix.xenix:715
Summary: Streams on I/O processors

In article <1313@mtune.ATT.COM>, jhc@mtune.ATT.COM (Jonathan Clark) writes:
# In article <123@mentat.UUCP> blc@mentat.UUCP () writes:
# I've been watching the "streams" discussion for the last little while
# with various people making statements about how easy/difficult it is
# to do streams development.  The nicest way we've found to do streams
# development is outside the kernel.
> 
> There's no reason that I can think of in 30 seconds apart from the need
> to access I/O space that *forces* stream modules to run in the kernel
> environment and address space. They would typically run *faster*
> there, because the support environment was designed to be the kernel.
> 
> I can certainly foresee in the future having a version of UNIX which
> runs in four rings: user, shared libraries, streams, and kernel. Five
> rings if you put device drivers between streams and kernel. Six if you
> stick the syscall interface somewhere appropriate. 7 and 8 anyone?
> 
> Conversely, running streams in user space would be useful mostly in
> the debugging phase of a project. Once the stream modules work (a
> Simple Matter of Programming, as Guy Harris said recently), you could
> put them into the kernel and forget about them. Saves all that
> tedious rebooting and disk rebuilding when your driver goes amok with
> the kernel buffer pointers...
> -- 

On National Semiconductors ICM series we have had several apporoaches to
stream module testing. Back in the days of V.2.2 we tried the dynamic overlay
scheme (modifing fmodsw). The overlays could be built using the
standard COFF tools (defining "real" sections as "dummy" sections and
leaving relocation bits on). When we progressed to I/O proccessors we arranged
our inter-processor interface to be "stream" supporting. Thus we can
"push" modules onto a remote processor. The processors code can be
dynamicly downloaded and board crashes automaticly close streams. (You
can also force this). We thus have very quick turn-around from comipile
to test and have all the advantages of off-loading the code onto dedicated
processors. In Jonathan`s scheme we have put streams and drivers on seprate 
processors. (now for kernel and shared libraries!)