[comp.sys.nsc.32k] real time op sys for the 32k. repost.

peter@stpl.UUCP (Peter CAMILLERI) (12/07/88)

I first posted this note a few weeks ago, and have been puzzled by the
lack of response. Then I remembered the bad case of HIV (Huge Internet Virus)
that caused so much trouble and figured it had clobbered my message. So
heres a repost. If you read the original and did'nt like it, tough! Flame
away, it's cold in the winter around here!

=========================================================================

Let me start of by saying that I am most pleased to note the larger volumes
of postings in this group. Many times I have felt that my technical questions,
all of which were answered very well, were about the only traffic. Keep the 
flow going!!!

I have been designing an application with the 32k for some time now, and I
can't help but feel that software options are limited to the following:

    Un*x - big, slow, expensive, monolithic.
    RTKs - tiny, fast, expensive, no local dev't tools.

I see the need for a 32k equivalent of the Motorola encouraged, OS/9 and
OS/K products. Its notable features are quick real time response, modular
construction ( modules, drivers and even file systems can be added on the
fly ), and small (128k RAM min, 256k or more recomended). 

The reason I mentioned this is that on several occasions I have noticed
similar pleas for such an OS in this newsgroup, and felt that I should
get off my duff and contribute to this fine idea!

So some brass tax :-)
  a modular approach would more readily facilitate a diverse genesis of
  our fledgling. The work could be divided on a module by module basis.

  each module could exist in several incarnations, and with some work, one
  could mix and match modules to create the desired whole.

Several approaches could be utilized to create the above nirvana. A few come
to mind:
1) a small message passing kernel, with modules implented as server tasks
      minix uses this approach, I think.
2) a small kernel is used to direct subroutine call via a network of indirect
   pointers. This is basically the OS/9 way, and it is quite fast, but not
   very portable.
3) and many more but this posting is getting too long :-)

I have acces to a 32k assembler, limited access to an ICM16 running BSD4.2,
and access to other Un*x based machines of less noble birth (ie: this one).
My message is simple. We need action! If a mailing list has been created,
please put me on it, else lets create one!

-- 
Peter Camilleri                              peter@ists.UUCP
Elan Data Technology Inc.                    peter@ists.yorku.ca
836 Yonge St., Toronto, Ontario,             uunet!mnetor!yunexus!ists!peter
CANADA M4W 2H1                               (416) 968-6668

=========================================================================

P.S I lied. I did get one response from nsc, suggesting that we consider
    looking into a nsc product called "Exec". There are a few problems
    with this.

    1) It is crucial that the op. sys. have NATIVE development tools. That
       is its own compilers, assemblers, edtiors etc. The "Exec" product
       has none of this, but could be a starting point...

    2) Perhaps this did'nt come through in the original posting, but as this
       system would be generated by community effort, it should be generally
       available in a manner not unlike GNU software. The "Exec" product is
       the property of nsc. Now if nsc would consider such a usage of a 
       pruduct that even it says:
                                                               Ray Curry

       I'm not certain in any event of the dispostion of nsc toward that
       sort of thing and the kernal of a properly designed system should
       be a small amount of albeit very finely crafted code.


-- 
Peter Camilleri                              peter@stpl.UUCP
Elan Data Technology Inc.                    
836 Yonge St., Toronto, Ontario,             uunet!mnetor!yunexus!stpl!peter
CANADA M4W 2H1                               (416) 968-6668

schultz@mmm.UUCP (John C Schultz) (12/11/88)

You mentioned that OS9 for Motorola processors was pretty good.  While it is
usable (mainly because it is so simple you can do anything without security
restrictions), it does have serious flaws that you, your company, or others
will hopefully not repeat.

Use either MSDOS/VMS commands or UNIX, not a mixture

Implement real pipes

Use a real C compiler instead of Microware's C compiler which apparently came
from a Cracker Jack box (no offense to Cracker Jack intended)

Supply reasonable UNIX style tools and try to retain the same flag settings

I would suggest the GNU software as a good place to start with some of these
things.-- 
   john c. schultz         schultz@mmm.3m.UUCP          (612) 733-4047
           3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000
  The opinions expressed herein are, as always, my own and not 3M's.

kim@mcrware.UUCP (Kim Kempf) (01/08/89)

In article <1190@mmm.UUCP> schultz@mmm.UUCP (John C Schultz) writes:
+You mentioned that OS9 for Motorola processors was pretty good.  While it is
+usable (mainly because it is so simple you can do anything without security
+restrictions), it does have serious flaws that you, your company, or others
+will hopefully not repeat.
+
+Use either MSDOS/VMS commands or UNIX, not a mixture
+
+Implement real pipes
+
+Use a real C compiler instead of Microware's C compiler which apparently came
+from a Cracker Jack box (no offense to Cracker Jack intended)
+
+Supply reasonable UNIX style tools and try to retain the same flag settings
+
+I would suggest the GNU software as a good place to start with some of these
+things.-- 
+   john c. schultz         schultz@mmm.3m.UUCP          (612) 733-4047
+           3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000
+  The opinions expressed herein are, as always, my own and not 3M's.

[John accidentally forgot to cross post this to comp.os.os9, so here it
 is.]
----------------
Kim Kempf, Microware Systems Corporation	{sun,uunet}!mcrware!kim