From leonid@rst.hellnet.org  Sun Jan  2 06:38:48 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Jan  2 06:38:57 PST 1994
Subject: Re: Where is Leonid Rosenboim?
I am still here folks, live and kicking. If e-mail fails for whatever
reason, you're welcome to send me a fax.

Happy New Year to All !
-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From morriss@smtplink.indigo.hellnet.org  Mon Jan  3 04:25:36 1994
From: Steve Morris <morriss@smtplink.indigo.hellnet.org>
Date: Mon Jan  3 04:25:46 PST 1994
Subject: Re: Where is Leonid Rosenboim?

Text item: Text_1

        >Has anybody heard from or talked with Leonid Rosenboim?  I can no 
        >longer send him Email at his last known address:  RST.HellNet.org.
        
        Having just spoken to him, I can assure you that he is well and still 
        living at RST@HellNet.org. The only possible cause for concern was a 
        slight garbling of his voice, but I suspect he was eating a sandwich at 
        the time.
        
----------------------------------------------------------------------
        
Steve Morris                        voice: (8)-381055 
Software Team Manager                      (8)-381818 
Indigo Graphic Systems              Fax:   (8)-408091
P.O. Box 150, Rehovot, Israel       e-mail: morriss@smtplink.indigo.hellnet.org
        
----------------------------------------------------------------------

From daemon@vxw.ee.lbl.gov  Tue Jan  4 04:01:31 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan  4 04:01:39 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan  4 04:01:23 PST 1994

        Subject: MVME167 MK48T08 TOD

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: MVME167 MK48T08 TOD
Date: Mon, 3 Jan 1994 18:23:47 GMT
From: steve@aplexus.jhuapl.edu (Steven Kahn)
Organization: Johns Hopkins U. Applied Physics Lab
Message-ID: <CJ2GFo.Fvn@netnews.jhuapl.edu>
Sender: usenet@netnews.jhuapl.edu

Does anyone happen to know of interface software for getting/setting
the MVME167 MK48T08 Time-of-Day clock?

Thanks in advance.

- -- 
=============================================================================
Steven Kahn,  room 6-103			       Steven_Kahn@jhuapl.edu
Johns Hopkins University Applied Physics Lab
Laurel, MD 20723-6099					      +1 301 953 6812
=============================================================================

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Wed Jan  5 04:01:28 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan  5 04:01:36 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan  5 04:01:19 PST 1994

        Subject: Fast Ethernet-FDDI?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Fast Ethernet-FDDI?
Date: Tue, 4 Jan 1994 18:45:48 GMT
From: davew@rsgi02.rhic.bnl.gov (David Whitehouse)
Organization: Brookhaven National Laboratory
Keywords: ethernet,fddi,atm
Message-ID: <1994Jan4.184548.26933@bnlux1.bnl.gov>
Sender: news@bnlux1.bnl.gov (Usenet news)

Hi,

I am currently invlvolved in a costing exercise for a VxWorks
based system scheduled to be operational in 1998. I am interested
in projections, guesses etc. relating high speed networking
between about 12 VME crates and 12 workstations. The system
analysis and design hasn't proceeded to the point where we
have a realistic model of the network traffic patterns but the 
general characteristics are

1) It isn't a realtime problem
2) There will be both point to point broadcast traffic.
3) A rough calculation suggests that about 100Mbits/sec is sufficient
   for the highest bandwidth part of the system.
4) TCP/IP must be supported.

Questions:

	1) how much does a VME based FDDI interface cost today?
        2) Are there any plans to support one of the fast ethernet
           or ATM protocols? If so how much will the interfaces cost
           in 1997-1998?

Thanks, David Whitehouse

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Wed Jan  5 07:09:57 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Wed Jan  5 07:10:07 PST 1994
Subject: Re: Fast Ethernet-FDDI? (long)
Greetings!
> 
> From: davew@rsgi02.rhic.bnl.gov (David Whitehouse)
> 

< Text deleted to save bandwidth...>

> 1) It isn't a realtime problem
> 2) There will be both point to point broadcast traffic.
> 3) A rough calculation suggests that about 100Mbits/sec is sufficient
>    for the highest bandwidth part of the system.
> 4) TCP/IP must be supported.
> 
> Questions:
> 
> 	1) how much does a VME based FDDI interface cost today?
>         2) Are there any plans to support one of the fast ethernet
>            or ATM protocols? If so how much will the interfaces cost
>            in 1997-1998?
> 

A few things to take note of:

1) Using TCP/IP, a 100 MBit/s pipe can be choked back to as little as 16-24
   MBits/sec.  

2) You can get fairly *close* to 100 MBits/s (i.e., full bandwidth) if you 
   bypass the TCP stack completely.

3) UDP can support broadcast, but multicasting is still not a distributed
   part of the protocol stack.  Also, you'd be surprised about just how
   many UDP packets get dropped on LANs.  There are several protocols
   such as IP Multicast and XTP(?) that do support multicast, but you
   have to hack them in yourself.  Besides, in a non-broadcast sort of
   media such as FDDI or ATM, you'll have to take propagation times
   into account. (Is multicast what you meant when you said "point to
   point broadcast traffic"?)

4) Here at SPARTA, we're just finishing modifications to our Interphase
   5211 FDDI driver to support VME64 block mode transfers.  No performance
   numbers yet (I'm waiting on a second 5211 to do the tests), but the
   bus analyzer shows a 5x improvement in transfer times over standard
   VME32 non-block transfers.  FDDI using VME32 transfers and a 68040 
   (33 MHz), you can get only about a 50-200% improvement over Ethernet 
   speeds, but you do get some level of determinism (The speed variability
   stems from the sophistication of the '040 manufacturer's bus interface).  
   UltraNet is faster, but not a "standard" with other companies producing 
   boards for it. 

5) We sell the 5211 DAS-Fiber for about $5,100 (retail $5,795).  The 
   driver is $200 per target.  You can get cheaper by going to single 
   attached stations (SAS), but then you'll need a concentrator.  Copper 
   versions are not that much less expensive due to lower production volumes.

6) ATM is coming soon.  In spite of the lack of firm standards, the ATM
   community is pushing hard to get products out the door.  The current
   ATM data rates are in the 155 MBits/sec range.  We will be working on
   the VxWorks driver for the Interphase ATM board as soon as we get a
   couple of boards from Interphase.  The costs for ATM will probably
   start in the $5-8K range per interface (I'm just guessing here 
   'cause we don't have firm pricing from Interphase yet) and fall off 
   rapidly by 1997-1998 to just a couple hundred bucks range as quantities 
   ramp up, and R&D costs are amortized (just as Ethernet did in the '80s).

7) (Engaging crystal ball ...) Fast-Ethernet looks like it could be a 
   non-player in the long run.  ATM is moving fast with a lot of support
   behind it.  Fast-Ethernet will enjoy a brief period of use because
   it will initially be cheaper than ATM, but I feel that Fast-Ethernet
   will eventually suffer the same fate as IBM's Token Ring.  There will
   be a few users, but nothing representing a "mass" market.  (Initiating
   crystall ball shutdown ;-).

Hope this helps,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From robert@orincon.com  Wed Jan  5 11:59:49 1994
From: robert@orincon.com (Robert Redfield)
Date: Wed Jan  5 11:59:58 PST 1994
Subject: FDDI VME
Can anybody recommend vendors for VME FDDI boards?
Thanks,
Rob Redfield
robert@orincon.com

From daemon@vxw.ee.lbl.gov  Thu Jan  6 04:01:29 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan  6 04:01:37 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan  6 04:01:21 PST 1994

        Subject: Booting from CDROM

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Booting from CDROM
Date: Wed, 5 Jan 1994 15:02:05 GMT
From: NSEMICH@relay.nswc.navy.mil (Neal Semich)
Organization: NSWCDD, Dahlgren, VA 22448
Message-ID: <NSEMICH.6.2D2AD66D@relay.nswc.navy.mil>
Sender: news@relay.nswc.navy.mil (newserver)

  I thought I posted this before Christmas and I left for a week and I did not 
see it.  So I am sorry if this is a repost.
  I have a VME-based system that has three Motorola 68040 processors.  
Currently we boot the processors via Ethernet (files are located on a 
BriteLite).  This is only for the development cycle.  We have looked at 
delivering the program using flash memory or removable hard drives.  These are 
not feasible methods for delivering the program.  It looks like the best 
method is from CDROM.  If it is of any use, I am developing this using 
VADSWorks and the version of of VxWorks is 5.0.3.  My questions are :

       1) Has anyone ever done this?
       2) Should the CDROM be DOS formated (we read that VxWorks likes SCSI 
devices that way) ?
       3) What do I need to do for the boot parameters on the boards?

Thanks,
 Neal
Neal Semich

nsemich@relay.nswc.navy.mil      ;  My opinion and only my opinion!!!!

---------------------------

End of New-News digest
**********************

From morriss@smtplink.indigo.hellnet.org  Thu Jan  6 06:23:29 1994
From: Steve Morris <morriss@smtplink.indigo.hellnet.org>
Date: Thu Jan  6 06:23:47 PST 1994
Subject: transparent translation registers

Text item: Text_1

        
        I am using gcc version cygnus-2.2.3 from VxWorks 5.1, cross-compiling to 
        68030 and 68040 boards.
        
        I need to use the transparent translation registers directly. For the 
        68040 boards I have no problems setting DTT0 and DTT1.
        
            /* read/write enable, cache disable $40000000-$77ffffff */
            #define DTT0_VALUE  0x403fc060
            asm( "movec     %0,dtt0" : : "r" (DTT0_VALUE) ) ;
        
        However the equivalent instruction for the 68030 registers TT0 and TT1 
        does not seem to assemble. 
        
            /* read/write enable, cache disable $40000000-$77ffffff */
            #define TT0_VALUE  0x403f8507
            asm( "movem     %0,tt0" : : "r" (TT0_VALUE) ) ;
        
        This results in "operands mismatch"
        
        Can anyone help me?
        
        Steve Morris
        
        
----------------------------------------------------------------------
        
Steve Morris                        voice: (972)-8-381055 
Software Team Manager                      (972)-8-381818 
Indigo Graphic Systems              Fax:   (972)-8-408091
P.O. Box 150, Rehovot, Israel       e-mail: morriss@smtplink.indigo.hellnet.org
        
----------------------------------------------------------------------

        
        
        

From clegg@tesla.elen.ssd.fsi.com  Thu Jan  6 13:01:25 1994
From: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg)
Date: Thu Jan  6 13:01:37 PST 1994
Has anybody attempted to read, write and format MS-DOS (3.3-5.0) compatible
1.4Meg 3.5" disks using VxWorks?  More specifically, has anyone ever 
mounted a MVME884K scsi drive to a MVME167 and successfully formatted a 
1.4Meg disk and then read and written files on it using both VxWorks and
MS-DOS?

I am currently attempting to read MS-DOS (5.0) compatible 1.4Meg 3.5" 
floppy disks using VxWorks (for Motorola MVME167) version 5.0.2-68040 beta-1
with a scsi disk drive (MVME884K).  I have been able to "successfully"
mount the disk and read and write data to it, but it seems to ignore the
blksPerTrack parameter I hand it in scsiBlkDevInit() and assume that it
is writing to a 1.2Meg 5.25" floppy instead (i.e. 15 blksPerTrack). This,
coincidently is the exact setup used for the example in usrConfig.c.  I
have carefully checked the disk via Norton Utilities on my PC and have
discovered that every every 15 sectors it skips 3 sectors.

Below is a copy of the source I am using to create the "/fd0/" device
to access the disk.  NOTE: You will be able to read and write to the disk
from VxWorks, but no where else.

Thanks in advance,
R. Clegg
FSI-SSD
"The best safety device in any plane is a well trained pilot"

int initFloppy()
{
    char modeData [4];		/* array for floppy MODE SELECT data */
 
    /* configure floppy at busId = 3, LUN = 1 */

    if ((pSpd31 = scsiPhysDevCreate (pSysScsiCtrl, 3, 0, 0, NONE, 0, 0, 0))
	== (SCSI_PHYS_DEV *) NULL)
	{
        printErr ("usrScsiConfig: scsiPhysDevCreate failed for Floppy.\n");
	return (ERROR);
	}

    /* Zero modeData array, then set byte 1 to "medium code" (0x1b). NOTE:
     * MODE SELECT data is highly device-specific. If your device requires
     * configuration via MODE SELECT, please consult the device's Programmer's
     * Reference for the relevant data format.
     */
	
    bzero (modeData, sizeof (modeData));
    modeData [1] = 0x1b;

    /* issue the MODE SELECT command to correctly configure floppy controller */

    scsiModeSelect (pSpd31, 1, 0, modeData, sizeof (modeData));

    /* delete and re-create the SCSI_PHYS_DEV so that INQUIRY will return the
     * new device parameters, i.e., correct number of blocks 
     */

    scsiPhysDevDelete (pSpd31); 

    if ((pSpd31 = scsiPhysDevCreate (pSysScsiCtrl, 3, 0, 0, NONE, 0, 0, 0))
	== (SCSI_PHYS_DEV *) NULL)
	{
        printErr ("usrScsiConfig: scsiPhysDevCreate failed for Floppy(2)\n");
	return (ERROR);
	}

    if ( (pSbdFloppy = scsiBlkDevCreate (pSpd31, 0, 0)) == NULL)
	{
        printErr ("usrScsiConfig: scsiBlkDevCreate failed.\n");
	return (ERROR);
	} 

    /* Fill in the <blksPerTrack> (blocks (or sectors) per track) and <nHeads>
     * (number of heads) BLK_DEV fields, since it is impossible to ascertain
     * this information from the SCSI adapter card. This is important for
     * PC compatibility, primarily. 
     */
    scsiBlkDevInit ((SCSI_BLK_DEV *)pSbdFloppy, 18, 2);
	
	/* Initialize as a dosFs device */
    if (dosFsDevInit ("/fd0/", pSbdFloppy, NULL) == NULL)
	{
        printErr ("usrScsiConfig: dosFsDevInit failed.\n");
	return (ERROR);						 
	}
}

From briggs@saturnv.jpl.nasa.gov  Thu Jan  6 15:29:41 1994
From: briggs@saturnv.jpl.nasa.gov (Clark Briggs #3-1019)
Date: Thu Jan  6 15:29:50 PST 1994
Subject: request for info on porting to ibm
I have two questions to pose to the realm seeking info to help us decide what
to do.

1)has VxWorks been ported to any IBM RS6000 (or derivative, eg. PowerPc 60X or
40X or RSC) as a real-time target.  The question is not can the RS6000 
workstation be used as a development host.

I need VxWorks running on a CPU board built with the RSC single chip implementation.

Given a negative answer to #1 which is my expectation,
2) Which companies would be likely candidates to accomplish such a port in the
near future quickly and without messing up?

Please email responses to me directly at briggs@saturnv.jpl.nasa.gov not to the
exploder (that is dont compose your response to the sender automatically since 
you are presumably reading this in the exploder).  If there is enough interest 
I will post a summary to the exploder or respond directly to requests for a 
summary.

Thanks in advance for your help
clark briggs
briggs@saturnv.jpl.nasa.gov

From daemon@vxw.ee.lbl.gov  Fri Jan  7 04:08:24 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan  7 04:12:00 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan  7 04:01:44 PST 1994

        Subject: write() transfer count wrong, but errno not set
        Subject: Realtime and SBus Questions

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: write() transfer count wrong, but errno not set
Date: Thu, 6 Jan 1994 19:08:42 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Keywords: errno write
Message-ID: <georg.757883322@sgl.ists.ca>
Sender: news@newshub.ists.ca

I am encountering a problem writing files where the write() call returns
a value less than the desired write count (sometimes even 0), yet the errno
variable is not set. This is on VxWorks 5.1.1 writing to a dosFs file system
on a SCSI disk which is nowhere near full.

My questions:

- -Does this indicate a VxWorks bug, or is it normal?
- -Under what circumstances might this happen?

It may be that the file system I am writing to is somehow corrupted, as the
problem does not appear on another file system. Also each write is preceded
by a seek, and in some cases the seek goes past the current end of file.
Still, I think VxWorks should report as an error anything which prevents the
write from completing.

Is there something similar to fsck that I can use to check the consistency
of a VxWorks DOS file system? I haven't heard of anything.

Thanks,

Georg.

- -- 

Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: Realtime and SBus Questions
Date: Thu, 6 Jan 1994 23:13:27 GMT
From: dog@xdev.sunspot.noao.edu (Fritz Stauffer)
Organization: Computer, Hardware and Observatory Support
Message-ID: <1994Jan6.231327.9595@noao.edu>
Sender: news@noao.edu

	I am interested in using a SBC with both VME and SBus.
	Does anyone have any recommendations?  Also, I am
	looking for pointers to list of SBus card manufacturers.

	thanks,

	fritz stauffer
	sac peak obs.
	sunspot, nm

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Fri Jan  7 06:48:21 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Jan  7 06:48:30 PST 1994
Subject: RE: Floppy Disk Drive
Greetings!

> From root@vxw.ee.lbl.gov Thu Jan  6 16:19:14 1994
> To: vxworks_users@vxw.ee.lbl.gov
> Content-Length: 3463
> X-Lines: 93
> 
> Submitted-by clegg@tesla.elen.ssd.fsi.com  Thu Jan  6 13:01:25 1994
> Submitted-by: ssd.fsi.com!clegg@tesla.elen.ssd.fsi.com (Roger Clegg)
>  
> Has anybody attempted to read, write and format MS-DOS (3.3-5.0) compatible
> 1.4Meg 3.5" disks using VxWorks?  More specifically, has anyone ever 
> mounted a MVME884K scsi drive to a MVME167 and successfully formatted a 
> 1.4Meg disk and then read and written files on it using both VxWorks and
> MS-DOS?
> 

Is the MVME884K actually a Teac FD-235HF floppy drive?  If so, then your
mode select is woefully inadequate.  That floppy requires the full page
one mode select (about 32+ bytes of data sent to page one rather than
page zero) information in order to be able to format the 3.5" floppy
and function as a proper MSDOG drive.  I have code that demonstrates this
and can send it to you if you'd like.

Hope this helps,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From mea@mclean.sparta.com  Fri Jan  7 10:03:22 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Fri Jan  7 10:03:30 PST 1994
Subject: Synchronous on 68302
Greetings!

  Does anyone in netland have a snippet of code that puts a Mot 68302 serial
port into any of the synchronous modes of operation that they'd be willing
to share?

Any help would be greatly appreciated,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From bgeer@beorn.sim.es.com  Fri Jan  7 12:01:20 1994
From: bob geer <bgeer@beorn.sim.es.com>
Date: Fri Jan  7 12:01:32 PST 1994
Subject: VxMemProbe on VW5.1 on MVME147
I unexpectedly got the rush job of upgrading from 5.0.2 to 5.1 on our
MVME147 boards.  Most everything works for me except vxMemProbe() --
it always returns ERROR when trying to access ram across the VME bus.
The same hardware works everytime for 5.0.2; also, if I vxMemProbe()
(using 5.1) the memory on the 147, OK is the status returned.

If there's any trick I need to know here that any of you have already
overcome I'd appreciate hearing about it.

For the record, my current situation is this:

We (the co.) now gets a single copy of upgrades instead of our dept.
getting its own, & while I managed to get my hands on the 5.1
installation tape, I've never seen the 5.1 documents (manuals, release
notes, whatever) & the guy that's *supposed* to have them isn't
available.

The guy who did our dept's 5.0.2 config isn't available, either.

I've compared our 5.0.2 & 5.1 various config files & haven't
identified any obvious inconsistencies.

I've cruised the VW man pages for both 5.0.2 & 5.1.  I did change READ
& WRITE to VX_READ & VX_WRITE.

I've cruised the .h files.

My applications compile without warning messages.

I've tried 3 different 147 boards & VME crates -- all work fine with
5.0.2, 

Bob

From baumann@proton.llumc.edu  Fri Jan  7 13:28:06 1994
From: baumann@proton.llumc.edu (Michael Baumann)
Date: Fri Jan  7 13:28:14 PST 1994
Subject: Re: VxMemProbe on VW5.1 on MVME147

> 
>I unexpectedly got the rush job of upgrading from 5.0.2 to 5.1 on our
>MVME147 boards.  Most everything works for me except vxMemProbe() --
>it always returns ERROR when trying to access ram across the VME bus.
>The same hardware works everytime for 5.0.2; also, if I vxMemProbe()
>(using 5.1) the memory on the 147, OK is the status returned.
>
>If there's any trick I need to know here that any of you have already
>overcome I'd appreciate hearing about it.
>

Sure, you need to configure some addresses out there on the bus. Although not
well documented (like, not at all even :-(  ) they use the MMU even if
you don't purchase the VxVMI interface. There is a table in usrConfig.c
that you need to update to get to the VME.
If you don't configure it, is shows as a bus error.

Michael Baumann    
Electus Technology Inc.	/ Loma Linda University Medical Center
San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu

From bgeer@beorn.sim.es.com  Fri Jan  7 14:55:12 1994
From: bob geer <bgeer@beorn.sim.es.com>
Date: Fri Jan  7 14:55:32 PST 1994
Subject: Re:  VxMemProbe on VW5.1 on MVME147
Thanks to Peregrine & Tim I figger'd out I should eliminate the
INCLUDE_MMU_BASIC & now things work as they did with 5.0.2.

Now to figure out how to utilize the MMU capability to our
best advantage; in particular, we have a lot of boards whose
DRAM is addressed from 0x40000000 thru 0xe8000000 & maybe
beyond (not sure if 0xe8000000 is the low or hi end of the
new board's address space).

Now, to track down the 5.1 docs...

Oh, yeah, & thanks to Mr. Rosenboim for his 5.1 upgrade write-up.

I do love this 'net!  Bob

From rh@spacenet.lanl.gov  Fri Jan  7 16:28:57 1994
From: rh@spacenet.lanl.gov (Rick Hodson)
Date: Fri Jan  7 16:29:05 PST 1994
Subject: Re: VxMemProbe on VW5.1 on MVME147

Ok....it will take about 20 mins.

From accom!tbm%accom@uunet.uu.net  Fri Jan  7 17:27:09 1994
From: accom!tbm%accom@uunet.uu.net (Tom McCurdie)
Date: Fri Jan  7 17:27:20 PST 1994
Subject: RPC communications with Macintosh

Hello.

I was wondering if anybody out there has successfully communicated with a 
vxWorks server from a Macintosh via RPCs.  I have located one organization
(Netwise) which provides their own proprietary flavor of RPCs for the Mac
platform but it is not ONC compliant, and therefore would require porting 
some of their libraries onto our target which I would rather not do.  It 
also requires you to run their own protocol compiler which they assure me
is superior to but in no way compatible with rpcgen.

So my questions are:

1) Is there a ONC compliant RPC implementation which does not require any 
modifications on the vxWorks target?

and, failing that:

2) Has anybody successfully used the Netwise implementation to communicate
to a vxWorks target?

Thank you.

Tom McCurdie
Accom Inc.

From rh@spacenet.lanl.gov  Fri Jan  7 17:51:59 1994
From: rh@spacenet.lanl.gov (Rick Hodson)
Date: Fri Jan  7 17:52:07 PST 1994
Subject: Re: VxMemProbe on VW5.1 on MVME147

Apologies for last irrelative mail message...please send comment to bit bucket.

Rick Hodson

From daemon@vxw.ee.lbl.gov  Sat Jan  8 04:01:33 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan  8 04:01:44 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan  8 04:01:23 PST 1994

        Subject: "production" release of TCL 7.0 for VxWorks available
        Subject: comp.os.vxworks FAQ?
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: Fast Ethernet-FDDI? (long)

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: "production" release of TCL 7.0 for VxWorks available
Date: 7 Jan 1994 22:10:40 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <2gkml0$bvh@ncar.ucar.edu>

I've made a few fixes to my previous beta release, and am now announcing
a "production" release of TCL7.0 for VxWorks.  I've been using this port for 3
months, and it is quite stable. 

Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is
on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz

1) What is it?  

TCL is a library that lets you embed an interpeter in your application.

2) What good is it?  Why would I want to have a "real-time" interpreter?

If you've ever been frustrated that the VxWorks shell is not re-entrant, 
and has no control flow (e.g. if then else, switch, case ),
then you will find TCL very useful since it is a very complete language,
that allows you to add your own application specific commands to
the interpreter.

I find it invaluable for system testing, since I register TCL commands for
all major functionality of my real-time application.  This allows me
to test most pieces of my data acquisition system from a command line,
and build nice flexible scripts to test and operate my system.  As a
matter of fact, I can even invoke specific methods of C++ classes via
TCL.

Also, you can control your real-time system from a Unix workstation by sending
TCL commands from either a TCL or Tk/TCL application (via tclTCP).  I find that
sending TCL commands (which are just strings) is much easier and more flexible
than writing a Remote Procedure Call (RPC) for each piece of functionality that I
need to remotely invoke.

3) How big is it?  
On the 68K architecture:
% size libTcl7.0.o
text    data    bss     dec     hex
104272  5880    980     111132  1b21c

Certainly not tiny, but once you've used it, you'll never give it up!

4) Where do I find out more?

Get the TCL Frequently Asked Questions list from
harbor.ecn.purdue.edu:~pub/tcl/docs/tcl-faq.part0[1-5]

Get the draft of TCL's author's book.
harbor.ecn.purdue.edu:~pub/tcl/sprite-mirror/book.p[1-4].ps.Z

Send me mail, if you have more questions.

- -- 
	Joe VanAndel  		    Internet: vanandel@ncar.ucar.edu
	National Center for 	    Web http://www.atd.ucar.edu/jva/home.html
	Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: comp.os.vxworks FAQ?
Date: Fri, 7 Jan 1994 23:01:35 GMT
From: borchew@storage.tandem.com (Howard Borchew)
Organization: Tandem Computers Inc.
Keywords: FAQ
Message-ID: <CJA7yo.1Bq@tandem.com>
Followup-To: borchew@storage.tandem.com
Sender: news@tandem.com

I'm looking for an FAQ for comp.os.vxworks.  Is there one?  Can I get
it off an ftp server?  Can someone mail me a copy?

Thanks,
- -hjb-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|     ,__o  ,__o	"Only from the alliance of the one, working	|
|    -\_<,_-\_<,	with and through the other, are great things	|
|  (*)/' -- /'(*)	born." - Antoine de Saint-Exupery		|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|				|					|
|  Howard Borchew		|  PHONE: (408)285-9919			|
|  borchew@storage.tandem.com	|  FAX: (408)285-9924			|
|  Development Engineer		|  US MAIL:				|
|  Storage & Printer Systems	|    Tandem Computers Inc.		|
|  Tandem Computers Inc.	|    10555 Ridgeview Court, LOC 100-03	|
|				|    Cupertino, CA   95014-0789		|
|				|					|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Sat, 8 Jan 1994 08:57:27 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: errno write
Message-ID: <hjbCJAzJr.3Fp@netcom.com>
References: <georg.757883322@sgl.ists.ca>

In article <georg.757883322@sgl.ists.ca> georg@sgl.ists.ca (Georg Feil) writes:
>
>I am encountering a problem writing files where the write() call returns
>a value less than the desired write count (sometimes even 0), yet the errno
>variable is not set. This is on VxWorks 5.1.1 writing to a dosFs file system
>on a SCSI disk which is nowhere near full.
>
>My questions:
>
>-Does this indicate a VxWorks bug, or is it normal?

my $.02...

normal as documented in vxworks man page.  if retval != count, it
is considered error.  this does not map precisely to unix paradigm,
nor is this vx-documented in sufficient detail for different types
of devices, or devices in different modes -- e.g. blocking vs. 
non-blocking.

unix will return error (-1) when a write() to file is not completely
satisfied, unless it is marked non-blocking i/o and/or the 'file'
in question is one of: pipe, socket, stream, etc.   vxworks does not
always do the same.  in case of msdog and rt11 or other filesystem
devices, vxworks will return actual number of bytes it was able to 
write, and set no error code.  there is no policy-making layer 
on top of device drivers which arbitrates the error condition
to make io layer interface to callers consistent; io system calls 
are indirected to lower level device routines, whose return values 
are then simply forwarded back to the user, who is supposed to
figure out what the retval means per given device.  a write() to
vxworks socket, for example, works more similar to unix counterparts.

in any case, given an 'error condition', would one like to know
why write() produces such error condition?  i would say yes.
so the lack of such info would constitute a bug, imho.

>-Under what circumstances might this happen?

kent long knows more than anyone on this one. prolly some corrupt FAT
entries...

>It may be that the file system I am writing to is somehow corrupted, as the
>problem does not appear on another file system. Also each write is preceded
>by a seek, and in some cases the seek goes past the current end of file.
>Still, I think VxWorks should report as an error anything which prevents the
>write from completing.

agreed, but if your filesystem is broken, msdog filesys in vxworks will
not know how to fix or make sense of it.

>Is there something similar to fsck that I can use to check the consistency
>of a VxWorks DOS file system? I haven't heard of anything.

i think people use norton utilities under msdog.  that is, move the disk
to a pc, connect it to its controller and run norton on the disk.
fix up the disk, move it back to vxworks target.

- --
Hwa-Jin Bae   Internet: hjb@netcom.com  UUCP(slow!): ...!bdt!peacefulstar!hjb 
PEACEFUL STAR Consultants, Oakland, CA	  Vox:510.536.7607  Fax:510.536.5889

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Fast Ethernet-FDDI? (long)
Date: Sat, 8 Jan 1994 10:05:48 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCJB2pp.9xC@netcom.com>
References: <9401051510.AA08254@helios>

some additions to mike's excellent article... disregard at will ;-)

In article <9401051510.AA08254@helios> mea@mclean.sparta.com (Mike Anderson) writes:
>1) Using TCP/IP, a 100 MBit/s pipe can be choked back to as little as 16-24
>   MBits/sec.  
>

true, but not always... vernon schryver will prolly tell you more about
fddi/ip/tcp performance in sgi systems.  near-full bandwidth utilization
over tcp/ip/fddi is available elsewhere.

>2) You can get fairly *close* to 100 MBits/s (i.e., full bandwidth) if you 
>   bypass the TCP stack completely.
>

the key to performance bottleneck is not mainly due to tcp stack, although
the tcp stack in vxworks does need some tuning.  driver/mbuf/ip interface
is what needs to be optimized; above all, avoiding copying and using
the right size buffers will solve a lot of problems.  as is, vxworks
network code needs work in this area, especially w.r.t fddi type of
medium where mtu is larger than 2k.  the fault lies more in the realm
of the driver, not tcp/ip stack.  and perhaps the socket interface
needs some tuning too.

>3) UDP can support broadcast, but multicasting is still not a distributed
>   part of the protocol stack.  Also, you'd be surprised about just how
>   many UDP packets get dropped on LANs.  There are several protocols
>   such as IP Multicast and XTP(?) that do support multicast, but you
>   have to hack them in yourself.  Besides, in a non-broadcast sort of
>   media such as FDDI or ATM, you'll have to take propagation times
>   into account. (Is multicast what you meant when you said "point to
>   point broadcast traffic"?)
>

udp doesn't care broadcast vs. multicast.  if your ip implements deering's
ip multicasting, you simply sendto() the multicast address.  and if
vxworks network code were avaialble in source code format, you could
just apply diffs to original bsd code to produce multicast ip capable
vxworks network.

xtp is essentially an academic issue; nobody uses it, and as beautiful
as it is, i think we can all agree it's dead. ;-)  talk to bob crispin
for xtp on vxworks if you really want.

i have no idea how you would support broadcast/multicast in atm.  ;-)

>4) Here at SPARTA, we're just finishing modifications to our Interphase
>   5211 FDDI driver to support VME64 block mode transfers.  No performance
>   numbers yet (I'm waiting on a second 5211 to do the tests), but the
>   bus analyzer shows a 5x improvement in transfer times over standard
>   VME32 non-block transfers.  FDDI using VME32 transfers and a 68040 
>   (33 MHz), you can get only about a 50-200% improvement over Ethernet 
>   speeds, but you do get some level of determinism (The speed variability
>   stems from the sophistication of the '040 manufacturer's bus interface).  
>   UltraNet is faster, but not a "standard" with other companies producing 
>   boards for it. 

peregrine II is a great board, but unless you perform surgery to fix problems
in vxworks network code, especially in mbufs, tcp, driver interface, sockets
and write the driver to avoid unnecssary copying, you will not be
seeing the 'true' potential of the board.

an easy test is: if you add faster cpu and the performance goes up
linearly, by noticeably large increments, you have excessive data copying
and/or cksum speed problem.

>
>5) We sell the 5211 DAS-Fiber for about $5,100 (retail $5,795).  The 
>   driver is $200 per target.  You can get cheaper by going to single 
>   attached stations (SAS), but then you'll need a concentrator.  Copper 
>   versions are not that much less expensive due to lower production volumes.
>

alternatively, if you are not tied to vme, try one of the sbus or eisa
fddi cards.  you can pick up a cddi card for around 1k.  and prices
will be dropping more soon.

>6) ATM is coming soon.  In spite of the lack of firm standards, the ATM
>   community is pushing hard to get products out the door.  The current
>   ATM data rates are in the 155 MBits/sec range.  We will be working on
>   the VxWorks driver for the Interphase ATM board as soon as we get a
>   couple of boards from Interphase.  The costs for ATM will probably
>   start in the $5-8K range per interface (I'm just guessing here 
>   'cause we don't have firm pricing from Interphase yet) and fall off 
>   rapidly by 1997-1998 to just a couple hundred bucks range as quantities 
>   ramp up, and R&D costs are amortized (just as Ethernet did in the '80s).
>

[trivia...]
there is at least one other company that is currently doing atm h.w. system
using vxworks as native o.s to drive atm gear.

>7) (Engaging crystal ball ...) Fast-Ethernet looks like it could be a 
>   non-player in the long run.  ATM is moving fast with a lot of support
>   behind it.  Fast-Ethernet will enjoy a brief period of use because
>   it will initially be cheaper than ATM, but I feel that Fast-Ethernet
>   will eventually suffer the same fate as IBM's Token Ring.  There will
>   be a few users, but nothing representing a "mass" market.  (Initiating
>   crystall ball shutdown ;-).
>

fast ethernet, as i understand it, is not really that faster, in terms
of burst bandwidth.  it's in a kind of different league all together i think.
am i wrong?  (i know, of course! ;-)

- --
Hwa-Jin Bae   Internet: hjb@netcom.com  UUCP(slow!): ...!bdt!peacefulstar!hjb 
PEACEFUL STAR Consultants, Oakland, CA	  Vox:510.536.7607  Fax:510.536.5889

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sun Jan  9 04:01:22 1994
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan  9 04:01:30 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan  9 04:01:13 PST 1994

        Subject: Is there a VxWorks Conference ???

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Is there a VxWorks Conference ???
Date: Sun, 9 Jan 1994 00:39:19 GMT
From: scoob@bnr.ca (Christian Marcotte)
Organization: Bell-Northern Research (Canada)
Message-ID: <1994Jan9.003919.22391@bnr.ca>
Sender: news@bnr.ca (usenet)

I recall hearing something about a user group or some conference about
VxWorks.  Where can I find more info about it?  Can users present papers
about their work?

Thanks,
- -- Scoob

- -- 
- ---------------------------------------------------------------------------
Christian Marcotte                Bell-Northern Research
scoob@bnr.ca                      3500 Carling Ave
Telephone: (613) 763-2782         Nepean, Ont., Canada K1Y 4H7

---------------------------

End of New-News digest
**********************

From vaughnf@ccmsmtp.stpaul.ncr.com  Mon Jan 10 08:02:54 1994
From: "Frank Vaughn" <vaughnf@ccmsmtp.stpaul.ncr.com>
Date: Mon Jan 10 08:03:03 PST 1994
Subject: port of vxWorks to multiple custom boards

     Greetings;
     
     I have previously written a BSP for an i960 target. There was only one 
     board, so no file problems/strategies were encountered/needed. I must 
     now port vxWorks to several different boards(custom, non-VME) w/ 
     different processors and very little software in common. I am hoping 
     someone out there has dealt w/ something similiar, and can offer some 
     advice.
     
     Question 1: In this case, is it reasonable to maintain the WRS 
     philosophy of creating one target directory for each board under a 
     common /config directory? I don't believe that 
     config/all/usrConfig.c(or the other files in /config/all) will be 
     similiar at all for the different targets. I've toyed w/ the idea of
     a completely different directory structure(shadowed from /usr/vw) for 
     each target. This could eliminate problems which could perhaps arise 
     if one target needed a different release or update of some/all of the 
     vxWorks files. Is it realistic to maintain one /usr/vw directory tree 
     to support different CPUs? As stated before, my biggest nightmare is 
     the case where one target would require an update that is present in a 
     later release, so a new set of files would perhaps be needed for one 
     target but not for others.
     
     Question 2: When doing a BSP for a custom board, do most people 
     continue to use the MakeSkel/mpp technique? or throw this stuff out 
     and build a fixed Makefile. I can see advantages to both methods.
     
     Question 3: What do you do about the frequent releases of GNU tools, 
     etc? Do you just stay w/ what you have until you have time to do a 
     "sanity check" to see that they work?
     
     
     I would appreciate any advice that can be given.
     
     Thanks;
     
     Frank (frank.vaughn@stpaul.ncr.com)

From andy@oe.fau.edu  Mon Jan 10 11:49:44 1994
From: "Mr.Andrew Shein" <andy@oe.fau.edu>
Date: Mon Jan 10 11:49:52 PST 1994
Subject: PPP for vxWorks
Hi 
   I remember someone saying they had done a port of PPP for
vxWorks. If anyone has, could someone post some info on where to get
it if it's public.

				Thanks 
				Andy Shein
				andy@transquest.oe.fau.edu

From daemon@vxw.ee.lbl.gov  Tue Jan 11 04:01:23 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 11 04:01:34 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 11 04:01:13 PST 1994

        Subject: C++ style
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: PPP for vxWorks
        Subject: Re: write() transfer count wrong, but errno not set

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: C++ style
Date: Mon, 10 Jan 1994 14:34:17 GMT
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Keywords: C++ style
Message-ID: <1994Jan10.143417.23480@bnlux1.bnl.gov>
Sender: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)

	I'm not currently a user of WRS' C++ product(s).
Still, I'm a little curious about the "programming style"
of C++ code developed at WRS. I am impressed by the level
of detail in WRS' style guide for C code, and by the fact
that WRS makes that style guide "public". Has anyone seen 
C++ code from WRS, or an updated style guide which includes
C++? Does WRS just extend the C style guide to cover C++?
If so, are C++ classes treated like other user-defined types
(all capital letters)? Do they have special treatment?
What extensions are used for C++ "header" and/or "source"
modules? Inquiring minds want to know.

- -- 
     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_   
    / / /     \ \ \    / / /     \ \ \     / / /     \ \ \    / / /     \ \ \  
     >>        <<        >>       <<        >>        <<        >>       <<    
     \\        //        \\       //        \\        //        \\       //    

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Mon, 10 Jan 1994 17:29:39 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Keywords: errno write
Message-ID: <james.758222979@wrs.com>
References: <georg.757883322@sgl.ists.ca> <hjbCJAzJr.3Fp@netcom.com>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)

hjb@netcom.com (squeedy) writes:

>In article <georg.757883322@sgl.ists.ca> georg@sgl.ists.ca (Georg Feil) writes:
>>-Does this indicate a VxWorks bug, or is it normal?

>normal as documented in vxworks man page.

Nope, it's a bug.  The SPR # is 2739.  (It doesn't appear in the
currently published bug list as it wasn't reported until Dec 20th,
after the 5.1.1 known problems list was printed.)  Write() no longer
will return fewer bytes than requested, as specified by posix.

- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
	 "Half of what he said meant something else, and the other half
			  didn't mean anything at all"

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Tue, 11 Jan 1994 04:23:15 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: errno write
Message-ID: <hjbCJG6us.Fzo@netcom.com>
References: <georg.757883322@sgl.ists.ca> <hjbCJAzJr.3Fp@netcom.com> <james.758222979@wrs.com>

In article <james.758222979@wrs.com> james@wrs.com writes:
>hjb@netcom.com (squeedy) writes:
>
>>In article <georg.757883322@sgl.ists.ca> georg@sgl.ists.ca (Georg Feil) writes:
>>>-Does this indicate a VxWorks bug, or is it normal?
>
>>normal as documented in vxworks man page.
>
>Nope, it's a bug.  The SPR # is 2739.  (It doesn't appear in the
>currently published bug list as it wasn't reported until Dec 20th,
>after the 5.1.1 known problems list was printed.)  Write() no longer
>will return fewer bytes than requested, as specified by posix.
>
>-- 
>James Moore                            /|\                        james@wrs.com
>Wind River Systems                     \|/                  Alameda, California

go read the whole article again.

you've quoted me out of context.  i said it is "normal as documented
in vxworks man page" for write() call; i also said that 
i consider it a bug, no matter what vxworks or vxman seems
to think how write() should work.  in other words, vxworks and vxman
are wrong, and it's a bug, but it still is "normal" as per vxman page
(which is wrong w.r.t other write() implementations).

while you're at it go check out the io system in general, and find other
"bugs".

regards,
hwajin

Hwa-Jin Bae   Internet: hjb@netcom.com  UUCP(slow!): ...!bdt!peacefulstar!hjb 
PEACEFUL STAR Consultants, Oakland, CA	  Vox:510.536.7607  Fax:510.536.5889

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Tue, 11 Jan 1994 05:44:21 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems
Keywords: errno write
Message-ID: <james.758267061@wrs.com>
References: <georg.757883322@sgl.ists.ca> <hjbCJAzJr.3Fp@netcom.com> <james.758222979@wrs.com> <hjbCJG6us.Fzo@netcom.com>
Reply-To: james@wrs.com
Sender: news@wrs.com (News Manager)

hjb@netcom.com (squeedy) writes:

>i consider it a bug, no matter what vxworks or vxman seems
>to think how write() should work.  in other words, vxworks and vxman
>are wrong, and it's a bug, but it still is "normal" as per vxman page
>(which is wrong w.r.t other write() implementations).

When in doubt, RTFM:

(most of the rest of the write() man page deleted>
RETURNS
     The number of bytes written (if not equal  to  <nbytes>,  an
     error  has  occurred),  or ERROR if the file descriptor does
     not exist or the driver returns ERROR.

Seems pretty clear that VxWorks is following standard practice (in
this case, a POSIX standard).

- -- 
James Moore                            /|\                        james@wrs.com
Wind River Systems                     \|/                  Alameda, California
	 "Half of what he said meant something else, and the other half
			  didn't mean anything at all"

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Tue, 11 Jan 1994 07:49:16 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: errno write
Message-ID: <hjbCJGGE4.3IJ@netcom.com>
References: <james.758222979@wrs.com> <hjbCJG6us.Fzo@netcom.com> <james.758267061@wrs.com>

In article <james.758267061@wrs.com> james@wrs.com writes:
>hjb@netcom.com (squeedy) writes:
>
>>i consider it a bug, no matter what vxworks or vxman seems
>>to think how write() should work.  in other words, vxworks and vxman
>>are wrong, and it's a bug, but it still is "normal" as per vxman page
>>(which is wrong w.r.t other write() implementations).
>
>When in doubt, RTFM:
>
>(most of the rest of the write() man page deleted>
>RETURNS
>     The number of bytes written (if not equal  to  <nbytes>,  an
>     error  has  occurred),  or ERROR if the file descriptor does
>     not exist or the driver returns ERROR.
>
>Seems pretty clear that VxWorks is following standard practice (in
>this case, a POSIX standard).
>
>-- 
>James Moore                            /|\                        james@wrs.com
>Wind River Systems                     \|/                  Alameda, California
>	 "Half of what he said meant something else, and the other half
>			  didn't mean anything at all"

wrong again.  you still do not understand.

the vxworks write() is wrong and the man page is also wrong.
the normal traditional unix write() will return the number of
bytes actually written when the write was *successful*.  a successful write() 
varies from one object to another.  a successful write() to socket
or any other object that is subject to flow control can return
number less than requested, at which time the user must retry
to send more data.  a succesful write() to non-blocking file i/o 
must either complete successfully with all bytes requested written
to the file, or return error (-1) indicating the errno.
vxworks does not do this to a normal synch i/o file write(),
which was the point of this whole discussion.

not only does vxworks write() man page describe none of the object
specific behaviors and error cases, the implementation of write()
is also incompatible.

Hwa-Jin Bae   Internet: hjb@netcom.com  UUCP(slow!): ...!bdt!peacefulstar!hjb 
PEACEFUL STAR Consultants, Oakland, CA	  Vox:510.536.7607  Fax:510.536.5889

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: PPP for vxWorks
Date: Tue, 11 Jan 1994 08:00:37 GMT
From: dab@netcom.com (Don Brooks)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <dabCJGGx1.4Cx@netcom.com>
References: <199401101946.AA29802@oe.fau.edu>

Mr.Andrew Shein (andy@oe.fau.edu) wrote:
: Hi 
:    I remember someone saying they had done a port of PPP for
: vxWorks. If anyone has, could someone post some info on where to get
: it if it's public.

: 				Thanks 
: 				Andy Shein
: 				andy@transquest.oe.fau.edu

Its available from netcom.com via anonymous ftp.  Once there, cd to
pub/peacefulstar/dab.  The file is pppd-1.3.tar.gz.

Don Brooks	 dab@netcom.com
Peaceful Star Consultants
510-536-7607 (office) 510-536-5889 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Tue, 11 Jan 1994 08:21:56 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: errno write
Message-ID: <hjbCJGHwL.IuH@netcom.com>
References: <hjbCJG6us.Fzo@netcom.com> <james.758267061@wrs.com> <hjbCJGGE4.3IJ@netcom.com>

In article <hjbCJGGE4.3IJ@netcom.com> hjb@netcom.com (squeedy) writes:
>varies from one object to another.  a successful write() to socket
>or any other object that is subject to flow control can return
>number less than requested, at which time the user must retry
>to send more data.  

i should add, *if* the object is marked non-blocking

>a succesful write() to non-blocking file i/o 
			^^^^^^^^^^^ i meant normal/blocking --
					just thinking one thing and typing
					another...

>must either complete successfully with all bytes requested written
>to the file, or return error (-1) indicating the errno.
>vxworks does not do this to a normal synch i/o file write(),
>which was the point of this whole discussion.

Hwa-Jin Bae   Internet: hjb@netcom.com  UUCP(slow!): ...!bdt!peacefulstar!hjb 
PEACEFUL STAR Consultants, Oakland, CA	  Vox:510.536.7607  Fax:510.536.5889

---------------------------

End of New-News digest
**********************

From rdmacko@somnet.sandia.gov  Tue Jan 11 06:58:11 1994
From: RD Mackoy <rdmacko@somnet.sandia.gov>
Date: Tue Jan 11 06:58:20 PST 1994
Subject: VxWorks, VXI, SCRAMNet
I am looking for any one who has used the above combination of HW and SW.
I would be insterested in even just the VxWorks and SCRAMNet.
RD Mackoy               rdmacko@somnet.sandia.gov
Sandia National Labs    505-844-1911
PO Box 5800  MS 365     505-844-4797
Albuquerque, NM         87185
                              

From visicom!VisiCom.COM!trest@lbl.gov  Tue Jan 11 09:14:37 1994
From: Mike Trest <trest@visicom.com>
Date: Tue Jan 11 09:14:46 PST 1994
Subject: Re: port of vxWorks to multiple custom boards
FrankVaughn asks:

>      Question 1: In this case, is it reasonable to maintain the WRS 
>      philosophy of creating one target directory for each board under a 
>      common /config directory? I don't believe that 
>      config/all/usrConfig.c(or the other files in /config/all) will be 
>      similiar at all for the different targets. I've toyed w/ the idea of
>      a completely different directory structure(shadowed from /usr/vw) for 
>      each target. This could eliminate problems which could perhaps arise 
>      if one target needed a different release or update of some/all of the 
>      vxWorks files. Is it realistic to maintain one /usr/vw directory tree 
>      to support different CPUs? As stated before, my biggest nightmare is 
>      the case where one target would require an update that is present in a 
>      later release, so a new set of files would perhaps be needed for one 
>      target but not for others.

We have followed the WRS approach for a long time and it works.
The only real pain is the thought of placing hardware specific
stuff in ../all/bootConfig.c ../all/usrConfig.c in the early
versions of VxWorks.  This has been reorganized in 5.1.  This
addresses the different CPUs.  However our collective problem
remains when WRS changes their structure between OS releases.

>      
>      Question 2: When doing a BSP for a custom board, do most people 
>      continue to use the MakeSkel/mpp technique? or throw this stuff out 
>      and build a fixed Makefile. I can see advantages to both methods.
>      

I do whenever the BSP is going to be sold to others.  I note that other 
engineers do not use MakeSkel when the BSP is for single-customer
or internal use.

>      Question 3: What do you do about the frequent releases of GNU tools, 
>      etc? Do you just stay w/ what you have until you have time to do a 
>      "sanity check" to see that they work?

I started using GNU long before WRS started distributing them.  I now
use the WRS distributed versions.  VisiCom Laboratories has been
a BETA site for many of the new releases and products from WRS.
We have, therefore, been able to do the sanity check before using
the stuff for production work.  

VisiCom has about 200 employees where 100 (or more) are activly writing 
VxWorks/pSOS/Lynx/Ada real time kernels, drivers, and applications.
We have probably written a hundred BSPs for VME, propritary OEM boards,
and other custom [military] hardware platforms.  We have found that
it is better to stick with the vendor distributed patterns of things
(unless they are broken).  Sticking with the pattern makes for easier
training of new engineers and easier transition to end-user customers.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From halecm@cod.nosc.mil  Tue Jan 11 09:17:28 1994
From: halecm@cod.nosc.mil (Curtis M. Hale)
Date: Tue Jan 11 09:17:37 PST 1994
Subject: g++ question

good day,

my name is Curtis Hale, halecm@cod.nosc.mil. I work for Naval Research
and Development Lab in San Diego, (619) 553-6147.  We are
running vxWorks applications and are interested in obtaining 
a C++ compiler for vxWorks development.

Pursuing this venture, I am exploring the use of the GNU g++
compiler.  I had problems building the cross-compiler from the latest 
version, 2.5.7, obtained from MIT's GNU area.  The configure command
doesn't know about m68k-wrs-vxworks as a target platform, which
is not surprising.  I did get the compiler to build using the
GCC Develop Toolkit's source distributed by Wind River. It DID
know about configure m68k-wrs-vxworks as a target platform, which
perhaps implies that someone at WRS hacked on it a little.  Anyway,
I seem to have the cross compiler built, v2.2.3 of gnu stuff (there is
an executable built anyway), and am 
wondering about the location of compatible g++ libraries and header files 
(istream.h,ostream.h, etc...).  I got the libg++-2.5.3 from MIT but I believe
that is not compatible with the older  v2.2.3 compiler I have built.

Actually, I am more curious about whether this is a valid approach - is
anybody else using the GNU g++ cross compiler or is using WRS 
Centerline C++ product the better approach. 

If anybody has information - good,bad,other - on using the GNU g++
compiler on vxWorks applications I would be interested in learning the
version you're using, where you got it, could I get it, etc.  

If anybody has information on Wind River's Centerline C++ product 
I would appreciate that, too.

Thank you,
curt hale

From technet!gmg%barney.macom.com@uunet.uu.net  Tue Jan 11 15:30:31 1994
From: technet!gmg%barney.macom.com@uunet.uu.net (Gary M. Greenberg)
Date: Tue Jan 11 15:30:40 PST 1994
Subject: Subscription To . . .
Please add me to your exploder subscription database.  I was refered to it 
by TriLogic Inc.

Thanks!
 2
G
gmg@macom.com

From john@csd.nad.northrop.com  Tue Jan 11 17:11:27 1994
From: John Sicklick <john@csd.nad.northrop.com>
Date: Tue Jan 11 17:11:35 PST 1994
Subject: Re: Subscription To . . .
    Send subscription requests & comments to vxwexplo-request@lbl.gov

From morriss@smtplink.indigo.co.il  Wed Jan 12 01:29:28 1994
From: Steve Morris <morriss@smtplink.indigo.co.il>
Date: Wed Jan 12 01:29:58 PST 1994
Subject: Re[2]: transparent translation registers

Text item: Text_1

        >         I am using gcc version cygnus-2.2.3 from VxWorks 5.1, 
        cross-compiling to
        >         68030 and 68040 boards.
        >
        >         I need to use the transparent translation registers directly. 
        >         For the 68040 boards I have no problems setting DTT0 and DTT1.
        >
        >                          :
        > 
        >         However the equivalent instruction for the 68030 registers TT0 
        and TT1
        >         does not seem to assemble. 
        >
        
        Thanks for the useful suggestions from several people. I managed to use 
        TT0 & TT1 in the end.
        I was asked why I want to use the DTT/TT registers. One reason to use 
        the transparent translation registers directly is that you can "cache 
        disable" large areas without generating correspondingly large MMU 
        translation tables (the 4 areas of 128 MBytes each that I need to cover 
        require either ~300 KBytes of MMU table or a single DTT/TT register) and 
        there is no translation time overhead. The disadvantage is that there 
        are only two DTT/TT registers and they have limited usage.
        
        The top 8 bits, the Logical Address Base, are compared with address bits 
        A31-A24 (i.e. multiples of 16 Mbyte). Addresses that match are 
        transparently translated. The next 8 bits, the Logical Address Mask, 
        contain a mask for the Logical Address Base, set bits cause the 
        corresponding bit in the Logical Address Base field to be ignored. Other 
        bits set the access modes, cache mode, etc., and are different for the 
        68030 and the 68040. You must be careful that the areas covered do not 
        clash with those defined by the MMU tables.
        
        For future referance, this is what you do :-
        

        /**************************/
        /* for 68030 (e.g. mv147) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_tt ()
        {
            register int *pVal;
            int ttVal;
            
            pVal = &ttVal;
            
            ttVal = TT0_VALUE;
            asm ("pmove %0,tt0" : : "g" (*pVal));
            ttVal = TT1_VALUE;
            asm ("pmove %0,tt1" : : "g" (*pVal));
        }
        
        /**************************/
        /* for 68040 (e.g. mv167) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_dtt ()
        {
            asm ("movec %0,dtt0" : : "r" (DTT0_VALUE));
            asm ("movec %0,dtt1" : : "r" (DTT1_VALUE));
        }

From daemon@vxw.ee.lbl.gov  Wed Jan 12 04:01:37 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 12 04:01:47 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 12 04:01:26 PST 1994

        Subject: Problem with cache
        Subject: Problems with cache
        Subject: Problem with cache
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: Re: g++ question
        Subject: Re: "production" release of TCL 7.0 for VxWorks available

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Problem with cache
Date: Wed, 12 Jan 1994 02:18:02 GMT
From: sterrett@manta.nosc.mil (Anthony E. Sterrett)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1994Jan12.021802.18732@nosc.mil>
Sender: news@nosc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: Problems with cache
Date: Wed, 12 Jan 1994 02:27:39 GMT
From: sterrett@manta.nosc.mil (Anthony E. Sterrett)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1994Jan12.022739.18805@nosc.mil>
Sender: news@nosc.mil

Hi all,
	We're working with VxWorks 5.1.1 sparc host
	and a mv167 target. We're writing some low 
	level driver these drivers require atomic
	writes to memory so we have to disable
	the cache using <cacheDisable(DATA_CACHE)>
	to write to the correct place in vme memory.

	A better solution would be to set aside a area
	of vme memory that would be non-cachable or to
	flush the cache. Now I know about the cacheFlush
	command exist however it doesn't seems to have 
	the correct effect.

	Any ideas?

- ------------------------------------------------------------------
Tony"The Tiger" Sterrett NRaD	This is my opinion and only mine
Reply to:sterrett@nosc.mil

		Jaya SriSri RadhaKrishna!
		Nkosi sikelel'iAfrika
- --Red Wings,Pistons Rule, Tigers Rule, Lions Rule!-----------------

From: sterrett@manta.nosc.mil (Anthony E. Sterrett)
Newsgroups: comp.os.vxworks
Subject: Problem with cache
Summary: 
Followup-To: 
Distribution: world
Organization: NCCOSC RDT&E Division, San Diego, CA
Keywords: 

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Wed, 12 Jan 1994 03:37:12 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc.
Keywords: errno write
Message-ID: <CJHzE2.6JC@wrs.com>
References: <hjbCJG6us.Fzo@netcom.com> <james.758267061@wrs.com> <hjbCJGGE4.3IJ@netcom.com>
Sender: news@wrs.com (News Manager)

In article <hjbCJGGE4.3IJ@netcom.com> hjb@netcom.com (squeedy) writes:
>
>a succesful write() to [normal, non-blocking] file i/o 
>must either complete successfully with all bytes requested written
>to the file, or return error (-1) indicating the errno.
>
>vxworks does not do this to a normal synch i/o file write(),
>which was the point of this whole discussion.

The specific case that started this discussion involved seeking
beyond the end of a dosFs file and then writing data.  That write()
returned prematurely (i.e. before <nbytes> were written), which
is a bug.  This is apparently due to a problem in the on-the-fly
allocation which occurs in this situation, with the result being
that the write() only extends to the next disk cluster boundary.
This will be fixed.

Normally, writes to local files do follow the unix/posix convention
and do in fact write the specified number of bytes.  Note that this
was not always the case in earlier versions of VxWorks, which tended 
to write a "convenient" amount and expect the user to make a second
(third, ...) call to write().

Repeat after me: it's a bug, it's a bug, it's a bug, it's a bug.....

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: 12 Jan 1994 04:23:15 GMT
From: squeedy@dhokkaebi.wpd.sgi.com (hwajin bae-contractor)
Organization: Silicon Graphics, Inc., Mountain View, CA
Keywords: errno write
Message-ID: <2gvtvj$eem@fido.asd.sgi.com>
References: <hjbCJG6us.Fzo@netcom.com> <james.758267061@wrs.com> <hjbCJGGE4.3IJ@netcom.com> <CJHzE2.6JC@wrs.com>

In article <CJHzE2.6JC@wrs.com>, Kent Long <kent@wrs.com> wrote:
>
>Normally, writes to local files do follow the unix/posix convention
>and do in fact write the specified number of bytes.  Note that this
>was not always the case in earlier versions of VxWorks, which tended 
>to write a "convenient" amount and expect the user to make a second
>(third, ...) call to write().
>

hmmm...which version of vxworks are you talking about?  the ones i have
seen all do not work correctly.  are you talking about a released version?
what is the last version of vxworks that had the wrong/buggy write()?
5.1?  is there something newer?

>
>Repeat after me: it's a bug, it's a bug, it's a bug, it's a bug.....

hey, no problem repeating... everybody now...

hwajin
 - speaking for myself only...

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: g++ question
Date: Tue, 11 Jan 1994 22:22:50 GMT
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1994Jan11.222250.25218@bnlux1.bnl.gov>
References: <9401111713.AA10361@cod.nosc.mil>

In article <9401111713.AA10361@cod.nosc.mil> halecm@cod.nosc.mil (Curtis M. Hale) writes:
>
>good day,
>
>my name is Curtis Hale, halecm@cod.nosc.mil. I work for Naval Research
>and Development Lab in San Diego, (619) 553-6147.  We are
>running vxWorks applications and are interested in obtaining 
>a C++ compiler for vxWorks development.

	From my notes :

You need to make a file called "cc1plus" (I assume this is the
C++ compiler's "first phase"). This file should be
copied to '$(GCC_EXEC_PREFIX)/m68k-wrs-vxworks/cygnus-2.2.3',
or whatever directory WRS puts the C compiler's "cc1" in.
Goto the gcc directory, and configure and make the whole
compiler, but only move cc1plus :

../configure --target=m68k-sun-sunos3 --host=sparc-sun-sunos4.1.1

One little kludge..... Comment out the SIZE_T #define in tm.h
VxWorks likes size_t to be an "unsigned int", not an "int",

To make libio.a (and libstdio++.a and libg++.a), go to the libg++
directory and make them using the newly created cross compiler :

make 'CXX=cc68k -I$(VXWORKS)/h'

Move libio.a (and libstdio++.a and libg++.a) into same directory 
as cc1plus (so that the "-l" flag works).

Make sure that the C (or C++) runtime libraries don't do 
foolish things like defining a UNIX-style exit(), or make
sure that they don't define exit() at all.

>If anybody has information on Wind River's Centerline C++ product 
>I would appreciate that, too.
>
	Me too. I cobbled the GNU stuff together before this
product was available. I'd like to hear real-life experiences.

- -- 
     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_   
    / / /     \ \ \    / / /     \ \ \     / / /     \ \ \    / / /     \ \ \  
     >>        <<        >>       <<        >>        <<        >>       <<    
     \\        //        \\       //        \\        //        \\       //    

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: "production" release of TCL 7.0 for VxWorks available
Date: 11 Jan 94 19:39:09 GMT
From: brown@ftms.UUCP (Vidiot)
Organization: Vidiot's Other Hangout
Message-ID: <1112@ftms.UUCP>
References: <2gkml0$bvh@ncar.ucar.edu>
Reply-To: brown@ftms.UUCP (Vidiot)

In article <2gkml0$bvh@ncar.ucar.edu> vanandel@rsf.atd.ucar.edu (Joe Van Andel) writes:
<I've made a few fixes to my previous beta release, and am now announcing
<a "production" release of TCL7.0 for VxWorks.  I've been using this port for 3
<months, and it is quite stable. 
<
<Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is
<on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz

This is in error.  Since I do not have ftp (yet), I had to track it down with
a mail server.  The correct info is:

	thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0v4.tar.gz

Notice the missing period.  It makes a world of difference to ftpmail users.
- -- 
harvard\
  ucbvax!uwvax!astroatc!ftms!brown  or  uu2.psi.com!ftms!brown
rutgers/
INTERNET: brown@wi.extrel.com  or  ftms!brown%astroatc.UUCP@cs.wisc.edu

---------------------------

End of New-News digest
**********************

From mpoulsen@piranha.sim.es.com  Wed Jan 12 07:07:08 1994
From: mpoulsen@piranha.sim.es.com (Mike Poulsen)
Date: Wed Jan 12 07:07:17 PST 1994
Mike Poulsen	---  mpoulsen@piranha.sim.es.com  ---
Howdy:

	This is a question concerning DAT tapes. We currently use tapes 
	formatted into two partitions, the first (partition 1) being used for
	directory information and the second (partition 0) for data 
	(i.e. files). We intend to enhace this to support multi-tape backups
	where information may be spread across several DAT tape volumes.
	We have several algorithms in mind on how to accomplish this,  but
	are concerned about adhereing to established standards if some exist.
	
	Has anyone delt with a situation similar to this, and if so do you 
	know of any such standard?

 	In particular, should directory information be stored only on the 
	tape volume that contains the data to which it refers or should
	the directory be kept on the first tape volume and only the data 
 	allowed to spread across several volumes.
	This would require a backup sequence of 1, 2, 3 ... 1.
 	
	(We are not yet convinced that it is possible to gather all information 
	 needed for the directory on a first pass (or any pass) since 
	 information on which volume a file will reside is not known until 
 	 the entire backup proceedure is done).

	Anyway, are main concerns are:
		1) How is directory info stored relative to the data it
		   represents when spread across multiple tape volumes.
		2) What is the typical order of a multi-tape backup sequence.
			A) 1, 2, 3, ...  1
			B) 1, 2, 3, ...
			C) n, 1, 2, 3, ...  (n = last tape volume)
			     etc.

	Thanks for any ideas!!!!

			Michael Poulsen
			Evans & Sutherland Computer Corporation
			Salt Lake City,  Utah

	mail to:	mpoulsen@piranha.sim.es.com

From shaffer_phillip@ae.ge.com  Wed Jan 12 14:26:17 1994
From: shaffer_phillip@ae.ge.com (Phil Shaffer)
Date: Wed Jan 12 14:26:33 PST 1994
Subject: System hang printing 0xffffffff as float
When debugging a program recently, I discovered that vxWorks 
(VxWorks version 5.0.2b as part of VADSworks version 2.0.3(b), on MVME165
or MVME167) hangs when trying to print 0xffffffff as a floating point value.
I wrote a little function to demonstrate this:

int printReal (addr)
   float *addr;
{
   printf("Real @ 0x%x = %f\n", addr, *addr);
}

Here is what I see:

-> ld < printReal.o
value = 0 = 0x0
-> d 0x20000000, 16
20000000:  0000 0000 0000 0010  0000 0000 ffff fffe   *................*
20000010:  4473 c000 40d7 ae14  3c17 e6a3 410d d32f   *Ds..@...<...A../*
value = 21 = 0x15
-> printReal 0x20000000
Real @ 0x20000000 = 0.000000
value = 29 = 0x1d
-> printReal 0x20000010
Real @ 0x20000010 = 975.000000
value = 31 = 0x1f
-> m 0x20000000
20000000:  0000-ffff
20000002:  0000-ffff
20000004:  0000-.   
                 
value = 1 = 0x1
-> printReal 0x20000000
Real @ 0x20000000 = 

The system hangs at this point, and control-X will reboot it.
Is this a known behavior/bug?  Shouldn't NaN (not a number) or
something informative be printed?

Thanks

     Phillip L. Shaffer
     shaffer_phillip@ae.ge.com

From sblachma@aoc.nrao.edu  Wed Jan 12 16:53:55 1994
From: Steve Blachman <sblachma@aoc.nrao.edu>
Date: Wed Jan 12 16:54:04 PST 1994
Subject: Re: System hang printing 0xffffffff as float
This is a known bug which is fixed in 5.1.

From daemon@vxw.ee.lbl.gov  Thu Jan 13 04:01:40 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 13 04:01:52 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 13 04:01:31 PST 1994

        Subject: Themis 10HS?
        Subject: VME Memory Map on a Motorola mvme162
        Subject: Re: Problems with cache
        Subject: pSOS+ to VxWorks porting
        Subject: Request:  Company names that sell VME enclosures
        Subject: HDLC for VxWorks
        Subject: Re: write() transfer count wrong, but errno not set
        Subject: SCSI Disk Drive

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Themis 10HS?
Date: Wed, 12 Jan 1994 15:12:03 GMT
From: br@cs.cmu.edu (Bill Ross)
Organization: CMU Vision and Autonomous Systems Center
Message-ID: <CJIvK4.H9J.3@cs.cmu.edu>
Reply-To: br@cs.cmu.edu
Sender: br@ykm.ius.cs.cmu.edu (Bill Ross)

   Is anyone running on a Themis 10HS Sparc board?  I'd love to
   ask you some questions...  Maybe I could answer some of yours.

   Send me mail
   Bill
   br@cs.cmu.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: VME Memory Map on a Motorola mvme162
Date: 12 Jan 1994 16:48:44 GMT
From: schuweil@forge.fnal.gov (greg schuweiler)
Organization: FERMILAB, Batavia, IL
Keywords: VME
Message-ID: <2h19lc$q23@fnnews.fnal.gov>

I have a question on what controls the memory map with vxWorks/mvme162.

The mvme162 has the VMEchip2 located at 0xFFF40000 - 0xFFF400FF (both
LCSR and GCSR registers), with the first master register located at 
0xFFF40014, (the following is a printing of a range of the VMEchip2 
registers and their content:

     Vme
   Register        Content
   FFF40000       023f0200
   FFF40004       00ff00c0
   FFF40008       0000ffc0
   FFF4000C       0000ffc0
   FFF40010       03df03ef
   FFF40014       efff0040
   FFF40018       00000000
   FFF4001C       00000000
   FFF40020       00000000
   FFF40024       00000000
   FFF40028       00000009
   FFF4002C       c201ad00
   FFF40030       00000700
   FFF40034       00000000
   FFF40038       00000000
   FFF4003C       00000000
   FFF40040       00000000
   FFF40044       00000000
   FFF40048       000f0100

According to my figuring I should be able to get off board via the VME
backplane starting at 0x400000 and ending at 0xEFFF0000.  The slave we are 
using has its full memory mapped to this setup.  Booting the master board 
via Motorola buggy instead of vxWorks shows that writing to the above range 
does indeed send the data to the slave.

Booting the board via vxWorks and then writing to anywhere in the above range
gives a bus error.  This happens with the m and d vxWorks commands along with
the software I have written.

During the vxWorks installation is there something I missed?  I have crusied 
through the various .h and .c files trying to decipher the vme support, but 
alas I had no luck.

=========================================================================
Greg Schuweiler                     The standard disclaimer applies
schuweil@forge.fnal.gov             to all I may have said, may say,
(708) 840-2665                      and/or may do.  It does not reflect,
                                    the feelings of my employer.  Heck,
                                    if it did, we would lose our funding. 

            Like a rock, I stand against the wind
=========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Problems with cache
Date: Wed, 12 Jan 1994 17:16:31 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <1994Jan12.171631.27728@nrtpa038.bnr.ca>
References:  <1994Jan12.022739.18805@nosc.mil>
Sender: billag@b4pphff (Bill Gutknecht)

In article <1994Jan12.022739.18805@nosc.mil>, sterrett@manta.nosc.mil (Anthony E. Sterrett) writes:
|> 
|> Hi all,
|> 	We're working with VxWorks 5.1.1 sparc host
|> 	and a mv167 target. We're writing some low 
|> 	level driver these drivers require atomic
|> 	writes to memory so we have to disable
|> 	the cache using <cacheDisable(DATA_CACHE)>
|> 	to write to the correct place in vme memory.
|> 
|> 	A better solution would be to set aside a area
|> 	of vme memory that would be non-cachable or to
|> 	flush the cache. Now I know about the cacheFlush
|> 	command exist however it doesn't seems to have 
|> 	the correct effect.
|> 
|> 	Any ideas?
|>

	Would cacheDmaMalloc() work?  It supposedly creates a 
	pointer to a "cache-safe" buffer.
 
- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
Bell Northern Research         	 ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC       not know it, he will cast me out of Valhalla
billag@bnr.ca                    and laugh at me ... "
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: pSOS+ to VxWorks porting
Date: Wed, 12 Jan 1994 19:25:05 GMT
From: choi@cod.nosc.mil (Sojin Q. Choi)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1994Jan12.192505.3384@nosc.mil>
Sender: news@nosc.mil

I have VME-based systems and each system is consist of a MVME167 board, a Interphase 4211 FDDI card, and other VME cards.  Application softwares have been developed on pSOS+, but now I am in rush to port VxWorks  for these systems(changing softwares based on pSOS+ to VxWorks 5.1.1.)  I am hoping someone has done this and offer some advice.  My questions are:   
 
 1)  Anyone has done it?
 2)  Anyone has the VxWorks source code for Interphase 4211 Perigrine driver?
 3)  How VxWorks different from pSOS+??

 I would appreciate any advice. 
  
  Thanks,
  choi@cod.nosc.mil  

---------------------------

Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks
Subject: Request:  Company names that sell VME enclosures
Date: Wed, 12 Jan 1994 20:27:11 GMT
From: scheeff@kraft.ecn.purdue.edu (David T Scheeff)
Organization: Purdue University Engineering Computer Network
Message-ID: <CJJA5C.3Dp@noose.ecn.purdue.edu>
Followup-To: poster
Sender: news@noose.ecn.purdue.edu (USENET news)

I am looking for companies that would sell a basic VME card cage
in an enclosed chassis.  Please send names and phone numbers.  
Any info is appreciated...

Thanks,

David Scheeff
scheeff@ecn.purdue.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: HDLC for VxWorks
Date: Wed, 12 Jan 1994 22:58:50 GMT
From: maillet@wrs.com (Al Maillet)
Organization: Wind River Systems, Inc.
Message-ID: <CJJH63.Mv8@wrs.com>

Hi,

Does anyone out there have an HDLC driver written
for VxWorks.  Either public domain or for sale will
do.

		Thanks in advance,

			Al Maillet

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 

  Al Maillet                           al@wrs.com
  Wind River Systems, Inc.             Southwest Application Engineer
  4225 Executive Sq. Suite 1200        Phone: (619)558-4165
  La Jolla, CA 92037                   Fax:   (619)558-8918
- -- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 

  Al Maillet                           al@wrs.com
  Wind River Systems, Inc.             Southwest Application Engineer

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: write() transfer count wrong, but errno not set
Date: Thu, 13 Jan 1994 00:10:05 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Message-ID: <georg.758419805@sgl.ists.ca>
Sender: news@newshub.ists.ca

Ok,

There's been enough heated debate on this so I'm sending out my brute force
workaround. Thanks to Kent Long who managed to let slip enough information
on the bug to identify the prerequisite: lseek() past the end of file.

My workaround simply extends a file by writing 0's on the end whenever there
is a seek past the end. (This may result in a file being extended when it
shouldn't have been, i.e. no write follows the seek, but what the hell.)
Use file_seek() below instead of lseek() to seek. Note that file_seek() is
not meant to be plug-replaceable with lseek(), that feature is not
required in our system. 'zero8k' is a character array of 8192 zero bytes.

Georg.

- --------------------------------------------------------------------------
int file_seek(int fd, int offset)
/*
 * Sets the byte offset for the next write or read from a file.
 * Simple interface to lseek() function. This returns ERR_NONE iff the actual
 * actual seek offset returned by lseek() exactly matches the desired offset.
 * 'fd' is the file descriptor to seek on.
 * 'offset' is the absolute file position to seek to in bytes, where 0 is
 *          the beginning of file.
 * Return value is error code (not a VxWorks error code, another type).
 */
{
   STATUS st;
   struct stat filestat;        /* file status info obtained from fstat() */
   int aoff;        /* actual seek offset returned by lseek() */
   long int fillsz;    /* (***) for SPR #2739 kludge */
   long int fillamt;   /* (***) for SPR #2739 kludge */

   if (FileDebug && Verbose>=2)  {
      wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n",
                                                                  offset,fd);
   }

   /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with
        transfer count too low but errno not set after seeking past current
        end of file). Note that this may extend the file prematurely, i.e.
        even if no write() calls follow the seek. */
   /* get current file size */
   st=fstat(fd, &filestat);
   if (st==VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n",
                                                           fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* manually extend file using zero writes if seek offset past end of file
        (note: tried ioctl() with FIOTRUNC, but this only works to shorten
        files! */
   if (offset>filestat.st_size)  {
      /* seek to the end of the file first */
      errno=0;
      aoff=lseek(fd, filestat.st_size, SEEK_SET);
      if (aoff != filestat.st_size)  {
         /* returned value should always match 'filestat.st_size' */
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n",
                                     fd, aoff, filestat.st_size, vw_errmsg(0));
         }
         return(ERR_VXIO);
      }

      /* fill file with zeroes to bring length up to 'offset' */
      fillsz=offset-filestat.st_size;
      while (fillsz>0)  {
         if (fillsz>8192)
            fillamt=8192;
         else 
            fillamt=fillsz;

         errno=0;
         aoff=write(fd, zero8k, fillamt);
         if (aoff == VX_ERROR)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         if (aoff != fillamt)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n",
                       fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         fillsz -= fillamt;
      }

      /* flush the output to disk immediately */
      st=ioctl(fd, FIOFLUSH, 0);
      if (st!=VX_OK)  {
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
         }
         return(ERR_VXIO);
      }
   }

   /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */

   errno=0;
   aoff=lseek(fd, offset, SEEK_SET);
   if (aoff == VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n",
                                                     offset, fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* returned value should always match 'offset' */
   if (aoff != offset)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n",
                                             fd, aoff, offset, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   return(ERR_NONE);
}
- -- 

Space Geodynamics Laboratory                 | Internet: georg@sgl.ists.ca
Institute for Space and Terrestrial Science  |    Phone: (416) 665-5458
4850 Keele St./North York/Ont/Canada/M3J 3K1 |      Fax: (416) 665-1815

---------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI Disk Drive
Date: Thu, 13 Jan 1994 01:36:59 GMT
From: tsai@li.loral.com (Edward Tsai)
Organization: Loral Instrumentation
Keywords: SCSI
Message-ID: <tsai.758425019@loral>
Sender: usenet@li.loral.com

Has anyone have any experience implementing a SCSI Floppy Drive under
VxWorks-5.1 ???.  Or, Booting vxworks from a floppy drive ???.

If yes, then Questions:

1. How large is the Floppy Device Driver ?.

2. How much E-PROM space is still required for the basic BOOT image ?.

3. Does it support SCSI-2 ?

4. Which types of SCSI Floppy Drive has 5.1 been successful with ?

5. How much work is involved in modifying scsi.c ?

A reply is greatly appreciated.

Please send reply to:	tsai@li.loral.com

or feel free to call me at :  1-800-351-8483  extension: 4488 

Edward Tsai
Loral Instrumentations
(619) 674-5100. ext: 4488

---------------------------

End of New-News digest
**********************

From rdmacko@somnet.sandia.gov  Thu Jan 13 07:44:31 1994
From: RD Mackoy <rdmacko@somnet.sandia.gov>
Date: Thu Jan 13 07:44:40 PST 1994
Subject: Booting and rebooting
Can a VxWorks image be generated to bring up the minimum functionality to
establish ethernet communications to a host, then let the host load a full
image and reboot the system?
The whys are long and convoluted, but if anyone has done a system this way
I would appreciate any input or help.
Thank you,
RD Mackoy		rdmacko@somnet.sandia.gov
Sandia National Labs	505-844-1911
PO Box 5800  MS 365	505-844-4797
Albuquerque, NM		87185

 

From wright@luke.atdiv.lanl.gov  Thu Jan 13 08:21:41 1994
From: wright@luke.atdiv.lanl.gov (Rozelle Wright)
Date: Thu Jan 13 08:21:49 PST 1994
Subject: Re: VME Memory Map on a Motorola mvme162

> Newsgroups: comp.os.vxworks
> Subject: VME Memory Map on a Motorola mvme162
> Date: 12 Jan 1994 16:48:44 GMT
> From: schuweil@forge.fnal.gov (greg schuweiler)
> Organization: FERMILAB, Batavia, IL
> Keywords: VME
> Message-ID: <2h19lc$q23@fnnews.fnal.gov>
> 
> I have a question on what controls the memory map with vxWorks/mvme162.
> 
> The mvme162 has the VMEchip2 located at 0xFFF40000 - 0xFFF400FF (both
> LCSR and GCSR registers), with the first master register located at 
> 0xFFF40014, (the following is a printing of a range of the VMEchip2 
> registers and their content:
> 
I think the problem is the bundled mmu support.
If you look in the default board support package for
the 162 in config/mv162/config.h, the line
#define INCLUDE_MMU_BASIC       /* bundled mmu support */
is included.  This means that the MMU maps your
memory using the default mapping that comes with the system.
On the 167, I was able to get a working system by
commenting out that line and including
#define INCLUDE_BP_5_0		/* version 5.0 backplane driver */
which seemed to be necessary because I was using eiattach during the boot.

I am not really happy with this solution.  John Winans from Argonne sent me
an assembly routine which does not require the BP_5_0 inclusion which works better.
I would appreciate some advice from Wind River experts such as Chris Ford as to the proper
way to use the mapping capability of the bundled MMU to allow access to 
extended memory.

Rozelle Wright
AOT-8, Los Alamos National Laboratory
wright@atdiv.lanl.gov

----- End Included Message -----

From daemon@vxw.ee.lbl.gov  Fri Jan 14 04:01:44 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 14 04:01:55 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 14 04:01:35 PST 1994

        Subject: Upgrading VXW 4.0.2 to latest version
        Subject: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare
        Subject: Phone# WRS
        Subject: Re: Request:  Company names that sell VME enclosures
        Subject: Re: Phone# WRS
        Subject: Re: Phone# WRS
        Subject: signal handler-like action on taskDelete()?
        Subject: General Micro System V64 Experiences?
        Subject: Re: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare
        Subject: Re: Booting and rebooting
        Subject: Re: signal handler-like action on taskDelete()?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Upgrading VXW 4.0.2 to latest version
Date: 13 Jan 1994 13:21:12 GMT
From: jka@air77.larc.nasa.gov (J. Keith Alston)
Organization: NASA Langley Research Center
Message-ID: <2h3hs8$l7e@reznor.larc.nasa.gov>
Reply-To: jka@air77.larc.nasa.gov

Hi,
    We currently run VXW 4.0.2. which is a very old version. 
I`m interested in getting some idea about what the effect on
our code would be if we updated to the VXW latest version. 
I'm wondering if we would have to make major changes to our
code or just minor adjustments? I guess the real question is,
how much is vxworks backward compatible? Any comments or 
info would be greatly appreciated.
 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Keith Alston Lockheed Eng & Sci Co  + There's a less than 5% chance of 
MS 130 Nasa LaRC Hampton VA 23666   = tonight and tomorrow
jka@air77.larc.nasa.gov             +                     

---------------------------

Newsgroups: comp.os.vxworks
Subject: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare
Date: 13 Jan 1994 13:47:36 GMT
From: jka@air77.larc.nasa.gov (J. Keith Alston)
Organization: NASA Langley Research Center
Message-ID: <2h3jdo$l7e@reznor.larc.nasa.gov>
Reply-To: jka@air77.larc.nasa.gov

Hi,
   I am running VXW 4.0.2 on heurikon 68030 boards. The host computer is another
Heurikon 68030 running Unix SYS VR3. I am attempting to write server code for
VXW which uses RPC. I am able to create an executable on the host but when I
download this executable to VXW I get undefined symbol errors:

undefined symbol: __iob
undefined symbol: _memset
ld error: error reading file.
value = -1 = 0xffffffff

I am looking for anyone out there with a similar setup who is using RPC or
who may be able to shed some light on this problem. Thank You.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Keith Alston Lockheed Eng & Sci Co  + There's a less than 5% chance of 
MS 130 Nasa LaRC Hampton VA 23666   = tonight and tomorrow
jka@air77.larc.nasa.gov             +                     

---------------------------

Newsgroups: comp.os.vxworks
Subject: Phone# WRS
Date: 13 Jan 1994 13:55:37 GMT
From: jka@air77.larc.nasa.gov (J. Keith Alston)
Organization: NASA Langley Research Center
Message-ID: <2h3jsp$l7e@reznor.larc.nasa.gov>
Reply-To: jka@air77.larc.nasa.gov

could someone please post the phone number for Wind River Systems?

- ---
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Keith Alston Lockheed Eng & Sci Co  + There's a less than 5% chance of 
MS 130 Nasa LaRC Hampton VA 23666   = tonight and tomorrow
jka@air77.larc.nasa.gov             +                     

---------------------------

Newsgroups: comp.arch.bus.vmebus,comp.os.vxworks
Subject: Re: Request:  Company names that sell VME enclosures
Date: Thu, 13 Jan 1994 16:36:09 GMT
From: johnb@fc.hp.com (John Barclay)
Organization: Hewlett-Packard Fort Collins Site
Message-ID: <CJKu49.BM8@fc.hp.com>
References: <CJJA5C.3Dp@noose.ecn.purdue.edu>
Followup-To: comp.arch.bus.vmebus,comp.os.vxworks
Sender: news@fc.hp.com (news daemon)

You may want to subscribe to VITA.  VITA has a directory, $50, that lists
pretty much all VME solutions, including cabinets.

Call 602-951-8866.

- --
John Barclay                                    Hewlett-Packard Company 
TN 229-4325					johnb@hpfcjb.fc.hp.com
AT&T (303) 229-4325				

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Phone# WRS
Date: 13 Jan 1994 17:54:37 GMT
From: adam@csi.jpl.nasa.gov (Adam Bernstein)
Organization: Jet Propulsion Laboratory
Message-ID: <2h41st$qib@csi.jpl.nasa.gov>
References: <2h3jsp$l7e@reznor.larc.nasa.gov>

WRS phone #:  800-545-WIND

- ------------------------------------------------------------------------
Adam Bernstein               Phone: 818 354-9784    Jet Propulsion Lab
Guidance & Control /         FAX:   818 393-6105    MS 198-235
  Optical Tracking Group                            4800 Oak Grove Dr.
adam@bloodhound.jpl.nasa.gov                        Pasadena, CA 91109
- ------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Phone# WRS
Date: Thu, 13 Jan 1994 17:59:20 GMT
From: jerald@wrs.com (Jerald Pendleton)
Organization: Wind River Systems, Inc.
Message-ID: <jerald.758483960@wrs.com>
References: <2h3jsp$l7e@reznor.larc.nasa.gov>
Sender: news@wrs.com (News Manager)

jka@air77.larc.nasa.gov (J. Keith Alston) writes:

>could someone please post the phone number for Wind River Systems?

1-800-545-WIND (9463)

- -- 
Jerald R. Pendleton (Jerry) - Tech Support Engineer - Wind River Systems
       Corporate Headquarters: 1010 Alantic Ave, Alameda, Ca.  94501
email: jerald@wrs.com  phone: 1-800-545-WIND  Non-WRS-email: jrpend@netcom.com
        "Bullet proof code can't stand up to teflon bullets"  - stig

---------------------------

Newsgroups: comp.os.vxworks
Subject: signal handler-like action on taskDelete()?
Date: 13 Jan 94 17:49:36 MST
From: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore)
Message-ID: <1994Jan13.174937.13103@hellgate.utah.edu>
Reply-To: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore)

Is there a way to install a signal handler that will run before a task
is deleted or suspended?  taskDeleteHookAdd() seems like overkill.

- -- 
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush

---------------------------

Newsgroups: comp.os.vxworks
Subject: General Micro System V64 Experiences?
Date: Fri, 14 Jan 1994 04:10:58 GMT
From: dog@xdev.sunspot.noao.edu (Fritz Stauffer)
Organization: Computer, Hardware and Observatory Support
Keywords: SBus, SPARC, MBus
Message-ID: <1994Jan14.041058.25463@noao.edu>
Sender: news@noao.edu

	I am interested in the GMS V64 cpu board and its ability to
use different cpus on an mbus card.  Does anyone have any
experience with the card?  Which cpus do you use?
What are the pros and cons?

	Thanks,

	fritz stauffer
	sac peak obs.
	sunspot, nm  88349

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VXW 4.0.2 + Heurikon SYS V host + RPC = nightmare
Date: Fri, 14 Jan 1994 10:52:19 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCJM8v7.24t@netcom.com>
References: <2h3jdo$l7e@reznor.larc.nasa.gov>

In article <2h3jdo$l7e@reznor.larc.nasa.gov> jka@air77.larc.nasa.gov writes:
>Hi,
>   I am running VXW 4.0.2 on heurikon 68030 boards. The host computer is another
>Heurikon 68030 running Unix SYS VR3. I am attempting to write server code for
>VXW which uses RPC. I am able to create an executable on the host but when I
>download this executable to VXW I get undefined symbol errors:
>
>undefined symbol: __iob
>undefined symbol: _memset
>ld error: error reading file.
>value = -1 = 0xffffffff

memset () can be changed to bzero() if it's setting memory to 0's.
otherwise, write your own.  4.0.2 is pretty old, and back then
there was no memset() in vxworks library (does it have memset()
now?).  it also looks as though you might be dragging in some
host library routines.  in the old days, vxworks linked with
host resident libraries as well as its own.  if you have stdio
routines that are not resolved by vxworks libs, you might be
draggin in host's stdio stuff, which will refer to _iob[].

Hwa-Jin Bae
PEACEFUL STAR

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Booting and rebooting
Date: Fri, 14 Jan 1994 11:00:52 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCJM99H.2n1@netcom.com>
References: <199401131547.IAA01094@somnet.sandia.gov>

In article <199401131547.IAA01094@somnet.sandia.gov> RD Mackoy <rdmacko@somnet.sandia.gov> writes:
>Can a VxWorks image be generated to bring up the minimum functionality to
>establish ethernet communications to a host, then let the host load a full
>image and reboot the system?

i'm not sure what "let the host load a full image" means.
if you're using ethernet for download, there needs to be something
running on the target reading off of ethernet.  given this, 
you'll be writing code that does essentially the same thing
as what vxworks network download does.

there are modified versions of vxworks code out there that
does something similar to what you describe -- over vme backplane.
the host (unix) downloads vxworks image over vme bus to target
memory directly and tells the target's monitor rom to go execute
the code just loaded (i.e. reboot).  this is how sun's network
co-processor board works (yes, it runs vxworks).

Hwa-Jin Bae
PEACEFUL STAR

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: signal handler-like action on taskDelete()?
Date: Fri, 14 Jan 1994 11:12:12 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCJM9sC.383@netcom.com>
References: <1994Jan13.174937.13103@hellgate.utah.edu>

In article <1994Jan13.174937.13103@hellgate.utah.edu> moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) writes:
>
>Is there a way to install a signal handler that will run before a task
>is deleted or suspended?  taskDeleteHookAdd() seems like overkill.

as far as i know there is no direct way to do this. even unix won't
allow you do catch SIGKILL.  taskDeleteHooks aren't really that
much of an overkill; it doesn't add overhead like switchHooks,
and is only called at deletion time.  implementing it in any other
way than deleteHooks is not impossible, but a bit messy.  in most
single-mode thread oriented OS'es, like vxworks, task deletion
is either done by the calling task's context or a third-party
task's context (excTask in vxWorks?) -- because the task 
at the time which is to be deleted needs to be suspended and
set to a state that can be manipulated statically, which means
the task will not resume its context to run any more code.
one could implement what you're asking, but it's not as clean as
deleteHooks, imho.

deleteHooks really shouldn't be necessary, but the lack of automatic/
optional resource reclamation in vxworks upon task deletion 
necessitates it.  nevertheless, its overhead really isn't "overkill".

Hwa-Jin Bae
PEACEFUL STAR

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sat Jan 15 04:01:01 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 15 04:01:10 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 15 04:00:53 PST 1994

        Subject: bpAlive Error at Bootup
        Subject: pcc2 timer int service time

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: bpAlive Error at Bootup
Date: Fri, 14 Jan 1994 14:07:36 GMT
From: campoe@tommy.jsc.nasa.gov (Alex Campoe)
Organization: Johnson Space Center, Houston, Tx
Message-ID: <1994Jan14.140736.19783@aio.jsc.nasa.gov>
Reply-To: campoe@mickey.jsc.nasa.gov
Sender: Alex Campoe

Hi,

I am working with two Force 30 CPUs connected to a VME backplane. A lot
of times when I reboot the systems, the slave board will not find the
anchor, printing this 'bpAlive' error once every 30 seconds or so.

The manual does not say anything about it. Has anybody seen this before?

Thanks.

Alex Campoe

- -- 
    ^^/^^/^^  /^^/^^/^^     Alex Campoe
   ^^/  /^^  /^^            Lockheed Engineering and Sciences Co.
  ^^/^^/^^  /^^             Houston, TX 
 ^^/  /^^  /^^/^^/^^        CAMPOE@MICKEY.JSC.NASA.GOV

---------------------------

Newsgroups: comp.os.vxworks
Subject: pcc2 timer int service time
Date: Fri, 14 Jan 1994 22:54:43 GMT
From: geger@den.mmc.com (George Eger (303) 971-6974)
Organization: Martin Marietta Astronautics Group
Keywords: mv167 pcc2 
Message-ID: <1994Jan14.225443.28852@den.mmc.com>
Sender: news@den.mmc.com (News)

Hi.  I am using the usrTime lib from MBARI on a mvme167 and have seen
a strange problem.  Every once in a while, two adjacent gettimeofday()
timestamps (using PCC2 timer1 for usec) will result in the elapsed time
being negative.  I can only explain this if the time to propagate the
interrupt from the PCC2 chip to the 68040 on the mv167 is significant - 
in this case about a microsecond.  It looks like my program is sometimes
able to read the timer before the interrupt gets propagated to the kernel
to update the accumulated time.

Does anybody out there know how much time (nominally) it would take for
the '040 to stop processing a normal task after the PCC2 timer matches the 
value in its compare register?

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

End of New-News digest
**********************

From leonid@rst.hellnet.org  Mon Jan 17 01:39:59 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Mon Jan 17 01:40:08 PST 1994
Subject: SPOX with VxWorks
We are looking for people who use SPOX and VxWorks and have
some experience with the interfaces between the two.
Those of you who have the relavent experience and wouldn't mind
abswering a couple of question, please respond directly to me.
W will submit a summary to the exploder if enougth information
will come in.

-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From daemon@vxw.ee.lbl.gov  Tue Jan 18 04:01:40 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 18 04:01:50 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 18 04:01:31 PST 1994

        Subject: Global Alert For All: Jesus is Coming Soon

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Global Alert For All: Jesus is Coming Soon
Date: 17 Jan 1994 19:19:24 -0500
From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV)
Organization: Andrews University, Berrien Springs, MI, 49104
Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu>

The earthquake in Los Angeles, California, the flood in Europe, the seemingly
unstoppable war in the former Yugoslavia, the devastating fires in Australia,
the flood in the Midwest of the United States of America, the devastating fires
near Los Angeles, California, the rapid and appalling increase in violence in
cities, towns, villages all over the world, the famines, the diseases, the rapid
decline of the family unit, and the destructive earthquake in India (in 1993)
are signs that this world's history is coming to a climax. The human race
has trampled on God's Constitution, as given in Exodus 20:1-17 (King James
Version Bible), and Jesus is coming to set things right. These rapidly
accelerating signs are an indication that Jesus is coming soon (Matthew 24).

God's Holy Spirit is gradually withdrawing its protection from the earth
and the devastating events you see are demonstrations of Satan's power. All
those who are not guarded by God are in danger of forever losing eternal life.

If you want to know what's about to happen, please study the books of Daniel
and Revelation which are located in God's Word, the Bible.  They are not
sealed or closed books. They can and must be understood by all. Every word
in the Bible from Genesis to Revelation is true. The Bible and the Bible only
must be your guide.

When God's Law (the Constitution for the Universe) is consistently ignored, 
disregarded, changed, and questioned, He permits certain events to occur to 
wake us up.  I would urge all, wherever you are and regardless of the 
circumstances, to directly call on Jesus and ask Him to intervene in your life.
Jesus who created this planet and every living creature in it and on it, died 
on the cross, was raised from the dead by God the Father, and is now in Heaven
interceding for you. Jesus is the only One who can rescue us from the slavery,
misery, and death Satan is causing us.

For reference I'm including God's Constitution as given in the King James
Version Bible. Please note that when God says the seventh day, he means Sabbath
(the 7th day of the week) not Sunday (1st day of the week).

Commandment #1:  Exodus 20:1-3 (KJV)  And God
                 spake all these words, saying, I am         
                 the LORD thy God, which have brought
                 thee out of the land of Egypt, out
                 of the house of bondage. Thou shalt have
                 no other gods before me.

Commandment #2:  Exodus 20:4-6 (KJV) Thou shalt not make
                 unto thee any graven image, or any
                 likeness of any thing that is in heaven
                 above, or that is in the earth beneath,
                 or that is in the water under the earth.
                 And shewing mercy unto thousands of them
                 that love me, and keep my commandments.

Commandment #3:  Exodus 20:7 (KJV) Thou shalt not take
                 the name of the LORD thy God in vain;
                 for the LORD will not hold him
                 guiltless that taketh his name in vain.

Commandment #4:  Exodus 20:8-11 (KJV) Remember the sabbath
                 day, to keep it holy. Six days shalt thou
                 labour, and do all thy work: But the
                 seventh day is the sabbath of the LORD
                 thy God: in it thou shalt not do any
                 work, thou, nor thy son, nor thy daughter,
                 thy manservant, nor thy maidservant, nor
                 thy cattle, nor thy stranger that is
                 within thy gates: For in six days the
                 LORD made heaven and earth, the sea, and
                 all that in them is, and rested the seventh
                 day: wherefore the LORD blessed the sabbath
                 day, and hallowed it.

Commandment #5:  Exodus 20:12 (KJV) Honour thy father and thy
                 mother: that thy days may be long upon the
                 land which the LORD thy God giveth thee.

Commandment #6:  Exodus 20:13 (KJV) Thou shalt not kill.

Commandment #7:  Exodus 20:14 (KJV) Thou shalt not commit
                 adultery.

Commandment #8:  Exodus 20:15 (KJV) Thou shalt not steal.

Commandment #9:  Exodus 20:16 (KJV) Thou shalt not bear
                 false witness against thy neighbour.

Commandment #10: Exodus 20:17 (KJV) Thou shalt not covet
                 thy neighbour's house, thou shalt not
                 covet thy neighbour's wife, nor his
                 manservant, nor his maidservant, nor
                 his ox, nor his ass, nor any thing that
                 is thy neighbour's.

I also recommend that the following books be obtained and closely studied:

         The Great Controversy
         By Ellen G. White
         Review and Herald Publishing Association
         Hagerstown, MD 21740

	 The Desire of the Ages
	 By Ellen G. White
	 Review and Herald Publishing Association
	 Hagerstown, MD 21740

         Patriarchs and Prophets
         By Ellen G. White
         Review and Hearld Publishing Association
         Hagerstown, MD 21740

	 Daniel and the Revelation
         By Uriah Smith
         Review and Herald Publishing Association
         Hagerstown, MD 21740
- -------
Clarence L. Thomas IV
Phone:  616-471-6116
E-mail: thomas@redwood.cc.andrews.edu

---------------------------

End of New-News digest
**********************

From kwaldman@bbn.com  Tue Jan 18 05:15:28 1994
From: Karl Waldman <kwaldman@bbn.com>
Date: Tue Jan 18 05:15:36 PST 1994
Subject:  daemons etc
	I've had trouble with some vxWorks daemons, perhaps
Clarence Thomas would give me some consultation on the problem.

	Karl

Note: for the humor impair please add multiple :-)

From mea@mclean.sparta.com  Tue Jan 18 06:24:23 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Tue Jan 18 06:24:35 PST 1994
Subject: Re: Global Alert For All: Jesus is Coming Soon
Greetings!

>From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV)

> are signs that this world's history is coming to a climax. The human race
> has trampled on God's Constitution, as given in Exodus 20:1-17 (King James
> Version Bible), and Jesus is coming to set things right. These rapidly
> accelerating signs are an indication that Jesus is coming soon (Matthew 24).

Speaking as a Taoist, it simply seems to me that the world is putting back
into equilibrium that which man has shifted out of whack.  But, if the 
above is true, does that mean that I can get some relief on my delivery
dates ;-)?

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From dwampl@atl.com  Tue Jan 18 11:04:11 1994
From: dwampl@atl.com (Dean Wampler (dwampl@atl.com))
Date: Tue Jan 18 11:04:32 PST 1994
Subject: Re:  Global Alert For All: Jesus is Coming Soon
> From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV)
> Organization: Andrews University, Berrien Springs, MI, 49104
> Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu>
> ...
> These rapidly accelerating signs are an indication that Jesus is 
> coming soon (Matthew 24)....

I was once foolish enough to believe those who claimed that there was 
something unique about this age which made the return of Christ near.  Then I
matured enough to realize that we have it *good* compared to some of the periods
of history that have come and gone in the last 2000 years.  As far as natural
disasters are concerned, the last 10,000 or so years have been relatively 
"uneventful".

Please keep your "angry-god" conspiracy theories out of this mail group. 
Some of us have honest work to do.

Thank you,

Dean  (dwampl@atl.com)

From larkin@csd.nad.northrop.com  Tue Jan 18 13:02:55 1994
From: "Sean K. Larkin" <larkin@csd.nad.northrop.com>
Date: Tue Jan 18 13:03:18 PST 1994
Subject: Re: comp.os.vxworks newsdigest

> wake us up.  I would urge all, wherever you are and regardless of the 
> circumstances, to directly call on Jesus and ask Him to intervene in your life

what is his e-mail address?

From hjb@dhokkaebi.wpd.sgi.com  Tue Jan 18 17:17:00 1994
From: "Hwa-jin Bae -- consultant" <hjb@dhokkaebi.wpd.sgi.com>
Date: Tue Jan 18 17:17:08 PST 1994
Subject: mvme147 
i'm looking for a mvme147 for a project.
if you have any extras sitting idle, available
either for sale or loan, please respond.

thanks.
hjb@netcom.com
PEACEFUL STAR

From daemon@vxw.ee.lbl.gov  Wed Jan 19 04:01:52 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 19 04:02:21 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 19 04:01:32 PST 1994

        Subject: Re: redirecting the shell input, anyone???
        Subject: re:  Global Alert For All: Jesus is Coming Soon
        Subject: re : Global Alert For All: Jesus is Coming
        Subject: Re: re : Global Alert For All: Jesus is Coming
        Subject: Re: VME Memory Map on a Motorola mvme162
        Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: redirecting the shell input, anyone???
Date: 18 Jan 94 11:39:45 -0400
From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer)
Organization: NRL SPACE SYSTEMS DIVISION
Message-ID: <1994Jan18.113945.1177@nrlvx1.nrl.navy.mil>
References: <1994Jan18.081847.1176@nrlvx1.nrl.navy.mil>

Thought I'd clairify things a bit:

In article <1994Jan18.081847.1176@nrlvx1.nrl.navy.mil>, dyer@nrlvx1.nrl.navy.mil (Doug Dyer) writes:
> Hi folks,
> 
> 	Has anyone successfully redirected the shell input?  I have
> strings I want the shell to parse, but I can't seem to get it to work
> (in fact, it ignores the string completely).

 -> cut discussion of problem code <-
> 
> I've tried leaving out the shell locks, the shellOrigStdSet, etc.   While
> the code above is not exactly slick, its just a proof-of-concept to see
> that I can indeed redirect input.  The string I sent it was "devs\n"
> and I expected to produce the usual devs report, but got nothing :(
> Suspecting the memory device and an incompatible ioctl call made by the shell,
> I tried this with a pty device too :(
> 
> anyone know what I'm doing/not doing????
> 
> thanks!

currently I am using the "execute()" routine, however this is not the same
as controlling standard input.  Since execute() just calls the yy* yacc stuff
it plays with the shell parser.  This works for standard shell work,
but does not help me control anything I run from the shell that requires
input (ie: help() ).

So my original question, "has anyone redirected shell input" should read
"standard input" not "shell".  I need to replace the keyboard, so to speak.
The shell may or may not be running.

any feedback would be appreciated!

> -- 
> Doug Dyer   *    STI   *    dyer@nrlvax.nrl.navy.mil    | "(2B) | !(2B) -> ?"
> DISCLAIMER:  These are my opinions, and not necessarily |  LOWLY SHOPKEEPER,  
> those of STI, NRL,  and most likely you too.            | WHERE IS YOUR PEZ!  
> --------------------------------------------------------+---------------------
- -- 
Doug Dyer   *    STI   *    dyer@nrlvax.nrl.navy.mil    | "(2B) | !(2B) -> ?"
DISCLAIMER:  These are my opinions, and not necessarily |  LOWLY SHOPKEEPER,  
those of STI, NRL,  and most likely you too.            | WHERE IS YOUR PEZ!  
- --------------------------------------------------------+---------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: re:  Global Alert For All: Jesus is Coming Soon
Date: Tue, 18 Jan 1994 21:09:56 GMT
From: billag@b4pphff.bnr.ca (Bill Gutknecht)
Organization: Bell-Northern Research, Ottawa, Canada
Message-ID: <1994Jan18.210956.13190@nrtpa038.bnr.ca>
References:  <9401181902.AA14366@atl.com>
Sender: billag@b4pphff (Bill Gutknecht)

In article <9401181902.AA14366@atl.com>, dwampl@atl.com (Dean Wampler (dwampl@atl.com)) writes:
|> > From: clarence@orion.cc.andrews.edu (Clarence L. Thomas IV)
|> > Organization: Andrews University, Berrien Springs, MI, 49104
|> > Message-ID: <2hf9uc$1gd@orion.cc.andrews.edu>
|> > ...
|> > These rapidly accelerating signs are an indication that Jesus is 
|> > coming soon (Matthew 24)....
|> 
|> I was once foolish enough to believe those who claimed that there was 
|> something unique about this age which made the return of Christ near.  Then I
|> matured enough to realize that we have it *good* compared to some of the periods
|> of history that have come and gone in the last 2000 years.  As far as natural
|> disasters are concerned, the last 10,000 or so years have been relatively 
|> "uneventful".
|> 
|> Please keep your "angry-god" conspiracy theories out of this mail group. 
|> Some of us have honest work to do.
|> 

	This bozo seems to have cross posted this message to 
	just about every newsgroup I read ... it's quite ridiculous ...

- ------------------------------------------------------------------------------
Bill Gutknecht                  "If I die, I will go before Crom and he will 
Bell Northern Research         	 ask me 'What is the Riddle of Steel?'  If I do
Research Triangle Park, NC       not know it, he will cast me out of Valhalla
billag@bnr.ca                    and laugh at me ... "
- ------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: re : Global Alert For All: Jesus is Coming
Date: 18 Jan 1994 22:24:53 GMT
From: edwink@orff.NoSubdomain.NoDomain (Edwin Khachatourian)
Organization: Image Analysis Systems Group, JPL
Message-ID: <2hhnjl$8hc@elroy.jpl.nasa.gov>

	This is not a religious newsgroup. This guy must have forgotten the 
11th commandment. This is how it goes.

	11th commandment: Thou shalt not post religious discussions at non
			  religious newsgroups such as comp.os.vxworks.

I just hope that he gets flamed by yhe people from all the newsgroups he
posted his message on. I sent him a personal copy of the 11th commandment.

	Edwin Kh.
	/(o\
	\o)/

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: re : Global Alert For All: Jesus is Coming
Date: Wed, 19 Jan 1994 00:06:51 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc.
Message-ID: <CJuoBH.J4H@wrs.com>
References: <2hhnjl$8hc@elroy.jpl.nasa.gov>
Sender: news@wrs.com (News Manager)

edwink@orff.NoSubdomain.NoDomain (Edwin Khachatourian) writes:
>
>	This is not a religious newsgroup.

I would have to say that very much depends on the topic!

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VME Memory Map on a Motorola mvme162
Date: Wed, 19 Jan 1994 07:41:04 GMT
From: Andreas P. Pauletti <pauletti@tech.ascom.ch>
Organization: Ascom Tech Ltd.
Message-ID: <1994Jan19.074104.10643@hasler.ascom.ch>
References: <2h19lc$q23@fnnews.fnal.gov>
Sender: news@hasler.ascom.ch

We are using also the MVME162 and I had also a problem with the VME
controller.
I added support for the Industry Pack of the board. And I realiezted that
the setup
of the VMECHIP2 in the file sysLib.c is not correct. 

1. If you are using the MMU of the board than you have to make sure that
the 
    structure "sysPhysMemDec" is corrdctly setup. That you don not have
any
    memory overlap.

2. Also check if the LOCAL_MEM_SIZE  and corresponding constants are set 
    to the correct value (in the package we got it was configured for 32M 
    allthough the onborad memeory is max 4M)

3. Check also the part of the sysLib.c where the VMECHIP2 is initialised
there
    the comment does not correspond to the settings.

4. When make a remake generate also  the bootrom.hex. This is needed for 
    the correct setup of the MMU.

I hope it helps

regards
           andreas pauletti

---------------------------

Newsgroups: comp.os.vxworks,comp.answers,news.answers
Subject: comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]
Date: Wed, 19 Jan 1994 06:26:41 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded
Message-ID: <hjbCJv5wI.AvA@netcom.com>
Followup-To: comp.os.vxworks
Reply-To: hjb@netcom.com
Sender: hjb@netcom.com (squeedy)

Archive-name: vxworks-faq
Maintained-by: hjb@netcom.com
Last-modified: Jan 18, 1994
Version: 1.2

This is the list of frequently asked questions (and their answers) for
the newsgroup comp.os.vxworks. 

Where possible, pointers to existing information are included here, rather
than rehashing that information again.

If you haven't already done so, now is as good a time as any to read the
guide to Net etiquette which is posted to news.annouce.newusers regularly.
You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know
about smileys, followups and when to reply by email to postings.

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  You can retrieve the latest copy
of this FAQ via anonymous FTP from rtfm.mit.edu in the directory
/pub/usenet-by-group/comp.os.vxworks.  Remember to use ASCII mode 
when transferring.

This FAQ was compiled by hjb@netcom.com using comments by readers of
comp.os.vxworks as well as his own limited knowledge of VxWorks.  Credits
appear at the end.  Comments and indications of doubt are enclosed in []s in
the text.  Each section begins with dashes ("-") on a line of their own,
then the section number.  This should make searching for a specific section
easy.

This FAQ is also available via anonymous ftp in:

	netcom.com:pub/hjb/vxfaq

- -------------------------------------------------------------------------

		TABLE OF CONTENTS

	1. What is VxWorks? 
	2. Brief History of VxWorks
	3. What are some of the major features of VxWorks?
	4. What are the Latest versions of VxWorks?
	5. Where is the archive site for user-contributed code?
	6. What application notes are available from Wind River?
	7. How can I join the VxWorks user's group?
	8. Is comp.os.vxworks also available via a mailing list?
	9. Can I use gcc or g++ with VxWorks?
	10. Other C/C++ Compiler tools for VxWorks?
	11. Which cross-debuggers can I use with VxWorks?
	12. What are differences between UNIX and VxWorks?
	13. What are the performance/benchmark numbers for WIND kernel?
	14. What are the performance/benchmark numbers for VxWorks TCP/IP?
	15. What is the VxSim VxWorks Simulator?
	16. Can I use one boot EPROM for multiple boards on the same net?
	17. What's the deal with 68881 FPU code in interrupt handlers?
	18. Why does ls() not work on netDrv devices?
	19. Why can't I do ".." at top level directories or NFS mount points?
	20. Why do I have trouble using relative symbolic links with NFS?
	21. X for VxWorks
	22. IEEE-488 (GPIB) driver for VxWorks
	23. How does one disable NFS client caching?
	24. Why doing a lot of slipInit()/slipDelete() cause routing 
		table corruption?
	25. How does one get better network I/O performance?
	26. How does one troubleshoot a backplane driver malfunction?
	27. How do I add select support to my driver?
	28. bind() gets EADDRINUSE, how do I fix it?
	29. Common errors in interrupt handlers with floating point 
		co-proc hardware
	30. Finding entry point of a given module using its name
	31. The problem with irint() in earlier (5.0.2 ?) releases
	32. What are +T, +I thingies in the "i" output?
	33. Gotchas w.r.t watchdogs
	34. Is it possible to delete a memory partition in VxWorks?
	35. rename() does not work in netDrv and nfsDrv filesystems, why?
	36. Free NFS Server for VxWorks
	37. Free SNMP for VxWorks
	38. What third party products are available for VxWorks?
	39. What kind of products have been developed using VxWorks?
	40. A complete list of CPU hardware supported by VxWorks
	41. A complete list of peripheral devices supported by VxWorks
	42. What's with these unbundled "accessories"?
	43. How come my 5.0.2 BSP isn't available in 5.1, damn it?
	44. How much is VxWorks?
	45. What is MicroWorks?
	46. Other Unbundled Products for VxWorks?
	47. How can I find out more about VxWorks?
	48. What other net.resources are available on real-time systems?
	49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?  
	50. Free lex and yacc for use with VxWorks
	51. timer_gettime() bug
	52. bogus INCLUDE_TCP_DEBUG
	53. free ppp for VxWorks
[new]	54. how to disable cache on mc68040 or mc68030 using TT regs?
[new]	55. work-arounds for ms-dos filesystem bug when lseek() past eof
[new]	56. TCL for VxWorks
	9999. Contributions to comp.os.vxworks FAQs.

- -------------------------------------------------------------------------

1. What is VxWorks?

VxWorks, from Wind River Systems, is a networked real-time operating
system designed to be used in a distributed environment.  It runs on a
wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel
i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems. 
It requires a host workstation for program development; supported host
platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS. 

It does not run development systems software such as compiler, linker
and editor on the target machine.  The development environment is based
on cross-development or remote-development method.  You will need a
UNIX machine of some sort (e.g. SUN's) to run the compilers and
debuggers.  The compiled application code can be downloaded to the
target and runs as part of the VxWorks image.  During the development
phase or thereafter, individual object code (.o files) can be
downloaded dynamically to running target system.  Finished applications
can be ROM'ed or whatever.

- ----------------------------

2. Brief History of VxWorks

Based on what I have heard from David Wilner and others, WRS was
started by Jerry Fiddler and David Wilner in Jerry's garage as a
contract/consultant shop for realtime, embedded systems and other fun
things.  Francis Coppola was one of the earlier customers.

They wrote a bunch of neat programs for their work and found that they
liked them a great deal themselves, and added more excellent features
to the system, eventually adding some things unheard of in
embedded/realtime market in those days such TCP/IP networking. And
continued to pioneer in this area by adding NFS, etc.

VxWorks was the name given the collection of software which ran on
top of various realtime kernels including VRTX and pSOS as well an
earlier slower version of WIND kernel.  [ editorial:
VxWorks no longer runs on other kernels; it now runs exclusively on 
its own WIND kernel since the 5.0 release, for which the WIND was 
rewritten by John Fogelin. ]

They got more people interested in the system and became successful.
And moved from a little building in Emeryville to a larger one. And
eventually to the present site in Alameda.  And hired a  lot of people.
 
WRS sold many many more copies of this system and continues to grow
like a real successful company.

- -----------------------------

3. What are some of the major features of VxWorks?

In Version 5.1:

 - wind kernel unlimited tasks
 - 256 priorities
 - binary, counting mutex semaphores
 - message q's
 - POSIX pipes
 - sockets
 - shared memory
 - profiling utilities
 - ethernet support (i596, LANCE, NIC, SONIC)
 - SLIP (no PPP yet)
 - backplane driver for network
 - rlogin (server & client)
 - telnet (server only)
 - rpc (no rpcgen)
 - nfs (client)
 - ftp (server & client)
 - tftp (client & server)
 - rsh
 - bootp
 - proxyarp
 - C-interpreter shell (incomplete but useful)
 - symbolic debugging
 - disassembly
 - performmance monitoring tools
 - exception handling
 - signal handling (not quite unix compatible)
 - dynamic object image loader
 - system symbol table
 - system info utilities
 - libraries of 600+ utility routines
 - remote source level debugger(VxGDB)
 - SCSI support
 - DOS & RT11 & Raw filesystems.
 - "full ANSI"
 - "POSIX I/O"

It is a good idea to get a copy of VxWorks manuals before purchasing
the system.  WRS can provide you with such documentation.  As far as I
know there is no "VxBook" in the bookstores.

- ----------------------------

4. What are the Latest versions of VxWorks?

As as of June 1993,

     5.0.3.: TRON will be discontinued.
     5.0.3 : i386
     5.0.5 : r3000
     5.1   : 680x0, 683xx, i960, SPARC
     i386 and r3000 will be upgraded to 5.1.

- ------------------------------

5. Where is the archive site for user-contributed code?

The VxWorks archive system is available for FTP as thor.atd.ucar.edu.
It is also accessible via email server at vxworks_archive@ncar.ucar.edu.
Questions should be directed to its maintainer, Richard Neitzel
<thor@thor.ucar.edu>.

To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix

A summary of the archives is periodically posted to comp.os.vxworks.

Some of the usual titles available:

ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench
cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress
flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2
lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe
poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod
tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar
vxtool, vxview, xc

- ------------------------------

6. What application notes are available from Wind River?

  List of Wind Technical Notes

 Motorola MV147 Slave Base Control       9-1
 System hang during lkup( ) output       10-1
 Reserving Memory                        11-1
 Serial IO Vanishing                     13-1
 NFS: problems with writing files        14-1
 Which interrupts does VxWorks use?      15-1
 Debugging ftp problems                  18-1
 Interrupt handlers, floating point      19-1
 Booting From a Memory Board             22-1
 Changing Network Interfaces             23-1
 Writing Non-buffered Sockets            24-1
 RPC and VxWorks                         25-1
 Using SCSI devices with VxWorks 5.x     26-1
 The Select Facility in VxWorks          28-1
        Using on-board Serial Ports  29-1
        Problems with ls()   30-1
 SCSI     31-1
 Trouble Shooting Booting Problems       32-1

- -----------------------------

7. How can I join the VxWorks user's group?

For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at:

 elr@netcom.com   or  ericr@wrs.com 
 phone: 408-429-0598

- ------------------------------

8. Is comp.os.vxworks also available via a mailing list?

Lawrence Berkeley Labs maintains an automated mailing list which is
bi-directionally gatewayed to comp.os.vxworks

It is called the 'VxWorks Exploder'.

Mail to vxwexplo@lbl.gov is automatically mailed to a number
of sites, including Wind River.

Send subscription request to vxwexplo-request@lbl.gov.

- ------------------------------

9. Can I use gcc or g++ with VxWorks?

WRS's gcc GNU Toolkit distribution can be reshipped in its entirety. 
WRS charges are for media and support, so obviously copies thereof
don't matter to them.

Lots of customers use g++ as provided by the "net" --
see the VxWorks Archive information below.

You can get a generic freely distributable GCC/G++ and compile your
code for VxWorks.  Or you can just get a copy from someone who has a
working GCC cross-development setup from WRS.

WRS worked with Cygnus to polish up their release of GCC but a generic
GCC distribution works just fine as well.

For MC68K targets:
 You can also use native SunOS 4.X cc running on Sun-3's.
 You can also use various other free m68k C compilers
 such as lcc, sozobon, etc. provided that you're willing
 to hack on them.

Richard Neitzel (thor@thor.atd.ucar.edu) writes,

Thanks to some feedback I've corrected the archive instructions on how to
build gcc, libgcc and libg++ for VxWorks. To make my life simpler the
patches referenced are no longer included in the vx_cplusplus file. Instead
there are now seperate patch files for the effected parts:

libg++-2.5-src.patch: Patches libg++/src.
libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0.
libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2.
libio-2.5.patch: Patch the stream library.

See VxWorks Archive information in this FAQ for details on how to 
get these files.

- ---------------------------------------

10. Other C/C++ Compiler tools for VxWorks?

WRS re-sells (re-engineered?) CenterLine cfront product and WindC++
Gateway for CenterLine ObjectCenter. They come with browsers, etc. 
Not free.

Wind C++ Gateway for ObjectCenter sold by WRS:

$995 / user 1-4 copies
$875 / user 5-9 copies

Note that this is the cost over and above ObjectCenter.

- ------------------------------

11. Which cross-debuggers can I use with VxWorks?

GDB & other more expensive tools from WRS, MicroTec Research, etc.

WRS sells a lightly modified version of xxgdb which has a lousy GUI
interface.  In 5.1 xvxgdb may have been slightly improved -- but the
ObjectCenter C++ with VxWorks solution provides better GUI interface.
      
With a little bit of hacking, regular GDB works just fine.  Personally,
I find GUI to a debugger gets in the way of real work.  I use GNU Emacs
GDB interface which works well and can be easily customized.

There might be some old VxWorks customers that also use VxWorks-aware 
dbxtool on Sun machines.  This used to be maintained and sold by SUN
Consulting.

If you're only interested in debugging your "application" on VxWorks,
the vxgdb approach (using RPC) works just fine.

If you are rather more interested in the guts of the system as well as
your application you might want to spend some time building
cross-debugging tools from generic GDB distribution into VxWorks.

- ------------------------------------ 

12. What are differences between UNIX and VxWorks?

They're both a hack.  UNIX has a larger installed base. :-)

Seriously though, similarities end there, IMHO.  VxWorks does have a lot of
UNIX "compatible" routines in the user libraries.  So porting a UNIX
application is not that hard.  But there are enough differences to make such
a port take longer than normally expected.

For one thing, UNIX definitely is not realtime, whatever that means. 
[ editorial: To me personally, what realtime means is this -- when there
is a spinning process or task running like crazy doing some stuff
busily, I still want my system to respond immediately when I type a
character on my console keyboard.  VxWorks, and other real realtime
OS'es, do this.  UNIX and MS-DOG don't. ]

VxWorks in its original form does not have any memory protection support.
It runs in one mode.  No protected vs. user mode switching is done.  Running
in supervisor mode on most processors, and not using traps for system calls,
VxWorks can achieve minimal overhead on a given piece of hardware than
UNIX.  Programming on VxWorks can be more tricky than UNIX for the same
reason.

UNIX provides resource reclamation; by default, VxWorks does not.  
[ editorial: using deleteHooks or whatever, you could implement
this on your own.]  Instead programmers write what they need as
needed.  As a result, the context switch time in VxWorks is on the
order of a few micro-seconds (since there is a lot smaller context to
save and restore). VxWorks does not have full "process";
it only has tasks, or "threads", or light weight processes as some people
like to call them.

Like any other multi-threaded environments (or SMP environments), care
should be taken when writing multi-tasking code.  Each routine should be
written carefully to be re-entrant (if it is going to be called from
multiple contexts), semaphores are used a lot for this. And static variables
are frowned upon.  Sometimes, when porting a UNIX application, you may need
to add "task variables" for this reason (as done for rpcLib in VxWorks).

VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented as
semaphores).  UNIX: ridiculous interrupt latency (e.g. spl's are implemented
as interrupt lock and unlock calls!).

VxWorks: priority preemption, optional round-robin time-slicing.  
Traditional UNIX: prioritized round-robin time-slicing.  
Since VxWorks is just a glorified "program" it can be 
changed and customized pretty easily.  Task scheduling can
be customized as desired, for example.  Most people prefer priority based
preemption in the realtime world.  UNIX prefers "fair-share time-slicing".

VxWorks networking code, however, is very UNIX compatible [editorial:
it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe
release ].  It is relatively easy to port socket based code to 
VxWorks.  [ editorial: except the not-so-compatible hostLib routines, etc.]

VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as
often misunderstood by some people.  The confusion perhaps is due to the
fact that UNIX hosts are used most widely to develop applications for 
VxWorks (and VxWorks itself).  [ editorial: Realtime UNIX sounds kind of like
Military Intelligence to me. (can you say, oxymoron?) ;-) ]

There are a lot more differences!  In short, UNIX is a nice system to run
emacs on.  VxWorks is much better at playing pin-ball game machines.

- ----------------------------

13. What are the performance/benchmark numbers for WIND kernel?

A WRS VxWorks 5.1 Benchmark Report hot off the press:

Benchmark numbers based on: mv167-25Mhz, 5.1

						        Cache	Cache 
Key Measurements        				Enabled	Disabled

Raw Context Switch Time 				4 us    14 us
Cyclic Test Time        				172 us  638 us
Suspend/Switch/Resume/Switch    			23 us   86 us

Kernel Timings

Task Related
taskSpawn       					124 us  370 us
taskInit        					58 us   181 us
taskActivate    					12 us   33 us
taskDelete      					101 us  303 us
Task Create / Delete    				249 us  684 us
taskLock
        CASE 1: no lock 				3 us    4 us
        CASE 2: lock exists     			2 us    5 us
taskUnlock
        CASE 1: no lock 				2 us    12 us
        CASE 2: lock exists     			5 us    6 us
taskSuspend
        CASE 1: ready task      			11 us   30 us
        CASE 2: pended task     			9 us    19 us
        CASE 3: suspended task  			8 us    19 us
        CASE 4: delayed task    			9 us    19 us
taskResume
        CASE 1: ready task      			6 us    19 us
        CASE 2: pended task     			10 us   19 us
        CASE 3: suspended task  			13 us   30 us
        CASE 4: delayed task    			9 us    18 us

Semaphore Related
semBCreate      					66 us   152 us
semCCreate      					46 us   150 us
semMCreate      					45 us   139 us
semDelete
        Binary  					49 us   157 us
        Counting        				49 us   163 us
        Mutual Exclusion        			48 us   157 us
semGive
        CASE 1: tasks in queue  
        Binary  					18 us   44 us
        Counting        				20 us   46 us
        Mutual Exclusion        			25 us   59 us
        CASE 2: no tasks in queue       
        Binary  					4 us    8 us
        Counting        				5 us    11 us
        Mutual Exclusion        			6 us    15 us

semTake
CASE 1: semaphore available     
        Binary  					4 us    9 us
        Counting        				5 us    11 us
        Mutual Exclusion        			5 us    13 us
        CASE 2: semaphore unavailable   
        Binary  					10 us   25 us
        Counting        				11 us   27 us
        Mutual Exclusion        			4 us    12 us
Semaphore Give / Take
        Binary  					7 us    15 us
        Counting        				9 us    21 us
        Mutual Exclusion        			10 us   26 us
semFlush
        Binary  					11 us   20 us
        Counting        				11 us   20 us
        Mutual Exclusion        			10 us   16 us

Miscellaneous Operating System Timings

Message Queue Related
msgQCreate      					93 us   280 us
msgQDelete      					71 us   229 us
msgQSend
        CASE 1: task pending    			39 us   102 us
        CASE 2: no tasks pending        		23 us   64 us
        CASE 3: queue full      			14 us   45 us
msgQReceive
        CASE 1: message available       		20 us   62 us
        CASE 2: message unavailable     		15 us   41 us

Memory Related
malloc  						28 us   81 us
free            					32 us   104 us

Watchdog Related
wdCreate        					42 us   106 us
wdDelete
        CASE 1: timer started   			48 us   160 us
        CASE 2: timer not started       		44 us   150 us
wdStart
        CASE 1: timer in queue  			20 us   70 us
        CASE 2: no timer in queue       		18 us   55 us
wdCancel					        11 us   34 us

Floating-Point  
robot application       				18 sec  51 sec

[ editorial:
If you're anal enough to count pico-seconds in comparing realtime
kernels, you  might want to actually get each of the evaluation copies
from various vendors and test them yourself.  But remember benchmarks
are misleading and almost always biased and inaccurate.  Given similar
benchmark numbers, give or take a few microseconds, etc., your dollars
are better spent in getting something you'll enjoy using. ]

- -----------------------------

14. What are the performance/benchmark numbers for VxWorks TCP/IP?

According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet)

				 w/ cache 	 w/o cache enabled
 TCP/IP Throughput (KB/sec)      859 KB/sec      682 KB/sec

No numbers available on latency.

Using a reasonably fast processor 25Mhz MC68040 and a reasonably well
made ethernet chip like SONIC or LANCE put together on a reasonable board
design will achieve TCP throughput close to full bandwidth of ethernet.

[ editorial:
This, of course, is rather slow in comparison with other fast
implementations, since a 16Mhz MC68020 with onboard LANCE 
or a PeeCee with an ethernet board can easily do the same.
I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC
that does: 1170KB/sec.  ]

- ---------------------------------

15. What is the VxSim VxWorks Simulator?

Propaganda from WRS:

 It really is VxWorks running under UNIX!  So sure it
 is not realtime, although all tasks and resources interact
 in the same way -- great for prototyping "high-level" code.
 Using the simulator saves wear and tear on h/w.  It (only)
 allows sytem level debugging with native GDB.

 Portably written object code compiled for VxSim (for SunOS SPARC)
 will usually load without recompilation on a SPARC target.  And,
 BTW under 5.1 switching from one architecture to anthoer really is
 pretty painless.

- ------------------------------

16. Can I use one boot EPROM for multiple boards on the same net?

WRS provides EPROMs with a default bogus bootline, virtually all
boards come with non-valiatile RAM which is set as soon as the user
fills in his parameters (which include CPU #).  Therefore 1 EPROM may
be duplicated and used in all boards at a site.  If the board does not
contain nvram then ROMs have to be specially blown, unless a custom
scheme for reading some switches or something is coded to index into a
bootline table.  In 5.1 BOOTP is supported -- no more repeated EPROM
burning is necessary.

- ------------------------------

17. What's the deal with 68881 FPU code in interrupt handlers?

In general, FP context is optimally saved only when the scheduler
notices that the new task coming in also uses the fpu (VX_FP_TASK).
ISRs don't.  If no tasks are using the FPU then ISRs may go ahead,
unless different levels of ISRs could interrupt each other and again
cause a protocol violation.

And Stan Schneider says,

You have to set the "VX_FP_TASK" option flag when you spawn your task.  You
also need to make sure you don't use the FPU in any interrupt service
routines.  Even if your code uses no floating point, some (brain-dead)
compilers save some FPU registers at the start of all routines if there's any
floating point in the file.  That's not usually a problem if you're using the
gcc compiler (at least with the "-O" flag on).  A sure way to check is via the
dissassembler.

And Leonid Rosenboim says,

This problem is quite common, and really simple to fix, all you have to
do is make sure that all tasks that do a float operation ever, will
be spawned with the VX_FP task option set. This is the best and only
solution. Also, if you run floating operations in ISRs care must be taken,
to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040,
there is a bug in the compiler that you must work around.

And Kent Long says,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a 
mid-instruction context (which causes the protocol violation), and the 
old swapped-out FP task ultimately ended up with its context set to IDLE 
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.

- ------------------------------

18. Why does ls() not work on netDrv devices?

Because the way directory information retrieval IOCTL calls are not acompatible
between different types of "filesystems" in VxWorks.  Another reason why
some think VxWorks filesytem does not exist; they're just a collection of
ioDevice drivers, and there is not a real consistent "design" to it.

The lsOld() should work on "filesystems" that does not support ls().

Chuck Mead proposes the following special routine in case lsOld() does not
work for you:

#include "vxWorks.h"
#include "bootLib.h"

#define RSHD 514

STATUS lsHost(path)
   char  *path ;
{
   char *lsString;
   int dataSock ;
   int n ;
   char nextChar ;

   extern BOOT_PARAMS sysBootParams ;
   extern char *sysBootHost ;

   if (path == (char *) NULL)
   {
      lsString = (char *) malloc(4) ;
      strcpy(lsString, "ls") ;
   }
   else
   {
      lsString = (char *) malloc(strlen(path) + 5) ;
      sprintf(lsString, "%s%s", "ls ", path) ;
   }

   dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr,
        sysBootParams.usr, lsString, (int *) NULL) ;

   if (dataSock == ERROR)
   {
      printf("Error opening socket") ;
      return (ERROR) ;
   }

   n = fioRead(dataSock, &nextChar, 1) ;
   while (n == 1)
   {
      printf("%c",nextChar) ;
      n = fioRead(dataSock, &nextChar, 1) ;
   }

   close(dataSock) ;
}

- ------------------------------

19.  Why can't I do ".." at top level directories or NFS mount points?

Because, again, VxWorks does not really have a "filesystem" as most people
understand it.  The top level directories are just implemented as device
driver "node", which is used to identify the ioDev associated with the
specific VxWorks "filesystem".  Since there is no underlying filesystem
layer, the story ends there.  When you're at the top of the directory
hierarchy within a given ioDev/filesytem, you simply cannot do "..".

- ------------------------------

20. Why do I have trouble using relative symbolic links with NFS?

See [Q: Why can't I do ".." at top level directories or NFS mount points?]
above.  This is just another problem caused by the fact that a real filesystem
does not exist for VxWorks.  NFS client implementation actually does implement
the symbolic links correctly, using lookup and readlink.  The problem is
due to the fact that, for some relative links that use ".." or whatever, that
crosses over filesystems, VxWorks cannot have underlying subsystem that will
handle file pathname to device mapping.  

Using absolute symbolic links work just fine (i.e. full path name from top).

- ------------------------------

21. X for VxWorks

WRS has a product called windX which supports Motif. There is also
libX11 contribution in the VxWorks Archive. This package is perhaps
fairly old and out of date. Essentially, to port X stuff to VxWorks
you'll need to do make sure code is re-entrant everywhere.  There is a
"multi-thread" safe version of Xlib available somewhere on the net, one
might try porting that.  There are also vendors that have built X servers
using VxWorks.  Jupiter Systems, in Alameda, makes high-end X server
machines based on VxWorks.  Other X terminal vendors (HP?) also use VxWorks.

- -----------------------------

22. IEEE-488 (GPIB) driver for VxWorks

 - National Instruments has lots of GPIB stuff
 - THEMIS computers has TSVME-409 whic hincludes a GPIB interface.
 - APLABS probably has some GPIB stuff too.

- -----------------------------

23. How does one disable NFS client caching?

VxWorks caches read and write requests in NFS client code.
To completely disable read and write cache, set nfsCacheSize to 0.
To just flush the write cache as needed, use nfsCacheFlush() or
FIOSYNC ioctl().

- ------------------------------

24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption?

This is due to a bug in slipDelete() and/or if_dettach().  slipDelete()
calls if_dettach() to clean up after itself (SLIP network interface driver).
Not only is if_dettach() misspelled, it also doesn't do a complete job.
One deficiency is that it does not delete routes that are pointing to the
interface being deleted.  This is remedied via another function that deletes
all routes for a give netif device driver.  [ ifRouteDelete() ??? ]
slipDelete() does call this routine to delete routes.  Another problem is
that if_dettach() does not delete a pointer to the netif device driver 
structure in the global in_ifaddr linked list.  The in_ifaddr list is
used by the network kernel code to find IP addresses of available network
interfaces, among other things.  This lack of proper cleanup turns out to 
be a rather hard-to-find memory corruption problem in network code, and
usually manifests itself as routing table corruptions.

To fix this add the following routine, and call it right after calling
slipDelete:

void in_ifaddr_remove(ifp)
        struct ifnet *ifp;  /* ifp = ifunit("sl0") before slipDelete() called */
{
        struct in_ifaddr *ia, *prev_ia;
 
        if (!ifp) 
                return;
 
        prev_ia = 0;
 
        for (ia = in_ifaddr; ia; ia = ia->ia_next) {
                if (ia->ia_ifp == ifp) {
                        if (prev_ia)
                                prev_ia->ia_next = ia->ia_next;
                        else
                                in_ifaddr = ia->ia_next;
                        return;
                }
                prev_ia = ia;
        }
}

This, along with the route cleanup, should be incorporated into if_detach().

- ------------------------------

25. How does one get better network I/O performance?

Most of the overhead is due to socket to network core interface overhead.
The copy that happens between the socket layer and network core code
can be avoided by using the routines in uipc_socket.c (as in BSD tahoe
release code available on various archive sites) and using mbufs directly.

You can also try using raw etherLib routines.  However, etherLib also
does copying between user application and network driver.

If you must use the socket interface (sockLib), make sure you tune the
socket level buffers sizes to optimal values using setsockopt() calls
SO_SNDBUF and SO_RCVBUF.  You might also just try changing the globals
that control the following default parameters to larger numbers (all
the way upto 48K):

 tcp_sendspace (default 4K)
 tcp_recvspace (default 4K)
 udp_sendspace (default 2K)
 udp_recvspace (default 4K)

To get around extra latency in some cases, you might turn on TCP_NODELAY
option on TCP sockets.

- ------------------------------

26. How does one troubleshoot a backplane driver malfunction?

There are a few rules of thumb:

 1) try the simplest case first -- use polling instead of
	bus or mailbox interrupts and software test-and-set
	instead of hardware test-and-set.  See if this
	works first.  And then try hardware test-and-set
	and then the desired mailbox or bus interrupt.

 2) use bpShow() to see what's up.  Also look for magic code
	0x1234 in share mem area being used for messages,
	and verify heartbeat is being incremented.
	At the "anchor" you should see the magic code (4 bytes)
	followed by a long word which should be incrementing (the
	heartbeat) every second.

 3) verify all memory mapping and make sure there's no
	address conflicts on the bus

 4) make sure bus controller is functioning properly.
	Some combinations of boards might not work well
	especially if your system controller board
	arbitrates the bus in one way and other boards
	expect to be arbitrated in a different way.
	Sometimes you might need to use a separate
	system controller.  Of course, also make sure
	you only have one bus master.  And that your VME
	bus strappings (BREQ, IACK daisychains) are right.

 5) call Wind River's VxWorks tech-support... 

- ------------------------------

27. How do I add select support to my driver?

#include "selectLib.h"
...

xxx_init(...)
{
	 ...
	 selWakeupListInit(&xxxdev->selwakeupList);
	 ...
}

xxx_ioctl(...)
{
	 ...
	 switch(request_type) {
	 ...
	 case FIOSELECT:
		  selNodeAdd(&xxxdev->selwakeupList,
			   (SEL_WAKEUP_NODE *)request_arg);
		  if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD)
			   && readable_condition_is_met)
			   selWakeup((SEL_WAKEUP_NODE*)request_arg);
		  if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE)
			   && writable_condition_is_met)
			   selWakeup((SEL_WAKEUP_NODE*)request_arg);
		  break;
	 ...
	 case FIOUNSELECT:
		  selNodeDelete(&xxxdev->selWakeupList,
			   (SEL_WAKEUP_NODE*)request_arg);
		  break;
	 ...
	 }
}

And, add calls to selWakeup() as appropriate in your interrupt handlers
and read/write routines as selective conditions are toggled or satisfied.

- ------------------------------

28. bind() gets EADDRINUSE, how do I fix it?

Fix: do setsockopt() SO_REUSEADDR

- ------------------------------

29. Common errors in interrupt handlers with floating point co-proc hardware

Don't forget to use:
 fppSave()
 fppRestore()

Interrupt handler encapsulation code doesn't always save fpp registers for you.

- ------------------------------

30. Finding entry point of a given module using its name

Example from a poster in vxworks newsgroup (who?):

 FUNCPTR  start;  /* found entry point goes here */
 UINT8    symType;
 int      tid;

 if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){
	/* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */

	tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start,
	arg1,arg2,.....);
 }

- ------------------------------

31. The problem with irint() in earlier (5.0.2 ?) releases

The problem:

 /* Include Files */
 #include "vxWorks.h"
 #include "math.h"

 long irint_count = 0;

 sinTest()
 {
	  int sinTable;
 
	  while(1)
	  {
		   sinTable = irint(sin(4./1024.*(2.*3.14))*10.);
		   irint_count++;
	  }
 }

 % cc68k -I/vxworks/vw/h -c sinTest.c

 -> ld < sinTest.o

 /* 0x08 Option = VX_FP_TASK within taskLib.h */
 -> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest)
 /* OR without the Floating Point Option */
 -> sp sinTest

 -> irint_count

 Bus Error
 Program Counter: 0xb0ac0124
 Status Register: 0x3004
 Access Address : 0xb0ac0120
 Special Status : 0x01e6
 Task: 0xfcb82c "sinTest"

The answer:

Submitted-by wrs!yuba!kent@uunet.uu.net  Fri Sep 27 18:55:25 1991
Submitted-by: wrs!yuba!kent@uunet.uu.net (Kent Long)

 > In the function irint, there is a bug that sets the floating point
 > Exception enable byte register to random values.  Here is the
 > disasembled code:
 >
 >                         _irint:
 > 00e034  4e56 0000                LINK  .W    A6,#0
 > 00e038  f227 6b80                FMOVE .X    F7,-(A7)
 > 00e03c  f22e 5780 0008           FMOVE .D    ($8,A6),F7
 > 00e042  f22e 6380 0008           FMOVE .L    F7,($8,A6)
 > 00e048  202e 0008                MOVE  .L    ($8,A6),D0
 >
 > 00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

<insert audible groan here>

 > 00e050  504f                     ADDQ  .W    #8,A7
 > 00e052  4e5e                     UNLK        A6
 > 00e054  4e75                     RTS
 >
 >    Line 0e04c is the line that sets the FPCR to some random value,
 > as D1 is unknown going into the function.  I rewrote the routine,
 > without line 0e4c, and everything works fine.
 >    If anyone out there knows why this line was put in, I would
 > appreciate knowing.  Hope this may keep someone else from spending
 > a couple of days tracking down this problem.
 
I have confirmed that this is a bug in all 5.x versions of VxWorks for
the 68k.  (In fact, it's in 4.0.2 as well.)  As Mark correctly observed,
the problem is that the FPCR register is erroneously being set.
 
This was a simple cut-and-paste error in the VxWorks source module.
The line which sets the FPCR should instead be restoring the value
of FP7, which was saved on the stack earlier (as you can see in the
code above).  So, it would appear that another side effect of this
bug is to clobber FP7.
  
The fix is pretty simple.  The following patch scripts should get things
back to what they should be.  (You can just include the appropriate lines
in your startup script, or enter them from the VxWorks shell.)
 
For VxWorks 5.0.1 and 5.0.2:
 
        pMathPatch = mathHardIrint + 0x18;
        *pMathPatch = (short) 0xf21f;
        pMathPatch = mathHardIrint + 0x1a;
        *pMathPatch = (short) 0x4b80;
 
This bug does NOT affect VxWorks 5.1.  The disassembled code for Vx5.1,
(HK68K/V3D) is:
                        _mathHardIrint:
2042e58  4e56 0000                LINK  .W    A6,#0
2042e5c  f227 6800                FMOVE .X    F0,-(A7)
2042e60  f22e 5400 0008           FMOVE .D    (0x8,A6),F0
2042e66  f22e 6000 0008           FMOVE .L    F0,(0x8,A6)
2042e6c  202e 0008                MOVE  .L    (0x8,A6),D0
2042e70  f21f 4800                FMOVE .X    (A7)+,F0
2042e74  4e5e                     UNLK        A6
2042e76  4e75                     RTS

Kent Long further clarifies,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a 
mid-instruction context (which causes the protocol violation), and the 
old swapped-out FP task ultimately ended up with its context set to IDLE 
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.

- ------------------------------

32. What are +T, +I thingies in the "i" output?

The following is an excellent description of all these symbols by many people
on the net, including "Fred J. Roeber" and others:

Description                                 Status symbol
=====================================       ===============
<blah> and task's priority inherited         <blah> + I                    
Delayed and suspended                        DELAY+S
Pended and suspended                         PEND+S
Pended and Delayed                           PEND+T
Pended, delayed and suspended                PEND+S+T

The DELAY state indicates that the task has done some sort of delayed
call while PEND means the task has done something that caused it to
block like trying to semTake a semaphore someone else was holding.
PEND+T means that the task is both delaying and pending; it has done a
semTake with a timeout. +I means that the task has (temporarily)
inherited a higher priority through the use of a mutex semaphore.

The priority inheritance protocol also accounts for the ownership of
more than one mutual exclusion semaphore at a given time.  A task in
such a situation will execute at the priority of the highest priority
task blocked on any of the owned resources.  The task will return to
its normal, or standard, priority only after relinquishing all of the
mutual exclusion semaphores with the inversion safety option enabled.

If you use nested mutex semaphores with priority inheritance turned on then
when a task inherits a high priority due to some inner semaphore it owns,
it doesn't lose that priority until it relinquishes all the semaphores it
holds.  This doesn't quite follow the rules for priority inheritance (to
the extent that there really are any rules) in that normally, a task's
inherited priority should decrease as it releases each nested semaphore to
whatever the priority ceiling is for the semaphores it still holds.  Getting
this incremental priority reduction to work right in practice, though,
is extremely difficult (some of the SUN papers on the Solaris real time
scheduling indicate that this was one of the hardest things for SUN to
get right in their OS upgrades).  Given that VxWorks is a real time embedded
OS, I, for one, don't care if WRS uses the current implementation even
though it isn't "pure" because the result is a more reliable implementation
that runs more deterministically.  Anyway, my guess is that you will find
that you have some nested semaphore code where you are doing something
after releasing one of the nested semaphores that shouldn't be done at a
high priority.  

- ------------------------------

33. Gotchas w.r.t watchdogs

watchdog handlers run at interrupt level.  You should not use
routines that can block in interrupt level code.  Frequent mistakes:
using printf() in watchdog routines -- use logMsg() instead.

- ------------------------------

34. Is it possible to delete a memory partition in VxWorks?

No.  memPartDestroy() is not really implemented.  Perhaps it will
be in the future.  Currently it just returns ERROR.  

- ------------------------------

35. rename() does not work in netDrv and nfsDrv filesystems, why?

Because rename() is not implemented for netDrv (although it could be),
and nfsDrv does not implement rename() completely either.

Talk to WRS to get these fixed.

- ------------------------------

36. Free NFS Server for VxWorks

A free, incomplete, sample implementation (i.e. hack) of NFS Server
for VxWorks is available in:

 netcom.com:pub/hjb/nfsd

There is a README file there that describes further details.  The current
snapshot of this implementation is a result of a couple of days of 
hacking, doesn't do everything right, and intended for educational and
further hacking purpose.

There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?)
to VxWorks.  Not clear on its availability yet (let me know!)

- ------------------------------

37. Free SNMP for VxWorks

hoff@bnlux1.bnl.gov (Lawrence T. Hoff) reports,

We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has
prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov --
130.199.96.82).

SNMP Research sells VxWorks compatible port of their SNMP implementation
with support.  Their's cost $$$$$, though.

- ------------------------------

38. What third party products are available for VxWorks?

I tried to include the third party products, list of consultants,
services, goodies, etc. available for VxWorks from various sources but...
there are too many to list here.  Instead,

the file:

 netcom.com:pub/hjb/vxworkers

is updated in realtime to contain a list of individuals and companies
that offer help, services (paid or unpaid), and goods for VxWorks.

To get a copy (if you don't have ftp access) or to be listed in this file, 
please contact or send info in ASCII to:

 hjb@netcom.com.

- ------------------------------

39. What kind of products have been developed using VxWorks?

 - flight simulators
 - radio and optical telescopes
 - automative ABS & realtime suspension
 - naviation systems
 - deep sea instrumentation
 - PBXs
 - traffic lights
 - modems
 - sonar systems

 [ editorial: And, regrettably, in: ]

 - military stuff

- ---------------------------------

40. A complete list of CPU hardware supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:pub/hjb/vxbsp

VxWorks runs on a lot of different hardware.  Majority of hardware
supported is based on VME bus.  Porting VxWorks to a new VME board
based on MC68K takes only a few days, give or take a week, depending
on your karmic condition at the time.  A lot of the ports are
initially done by the customers and later "approved" by WRS, for
which they charge, in order to keep them on "supported" list.

Porting to a new "architecture" (new processor) takes longer.
This varies more widely -- from a few months to a few years.

- ---------------------------------

41. A complete list of peripheral devices supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:pub/hjb/vxbsp

VxWorks supports a wide variety of devices.  A lot of device drivers 
are written both by customers and WRS staff.  There are device drivers
for almost popular available ethernet chips (except perhaps SEEQ and
Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async
COMM chip, etc.), little I/O thingies in micro-controllers (MC68302
serial I/O, etc.), SCSI, etc.

Customers of VxWorks, hackers and other hardware vendors (especially
VME) usually have a VxWorks driver for their board.  There are drivers
for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers,
frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch
toy games.

A list of available device driver for VxWorks can be found in:

 netcom.com:pub/hjb/vxdrivers

Some evil VxWorkers have drivers for military/weapons systems.

- ----------------------------------

42. What's with these unbundled "accessories"?

Propaganda from WRS:

 The new product/feature doesn't need to wait for the
 next OS release.  Only the users who want/need it pay for it 
 lengthens price list which keeps individual items lower
 but still enhances WRS revenue growth.

 Please Note:
 WRS still always adds features to the core product, and
 has never taken items out of core product to make them
 unbundled.  Unlike UNIX vendors and others.

- -----------------------------------------

43. How come my 5.0.2 BSP isn't available in 5.1, damn it?

Propaganda from WRS:

 WRS tries to give customers 1 year warning when any product
 may be discontinued.  Unfortunately, all the bugs in
 the notification system are still to be worked out.
 Complain vehemently to your sales rep. if he didn't
 keep you informed.  WRS BSP obsoletion policy is primarily
 based on BSP volume and h/w avalability.

The 5.1 Guide and Release Notes provide a step by step recipe to
upgrade from 5.0.2 -- minimal changes,  start by ANISifying.  The BSP
Port Kit 1.1 provides extensive  info for the masochist.

- ----------------------------------------

44. How much is VxWorks?

 In general: Not free, in fact, quite the opposite.

 - Development License $23.5K (per project?)
 - Source $120K.
 - Target Licenses from $1000 for single quantity to $10 for 100,000+.

- ------------------------------

45. What is MicroWorks?

VxWorks is also available as a kernel-only product (MicroWorks 1.0) for
 the following processors:

 i960, 680x0, 683xx

MicroWorks is -- half the product at a half the price.

It has no network, native debug, shell, or profiling.  Comes with
VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0
also included -- this is the debug agent which allows true system
level debugging in ISR or wherever.  In future, VxWorks may also be
able to work with VxMon.

Development License $12,500.

- ------------------------------------

46. Other Unbundled Products for VxWorks?

Other unbundled "accessory" products are: VxMP ($4K) which is an
extended shared memory capabilities for the kernel allowing semaphores
and other objects to be manipulated over the backplane transparently
(really!).

VxVMI ($3K) is a library of virtual memory interface routines allowing
text & kernel data protection.  complementary products: BSP Port Kit
1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++
Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K).

- ----------------------------- 

47. How can I find out more about VxWorks?

 Read: comp.os.vxworks
 Email: inquiries@wrs.com
 Call: 1-800-KIK-WIND

- ------------------------------

48. What other net.resources are available on real-time systems?

There is at least one other newsgroup devoted exclusively to a particular
vendor's real-time operating system:

comp.os.os9  Discussions about the OS/9 operating system.

Here are some other related newsgroups:

comp.arch		Computer architecture.
comp.arch.bus.vmebus	Hardware and software for VMEbus Systems.
comp.os.misc		General OS-oriented discussion not carried elsewhere.
comp.realtime		Issues related to real-time computing.
comp.os.os9		Issues related to OS9 and OS9000 realtime OS.

There are too many other newsgroups devoted to computer operating systems
to list here.  The interested reader is advised to check the "newsgroups"
file on a local news service machine.

The automatic server for users of pSOS RTOS is now in place.

PSOSUSER - A list intended for the discussion of topics relating to
           pSOSystem and other products of Integrated Systems Inc.,
           Software Components Group.

Send articles to psosuser@isi.com and administrative requests to
listserver@isi.com.

If you aren't already subscribed and would like to, please send a mail
message to listserv@isi.com containing the following in the body of
the message

SUBSCRIBE PSOSUSER <substitute your full name here>

- ------------------------------

49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?  

Use ioctl() instead.

...
{
	...
	int on = 1;	/* turn it on */
	...
	ioctl(fd, FIONBIO, &on);
	...
}

- ------------------------------

50. Free lex and yacc for use with VxWorks

John Winas (winas@phebos.aps.anl.gov) writes,

I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where
the vxWorks archive is.  When ever the maintainer moves it into the release
area they will be available to everyone.  I named the file lexyacc.tar.Z
and it contains all of the sources and make files for you to build them.
It all seems to work perfectly on my sun sparc running 4.1.3.  The
only thing you have to configure is the full path name to where you wish
to keep flex so that it can find its skeleton file when you use it to
lexify your .l files.  Byacc has no skeleton files and simply needs to 
be in your path.

I am interested in any bugs found in because we are using them here.  Feel
free to email me at winans@phebos.aps.anl.gov.

- ------------------------------

51. timer_gettime() bug

From: kent@wrs.com (Kent Long)

In article <9311230139.AA21147@focal.com> bobk@focal.com (Bob Klawuhn) writes:
>I am currently trying to user the timerLib to obtain
>the amount of time that a timer has left before it
>expires. I am trying to use the timer_gettime function. 
>The value that it seems to return is always the time
>that the start timer was given, not what is left on the
>timer.

This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions.
It is now being tracked as WRS SPR #2673.

As a workaround, the following could be done following the
timer_gettime() call, to convert the erroneous results into
the desired remainder value:

     #include "private/timerLibP.h"
     struct timespec timeNow;

     (void) clock_gettime (CLOCK_REALTIME, &timeNow);
     TV_SUB (timerid->exp.it_value, timeNow);

...which leaves the remainder in it_value.

- ------------------------------

52. bogus INCLUDE_TCP_DEBUG

From: hipp@wrs.com (Emily Hipp)

>Bus Error
>Program Counter: 0x0001c738
>Status Register: 0x3000 
>Access Address : 0xbfbfbfd3
>Special Status : 0x0505
>Task: 0x3dcc54 "tExcTask"
>TCP tracing not enabled (use INCLUDE_TCP_DEBUG).  

This is misleading information.  INCLUDE_TCP_DEBUG is not supported
as a configAll.h include option.

[ editorial: 
  INCLUDE_TCP_DEBUG never got integrated into VxWorks config files.
  To get around this bug, until WRS fixes it, either unset SO_DEBUG 
  socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?)
  which will drag in tcp_debug.o and set the tcp_trace() routine to
  be called when debug option is set on TCP sockets.
]

- ------------------------------

53. free ppp for VxWorks

Is available via anonymous ftp 

	netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz

- ------------------------------

54. how to disable cache on mc68040 or mc68030 using TT regs?

[ From: Steve Morris <morriss@smtplink.indigo.co.il> ]

        /**************************/
        /* for 68030 (e.g. mv147) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_tt ()
        {
            register int *pVal;
            int ttVal;
            
            pVal = &ttVal;
            
            ttVal = TT0_VALUE;
            asm ("pmove %0,tt0" : : "g" (*pVal));
            ttVal = TT1_VALUE;
            asm ("pmove %0,tt1" : : "g" (*pVal));
        }
        
        /**************************/
        /* for 68040 (e.g. mv167) */
        /**************************/
        
        /* 2 large areas, R/W, cache disabled */
        #define TT0_VALUE   0x403f8507  /* from $40000000 -> $77ffffff */
        #define TT1_VALUE   0x03018507  /* from $02000000 -> $03ffffff */
        
        test_dtt ()
        {
            asm ("movec %0,dtt0" : : "r" (DTT0_VALUE));
            asm ("movec %0,dtt1" : : "r" (DTT1_VALUE));
        }

- ------------------------------

55. work-arounds for ms-dos filesystem bug when lseek() past eof

[From: georg@sgl.ists.ca (Georg Feil)] 

[editorial: This is a workaround for the bug in VxWorks ms-dos
implementation which produces incorrect error return on write() after
lseek() beyond eof.  N.B.: VxWorks versions upto 5.1.1 have buggy IO
system layer that does not support "correct" write() to normal files.
When writing to a file via write() expect to check the return value
even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks
write() upto version 5.1.1 will return number of bytes actually written
even when write() was not completely successful on devices that are
not marked non-blocking and/or are subject to flow control. ]

There's been enough heated debate on this so I'm sending out my brute force
workaround. Thanks to Kent Long who managed to let slip enough information
on the bug to identify the prerequisite: lseek() past the end of file.

My workaround simply extends a file by writing 0's on the end whenever there
is a seek past the end. (This may result in a file being extended when it
shouldn't have been, i.e. no write follows the seek, but what the hell.)
Use file_seek() below instead of lseek() to seek. Note that file_seek() is
not meant to be plug-replaceable with lseek(), that feature is not
required in our system. 'zero8k' is a character array of 8192 zero bytes.

int file_seek(int fd, int offset)
/*
 * Sets the byte offset for the next write or read from a file.
 * Simple interface to lseek() function. This returns ERR_NONE iff the actual
 * actual seek offset returned by lseek() exactly matches the desired offset.
 * 'fd' is the file descriptor to seek on.
 * 'offset' is the absolute file position to seek to in bytes, where 0 is
 *          the beginning of file.
 * Return value is error code (not a VxWorks error code, another type).
 */
{
   STATUS st;
   struct stat filestat;        /* file status info obtained from fstat() */
   int aoff;        /* actual seek offset returned by lseek() */
   long int fillsz;    /* (***) for SPR #2739 kludge */
   long int fillamt;   /* (***) for SPR #2739 kludge */

   if (FileDebug && Verbose>=2)  {
      wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n",
                                                                  offset,fd);
   }

   /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with
        transfer count too low but errno not set after seeking past current
        end of file). Note that this may extend the file prematurely, i.e.
        even if no write() calls follow the seek. */
   /* get current file size */
   st=fstat(fd, &filestat);
   if (st==VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n",
                                                           fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* manually extend file using zero writes if seek offset past end of file
        (note: tried ioctl() with FIOTRUNC, but this only works to shorten
        files! */
   if (offset>filestat.st_size)  {
      /* seek to the end of the file first */
      errno=0;
      aoff=lseek(fd, filestat.st_size, SEEK_SET);
      if (aoff != filestat.st_size)  {
         /* returned value should always match 'filestat.st_size' */
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n",
                                     fd, aoff, filestat.st_size, vw_errmsg(0));
         }
         return(ERR_VXIO);
      }

      /* fill file with zeroes to bring length up to 'offset' */
      fillsz=offset-filestat.st_size;
      while (fillsz>0)  {
         if (fillsz>8192)
            fillamt=8192;
         else 
            fillamt=fillsz;

         errno=0;
         aoff=write(fd, zero8k, fillamt);
         if (aoff == VX_ERROR)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         if (aoff != fillamt)  {
            if (Verbose>0)  {
               wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n",
                       fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0));
            }
            return(ERR_VXIO);
         }

         fillsz -= fillamt;
      }

      /* flush the output to disk immediately */
      st=ioctl(fd, FIOFLUSH, 0);
      if (st!=VX_OK)  {
         if (Verbose>0)  {
            wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n",
                                       fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0));
         }
         return(ERR_VXIO);
      }
   }

   /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */

   errno=0;
   aoff=lseek(fd, offset, SEEK_SET);
   if (aoff == VX_ERROR)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n",
                                                     offset, fd, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   /* returned value should always match 'offset' */
   if (aoff != offset)  {
      if (Verbose>0)  {
         wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n",
                                             fd, aoff, offset, vw_errmsg(0));
      }
      return(ERR_VXIO);
   }

   return(ERR_NONE);
}

- ------------------------------

56. TCL for VxWorks

[From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)]

Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is
on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz

If you've ever been frustrated that the VxWorks shell is not re-entrant, 
and has no control flow (e.g. if then else, switch, case ),
then you will find TCL very useful since it is a very complete language,
that allows you to add your own application specific commands to
the interpreter.

I find it invaluable for system testing, since I register TCL commands for
all major functionality of my real-time application.  This allows me
to test most pieces of my data acquisition system from a command line,
and build nice flexible scripts to test and operate my system.  As a
matter of fact, I can even invoke specific methods of C++ classes via
TCL.

Also, you can control your real-time system from a Unix workstation by
sending TCL commands from either a TCL or Tk/TCL application (via
tclTCP).  I find that sending TCL commands (which are just strings) is
much easier and more flexible than writing a Remote Procedure Call
(RPC) for each piece of functionality that I need to remotely invoke.

- ------------------------------

9999: Contributions to comp.os.vxworks FAQs.

The following net.folks, among others, have contributed to this posting:

 Name			email address
 ------------		----------------------------	
 Mark Linimon 		linimon@nominil.lonestar.org
 Geoff Espin		geoff@wrs.com
 Rev. Bob Crispen	crispen@foxy.boeing.com
 Stan Schneider		stan@rti.com
 Fred J Roeber		fjr@ssd.ray.com
 Marc Friedman		maf@verdix.com
 Joe Van Andel		vanandel@ncar.ucar.edu
 Bob Marino		ram@mr.picker.com
 Richard Kowalsky	cmdorat@tc.fluke.com 
 Kent Long		kent@wrs.com
 James Moore		james@wrs.com
 Chuck Meade		chuckm@verdix.com
 Patrick T. Pinkowski	ppinkow@jupiter.ksc.nasa.gov
 D'Anne Thompson	dat@noao.edu
 Leonid Rosenboim	leonid@rst.hellnet.org
 David Lim		lim@robotics.jpl.nasa.gov
 Richard Neitzel	thor@thor.atd.ucar.edu
 John Winas		winas@phebos.aps.anl.gov
 Georg Feil		georg@sgl.ists.ca
 Steve Morris		morriss@smtplink.indigo.co.il

I welcome flames, insults, accusations, reactions, additions, and
corrections to this posting via email:

 hjb@netcom.com 

- ------------------------------

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

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Thu Jan 20 04:01:29 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 20 04:01:38 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 20 04:01:21 PST 1994

        Subject: Re: Global Alert For All: Jesus is Coming Soon
        Subject: socket ioctl?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Global Alert For All: Jesus is Coming Soon
Date: Tue, 18 Jan 1994 22:03:51 GMT
From: zal@bnlux1.bnl.gov (gonzalo maldonado)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1994Jan18.220351.11723@bnlux1.bnl.gov>
References: <9401181424.AA23579@helios>

Jesus Christ can set you free from the fear of DEADLINES because He died to pay
the price for all your MISSED DATES.

Taoism doesn't provide for your DELAYED DELIVERIES.

Boy! You better have your RELEASE in on time before He returns.

This VERSION of creation is about to get REVISED and only those who have
accepted Jesus Christ as Lord will not have their CONTRACTS CANCELLED!

                                 :-{) 
                                 Zal Maldonado

                                     

---------------------------

Newsgroups: comp.os.vxworks
Subject: socket ioctl?
Date: 20 Jan 1994 10:24:51 GMT
From: smagt@fwi.uva.nl (Patrick van der Smagt)
Organization: FWI, University of Amsterdam
Message-ID: <2hlm5j$b9v@mail.fwi.uva.nl>

HI!

I'm trying to port my SYSV/BSD socket code to VxWorks.  I encountered
a problem with raising signals on socket input, which can be done
using

#if SYSV
  if (ioctl(d_learn_socket, I_SETSIG, S_RDNORM|S_INPUT))
  {
        perror("setup_learn ioctl()");
        panic_exit();
  }
#elif BSD
  if (fcntl(d_learn_socket, F_SETOWN, getpid()) == -1)
  {
        perror("fcntl F_SETOWN");
        panic_exit();
  }
  if (fcntl(d_learn_socket, F_SETFL, FASYNC) == -1)
  {
        perror("fcntl F_SETFL");
        panic_exit();
  }
#endif

However, VxWorks doesn't know fcntl nor I_SETSIG (I'm running
VxWorks 5.0.2).  Is there a solution to this problem?

							Patrick

---------------------------

End of New-News digest
**********************

From erolfe@ll.mit.edu  Thu Jan 20 06:45:54 1994
From: erolfe@ll.mit.edu (Ed Rolfe)
Date: Thu Jan 20 06:46:09 PST 1994
Subject: Questions on TCL under VxWorks...
Hi,

Is anyone else using Joe Van Andel's port of
tcl7.0 to vxworks?  If so, I have the following
questions, and being a newbie myself to tcl/tk,
I apologize in advance if the answer(s) are obvious...

[Q1]: from my development workstation, how can i issue
      the following  tk command to the interpreter 
      running on the vxworks host?

      "send appName arg ?arg ...?" 

      I've briefly looked through the modified tcl code
      and still can not see how to do this.  I doubt the
      vxworks tclMain task is registering the app-name
      against any display on our net, yet Joe eludes to 
      this capability in his release notes.

      An example of how to do this, even if only with the
      vxTCLDemo() function, would be useful.      

      BTW: I did also scan the tclTCP.c code, and while
      it looks like this may be how remoted command
      execution could be performed, again, i'm not
      clear on how the vxworks server-interpreter is 
      established nor what commands must be registered
      with the client-interpreter (workstation in this case),
      in order to establish a link to the vxworks server.

[Q2]: for those people who are using this port of tcl7.0,
      do you have any interesting and useful VxWorks applications
      you are willing to release publicly, or snipets of 
      which you might think helpful to those of us just
      getting started under tcl.  One such interesting case
      would be to use tclsh, rather than vxRsh, to execute 
      a remoted VxWorks command.
      

[Q3]: perhaps a question more for the WRS folks...

      Did WRS or FSF add the TCL interface to VxGDB? In either
      case, can (or should) we expect that at some point in
      the future, WRS will perhaps be supplying an alternative
      to their existing shell?

Thanks -
 
ed

+-----------------------------------------------------------------------+
|     Edward G. Rolfe              email: erolfe@ll.mit.edu             |
|     MIT Lincoln Laboratory       voice: 617/981-4013                  |
|     MS B-284                     fax:   617/981-0785                  |
|     244 Wood Street              Division 6 Group 64                  |
|     Lexington, MA 02173          Satellite Communication Technology   |
+-----------------------------------------------------------------------+

From mpoulsen@piranha.sim.es.com  Thu Jan 20 07:35:46 1994
From: mpoulsen@piranha.sim.es.com (Mike Poulsen)
Date: Thu Jan 20 07:35:58 PST 1994
Mike Poulsen	---  mpoulsen@piranha.sim.es.com  ---
Howdy:

	We are currently using vxWorks 5.1 and are experiencing some 
	difficulties with the MV147 SCSI driver. 
  	When we attempt to format some SCSI devices, the vxWorks SCSI driver
	seems to timeout before the format command has a chance to finish.
	This seems to happen only on large disk drives which may take in excess
	of 40 minutes to complete the format.
	We have analyzed the SCSI information with a SCSI analyzer and have
	come to the conclusion that it is the driver that is timing out.
	We have attempted to increase this timeout period by assigning the
	SCSI_TIMEOUT_FULL value to the pScsiXaction->cmdTimeout field of the 
	SCSI_PHYS_DEV structure before issuing the format command but with no
	success.   
	We have tried both the scsiIoctl() and scsiFormatUnit() command 
	(of course not both in the same image at the same time).

  SCSI_PHYS_DEV *pScsiPhysDev = scsiPhysDevCreate(...
  .
  .
  .

  pScsiPhysDev->pScsiXaction->cmdTimeout = SCSI_TIMEOUT_FULL;
  scsiIoctl(pScsiPhysDev, FIODISKFORMAT, arg);                /* This command */
  scsiFormatUnit(pScsiPhysDev, FALSE, 0, 0, 0, NULL, 0);   /* or this command */

	The formatting process begins well and continues for about 35 to 40
	minutes (We know the drives require at least 40 minutes to format), at
	which time the SCSI driver issues a SCSI bus reset (a good indication
	that the driver timed out).
	At this point the drive cannot even be seen by the SCSI driver (even
	after reboot or power down) since the drive returns nothing on a 
        scsiReadCapacity() called from scsiPhysDevCreate().
	(We are pretty sure that the drives themselves are good since we can 
	 then mount them on other systems not using the vxWorks MV147 SCSI 
	 driver and be able to format them fine).
	An example of one of the drives we`re working with is a 2.2 Gig 
	Seagate ST12400N removable shuttle drive.

	Has anyone experienced this before and if so do you know of a
	solution.

	Thanks for any ideas!!!!

			Michael Poulsen
			Evans & Sutherland Computer Corporation
			Salt Lake City,  Utah

	mail to:	mpoulsen@piranha.sim.es.com

From mea@mclean.sparta.com  Thu Jan 20 09:11:12 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 20 09:11:21 PST 1994
Subject: Modems and/or DES on VME
Greetings!

  Is anyone out in netland familiar with any manufacturer that builds a
VMEbus implementation of any of the popular modems (V.32, V.32bis, etc.).
Alternatively, we could use a DSP if someone had code to make the DSP
look like a modem.  I realize that modems are cheap, but it's a packaging
issue.  We'd like to have at least 3-4 channels with just phone line
jacks on the back of the box.

  On a separate, yet related, topic, does anyone have information of 
anyone who has implemented a VME board that supports DES (Data Encryption 
Standard) either in hardware?  I have software versions of the algorithms,
but was looking for hardware to take the load off my VxWorks systems.

Any pointers would be appreciated,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From visicom!VisiCom.COM!trest@lbl.gov  Thu Jan 20 10:33:05 1994
From: Mike Trest <trest@visicom.com>
Date: Thu Jan 20 10:33:21 PST 1994
Subject: RTOS Professional Positions
To All:

"... If you know your stuff in RTOS generally or VxWorks in particular,
please open an EMAIL-ONLY dialog with me.  If you have serious experience 
in UNIX/C/Networking/X-Windows/Motif applications, I am interested in 
hearing from you. ..."

It has been six months since my original posting of this message in 
July 1993.  In that time I have received a few hundred pieces of mail.
Approximately 20 organizations with about 30 current openings for
experienced RTOS professionals have responded.  The balance have
been from individuals who wished to be on the distribution list.

My motivation was, and remains, to raise the level of understanding
of the career paths and opportunities available to the experienced
RTOS processional.  I want to encourage more people starting out
in the RTOS field.  I want to encourage visibility to our industry
and the kinds of skills needed to function professionally.  I want
to encourage experienced RTOS people to be aware of the broader
horizions available in our industry.

I am beginning another cycle.  I am asking those who have previously 
given me job offering EMAIL to update their data.  Likewise, I am 
sending EMAIL to those who have previously asked me for a listing 
of these offerings.  

This cycle will be opened to include all RTOS professionals but 
with special interest in VxWorks, pSOS, and LYNX/OS.  

I have been asked why I am not restricting this to the news groups 
devoted to job-offerings.  It is because of my narrow focus on 
experienced RTOS professionals only and because of the satisfaction
expressed by previous participants.  Therefore, I am submitting
this announcement only to those EMAIL groups in which I am an
active participant.

=======================================================================
Here is the way I will be working this cycle:

1. If you employ RTOS professionals in your organization, please EMAIL
me a simple description of your organization, your typical RTOS 
requirements, and how an interested individual may contact you.  

If you have current needs, please indicate.  If you have no current 
openings, please state "FOR INFORMATION ONLY" somewhere in your message.  
I encourage organizations to send me an EMAIL even if you do not have 
any current openings.

2. Ever EMAIL received in response to item 1, will be forwarded on
to a distribution list of individuals who express an intrest in
hearing about organization who employ RTOS professionals.

3. If any individual wants to be copied on EMAIL received, please
send me a message and I will put you on the distribution list.

4. Anyone on the distribution list who wants to contact any of
the oragnizations who send me EMAIL must do so directly.

5. I WILL NOT GIVE A COPY OF THE DISTRIBUTION LIST TO ANYONE.
Don't even ask.

6. I will provide a moderator/editor service for all messages
received.  I plan filter out flames and other meaningless messages
to keep the distribution list clean.

7. This is not an official function of VisiCom Laboratories, Inc.
I am acting as an individual.  However, VisiCom may, from time
to time, submit its own EMAIL which will, like other organizations
will be submitted to the dristribution list.

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From rdmacko@somnet.sandia.gov  Thu Jan 20 14:03:47 1994
From: RD Mackoy <rdmacko@somnet.sandia.gov>
Date: Thu Jan 20 14:03:56 PST 1994
Subject: Boot and Reboot revisited
From the responses I got, let me try to describe the situation in more detail.

We have eight VXI crates with NIcpu030 cards as the slot 0 controller.  We
are running VxWorks 5.1.1.  Our testing is weapon related (go military
apps :-) ) in which we have only one chance to collect the data.
We want to have the host (a SPARC 10) to be in control if and when a
subsystem (the VXI crates) boot.  The power up sequence is not
deterministic, so a subsystem may try to boot before there is a host
available.  And if a subsystem controller goes down during a test we do
not want it to reboot itself and possibly erase valid data on other cards.
 We have come up with one solution, to modify the boot PROMs and use
BOOTP.  The modification allows BOOTP to wait until an image is available
for downloading.  In the default PROMs, the BOOTP would wait until it
found a host and if no image was available it would go to a serial console
mode only.  With the number of crates we did not want a serial network as
well as ethernet.
Does anyone see any gotchas or other possible solutions?  If anyone is
interested in our solution please let me know.
Thanks,
RD Mackoy               rdmacko@sandia.gov
Sandia National Labs    505-844-1911
PO Box 5800             505-844-4797
Albuquerque, NM         87185-0635

I speak for myself, only for myself, and noone but myself, so help me God!
     

From hill@luke.atdiv.lanl.gov  Thu Jan 20 16:28:10 1994
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Thu Jan 20 16:28:18 PST 1994
Subject: Re: Boot and Reboot revisited

Hello

> 
> We have eight VXI crates with NIcpu030 cards as the slot 0 controller.  We
> are running VxWorks 5.1.1.  Our testing is weapon related (go military
> apps :-) ) in which we have only one chance to collect the data.
> We want to have the host (a SPARC 10) to be in control if and when a
> subsystem (the VXI crates) boot.  The power up sequence is not
> deterministic, so a subsystem may try to boot before there is a host
> available.  And if a subsystem controller goes down during a test we do
> not want it to reboot itself and possibly erase valid data on other cards.
>  We have come up with one solution, to modify the boot PROMs and use
> BOOTP.  The modification allows BOOTP to wait until an image is available
> for downloading.  In the default PROMs, the BOOTP would wait until it
> found a host and if no image was available it would go to a serial console
> mode only.  With the number of crates we did not want a serial network as
> well as ethernet.
> Does anyone see any gotchas or other possible solutions?  If anyone is
> interested in our solution please let me know.

If you need stand alone operation you might try booting out of a RAM 
or SCSI disk. Its possible to avoid the VME sysreset when you reboot
(at least on most processors- check out your BSP).

By the way. We are just beginning to use NI CPU030's for some
of our EPICS applications. Have used the 030 long enough to rate 
its reliability?

Jeff

From daemon@vxw.ee.lbl.gov  Fri Jan 21 04:01:29 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 21 04:01:38 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 21 04:01:17 PST 1994

        Subject: Re: Questions on TCL under VxWorks...
        Subject: Re: Questions on TCL under VxWorks...

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Questions on TCL under VxWorks...
Date: 20 Jan 1994 21:47:23 GMT
From: vanandel@stout.atd.ucar.edu. (Joe Van Andel)
Organization: National Center for Atmospheric Research
Keywords: TCL vxworks
Message-ID: <2hmu5b$5ku@ncar.ucar.edu>
References: <9401200943.AA15062@LL.MIT.EDU>
Sender: vanandel@stout (Joe Van Andel)

In article <9401200943.AA15062@LL.MIT.EDU>, erolfe@ll.mit.edu (Ed Rolfe) writes:
|> Hi,
|> 
|> Is anyone else using Joe Van Andel's port of
|> tcl7.0 to vxworks?  If so, I have the following
|> questions, and being a newbie myself to tcl/tk,
|> I apologize in advance if the answer(s) are obvious...
|> 
|> [Q1]: from my development workstation, how can i issue
|>       the following  tk command to the interpreter 
|>       running on the vxworks host?
|> 
|>       "send appName arg ?arg ...?" 
|> 

You are correct, "send" only works from Tk, to other Tk/TCL processes attached to
the same 'X' display.  My port of tcl to vxworks supports tclTCP, which uses the
"tcp" command to communicate between interpreters.  You need to add tclTCP2.0 to
your Unix Tk/TCL application to use this.   (Get this from harbor.ecn.purdue.edu 
It should be available shortly as pub/tcl/extensions/tclTCP2.0.tar.Z )

Please note that tclTCP does have a known bug. If two tasks send messages to each
other at the same time, they may deadlock.  (Note, I didn't write tclTCP, I just
ported it!)  It works fine if you keep a "master-slave" task relationship, where
one task always sends commands to the other.

(I've investigating using a package called tcl-dp as a replacement, but it relies
on Tk, so it can't easily be ported to vxworks.)

	Joe VanAndel  		    Internet: vanandel@ncar.ucar.edu
	National Center for 	    Web http://www.atd.ucar.edu/jva/home.html
	Atmospheric Research

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Questions on TCL under VxWorks...
Date: 20 Jan 1994 23:02:30 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Keywords: TCL vxworks
Message-ID: <2hn2i6$dn1@ncar.ucar.edu>
References: <9401200943.AA15062@LL.MIT.EDU> <2hmu5b$5ku@ncar.ucar.edu>

I posted:
(Get this from harbor.ecn.purdue.edu 
|> It should be available shortly as pub/tcl/extensions/tclTCP2.0.tar.Z )

Sorry, make that tclTCP2.0.tar.gz 

	Joe VanAndel  		    Internet: vanandel@ncar.ucar.edu
	National Center for 	    Web http://www.atd.ucar.edu/jva/home.html
	Atmospheric Research

---------------------------

End of New-News digest
**********************

From kevinr@photon.ceco.com  Fri Jan 21 19:36:06 1994
From: kevinr@photon.ceco.com (Kevin R. Rumbaugh)
Date: Fri Jan 21 19:36:14 PST 1994
Subject: Way to tell time since boot

I have thought several times that I would like some way to be able 
to either query a board or at least figure out from the shell, how
long a board running VxWorks has been 'up'.  Has anyone else
thought about this and implemented something along these lines,
particularly for MVME1[46]7's?  Does someone know of someway
to extract this information from the 'kernel'?  It does not
necessarily have to be time, but simply some indication of
how long it has been since the board was booted.  If I could
find someway to get the information it should be relatively
easy to port the rstatd rpc code to send back the data to
a remote requester.  Any help would be appreciated.

-- 

                     Kevin Rumbaugh  'The Marauder'
		      --- Commonwealth Edison ---
E-MAIL    : kevinr@ceco.com  OR   uunet!ceco!kevinr
AT&T      : (312) 394-8894        FAX	: (312) 394-4233
USMAIL    : Information Systems; Room 1135; 125 S. Clark; Chicago IL 60603

From daemon@vxw.ee.lbl.gov  Sat Jan 22 04:01:36 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 22 04:01:45 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 22 04:01:28 PST 1994

        Subject: mv167 SCSI disk write CPU Hog

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: mv167 SCSI disk write CPU Hog
Date: 21 Jan 1994 13:10:49 -0600
From: irwin@sugar.NeoSoft.COM (Bob Irwin)
Organization: Realtime Systems / SW Houston
Message-ID: <2hp9bp$bdg@sugar.NeoSoft.COM>

Help!  I've called for WRS support on the following, but am not getting
much help.  This is a plea to experienced vxWorks users.

We've genned vxWorks 5.1 to support two SCSI disks (Seagate ST11200Ns)
on a mv167 target using the DOS filesystem to write 'Contiguous' files while
accessing data (A/D, Digital I/O, ieee488, 1553, serial, etc)
in a realtime environment.  The accessing of data is triggered by interrupts
with periods of 1 and 10 milliseconds.  A relatively low priority task
'archives' this data into one of two 1 megabyte buffers and when one of these
buffers becomes full the 'archive' task writes the data to a pre-allocated
contiguous local SCSI disk file.

It appears that the vxworks filesystem is copying this 1 Megabyte buffer
from user space and locking out ALL user tasks during the copy.  As a result
we cannot service the interrupts and lose data during this copy operation.

I'm rather amazed that vxWorks doesn't seem to support what I'm used to calling
"Asynchronous" disk IO  or at least spooling of data to the filesystem.  Older
generation Operating Systems like DEC's RT11 and Intel's RMX handled this
readily.  How do we do it under vxworks? 

So, how do you guys work around this apparent limitation?  Do we need to
go to raw disk access?  or direct Scsi access of the disk? 

Our time fuse is burning rapidly.   

Thank you.  If we've missed an apparent way to handle this data spooling
my apologies to the authors of WRS documents.

Please post to this newsgroups or email me via:

  irwin@neosoft.com   or sis@neosoft.com
- -- 
R L Bob Irwin | Realtime Systems | Houston | (713)981-7580 <irwin@neosoft.com>
When I was a boy I was told that anybody could become president;
I'm beginning to believe it.    - Clarence Darrow

---------------------------

End of New-News digest
**********************

From leonid@rst.hellnet.org  Sun Jan 23 01:43:55 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Jan 23 01:44:06 PST 1994
Subject: Re: Way to tell time since boot
Usually the kernel ticks start at 0 when the system boots, so
if you need to know the time since last reboot in seconds just do:

  seconds = tickGet() / sysClkRateGet() ;

-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From leonid@rst.hellnet.org  Sun Jan 23 01:44:04 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Jan 23 01:44:24 PST 1994
Subject: DR-11 Board & Driver
Does anyone have any pointer to a DR-11 VME board that has a VxWorks
driver for it ?
-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From leonid@rst.hellnet.org  Sun Jan 23 01:44:05 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Jan 23 01:44:28 PST 1994
Subject: Re: mv167 SCSI disk write CPU Hog
irwin@sugar.NeoSoft.COM (Bob Irwin) writes:

> It appears that the vxworks filesystem is copying this 1 Megabyte buffer
> from user space and locking out ALL user tasks during the copy.  As a result
> we cannot service the interrupts and lose data during this copy operation.

This diagnose of the problem is incorrect. We have experience with
a similar application and we did not observe any interrupts locking.
The mv167 ncr710 CSI chip writes the data to the disk directly from
the user buffer. Besides, in VxWorks there is no concept of user space
versus user space like in Unix.

There is however a different problem in dosFs - the CPU overhead
increases as the file size interases, which makes the use of very
large cotigous files not practical. Our work around has been
to use relative small files (~ 10 MBytes). This problem was filed
with WRS support.

Bob, I recommend you inspect your own code to see if YOU are not
doing any intLock() or taskLock() within the archiver task.
-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From morriss@smtplink.indigo.co.il  Sun Jan 23 05:09:14 1994
From: Steve Morris <morriss@smtplink.indigo.co.il>
Date: Sun Jan 23 05:09:32 PST 1994
Subject: rshd

Text item: Text_1

        Has anyone implemented an rsh daemon for VxWorks, or know where I can 
        get a source that I could modify or just the correct protocol.
        
        I tried to write a server according to the protocol listed in the Sun 
        "rshd" man page but just got the arcane message "socket: protocol 
        failure in circuit setup" and do not know how to procede.
        
        Steve Morris
        
----------------------------------------------------------------------
        
Steve Morris                        voice: (972)-8-381055 
Software Team Manager                      (972)-8-381818 
Indigo Graphic Systems              Fax:   (972)-8-408091
P.O. Box 150, Rehovot, Israel       e-mail: morriss@smtplink.indigo.hellnet.org
        
----------------------------------------------------------------------

        

From stan@rti.com  Sun Jan 23 16:47:52 1994
From: stan@rti.com (Stan Schneider)
Date: Sun Jan 23 16:48:03 PST 1994
Subject: Re: rshd
>> Submitted-by morriss@smtplink.indigo.co.il  Sun Jan 23 05:09:14 1994
>> 
>>         Has anyone implemented an rsh daemon for VxWorks, or know where...
>>

RTILib has a similar functionality called "rshell"; it doesn't use the rsh
protocol but accomplishes very similar results.  There's also a program called
vxRsh in the archives.  I think it only supports one connection (?), but it may
do what you want.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From lerible@sass165.sandia.gov  Sun Jan 23 16:52:57 1994
From: lerible@sandia.gov (Loren E. Riblett)
Date: Sun Jan 23 16:53:05 PST 1994
Subject: shared backplane communications
Help!  We are running a sparc 2ce as a slot 0 controller running unix
and an HK-MIPS V3500 in the same chassis running vxWorks.  My question is,
how can i signal the sparc from the V3500 that data is available for the
sparc to display?  I would also like to perform similar operations from the
unix side to the vxWorks side.  Any help with this problem would be greatly
appreciated!!

Thanks in advance.

Loren Riblett

From mea@mclean.sparta.com  Sun Jan 23 17:00:24 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Sun Jan 23 17:00:35 PST 1994
Subject: Re: rshd
Greetings!

> 
>         Has anyone implemented an rsh daemon for VxWorks, or know where I can 
>         get a source that I could modify or just the correct protocol.
>         
>         I tried to write a server according to the protocol listed in the Sun 
>         "rshd" man page but just got the arcane message "socket: protocol 
>         failure in circuit setup" and do not know how to procede.
>         

There is a vxrshd in the user's group archives that has clients on both sides
of the link.  Here at SPARTA, we took that code as a starting point and hacked
it (yes, Hwa Jin, we HACKED it ;-) to support the "normal" rshd call from
SunOS.  Works like a champ.  I'll be happy to send a copy to anyone who wants
it (I thought I sent it to the archives once, but somehow it got lost in the 
shuffle).  Rich, maybe I can try to post it to the archives again, if you can
tell me what I have to do this time?  BTW, I'll be out of town until next
Thursday, so I can send the code as soon as I get back.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From mea@mclean.sparta.com  Sun Jan 23 17:00:28 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Sun Jan 23 17:00:45 PST 1994
Subject: Re: DR-11 Board & Driver
Hi Leonid!

  VMIC has a DR11W-A board with VxWorks support.  The folks at NASA Goddard
are using it and we helped them integrate it into their system.  It can
run in either A32 or A24 space and has on-board DMA.  The board makes
some screwy assumptions regarding the use of BUSCLR (none of your boards
can drive that signal while DMA transfers are occurring), but other than
that, is works reasonably well.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From ah442@piglet.ins.cwru.edu  Mon Jan 24 05:36:47 1994
From: ah442@cleveland.freenet.edu (Erik C. Orange)
Date: Mon Jan 24 05:36:56 PST 1994
Subject: Spurious Interrupt:  What is it?

I thought I saw this subject pop up once before, so hopefully
someone can re-iterate for me.

Every now and then our development system pops up this message
on the console shell:

interrupt:
Uninitialized Interrupt!
Vector number 24 (0-255). Spurious Interrupt
Program Counter: 0x0000177a
Status Register: 0x3100

What is the significance of Vector Number 24?  Thanks in
advance for any insight.

Erik

--
Erik C. Orange                        FRD Industrial Automation
Systems Engineer                      Avery-Dennison Corporation
ah442@cleveland.Freenet.Edu           Concord, OH

From tlusco@aegis.gsfc.nasa.gov  Mon Jan 24 06:44:03 1994
From: tlusco@aegis.gsfc.nasa.gov (C Tom Lusco)
Date: Mon Jan 24 06:44:13 PST 1994
Subject: Re: dr11

Leonid,

(See Mike Anderson's message).

We've been using VMIC's dr11 board for about 1-1/2 years now.  Other than the
screwy BCLR thing, its been great. 
 
E-mail me personally if you have any specific questions.
 
Tom Lusco
tlusco@aegis.gsfc.nasa.gov
NASA/GSFC

From ma@tadpole.com  Mon Jan 24 07:19:08 1994
From: ma@tadpole.com (Mark Armitage)
Date: Mon Jan 24 07:19:32 PST 1994
Subject: Re: Spurious Interrupt:  What is it?
> Every now and then our development system pops up this message
> on the console shell:
> 
> interrupt:
> Uninitialized Interrupt!
> Vector number 24 (0-255). Spurious Interrupt
> Program Counter: 0x0000177a
> Status Register: 0x3100
> 
> What is the significance of Vector Number 24?  Thanks in
> advance for any insight.

The '3' in the status register is the level that the interrupt occurred on.
This should let you narrow down what it is that is causing the interrupt.  A
spurious interrupt is signalled when something asserts an interrupt, but when
the CPU get around to fetching the vector number from the interrupting
device, nothing responds (ie the CPU gets a Bus error).  

If you only get the error "every now and again", I assume that it must be
working most of the time.  My guess would be that this is a VME interrupt, and
that a bus arbitration problem is stopping the CPU reading the vector from
the interrupting board before it gets bus errored.  My other guess is that
you are using an Intel 82596 ethernet controller, which has an irritating
habit of asserting an interrupt, and then removing it again before you have
a chance to serve it (it's more complicated than that, but that's the
general idea).

Mark Armitage
Tadpole Technology

Tel: (512) 219 2200
Fax: (512) 219 2222
Email: ma@tadpole.com

From ddavies@jaba.sim.es.com  Mon Jan 24 07:49:46 1994
From: ddavies@jaba.sim.es.com (Doug Davies)
Date: Mon Jan 24 07:49:57 PST 1994
Subject: Re: rshd
Mike,

I'd be interested in a copy of you HACKED <grin> rsh code.

Thanks,

-Doug
--------------------------------------------------------------------------------
Douglas Davies (software engineer) |
Evans & Sutherland                 | "Never underpay your software engineers"
INTERNET: ddavies@jaba.sim.es.com  |                     -Jurassic Park Moral

From bennett@cs.unc.edu  Mon Jan 24 08:30:36 1994
From: Robert Bradley Bennett <bennett@cs.unc.edu>
Date: Mon Jan 24 08:30:45 PST 1994
Subject: Re: Spurious Interrupt:  What is it?
If you have a bus, in particular a VME bus, double-check the back plane jumpers.
I've seen spurious interrupt messages under SUNOS when the Interrupt
Ackowledge Daisy chain has been broken by lack of an interrupt jumper.

From goodrich@cabernet.gong.noao.edu  Mon Jan 24 08:56:55 1994
From: goodrich@cabernet.gong.noao.edu (Bret Goodrich)
Date: Mon Jan 24 08:57:10 PST 1994
Subject: Re: rshd
    we have implemented an rsh daemon for vwWorks that receives standard
rsh socket connects from a UNIX client.  this software supports our needs
for rsh but i won't say it's been tested *extensively*.  since there is
some interest in rsh daemons in this group i'll send out our implementation.
caveat emptor, as always.

bret
--------------------  
Bret Goodrich, National Optical Astronomy Observatories, Tucson, Arizona, USA
Usenet:   {arizona,decvax,ncar}!noao!goodrich or  uunet!noao.edu!goodrich
Internet: goodrich@noao.edu         SPAN/HEPNET:  noao::goodrich
Phonenet: 602.322.8522

-----------------------rshd.shar---------------------------
# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by cabernet!goodrich on Fri Jul  9 19:00:01 MST 1993
# Contents:  rshd.c rshd.h
 
echo x - rshd.c
sed 's/^@//' > "rshd.c" <<'@//E*O*F rshd.c//'
/* rshd.c - remote shell daemon for WRS VxWorks */

/*
 * Developed 1993 by the Global Oscillation Network Group (*)
 *
 * (*) A project of the National Solar Observatory, which is a division of
 *     the National Optical Astronomy Observatories (NOAO), operated by the
 *     Association of Universities for Research in Astronomy, Inc. (AURA)
 *     under cooperative agreement with the National Science Foundation.
 */
 
/*
modification history
-------------------
01a,05feb93,bdg  created
*/

/*
DESCRIPTION
The remote shell daemon processes commands from remote machines that execute
the BSD UNIX "rsh" command.  All VxWorks shell commands may be executed on a
remote host, with appropriate STDOUT and STDERR return messages returned.  The
daemon is initialized with a call to rshdInit(), which in turn spawns the tRshd
task.  This task makes a connection on the standard rsh port (514) and waits
for communications.  A second port is opened for output once the connection
has been initiated.

The rsh daemon will return an error to the client host if that host is not
in the hostLib.

NOTES
At this point there is no graceful way to quit the rsh daemon.
Log messages are not redirected.

SEE ALSO
remLib (1)

AUTHOR
@.CS
Bret D. Goodrich, Global Oscillation Network Group,
                  National Solar Observatory,
                  National Optical Astronomy Observatories
                  Tucson, Arizona, USA
                  goodrich@noao.edu
@.CE
*/

/* rshd.c 1.1 2/10/93 NOAO" */

#include "vxWorks.h"
#include "remLib.h"
#include "types.h"
#include "socket.h"
#include "in.h"
#include "ioLib.h"
#include "iosLib.h"
#include "taskLib.h"
#include "ptyDrv.h"
#include "logLib.h"
#include "errnoLib.h"
#include "string.h"
#include "sysLib.h"
#include "stdlib.h"
#include "sockLib.h"
#include "shellLib.h"
#include "stdioLib.h"
#include "hostLib.h"

#include "rshd.h"

#define RSH_PORT	514		/* shell port number */
#define RSHD_TASK_NAME	"tRshd"
#define RSHD_TASK_PRI	2
#define RSHD_TASK_OPT	(VX_SUPERVISOR_MODE | VX_UNBREAKABLE | VX_STDIO)
#define PTY_BUF_SIZE	4096
#define PTY_RSH		"/pty/rsh."
#define PTY_RSH_MASTER	"/pty/rsh.M"
#define PTY_RSH_SLAVE	"/pty/rsh.S"
#define ETX		'\001'
#define ETX_STRING	"\001\0"

extern printErr (char *, ...);

/*******************************************************************************
* rshdInit - initialize remote shell daemon
*
* This routine initializes the pseudo terminal connection then spawns the
* rshd task.  It should be executed only once.
*
* RETURNS
*   void
*/

VOID rshdInit (VOID)
{
					/* check for existing rshd task */
    if (taskNameToId (RSHD_TASK_NAME) != ERROR)
	return;
					/* create pseudo tty pair */
    if ((ptyDrv () == ERROR ||
	ptyDevCreate (PTY_RSH, PTY_BUF_SIZE, PTY_BUF_SIZE ) == ERROR) &&
	errnoGet () != S_iosLib_DUPLICATE_DEVICE_NAME)
    {
	logMsg ("rshInit: ERROR--unable to create pty device (0x%x)\n",
	    errnoGet ());
	return;
    }

    if (taskSpawn (RSHD_TASK_NAME, RSHD_TASK_PRI, RSHD_TASK_OPT,
	10000, (FUNCPTR) rshd) == ERROR)
	logMsg ("rshInit: ERROR--unable to spawn rshd (0x%x)\n",
	    errnoGet ());
}

/*******************************************************************************
* rshd - remote shell daemon
*
* This is the remote shell daemon.  It opens a pseudo terminal to connect to
* the VxWorks shell when a command has been accepted on the remote shell port.
* The shell is redirected, restarted, and sent a remote command.  Output goes
* to the remote shell port, then the shell's STDIN, STDOUT, and STDERR are
* returned to their previous descriptors.  This operation will momentarily
* disrupt any activity in the shell, whether on the console port or via
* rlogin or telnet.
*
* RETURNS
*   ERROR if rshd cannot initialize, otherwise it never returns.
*/

VOID rshd (VOID)
{
    IMPORT char *shellTaskName;
    struct sockaddr_in sin, sin2;
    int sinl;
    int sd[3];
    int slave, master;
    int shIn, shOut;
    char shellPrompt[64];
    char buf[PTY_BUF_SIZE];
    char c;
    int i, n;
    int lport;
    short port;
    int shellTid;
    char hostName[MAXHOSTNAMELEN+1];

					/* open master (network-side) file */
    if ((master = open (PTY_RSH_MASTER, O_RDWR, 0)) == ERROR)
    {
	logMsg ("rshd: ERROR--error opening %s (0x%x)\n",
	    PTY_RSH_MASTER, errnoGet ());
	return;
    }
					/* open slave (shell-side) file */
    if ((slave = open (PTY_RSH_SLAVE, O_RDWR, 0)) == ERROR )
    {
	logMsg ("rshd: ERROR--error opening %s (0x%x)\n",
	    PTY_RSH_SLAVE, errnoGet ());
	return;
    }
					/* Wait for shell to exist */
    while ((shellTid = taskNameToId (shellTaskName)) == ERROR )
	taskDelay (sysClkRateGet());

					/* Open socket and wait for client */
    sd[0] = socket (AF_INET, SOCK_STREAM, 0);

    bzero ((char *) &sin, sinl = sizeof (sin));
    sin.sin_family = AF_INET;
    sin.sin_port = RSH_PORT;
    if (bind (sd[0], (struct sockaddr *) &sin, sizeof (sin)) == ERROR)
    {
	logMsg ("rshd: ERROR--bind failed (0x%x)\n",
	    errnoGet ());
	close (master);
	close (slave);
	return;
    }
 
    listen (sd[0], 1);
					/* loop forever waiting for accept */
    FOREVER
    {
	errnoSet (OK);			/* clear errno for pretty i() display */
					/* Now accept connection */
	bzero ((char *) &sin, sinl = sizeof (sin));
	sin.sin_family = AF_INET;
	sin.sin_port = RSH_PORT;
	if ((sd[1] = accept (sd[0], (struct sockaddr *) &sin, &sinl)) == ERROR)
	{
	    logMsg ("rshd: ALERT--accept failed (0x%x)\n",
		errnoGet());
	    continue;
	}
					/* read the stderr port */
	if ((n = read (sd[1], buf, sizeof (buf))) <= 0)
	{
	    logMsg ("rshd: ALERT--read failed (0x%x)\n", errnoGet());
	    goto RESET3;
	}
	buf[n] = 0;
	sscanf (buf, "%hd", &port);
					/* connect the stderr port */
	lport = IPPORT_RESERVED - 1;
	if ((sd[2] = rresvport (&lport)) == ERROR)
	{
	    logMsg ("rshd: ALERT--rresvport failed (0x%x)\n", errnoGet ());
	    goto RESET3;
	}
	bcopy ((char *) &sin, (char *) &sin2, sinl);
	sin2.sin_port = port;		/* new port number */
	if (connect (sd[2], (struct sockaddr *) &sin2, sinl) == ERROR)
	{
            logMsg ("rshd: ALERT--connect failed (0x%x)\n", errnoGet ());
            goto RESET2;
	}
					/* check for valid host name */
	if (hostGetByAddr (sin.sin_addr.s_addr, hostName) == ERROR)
	{
	    sprintf (buf, "rshd: ALERT--Unknown host 0x%08x\n",
		sin.sin_addr.s_addr);
	    logMsg ("%s", buf);
	    write (sd[2], "\0", 1);
	    write (sd[1], buf, strlen (buf));
	    goto RESET2;
	}
					/* get command from remote host */
					/* ignore 2 user names */
	for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++);
	for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++);
	for (n = 0; read (sd[1], &buf[n], 1) > 0 && buf[n] != NULL; n++);
	buf[n++] = '\n';
	buf[n++] = NULL;

	write (sd[1], "\0", 1);		/* protocol bytes */
	write (sd[2], "\0", 1);
					/* save original standard in of shell */
	if (!shellLock (TRUE))
	{
	    sprintf (buf, "rshd: ALERT--Shell is locked\n");
	    logMsg ("%s", buf);
	    write (sd[1], buf, strlen (buf));
	    goto RESET2;
	}
	printErr ("\n*** Shell redirected to RSHD ***\n");
	shIn = ioGlobalStdGet (STD_IN);
	shOut = ioGlobalStdGet (STD_OUT);
					/* Redirect standard in of shell */
	shellOrigStdSet (STD_IN, slave);
	shellOrigStdSet (STD_OUT, slave);
					/* set options & clear pipe */
	ioctl (slave, FIOOPTIONS, (VOID *) OPT_RAW);
	ioctl (slave, FIOFLUSH, (VOID *) 0);
	taskRestart (shellTid);		/* restart shell */

					/* get old prompt, make new one */
	n = read (master, shellPrompt, sizeof (shellPrompt));
	shellPrompt[n++] = '\0';
	shellPromptSet (ETX_STRING);
					/* send command to shell */
	if ((n = write (master, buf, strlen (buf))) == ERROR)
	{
	    logMsg ("rshd: ALERT--error writing to master (0x%x)\n",
		errnoGet ());
	    goto RESET;
	}
					/* get response, remove prompt, etc */
	for (n = 0; read (master, &buf[n], 1) > 0 && buf[n] != '\r'; n++);
	for (i = n = 0; read (master, &c, 1) > 0; i++)
	    if (c == '\r')
		continue;
	    else if (c == ETX)
		break;
	    else
		buf[n++] = c;
	buf[n++] = '\0';

					/* send response to stdout socket */
	if (write (sd[1], buf, n) == ERROR)
	    logMsg ("rshd: ALERT--error writing to socket (0x%x)\n",
		errnoGet ());

RESET:					/* set shell back to orginal stdin */
	(VOID) shellLock (FALSE);
	shellOrigStdSet (STD_IN, shIn);
	shellOrigStdSet (STD_OUT, shOut);
	shellPromptSet (&shellPrompt[2]);
	printErr ("*** Shell returned to console ***");
	(VOID) taskRestart (shellTid);
RESET2:
	close (sd[2]);
RESET3:
	close (sd[1]);
    }

    close (sd[0]);
}
@//E*O*F rshd.c//
chmod u=rw,g=rw,o=r rshd.c
 
echo x - rshd.h
sed 's/^@//' > "rshd.h" <<'@//E*O*F rshd.h//'
/* rshd.h - remote shell daemon include file */
 
/*
Developed 1993 by the National Optical Astronomy Observatories(*)
 
(*) Operated by the Association of Universities for Research in
    Astronomy, Inc. (AURA) under cooperative agreement with the
    National Science Foundation.
*/
 
 
/*
modification history
--------------------
01a,05feb93,bdg  written
*/
 
 
/* rshd.h 1.1 2/10/93 NOAO */

#ifndef INCrshdh
#define INCrshdh

IMPORT VOID	rshdInit (VOID);
IMPORT VOID	rshd (VOID);

#endif	/* !INCrshdh */
@//E*O*F rshd.h//
chmod u=rw,g=rw,o=r rshd.h
 
exit 0

From rodin33!wgsu13!jdeangcd@uunet.uu.net  Mon Jan 24 21:07:32 1994
From: rodin33!wgsu13!jdeangcd@uunet.uu.net (Joe DeAngelo)
Date: Mon Jan 24 21:07:41 PST 1994
Subject: Shared Memory Network

I am using an MVME147 and a Cyclone i960 card in a VME rack.
I am using the shared memory network between them, but the
'147 card is a real-time controller which needs real-time 
access to peripheral devices which are memory mapped into
VME address space. We want the 147 card to be the only bus
master in order to assure bus access.
	This requires the shared memory for the network, etc.
to be on the cyclone card. We cannot get the sm network to 
function in this configuration. Has anyone else tried to get
this to work? (Anchor, etc. on other than CPU 0)???
	This has been called into Wind River, with little
response.

Joe DeAngelo
Kulicke and Soffa Industries
deangelo@kns.com

From daemon@vxw.ee.lbl.gov  Tue Jan 25 04:02:01 1994
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 25 04:02:13 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 25 04:01:44 PST 1994

        Subject: SCSI Communication
        Subject: netDrv, Mil-Std-1553, Sockets, and VxWorks
        Subject: 1994 June Usenix Call for Papers -- Last Chance

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI Communication
Date: Mon, 24 Jan 1994 17:27:37 GMT
From: RRAILEY@relay.nswc.navy.mil (Rene H. Railey)
Organization: NSWCDD, Dahlgren, VA 22448
Message-ID: <RRAILEY.1.2D440509@relay.nswc.navy.mil>
Sender: news@relay.nswc.navy.mil (newserver)

I am looking for some help with the initialization of some SCSI devices we are 
trying to install on our mv167 system with 5.0.3. Seems everyone looks for dos 
file systems for the norm but my situation calls for Unix type initialization. 
My configuration consists of two SCSI devices , one an Exabyte model 8505 5GB 
half high , and the other a CD-ROM device which we have not yet purchased. 
I am not experienced in device drivers , so any suggestions will come in handy.
Thanks in advance.
Rene H. Railey
Naval Surface Warfare Center
Dahlgren Division Code  F33
Dahlgren, VA  22448-5000
(703) 663-6276
rrailey@relay.nswc.navy.mil     

---------------------------

Newsgroups: comp.os.vxworks
Subject: netDrv, Mil-Std-1553, Sockets, and VxWorks
Date: Tue, 25 Jan 94 00:36:42 GMT
From: trimble@titan.rdd.lmsc.lockheed.com (Gary Trimble)
Organization: Lockheed Missiles & Space Co., Palo Alto, CA
Message-ID: <1994Jan25.003642.3057@enterprise.rdd.lmsc.lockheed.com>
Sender: news@enterprise.rdd.lmsc.lockheed.com (News Administrator)

Has anyone implemented netDrv to support socket communications using
the 1553 bus. Are there any significant limitations or reasons one 
would not do this? Please reply via email.

---------------------------

Newsgroups: news.announce.conferences,comp.os.386bsd,comp.os.linux,comp.unix.bsd,comp.unix.internals,comp.os.mach,comp.os.vxworks,comp.unix.wizards
Subject: 1994 June Usenix Call for Papers -- Last Chance
Date: 24 Jan 1994 22:22:49 -0500
From: margo@virtual61.harvard.edu (Margo Seltzer)
Organization: Aiken Computation Lab, Harvard University
Message-ID: <1994Jan25.010724.21117@das.harvard.edu>
Sender: barr@pop.psu.edu

ANNOUNCEMENT AND CALL FOR SUBMISSIONS

USENIX SUMMER 1994 TECHNICAL CONFERENCE
June 6-10, 1994
Boston Massachusetts

USENIX
The UNIX and Advanced Computing 
Professional and Technical Association

IMPORTANT DATES TO REMEMBER

DATES FOR REFEREED PAPER SUBMISSIONS
Submissions due:                 January 28, 1994
Authors notified by:            February 21, 1994 
Camera-ready papers due:           April  8, 1994

PRE-REGISTRATION SAVINGS DEADLINE
Monday, May 16, 1994
HOTEL DISCOUNT RESERVATION DEADLINE
Monday, May 16, 1994
REGISTRATION MATERIALS AVAILABLE
mid-March, 1994

CONFERENCE SCHEDULE IN BRIEF
Tutorial Program:  Monday and Tuesday June 6-7, 1994
Technical Sessions:  Wed. through Fri., June 8-10, 1994
Birds-of-a-Feather Sessions:  Tues. through Thurs., June 7-9, 1994
USENIX Reception:  Thursday evening, June 9, 1994
Vendor Display:  Wednesday and Thursday, June 8-9, 1994
Product Demonstrations  Wednesday and Thursday, June 8-9, 1994

Come join us in celebrating the 25th anniversary of UNIX!

Our emphasis at the USENIX Summer 1994 Technical Conference in Boston
is on UNIX in the real world:  describe your experiences developing
portable applications, running businesses on UNIX, or using UNIX as an
educational platform.  Share the trials and tribulations of migrating
complex applications into a UNIX environment.  Describe the network
protocols necessary to make the networking superhighway a reality. Or,
take a foray into the future of computing:

        * What to do when your toaster runs UNIX:  Does cat still work?
        * What should we do now to prepare for the 21st century?
        * Of Mice and Pen: Human-computer interaction
        * UNIX for the Masses
        * Terabytes a Day:  What's a disk to do?

Our traditional focus on UNIX remains, but we also encourage
submissions about systems other than UNIX, that have a significant
impact on the world of open systems.  We are interested in papers
describing new and interesting developments in and around open systems,
including networking, new languages, tools, and software engineering.
As at all USENIX conferences, papers that analyze problem areas and
draw important conclusions from practical experience are welcomed.

Note that the USENIX conference, like most conferences and journals,
requires that papers not be submitted simultaneously to more than one
conference or publication and that submitted papers not be previously
or subsequently published elsewhere.

CONFERENCE PROGRAM COMMITTEE
Program Co-Chairs:
Margo Seltzer, Harvard University
Keith Bostic, University of California, Berkeley

Mary Baker, Stanford University
John Bongiovanni, Stratus Computer, Inc.
Glen Dudek, Object Design, Inc.
Peter Honeyman, University of Michigan
Michael Jones, Microsoft Research, Microsoft Corporation
Kent Peacock, Consultant
Rob Pike, AT&T Bell Laboratories
Joseph Provino, Sun Select, Inc.
Greg Rose, Australian Computing and Communications Institute
Win Treese, Massachusetts Institute of Technology
Ozan Yigit, York University

DATES FOR REFEREED PAPER SUBMISSIONS
Submissions due:                 January 28, 1994
Authors notified by:            February 21, 1994 
Camera-ready papers due:           April  8, 1994

CASH PRIZES
Cash prizes will be awarded for the best paper at the conference, the
best paper by a full-time student, and the best presentation.

HOW TO SUBMIT A REFEREED PAPER
It is important that you contact the USENIX Association office to
receive detailed guidelines for submitting a paper to the refereed
track of the technical sessions; e-mail to summer94authors@usenix.org

In addition, enquiries about submissions to the USENIX Summer 1994
Conference may be made by e-mail to margo@usenix.org

The schedule for reviewing submissions for the conference is very
short, so our preferred submission is an exteded abstract (although we
will accept full papers).  The object of an extended abstract is to
convince the reviewers that a good paper and 25-minute presentation
will result.  They need to know that authors:
	* are attacking a significant problem
	* are familiar with the current literature about the problem
	* have devised an original or clever solution
	* if appropriate, have implemented the solution and
	  characterized its performance
	* have drawn appropriate conclusions about what they have
	  learned

The extended abstract should be 5 manuscript pages (single-sided) or
less in length.  It should represent the paper in "short form."  Please
include the abstract as it will appear in the final paper.  Include
references to establish that you are familiar with related work, and,
if appropriate, performance data to establish that you have a working
implementation and measurement tools.  If the full paper has been
completed, it may be submitted instead of an extended abstract.  Full
papers should be limited to 12 single-spaced pages.

Every submission should include one additional page containing:
	* the name of one of the authors, who will act as the contact
	  for the program committee
	* contact's surface mail address, daytime and evening
	  telephone numbers, e-mail address and (if available) fax
	  number
	* an indication of which, if any, of the authors are full-time
	  students

Authors of accepted submissions will be notified by February 21, 1994.
They will promptly receive instructions for preparing camera-ready copy
of an 8-12 page final paper, which must be received by April 8, 1994.

WHERE TO SEND SUBMISSION
Submit one copy of an extended abstract or full paper by January 28, 1994
via AT LEAST TWO of the following methods:
	* E-mail to summer94papers@usenix.org
	* FAX to +1-510-548-5738
	* Mail to:
                Summer 1994 USENIX
                USENIX Association
                2560 Ninth St., Suite 215
                Berkeley, CA 94710
                U.S.A.

TUTORIAL PROGRAM
On Monday and Tuesday of the conference you can explore topics
essential to anyone using or developing UNIX and UNIX-like operating
systems, X windows, networks, advanced programming languages, and
related technologies.  The USENIX Association's well-respected program
offers you introductory and advanced, intensive yet practical
tutorials.  Courses are presented by skilled teachers who are hands-on
experts in their topic areas.  At Boston, USENIX will offer two full
days of tutorials covering topics such as:

Introductory and advanced system administration
Distributed computing:  DCE, DFS, RPC, CORBA
Kernel internals:  SVR4, Chorus, Windows NT
Systems programming tools and program development
Systems and network security
Portability and Interoperability
Client-server application design and development
Sendmail and DNS
GUI technologies and builders

To provide the best possible tutorial slate, USENIX is constantly
soliciting proposals for new tutorials.  If you are interested in
presenting a tutorial, contact the Tutorial Coordinator: Daniel V.
Klein +1 (412) 421-2332, E-mail:  dvk@usenix.org

TECHNICAL SESSIONS
The conference technical sessions include one track presentations of
papers selected by the Program Committee.  These refereed papers are
published in the Conference Proceedings, provided free to technical
session attendees.

A parallel track of Invited Talks complements the refereed paper
track.  These survey-style or tutorial-type talks by invited experts
range over a variety of interesting topics, such as harnessing
programming tools, resolving system administration difficulties, or
employing specialized applications.  Submitted Notes from the Invited
Talks are published and distributed free to technical sessions
attendees.  This second track includes selections from the best
presentations offered at recent Symposia.

The Invited Talks Coordinators welcome suggestions for topics as well
as request proposals for particular Talks. In your proposal, state the
main focus, include a brief outline, and be sure to emphasize why your
topic is of general interest to our community.  Please submit to:
Brent Welch, Xerox PARC (1-415-812-4405) and Bob Gray, US WEST Advanced
Technologies (1-303-541-6014) or via e-mail to:  ITusenix@usenix.org

WORK-IN-PROGRESS REPORTS
Work-in-Progress Reports, scheduled during the technical sessions,
introduce interesting new or ongoing work.  The USENIX audience
provides valuable discussion and feedback.

Do you have interesting work you would like to share, or a cool idea
that is not ready to be published?  Works In Progress Reports are for
you!  We are particularly interested in presentation of student work.
To schedule your report, contact Peg Schafer via e-mail to
wips@usenix.org

BIRDS-OF-A-FEATHER SESSIONS
The always popular Birds-of-a-Feather sessions (BOFs) are very informal
gatherings of persons interested in a particular topic.  BOFs often
feature presentations or demonstrations followed by discussion,
announcements, and the sharing of strategies.  BOFs are offered
Tuesday, Wednesday, and Thursday evenings of the conference.  BOFs may
be scheduled at the conference or in advance by telephone to the USENIX
Conference Office at 1-714-588-8649 or via e-mail to conference@usenix.org

SUMMER 1994 VENDOR DISPLAYS & PRODUCT DEMONSTRATIONS
In Boston, vendor representatives will demonstrate the technical
innovations which distinguish their products, in scheduled 30-minute
product presentations in a theater-style setting.  In the USENIX Vendor
Display, emphasis is on serious answers from technically savvy vendor
representatives.  Here, in a relaxed environment, conference attendees
can "kick the tires" and be sure the products and services on display
really do what they're said to do.  Plus, you can review the newest
releases from technical publishers.

Vendors:  this is an exceptional opportunity for receiving feedback on
new development from USENIX's technically astute conference attendees.
If your company would like to demonstrate or display its products and
services, please contact:
Peter Mui
Telephone 1-510-528-8649
FAX 1-510-548-5738
Email: pmui@usenix.org

SPECIAL HOTEL RATES
The Boston Marriott Copley Place Hotel is headquarters for the USENIX
Summer 1994 Technical Conference and will be the location for all
conference activities.  The Boston Marriott Copley Place will be
offering special room rates to USENIX conference attendees.

FOR MORE INFORMATION
Materials containing all details of the technical and tutorial program,
conference registration, hotel and airline discount and reservation
information will be mailed at the end of March 1994. If you wish to
receive the registration materials, please contact:

USENIX Conference Office
22672 Lambert St., Suite 613
Lake Forest, CA 92630
USA
Telephone:  1-714-588-8649
FAX: 1-714-588-9706
E-mail: conference@usenix.org

---------------------------

End of New-News digest
**********************

From js@rtp.co.uk  Tue Jan 25 07:24:38 1994
From: js@rtp.co.uk (Jatinder Sangha)
Date: Tue Jan 25 07:24:48 PST 1994
Subject: tar for VxWorks

  Does anyone out there have a VxWorks version of the UNIX tar program?
  Or any idea how difficult it would be to port it?

  Thanks in advance,
--Jatinder

js@rtp.co.uk

From bdoerr@apljax.jhuapl.edu  Tue Jan 25 07:56:01 1994
From: bdoerr@apljax.jhuapl.edu (Bryan S. Doerr)
Date: Tue Jan 25 07:56:14 PST 1994
Subject: TCP Sockets: Mid-level Flow Desc Req.

	I'm trying to obtain information on how TCP/IP sockets are
implemented in vxworks.  Specifically, what kind of copies, buffering,
context changes etc occur during the transmission of a data buffer
from micro to micro.  I'm sure the answer involves knowledge of
not only TCP/IP as described in an RFC but also the bp driver used
by WRS.  Also, didn't WRS incoporate some optimizations between 5.1
and 5.0 ( or was it 5.0 and 4.x). Does BSD "tahoe" release play a 
part in this question or its answer?

	The level of detail that I'd like is more than just "you put the 
data in here and it comes out here", but less than "and then this 
bit, in this packet is toggled, followed by a 100ms timeout ...).
Kind of a Mid-level description.

	I checked the FAQ for a WRS App Note.  Does anybody have any
other references.  If the BSD socket implementation is still current,
I'll read the RFC and a UNIX book for that part of the question.  Does
anyone have the appropriate RFC number?  How about documentation on the 
bp driver implementation. Regarding the bp driver, I know the very basics
like shared memory on proc 0, carved up for each CPU, mailboxes or some
other interrupt telling the CPU there is data (or polled).  What happens
before and after this part is the core of my question. 

	BTW, I'm trying to learn what the user can do to optimize socket
operation by making intelligent choices on buffer size, data timeout,
etc.  I'm hoping this infomation will give me the background that I 
need.  Sorry for the wordy description.

	Thanks,
	Bryan

From ddowning@well.sf.ca.us  Tue Jan 25 09:58:12 1994
From: "Daniel D. Downing" <ddowning@well.sf.ca.us>
Date: Tue Jan 25 09:58:19 PST 1994
Subject: Re:  Modems and/or DES on VME
If your volumn is high enough, consider contacting Kodak Berkeley Research
@ 510-649-2720.  They specialize in Forward Error Correction devices and
can also handle crypto.

dan

From mitchh@hops.gvg.tek.com  Tue Jan 25 18:15:57 1994
From: Mitch Hendrickson <mitchh@hops.gvg.tek.com>
Date: Tue Jan 25 18:16:07 PST 1994
Subject: Re: RTOS Professional Positions 

Hi Mike:

I was on the original RTOS dist list, and I deleted most of your other
recent mail but saved the big second go-round one.  From rereading it,
it's unclear to me whether I'm automatically still on the list.  If
not, I would like to be added.  You might have me down as
mitchh@hops.gvg.tek.com or mitchh@gold.gvg.tek.com, which is the
preferred address.

Thanks,

-Mitch

-- 
Mitch Hendrickson		mitchh@gold.gvg.tek.com
Grass Valley Group, Inc.	(of course I don't speak for them!!)
P.O. Box 1114  (M/S N3-2B)	also: mitchh@well.sf.ca.us
Grass Valley, CA 95945		"Control for smilers can't be bought..."
 

From daemon@vxw.ee.lbl.gov  Wed Jan 26 04:01:56 1994
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 26 04:02:06 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 26 04:01:45 PST 1994

        Subject: Configuring Gcc to produce VxWorks compatible objects ?
        Subject: Of interest of VxWorks/MIPS users
        Subject: Re: SCSI Communication
        Subject: Re: port of vxWorks to multiple custom boards
        Subject: Re: Spurious Interrupt:  What is it?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Configuring Gcc to produce VxWorks compatible objects ?
Date: Tue, 25 Jan 1994 13:21:14 GMT
From: heyes@dahp1.cebaf.gov (Graham Heyes)
Organization: Continuous Electron Beam Accelerator Facility
Message-ID: <HEYES.94Jan25082114@dahp1.cebaf.gov>
Sender: usenet@murdoch.acc.Virginia.EDU

Someone has asked me how to configure the GNU C compiler to generate
VxWorks compatible object code. Sadly I can't remember the answer,
something to do with using the configure option for SUN OS or maybe I am
totally wrong. Can someone jog my memory?

I seem to remember seeing this somewhere here in the past few months.
- --

		Graham

- -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Graham Heyes,CEBAF,12000 Jefferson Ave,Newport News,VA 23606,Tel:(804) 249-7030

---------------------------

Newsgroups: comp.os.vxworks
Subject: Of interest of VxWorks/MIPS users
Date: 25 Jan 1994 23:36:48 GMT
From: edmunds@s1.gov (Dave Edmunds)
Organization: Lawrence Livermore National Laboratory
Message-ID: <edmunds-250194153440@macedmunds.s1.gov>
Followup-To: comp.os.vxworks

   This is a long post that I think would only be of interest to people
running VxWorks on MIPS targets, and in particular ones running it on the
MIPS Magnum development platform.

   After telling us last fall (when we were debating whether to get another
year of maintenance on VxWorks) that the release of version 5.1 was going
to be "very soon", I came to find out (several months later) that not only
was it not going to be very soon, it wasn't going to be at all.  Wind River
said that MIPS didn't have an ANSI C compiler, and 5.1 couldn't be compiled
without one.  I called up Silicon Graphics, got put in touch with their
MIPS folks, and was told that the current release of their compiler was
ANSI, and had been so for quite a while.  The compiler that ships with the
workstations isn't ANSI, but one can buy one that is.  I called Wind River
back, and they verified this with MIPS and said they would put it on their
work list, but they couldn't say quite when it would be complete yet, and
that I should call back in the middle to end of February and that they
could give me a date then.

   In the meantime, WRS has released 5.1.1 in beta for the Sun/MIPS and
SGI/MIPS combinations.  They suggested I try one of those.  Well, I don't
have ready access to an SGI machine, and the cross-compiler for the Sun is
$5000 for one machine or $15000 for eight.  This seems hefty to me for a C
compiler in this day and age, but WRS said they just buy it from MIPS. 
These are my only alternatives at the moment.

   WRS says they  didn't know about the ANSI C compiler because it didn't
ship standard with the MIPS systems, and nobody asked if there was another
one.  They added that they don't like to rely on compilers that cost extra
over and above the workstations because the end-users don't like to have to
pay more.  I can understand that, and suggested to them that they do a port
for the GNU C compiler, which will generate R3000 code, as they have done
for most of their other targets.  Their response, and I would very much
like to hear responses from anyone on the Net about this, is that the MIPS
community overall felt that the performance of their target machines was
very much tied to the excellent performance of the MIPS C compiler, and
that they wouldn't consider using the GNU compiler.  I said that I would
consider it, and that in fact version 2.x of the MIPS compiler was pretty
buggy, to the point of generating erroneous code on at least two occasions
that I came across in only a few months of using it.  WRS said they didn't
doubt this, but that the MIPS community's perception is what mattered.  I
don't know about the quality of the code generated by the GNU compiler (is
it really bad?), but does everyone really feel that strongly about the MIPS
compiler?

   I could go on (believe it or not), but I think that's enough for now.  I
thought this might be of interest to some of the MIPS users out there.

- -- Dave Edmunds

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: SCSI Communication
Date: 26 Jan 94 00:35:33 GMT
From: mike@imatron.COM (Mike Morrison[Software Eng])
Organization: Imatron Inc., South San Francisco
Message-ID: <360@imatron.COM>
References: <RRAILEY.1.2D440509@relay.nswc.navy.mil>

In article <RRAILEY.1.2D440509@relay.nswc.navy.mil> RRAILEY@relay.nswc.navy.mil (Rene H. Railey) writes:
>I am looking for some help with the initialization of some SCSI devices we are 
>trying to install on our mv167 system with 5.0.3. Seems everyone looks for dos 
>file systems for the norm but my situation calls for Unix type initialization. 
>My configuration consists of two SCSI devices , one an Exabyte model 8505 5GB 
>half high , and the other a CD-ROM device which we have not yet purchased. 
>I am not experienced in device drivers , so any suggestions will come in handy.
>Thanks in advance.
>Rene H. Railey
>Naval Surface Warfare Center
>Dahlgren Division Code  F33
>Dahlgren, VA  22448-5000
>(703) 663-6276
>rrailey@relay.nswc.navy.mil     

- - VxWorks doesn't support a unix filesystem, only DOS, RT-11 and RAW. You can
  use long unix type filenames however.

- - What exactly do you mean by initialization of SCSI devices?  low level format?
  writting a file system?

- - VxWorks scsi devices get set up in $(VX_VW_BASE)/src/config/usrScsi.c
  You will probably have to change the arguments to scsiPhysDevCreate
  to reflect your SCSI ids. 

- - Feel free to e-mail me any specific questions.  I just did this type of
  stuff on a 167.

- -- 
********************************************************************
*	Michael Morrison	      	mike_morrison@imatron.com		   *
********************************************************************

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: Wed, 26 Jan 1994 04:44:18 GMT
From: tna@ornl.gov (NOELL T E)
Organization: Oak Ridge National Laboratory
Message-ID: <1994Jan26.044418.22090@ornl.gov>
References: <9401111613.AA00377@maureen.VisiCom.COM>

FrankVaughn asks:

 >      Question 1: In this case, is it reasonable to maintain the WRS 
 >      philosophy of creating one target directory for each board under a 
 >      common /config directory? I don't believe that 
 >      config/all/usrConfig.c(or the other files in /config/all) will be 
 >      similiar at all for the different targets. 
 >
 >      (remainder deleted)
 >

In general, I think the philosophy of a common tree for all BSPs is
good, but in practice (at least in the example of 5.1, I haven't
switched to 5.1.1 yet), there are some problems.

A minor problem:  how can a single vw/h/bspVersion.h file keep track of
bspVersions for multiple BSPs?  Every time you load a BSP, this file
gets overwritten.

A 3rd party problem: Synergy apparently supplies their own BSP (target =
sv4X).   When you run their install script, they replace files in 
config/all, which (I believe) are supposed to remain the same for "all" 
targets (thus the name?).  As a result, after you run their install,
the sv4X is the only kernel you can rebuild. Gee, I wonder why :-)

If I've missed something (regarding the scope of config/all/* across
BSPs, please let me know!

BTW, did they fix the bspVersion.h ambiguity in 5.1.1?

Regards,
Tim

noellte@ornl.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Spurious Interrupt:  What is it?
Date: Wed, 26 Jan 1994 05:50:40 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCK82wH.Dv2@netcom.com>
References: <9401241519.AA04066@tadpole.tadpole.com>

In article <9401241519.AA04066@tadpole.tadpole.com> ma@tadpole.com (Mark Armitage) writes:
>> Vector number 24 (0-255). Spurious Interrupt
>> Program Counter: 0x0000177a
>> Status Register: 0x3100
>> 
>> What is the significance of Vector Number 24?  Thanks in
>> advance for any insight.

spurious interrupt -- caused when a device does not respond to IACK cycle,
typically due to faulty hardware or incorrect PAL's or incorrect
software configuration of hardware interrupts.  the device should
be asserting /avec (if autovector'ed), /sterm, or /dsack (/dtack on 68000)
if using external vector'ed devices.  in the latter case, your device
is prolly not putting out correct vector address.

>The '3' in the status register is the level that the interrupt occurred on.

the '3' in the above message is S and M bit in SR, not interrupt level mask.
it means exception occurred during supervisor mode (vxworks always runs
in this mode), and while using SSP (as opposed to ISP).  

the correct interrupt level encoded is the following nybble -- '1' in 0x3100.

hwajin
PEACEFUL STAR

---------------------------

End of New-News digest
**********************

From rayssd!ssd.ray.com!fjr@uunet.uu.net  Wed Jan 26 05:30:21 1994
From: "Fred J. Roeber" <fjr@ssd.ray.com>
Date: Wed Jan 26 05:30:31 PST 1994
Subject: Re: Shared Memory Network
Joe DeAngelo says:

>  I am using an MVME147 and a Cyclone i960 card in a VME rack.
>  I am using the shared memory network between them, but the
>  '147 card is a real-time controller which needs real-time 
>  access to peripheral devices which are memory mapped into
>  VME address space. We want the 147 card to be the only bus
>  master in order to assure bus access.
>  	This requires the shared memory for the network, etc.
>  to be on the cyclone card. We cannot get the sm network to 
>  function in this configuration. Has anyone else tried to get
>  this to work? (Anchor, etc. on other than CPU 0)???
>  	This has been called into Wind River, with little
>  response.

I think you may be approaching the problem wrong Joe.  You say your
147 is doing "real time" processing.  I assume it is in slot 0 and
is acting as the VME bus arbiter.  The fact that it's memory is dual
ported for backplane communication shouldn't cause problems.  I assume
that the backplane communications you are worried about are between the
147 and i960.  Since there will be backplane traffic for inter CPU
messages, you will get better response in the 147 if it is accessing
it's own memory rather than trying to get to the i960.  The backplane
driver uses spin locks for synchronization.  Thus, there are loops
where the code tries to test and set flags atomically.  This will be
faster for the 147 if it is going to it's own memory.  Rather than
relocating the backplane buffers, I would suggest you look into using
priority based VME bus arbitration.  Put the 147 at the highest level
(level 3) and put the i960 at a lower level (e.g. 2).  Setting this
mode of operation is possible in the config files.
  You don't mention if there is an ethernet connection too.  If there
is one being used on the 147 that routes info to the i960 over the
backplane then you could have other loading concerns.  Other than that,
there shouldn't be any real problems with the 147 getting locked out
from VME access unless your basic design is overloading the VME bus,
throughput wise.    Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |

From tweadon@sadira.gb.nrao.edu  Wed Jan 26 07:24:36 1994
From: tweadon@sadira.gb.nrao.edu (TIM WEADON)
Date: Wed Jan 26 07:24:44 PST 1994
Subject: MV167 and the CD2400 Serial Chip
I'm having a problem with the Cirrus CD2400 in an application which
is "different" than normal. 

I'm setting up the chip to run at 57.6k baud async. This
chip is the controller on an in-house bus which requires all
command bytes to be sent out in even parity and all data bytes
to be send out in odd parity. 

Well, I "hacked" the CD2400Serial.c file to setup the port of interest
up to 57.6k baud and I added routines which will allow me to dynamically
enable / disable the receiver and change parity (two independent functions).
I have been working with Cirrus and they have assured me that my software
looks fine. But it doesn't work all the time.

The protocol is:
I send out 1 sync byte at even parity then 4 data bytes at odd parity.
Right after the 2nd data byte is received I get a response from a
device acknowledging it is responding to this message. 

What happens (1 out of probably every 5 to 40 transmissions) is the
parity on the CD2400 doesn't seem to change and instead of transmitting
4 data words at odd parity I see (on a logic analyzer) 3 + bytes to 
4 + bytes being sent out! In other words, the parity is not only not 
changed but a byte (11 bits [start, 8 data, parity, 1 stop]) now has
2 or three extra bits!

Yes, I have tried putting in delays between setting the parity and transmitting.
In addition I do wait till the chip says that the transmitter is empty
before I change parity (not just fifo). 

The MV167 is running at 33MHZ.

Has anybody else tried to change parity dynamically with this chip?
At what baud rate?
What is your experience?

I have done the same thing on an MV147 running at 25MHZ (using an external
baud rate generator) and it works very well. In fact the exact code runs
on the MV147 except the actual "hacked up" chip specific code. (The MV147
uses a 8530.)

Thanks for any thoughts.
Tim Weadon
National Radio Astronomy Observatory (NRAO)
(304) 456-2120
tweadon@nrao.edu

From lam@csd.nad.northrop.com  Wed Jan 26 10:59:27 1994
From: Christine Lam <lam@csd.nad.northrop.com>
Date: Wed Jan 26 10:59:35 PST 1994
Subject: Re: DR-11 Board & Driver

AP Labs has a Asynchronous I/O(AIO) DEvice Driver and it supports
the IKON DR11 board.  But you have to write your own interface for it.  
Here is the AP Labs San Diego and Colorado Spring phone numbers
(619) 546-8626 and (719) 598-2801.

Christine Lam

From daemon@vxw.ee.lbl.gov  Thu Jan 27 04:02:10 1994
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 27 04:02:23 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 27 04:01:58 PST 1994

        Subject: Re: Of interest of VxWorks/MIPS users
        Subject: Re: port of vxWorks to multiple custom boards
        Subject: Need Feedback/Opinions on Upgrade?
        Subject: VxWorks in Space
        Subject: Re: port of vxWorks to multiple custom boards
        Subject: Re: port of vxWorks to multiple custom boards
        Subject: Re: Of interest of VxWorks/MIPS users

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Of interest of VxWorks/MIPS users
Date: 26 Jan 94 18:35:09 GMT
From: wesw@fog.WV.TEK.COM (Wes Whitnah)
Organization: Network Displays Division
Message-ID: <4534@shaman.wv.tek.com>
References: <edmunds-250194153440@macedmunds.s1.gov>
Reply-To: wesw@orca.WV.TEK.COM
Sender: news@shaman.wv.tek.com

In article <edmunds-250194153440@macedmunds.s1.gov>, edmunds@s1.gov (Dave Edmunds) writes:
	< Many frustrating dealings with MIPS and WRS deleted... >

   I've been very disappointed in the attitudes of MIPS and WRS regarding
   compiler and development environments in general, and WRS's approach to
   supporting MIPS in particular.  I've experienced the same things Dave
   listed in his email.  Neither MIPS nor WRS are prompt or forthright in
   providing (correct) information or support, unless you are willing to
   pay big bucks up front!  This is why we've pretty well gone on our own
   in our development environment.

   We've been successfully using GNU C running on Sun workstations and
   cross-compiling for MIPS for quite some time (going on two years now).
   While it is true the first versions of GNU C were not as good at
   optimizing as the MIPS compilers and were a bit buggy, the later
   versions produced comperable if not better code than MIPS for our
   code base.  The current GNU C version we are using is 2.5.7 .  GNU is
   a strong alternative to MIPS, and much easier to work with.

   Wes Whitnah
   Principal Software Engineer
   Network Displays Division
   Tektronix, Inc.
   wesw@orca.wv.tek.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: Wed, 26 Jan 1994 19:59:48 GMT
From: geoff@wrs.com (Geoff Espin)
Organization: Wind River Systems, Inc.
Message-ID: <geoff.759614388@wrs.com>
References: <9401111613.AA00377@maureen.VisiCom.COM> <1994Jan26.044418.22090@ornl.gov>
Sender: news@wrs.com (News Manager)

tna@ornl.gov (NOELL T E) writes:
>In general, I think the philosophy of a common tree for all BSPs is
>good, but in practice (at least in the example of 5.1, I haven't
>switched to 5.1.1 yet), there are some problems.
>A minor problem:  how can a single vw/h/bspVersion.h file keep track of
>bspVersions for multiple BSPs?  Every time you load a BSP, this file
>gets overwritten.

The bspVersion.h (1.0) for 5.1 is, unfortunately, of little practical use.
It can't be tweaked on a board by board basis, it more or less stands
for the "interface level" which has changed little since 4.0.2
(+mmu support, +generic serial/timer drivers).

We have recently started adding to sysLib.c, sysBspRev(),
which concatenates the BSP_VERSION (1.0) with a release
number (starting now at "/1").  However, usrConfig.c does
not know about this routine yet, so it is not called.
When the next major release is made, both BSPs and device drivers
will have unique version numbers associated with them.

>A 3rd party problem: Synergy apparently supplies their own BSP (target =
>sv4X).   When you run their install script, they replace files in 
>config/all, which (I believe) are supposed to remain the same for "all" 
>targets (thus the name?).  As a result, after you run their install,
>the sv4X is the only kernel you can rebuild. Gee, I wonder why :-)

You are correct, this is not the right way, but if you're only
using Synergy products then it doesn't matter.  The correct
way is to fix the MakeSkel/Makefile to redefine:

    ## alternate file directory
    CONFIG_ALL = $(VX_BSP_BASE)/config/all/

to be "/<bsp>/" instead of "/all/".

I spoke with Synergy and they explained that due to the
various changes to WRS sources, that they instruct the
developer to clone a new vw tree before installing patches.
They weren't aware of this "trick", but there were several other
patches they had due to some of the fancy h/w they support.

The BSP Port Kit that most 3rd party vendors use does
make a lot of suggestions in this area, but often vendors
find there still aren't enough "hooks" so such compromises are made.

>BTW, did they fix the bspVersion.h ambiguity in 5.1.1?

Version 5.1.1 was an OS maintenance release only.
No BSP or drivers were included.

Geoff (Hardware Interface Technology Group Leader nee BSP&Drivers)
- --
Geoff Espin		geoff@wrs.com	(510)748-4100
Wind			River		Systems
1010 Atlantic Avenue	Alameda		CA 94501
- -- 
Geoff Espin		geoff@wrs.com	(510)748-4100
Wind			River		Systems
1010 Atlantic Avenue	Alameda		CA 94501

---------------------------

Newsgroups: comp.os.vxworks
Subject: Need Feedback/Opinions on Upgrade?
Date: 26 Jan 1994 14:46:05 -0700
From: rdhunt@unm.edu
Organization: University of New Mexico, Albuquerque
Message-ID: <2i6oat$gaf@triton.unm.edu>

Hi Folks:

    Well, I'm thinking of upgrading my development environment in a MAJOR
    way.  I realize that I am flying in the face of the "just change one 
    thing at a time" rule but there doesn't seem to be any alternative. I 
    could use a little guidance on what versions of what to use.  Does anyone 
    have any opinions on this set of hardware/software ?

    Host:	SUN SPARC10
    Host OS:	Solaris 2.3
    Target:	FORCE CPU-30 68030 VME board
    Target OS:	vxWorks version 5.1

    Software Tools:

    GNU Binutils version 1.97.1 ??  ( per the warning from wjasper@tx.ncsu.edu
                                      in archive9312)
    GCC 2.5.7 ????
    GAS version ????
    BISON version ????
    libg++ version ????
    gdb version ????
    xxgdb version ????

    If you have a working development environment with similar hardware and 
    fairly current versions of these tools please let me know what you are 
    using.  Also, I'm aware of the stink over RPCGEN and have already built
    it from the source, so don't bother warning me about that.  Thanks in 
    advance.

==============================================================================
Jeff Hollowell                                  e-mail:  jahollo@sandia.gov
Sandia Labs (Sandia is Spanish for watermelon)   voice:  (505) 844 - 6981
            (We're working on the big seedless ones)
- ------------------------------------------------------------------------------
  "In theory, theory and practice are the same thing"
==============================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks in Space
Date: 26 Jan 94 12:13:50 -0400
From: cacciaglia@nrlvx1.nrl.navy.mil
Organization: NRL SPACE SYSTEMS DIVISION
Message-ID: <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>

1. I am interested in hearing from other users of VxWorks which 
have or our planning to use in space based applications.  In 
particular error recovery and fault tolerance.

2. With the successful launch of the Deep Space Program Science 
Experiment (DSPSE) also known as Clementine 1 on Jan. 25, we are 
using VxWorks on a r3081 IDT processor. 

3. The use of VxWorks and the flexibility in development 
configurations really boost the productivity compared to the normal 
environments available for spacecraft software development.  We 
were able to use the networking capabilities using SLIP and the Shell 
vs. using In Circuit Emulators or break/halt/snapshot diagnostic 
ports.

4. With the flexibility of I/O devices we are able to upload new ecoff 
object files into a Memory device and then use the standard loadLib 
routines to use it, instead of the tedious and awkward methods of 
patch areas.

If you wish not to post my email address is:
           cacciaglia@nrlvax.nrl.navy.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: 27 Jan 94 02:18:44 GMT
From: wa137@sdcc12.ucsd.edu (john e. clark)
Organization: University of California, San Diego
Message-ID: <60224@sdcc12.ucsd.edu>
References: <9401111613.AA00377@maureen.VisiCom.COM> <1994Jan26.044418.22090@ornl.gov>
Sender: news@sdcc12.ucsd.edu

In article <1994Jan26.044418.22090@ornl.gov> tna@ornl.gov (NOELL T E) writes:
+FrankVaughn asks:
+
+ >      Question 1: In this case, is it reasonable to maintain the WRS 
+ >      philosophy of creating one target directory for each board under a 
+ >      common /config directory? I don't believe that 
+
+In general, I think the philosophy of a common tree for all BSPs is
+good, but in practice (at least in the example of 5.1, I haven't
+switched to 5.1.1 yet), there are some problems.
+
+A 3rd party problem: Synergy apparently supplies their own BSP (target =
+sv4X).   When you run their install script, they replace files in 
+config/all, which (I believe) are supposed to remain the same for "all" 
+targets (thus the name?).  As a result, after you run their install,
+the sv4X is the only kernel you can rebuild. Gee, I wonder why :-)

The following remarks refer to WRS BSP 1.0 for vx5.1. It will remain
to be seen how these items are delt with in later versions of the
BSP kit.

Because bootConfig.c only containes WRS BSP provided boot devices,
or libXXXXdrv.a only contains drivers found in WRS's BSP's. 3rd
parties on the left hind txxxt in regards to inclusion or even
pre-sight to inclusion in these important details.

Of course, if a board is from Motorola then WRS may dein to do the
port "themselves", well, unless you happen to be talking to someone
trying to sell you WRS programming support, and then you get the
'Well, WRS does say that, but really...'.

But back to the BSP. If one wished to modify some 'driver' and place
it in the 'src/drv' level, which seesm according to the hierarchy to
be the place, and use the 'driver' makefile skeleton, one is
confronted with two problems. One problem is that the libxxxxdrv.a
which will eventually be made includes all 'drivers' which happen to
'work correctly' one WRS supported boards, but may not work
correctly on other boards. There is no provision to have
libxxxxdrv_special.a processed before the libxxxxdrv.a supplied by
WRS. So, to the next problem. If a special driver needs to be
included in libxxxxxdrv.a then it must have a different name than
the so called generic one. And that is the crux of the problem. A
Boards Support Package is that set of software modules which CHANGES
on a per board basis. In other words WRS libxxxxdrv.a is excluded
from the BSP, but in fact is part of those modules which CHANGES
from board to board.

Other BSP details are there is no provision to version stamp the
vendor's BSP modules and the WRS level in 'h/bspVersion.h'.

Additionally, the bootConfig.c file contains only ethernet or
booting devices which are supported directly by WRS. All other 3rd
parties must use a singel defined macro to include their 'one'
interface. This means that either the 3rd party make a zillion
configurations for each possible interface, or CHANGE the module
which CHANGES with the board, namely bootConfig.c

In another area WRS fumbled the MakeSkel was that of memory sizes
and bases. Again, since WRS does not directly support a dual
processor version of vxWorks for the MC68040 processor, the memory
base and size parameters are not very will suited for vendor
modification. The vxWorks kernel must be compiled individually for
each option, since the RAM_... definitions are not only used in the
code but used in the link commands to set the base addresses where
the final kernel will execute.

For single CPU version this is OK. But for the dual processors this
means that for what ever partition of the various memory sizes the
MakeSkel file needs to be changed for each configured kernel.

A simple 'RAM_BASE_ADRS=memBaseAddress', memBaseAddress being a
variable which on initialization would contain the base of memory
would work except for later on in the resulting 'Makefile.MC...gnu'
there is a line '-Ttext $(RAM_LOW_ADRS)', which would fail if the
value is not the explicit numerical address.

WRS could better define a Board Support Package to be all those
files which change on a per vendor basis. The
'config/vendor/boardxxx' hierarchy could be such that all vendors
use a 'config/h/xxxx.h' if those files are generic enough or have a
'config/vendor/h/xxxx.h' file which a '-I../h' CFLAGS definition
would cause the compiler to search the vendor's 'h' directory first
and the subsequent 'h' directories on up the hierarchy. The current
one is this:

CC_INCLUDE      = -I$(UP)/h $(INCLUDE_CC) $(EXTRA_INCLUDE) \

Notice the subtle placement of the EXTRA_INCLUDE after anything
else. The $(UP) macro may be useful, but where's any documentation
describing that item?

For those files which 99% remain the same, '#include "vendor-option.h",
for the 1% that varies, or could vary would allow the 'config/all'
directory to be truely 'all boards' independent of vendor.

Other issues of the vendor support such as SCSI configurations,
types of disk drives etc. are also a problem. The vendor is 'stuck'
with handling the first call from a customer with a line like 'your
vxWorks doesn't work with a MAXTOR xxxYYYzzz'. It is very
unsatisfying to either the customer or the vendor to say 'Please
refer all vxWorks calls to your vxWorks customer support person'. It
gives the customer the impression that he's getting a run-around.
Especially when WRS support says, 'that sound like a BSP problem'.
The solution for the vendor has been to 'solve' the integration
issue on a particular set of hard drives, modify 'usrScsi.c'
to match that set or some reasonable subset, and when a customer
calls, give explicit instructions on how to integrate a new drive
based on experience with some known set of drives.

Alternatively, a vendor can pay WRS for inclusion in to the 'big
picture', or become so big that WRS offers to do the BSP
'themselves'.

- --------------

My personal opinion is that when WRS grew to a point where 'public'
was in the near future it's technical support to vendors declined
exponentially with the 'size' of the vendor. But in the VME board
biz size often changes, so other than Motorola, which can float an
operating unit for a while, this year's big VME vendor may be next
year's has been. Also, there has been a lemming race for RISC. Of
course these chips will be big biz in the future and there will be
need to support them. But again, what ever happend to MIPS anyway?
And were's an I860 when you need one. So while supporting the new
WRS should not disconnect from the past. One way to do this is to
be more atuned to the vendors suppling the current set of boards,
and not just atuned to the 'mighty mote' or 'the force'.
- ----

As a last word, let VRTX be an object lesson in kernel technology vs
vendor support, 'uh, yah I'm using VRTX 'cause it's 'fast' and we
got all this code, but I'd junk it in a second if there was an
alternative'. Some of the features of VRTX support were 'no call
backs' to OEM's who didn't seem to have 'the immediate sales numbers';
no-support on the sales pitch, 'we're great and everyone should know
that, and if they don't then they're not worth the time' or 'Uh, why
should we break our necks installing some XYZ BSP, when we got
Mot..' (well the sale was lost 'cause the customer liked XYZ's
performance over Mot.. and XYZ had an alternative Real Time Kernel').

- -- 

John Clark
wa137@sdcc12.ucsd.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: Thu, 27 Jan 1994 03:45:20 GMT
From: chris@wrs.com (Chris Ford)
Organization: Wind River Systems, Inc.
Message-ID: <chris.759642320@wrs.com>
References: <geoff.759614388@wrs.com>
Sender: news@wrs.com (News Manager)

Hello, regarding problems encountered when installing 3rd party BSPs...

geoff@wrs.com (Geoff Espin) writes:
> tna@ornl.gov (NOELL T E) writes:
> >         ... When you run their install script, they replace files in 
> >config/all, which (I believe) are supposed to remain the same for "all" 
> >targets (thus the name?).  As a result, after you run their install,
> >the sv4X is the only kernel you can rebuild. Gee, I wonder why :-)
>
> You are correct, this is not the right way, but if you're only
> using [name withheld] products then it doesn't matter.

Until recently the configuration policies for 3rd party BSP vendors were
ill-defined.  At the beginning of 1994, however, Wind River released BSP
Porting Kit 1.1 FCS.  The documentation element of this product answers
questions such as: "Should I modify bspVersion.h?" (Answer: "No"); and "What
if the config/all/* files supplied on the VxWorks object tape are not
appropriate for my hardware?" (Answered earlier by Geoff Espin).

Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks
5.1.x that will not clobber other BSPs when installed.  To be assured
that 3rd party VxWorks BSPs meet Wind River standards, insist that their
BSPs are validated by Wind River.  (BSP validation is a service offered
to VxWorks BSP Porting Kit customers).

Have fun,
- -Chris Ford
 Wind River Systems Engineering

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Of interest of VxWorks/MIPS users
Date: Thu, 27 Jan 1994 05:10:45 GMT
From: chris@wrs.com (Chris Ford)
Organization: Wind River Systems, Inc.
Message-ID: <chris.759647445@wrs.com>
References: <edmunds-250194153440@macedmunds.s1.gov> <4534@shaman.wv.tek.com>
Sender: news@wrs.com (News Manager)

Hello again, regarding tools for VxWorks MIPS targets...

edmunds@s1.gov (Dave Edmunds) writes:
> ... [Wind River] wouldn't consider using the GNU compiler.  I said that I
> would consider it, and that in fact version 2.x of the MIPS compiler was
> pretty buggy ...

wesw@orca.wv.tek.com (Wes Whitnah) writes:
> I've been very disappointed in the attitudes of MIPS and WRS regarding
> compiler and development environments in general, and WRS's approach to
> supporting MIPS in particular ...
> We've been successfully using GNU C running on Sun workstations and
> cross-compiling for MIPS for quite some time (going on two years now)
> ... later versions produced comperable if not better code than MIPS for
> our code base.  The current GNU C version we are using is 2.5.7 .
> GNU is a strong alternative to MIPS, and much easier to work with.

The customer is always right.  Any more calls for a GNU-based MIPS toolchain,
or (gulp) my resignation?

We're listening,
- -Chris Ford   <chris@wrs.com>
 Wind River Systems Engineering

---------------------------

End of New-News digest
**********************

From mea@mclean.sparta.com  Thu Jan 27 09:27:50 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Thu Jan 27 09:28:04 PST 1994
Subject: Re: GCC MIPS Tool Chain
Greetings!

  Toss my name in in favor of a GCC Sun X MIPS flavor.  If the fellow from
Tektronix could tell us how he generated the compiler, I think that many
of us who are interested in GCC MIPS would applaud.  WRS, I, for one, am
willing to give up a MIP or two to get a toolchain that is consistent with
my i960 and 68k flavors without costing me (and my customers) an arm and
a couple of legs.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From visicom!VisiCom.COM!trest@lbl.gov  Thu Jan 27 11:36:06 1994
From: Mike Trest <trest@visicom.com>
Date: Thu Jan 27 11:36:15 PST 1994
Subject: WRS is listening

> The customer is always right.   ...  We're listening,
> -Chris Ford   <chris@wrs.com>   ...  Wind River Systems Engineering

A few voices have expressed grief and frustration at WRS.   On some
issues there are more than a few voices.

Working at VisiCom Laboratories, I hear these voices from our customers. 
Quite often, I add my own comments and send them to WRS.  Most of the 
time, WRS' time schedules do not match mine, but eventually we find 
mutual solutions.

As both a major consumer of VxWorks and as a Value Added Reseller 
of WRS products, we are aware of the increasing price sensitivity 
in the RTOS marketplace.  We are also aware of the growing technical
awareness of the RTOS customer and their demands for *MORE* in every
aspect of hardware and software products.

I wish to thank Chris for his personal attention to issues such
as this WRS/MIPS/GNU issue.  My experiences with Dave, Chris,
Goeff, Kent, Mike, Mani, ... (and quite a few others over the
years) tell me that there are some real people at WRS who really do 
care about the future of their product and the customers who use it.

I encourage WRS and all of us to keep the messages flowing both
privately and publically.   It is through this kind of constructive,
factual exchange that we all gain a better product and happier
customers.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From daemon@vxw.ee.lbl.gov  Fri Jan 28 04:02:00 1994
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 28 04:02:16 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 28 04:01:49 PST 1994

        Subject: Re: FDDI VME
        Subject: Re: HDLC for VxWorks
        Subject: Re: VxWorks in Space
        Subject: Re: GCC MIPS Tool Chain
        Subject: Re: TCP Sockets: Mid-level Flow Desc Req.

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: FDDI VME
Date: Thu, 27 Jan 1994 17:27:02 GMT
From: johnb@fc.hp.com (John Barclay)
Organization: Hewlett-Packard Fort Collins Site
Message-ID: <CKAtt3.JuL@fc.hp.com>
References: <9401052014.AA23613@rad.orincon.com>
Sender: news@fc.hp.com (news daemon)

Suppliers of FDDI within the HP Complementary Hardware Vendor Program are:

Rockwell Networking
SBE, Inc.
Performance Technologies Inc.

Checkout the VITA Directory for VMEbus solutions which the above are.

- --
John Barclay                                    Hewlett-Packard Company 
TN 229-4325					johnb@hpfcjb.fc.hp.com
AT&T (303) 229-4325				

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: HDLC for VxWorks
Date: Thu, 27 Jan 1994 17:31:09 GMT
From: johnb@fc.hp.com (John Barclay)
Organization: Hewlett-Packard Fort Collins Site
Message-ID: <CKAtzx.JyA@fc.hp.com>
References: <CJJH63.Mv8@wrs.com>
Sender: news@fc.hp.com (news daemon)

You might want to check in with HDLC solution providers to findout what
drivers are available.  I think VMIC and SBE have HDLC solutions.

- --
John Barclay                                    Hewlett-Packard Company 
TN 229-4325					johnb@hpfcjb.fc.hp.com
AT&T (303) 229-4325				

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: VxWorks in Space
Date: 27 Jan 1994 18:06 UT
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Organization: Jet Propulsion Laboratory
Message-ID: <27JAN199418065999@kelvin.jpl.nasa.gov>
References: <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>

In article <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>, cacciaglia@nrlvx1.nrl.navy.mil writes...
>1. I am interested in hearing from other users of VxWorks which 
>have or our planning to use in space based applications.  In 
>particular error recovery and fault tolerance.
> 
We are using VxWorks  on the Galileo S-Band project.  The goal
of the project is to maximize the data output from the Galileo
spacecraft using its low gain antenna.  We use VxWorks to process
the signal from Galileo in real-time.  This week we had our first
real test when we took our system out to Goldstone.  We were able to
acquire and record the signal from the Voyager 1 and Voyager 2 spacecraft
using DSS-13 (a 34 meter antenna).  Next week we go back out to Goldstone
for our first opportunity with Galileo.
     ___    _____     ___
    /_ /|  /____/ \  /_ /|     Ron Baalke         | baalke@kelvin.jpl.nasa.gov
    | | | |  __ \ /| | | |     Jet Propulsion Lab | 
 ___| | | | |__) |/  | | |__   Galileo S-Band     | Failure is success if we
/___| | | |  ___/    | |/__ /| Pasadena, CA 91109 | learn from it.
|_____|/  |_|/       |_____|/                     |             Malcom Forbes

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC MIPS Tool Chain
Date: Thu, 27 Jan 1994 19:28:27 GMT
From: bradley@gaia.den.mmc.com (Jami Bradley)
Organization: Martin Marietta Astronautics, Denver
Message-ID: <BRADLEY.94Jan27122828@gaia.den.mmc.com>
References: <9401271728.AA04022@helios>
Sender: news@news2.den.mmc.com (News Admin)

What, the R3000 is using the MIPS compilers?  I am about to get the R3000
development system, and a very important feature of it is my software
compatibility with the MV167's, so we can use either board as needed.  This
will put a big damper on my development effort.  I far prefer the GCC toolset
for all C/C++ code I write.  I would be very interested in any GCC ports to the
R3000 as well!

Jami Bradley
jbradley@den.mmc.com
Embedded Flight Systems Software
Martin Marietta Corporation

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP Sockets: Mid-level Flow Desc Req.
Date: 27 Jan 1994 23:14:25 GMT
From: hjb@dhokkaebi.wpd.sgi.com (Hwa-jin Bae)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Message-ID: <HJB.94Jan27151425@dhokkaebi.wpd.sgi.com>
References: <9401251555.AA14369@apljax.jhuapl.edu>

In article <9401251555.AA14369@apljax.jhuapl.edu> bdoerr@apljax.jhuapl.edu (Bryan S. Doerr) writes:

>	   I'm trying to obtain information on how TCP/IP sockets are
>   implemented in vxworks.  Specifically, what kind of copies, buffering,
>   context changes etc occur during the transmission of a data buffer
>   from micro to micro.  I'm sure the answer involves knowledge of
>   not only TCP/IP as described in an RFC but also the bp driver used
>   by WRS.  Also, didn't WRS incoporate some optimizations between 5.1
>   and 5.0 ( or was it 5.0 and 4.x). Does BSD "tahoe" release play a 
>   part in this question or its answer?

vxworks tcp/ip in 5.x is a direct port of bsd tahoe release.
the optimizations occurred between 4.x and 5.0 are significant:
they include things like addtion of cluster mbuf, optimization
of various network drivers to perform buffer-loaning (avoids 
expensive copying of data), socket level recoding for more
efficient user interface, recoding of checksum routines, etc.
the buffer-loaning stuff was taken out by wind river since i left
due to misunderstanding by other engineers, and i believe they'll
be put back in soon, since they provide maximum bang for the buck
in the whole optimization scheme.  vxworks tcp/ip stuff could
use some serious updates and tuning again...
but i'm not sure of wrs's plans.

>	   The level of detail that I'd like is more than just "you put the 
>   data in here and it comes out here", but less than "and then this 
>   bit, in this packet is toggled, followed by a 100ms timeout ...).
>   Kind of a Mid-level description.

this kind of information is not readily available.  it's prolly only
available in source code format.  when in doubt read the bsd tahoe code.
bulk of the protocol code is essentially the same inside vxworks.
alternative is to pay big bucks to get wrs's modified version of
network code.  if you ask some specific questions on the net, you
have a good chance of getting them answered.  unfortunately, there
is no "cookbook" on this stuff as you might need.

>	   I checked the FAQ for a WRS App Note.  Does anybody have any
>   other references.  If the BSD socket implementation is still current,
>   I'll read the RFC and a UNIX book for that part of the question.  Does
>   anyone have the appropriate RFC number?  How about documentation on the 
>   bp driver implementation. Regarding the bp driver, I know the very basics
>   like shared memory on proc 0, carved up for each CPU, mailboxes or some
>   other interrupt telling the CPU there is data (or polled).  What happens
>   before and after this part is the core of my question. 

the socket interface is compatible with almost all other bsd based
implementations.  some companies ship net2 based tcp/ip sockets, with
the new socket address scheme, but all that stuff is essentially done
transparently, so it's no problem as long as you recompile for those
machines.

>	   BTW, I'm trying to learn what the user can do to optimize socket
>   operation by making intelligent choices on buffer size, data timeout,
>   etc.  I'm hoping this infomation will give me the background that I 
>   need.  Sorry for the wordy description.

a reasonable thing to do is to experiment.  i have found that experimenting
with different buffer sizes can result in widely varied througput
measurements.  try different ones and find the one that fits your 
requirement.  

unless you're willing to modify/enhance vxworks network code, that's 
probably all you can do to improve your performance.

hwajin
PEACEFUL STAR

---------------------------

End of New-News digest
**********************

From WELCH@asd1.jsc.nasa.gov  Fri Jan 28 10:47:36 1994
From: WELCH@asd1.jsc.nasa.gov
Date: Fri Jan 28 10:47:44 PST 1994
Subject: Re: VxWorks in Space

In article <1994Jan26.121351.1185@nrlvx1.nrl.navy.mil>,
cacciaglia@nrlvx1.nrl.navy.mil writes... 
>1. I am interested in hearing from other users of VxWorks which 
>have or are planning to use in space based applications.  In 
>particular error recovery and fault tolerance. 
> 
We will be using VxWorks on the Space Shuttle Mass Memory Unit (MMU) project
here at JSC.  The redesigned MMU is based on a standard VME architecture using
a custom rad-tolerant 68020 based CPU board.  We are ready to fabricate the
prototype of the CPU board and will be porting VxWorks in the not to distant
future.  We have taken some pretty intresting approaches to memory scrubing and
health monitoring.  We have also implemented a "sleep" mode which provides
for low power consumption during periods of inactivity. 

I would be happy to exchange information and experiences.

Tim Welch	welch@asd1.jsc.nasa.gov
Lockheed Engineering & Sciences Co.
Houston, Tx.77058
713-333-7769  

From lou@nova.arc.nasa.gov  Fri Jan 28 12:15:43 1994
From: lou@nova.arc.nasa.gov (Lou's Work)
Date: Fri Jan 28 12:15:51 PST 1994
Subject: Error Recovery and Fault Tolerance

I am presently working on a large wind-tunnel project and am interested
in hearing from other VxWorks users on available algorithms or code
concerning error recovery and fault tolerance.

I too would be happy to exchange experiences in both VxWorks, SunOS,
SGI IRIX, or Unix in general.

Did I say both? Oops.

Lou Bangert	lou@nova.arc.nasa.gov
(415) 604-1309
(415) 604-0563

From ioinc.tucson.az.us!sarge%ioinc.UUCP@noao.edu  Fri Jan 28 15:38:24 1994
From: sarge@ioinc.tucson.az.us (Tom Sargent)
Date: Fri Jan 28 15:38:38 PST 1994
Subject: programming position
        My company is looking for a programmer with experience in some
subset of the following:  Unix, VxWorks, pSOS, VRTX, writing hardware
diagnostics, networks and telecommunications.

        We are a small VMEbus board level design and manufacturing company
with a site in Tucson, AZ and a site in San Diego, CA.  Our products
include CPU cards (Motorola family microprocessors and soon PowerPC) with a
wide variety daughter card modules which add SCSI, Ethernet, serial,
parallel and various custom I/O capabilities to the CPUs.

        
_____________________________________
--- Tom Sargent, Synergy Microsystems/Io,  Tucson, AZ

From daemon@vxw.ee.lbl.gov  Sat Jan 29 04:01:13 1994
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 29 04:01:27 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 29 04:01:03 PST 1994

        Subject: Re: WRS is listening
        Subject: Re: Way to tell time since boot
        Subject: Re: GCC MIPS Tool Chain
        Subject: Re: port of vxWorks to multiple custom boards
        Subject: Re: Spurious Interrupt:  What is it?
        Subject: TCP/IP recovery
        Subject: vxWorks Shell Metqlanguage availability
        Subject: Multicast under vxWorks?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: WRS is listening
Date: Fri, 28 Jan 1994 16:13:15 GMT
From: geger@phantom.den.mmc.com (George Eger (303) 971-6974)
Organization: Martin Marietta Astronautics Group
Message-ID: <1994Jan28.161315.21494@den.mmc.com>
References:  <9401271633.AA05298@maureen.VisiCom.COM>
Sender: news@den.mmc.com (News Admin)

In article <9401271633.AA05298@maureen.VisiCom.COM>, Mike Trest <trest@visicom.com> writes:
|> 
|> As both a major consumer of VxWorks and as a Value Added Reseller 
|> of WRS products, we are aware of the increasing price sensitivity 
|> in the RTOS marketplace.  We are also aware of the growing technical
|> awareness of the RTOS customer and their demands for *MORE* in every
|> aspect of hardware and software products.
|> 

I recently got some info from DDC-I about a new C++ RTOS that they are 
introducing.  What struck me as very interesting was the pricing.  The
cost of the development system (sans compiler, they resell the
Microtek and don't currently have a GNU option) starts at $5K.  For $10K,
you get 10 seats.  This is reasonable; the run time target licenses are
cheap - starting at $50 for onesies going to $15 in volume.  Source code
for the run time kernel is $15K.

If WRS is listening, I think they should consider they might be missing 
out by charging 10x more for the RTL's.  IMHO, I think they'd get a
lot more volume with relatively little support cost by expanding the number
of targets their kernel is running on with cheaper pricing.

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Integ. Fault Tolerant Avionics  ||   Fax   - (303) - 977 - 1145         ||
||Space Launch Systems            ||   MS T320                            ||
||Martin Marietta Astronautics    ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Way to tell time since boot
Date: 28 Jan 1994 13:32:00 -0500
From: realtime@access2.digex.net (REAL TIME Corporation)
Organization: Express Access Online Communications, Greenbelt, MD USA
Message-ID: <2ibln0$ja9@access2.digex.net>
References: <9401220335.AA04445@marauder.is.ceco.com>

In article <9401220335.AA04445@marauder.is.ceco.com>,
Kevin R. Rumbaugh <kevinr@photon.ceco.com> wrote:
>
>I have thought several times that I would like some way to be able 
>to either query a board or at least figure out from the shell, how
>long a board running VxWorks has been 'up'.  Has anyone else
>thought about this and implemented something along these lines,
>particularly for MVME1[46]7's?  Does someone know of someway
>to extract this information from the 'kernel'?  It does not
>necessarily have to be time, but simply some indication of
>how long it has been since the board was booted.  If I could
>find someway to get the information it should be relatively
>easy to port the rstatd rpc code to send back the data to
>a remote requester.  Any help would be appreciated.

On a 68xxx cpu card you can do the following:

1. Assign one of the interrupt vector spaces to TicksSinceBoot
   (you may use any other global address which you find appropriate).
2. At boot time, clear that address to zero.
3. Each time the clock interrupts, increment that vector space
   by 1. hopefully the 32 bit value is long enough to cover
   more than the time between consecutive boots. If not, then
   use 2 vectors (64 bits). this will cost you more time
   on every clock interrupt.
4. Since the vector space is a well known address, any routine
   can get access to it, and read the value of TicksSinceBoot.

I am assuming that you have source for the clock interrupt routine.

If you do not have the source for the clock interrupt routine, then 
replace the clock vector with the address of your own routine 
and save the original routine address. do step #3 above and then 
call the original clock interrupt routine (the one that you do not have 
source for). At the end of that original routine you will have to
replace a "return from interrupt" instruction with the "return from
subroutine" instruction, since you want to return to *your* modified
clock interrupt routine. 

Naomi Avigdor

realtime@access.digex.net

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC MIPS Tool Chain
Date: 28 Jan 94 19:29:11 GMT
From: wesw@fog.WV.TEK.COM (Wes Whitnah)
Organization: Network Displays Division
Message-ID: <4544@shaman.wv.tek.com>
References: <9401271728.AA04022@helios> <BRADLEY.94Jan27122828@gaia.den.mmc.com>
Reply-To: wesw@orca.WV.TEK.COM
Sender: news@shaman.wv.tek.com

   For those who asked, and those with an interest:

   GNU fully supported MIPS processors since their 2.0 release, and it
   is integrated into their current environment.  We've found the binaries
   generated to be comperable to (and sometimes better than) the MIPS
   compilers for our code.  The last time we compared the two was last year,
   just before we got rid of our last MIPS host.  It would be best to compile
   your code with both compilers and compare the two in size and performance
   for yourself.

   Using GNU is not necessarily a piece of cake.  You have to build and
   maintain the whole works on your own.  However, I've found it preferable 
   to dealing with MIPS on compiler issues.

   You will need the following sources, which can be found at most archive
   sites (we usually get them from prep.ai.mit.edu in the pub/gnu directory):
	gcc-2.5.8.tar.gz	(We are using 2.5.7 with a patch.  This
				 version should include the patch, but we
				 haven't tried it.)
	gas-2.2.tar.gz
	binutils-2.3.tar.gz
	gdb-4.11.tar.gz

   Unpack the whole works and follow the instructions given on configuring
   for your host and target processors.

   A few caveats:

    1) We first used VxWorks with the TI34020, whose tools only supported COFF
       output, so we made our own COFF downloader as WRS did not have one at the
       time (TI tools required preservation of sections that the a.out converter
       would strip out).  When we added MIPS processors we used the native COFF
       output of their tools as well, and continued this with GNU.  I'm unsure
       of whether WRS now provides a COFF loader or whether they still use an
       a.out converter.  If you don't need the extra sections, then the WRS
       converter should work fine.  I've heard the GNU linker can take MIPS
       objects and produce a.out directly, but we've not tried it.

    2) GNU does not supply (to my knowledge) a soft-float library for MIPS,
       so if you need one, you'll need to find one elsewhere.

    3) We've put a lot of effort into the GNU environment over the years,
       so I've probably forgotten something else that you need to do which
       is different from a vanilla WRS VxWorks release.  Perhaps now that
       WRS seems interested, they can help fill in the gaps in a future
       release ;-).

   Wes Whitnah
   wesw@orca.wv.tek.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: 28 Jan 94 21:09:59 GMT
From: wa137@sdcc12.ucsd.edu (john e. clark)
Organization: University of California, San Diego
Message-ID: <60337@sdcc12.ucsd.edu>
References: <geoff.759614388@wrs.com> <chris.759642320@wrs.com>
Sender: news@sdcc12.ucsd.edu

In article <chris.759642320@wrs.com> chris@wrs.com (Chris Ford) writes:
+
+Hello, regarding problems encountered when installing 3rd party BSPs...
+
+Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks
+5.1.x that will not clobber other BSPs when installed.  To be assured
+that 3rd party VxWorks BSPs meet Wind River standards, insist that their
+BSPs are validated by Wind River.  (BSP validation is a service offered
+to VxWorks BSP Porting Kit customers).

And how much does this 'service' cost? FreeBSD has better 'machine'
separation than WRS's Porting Kits. What's more FreeBSD is more likely
to have posix compliance if someone bothered to take the time to do
so than WRS's kernel may ever have. What's more FreeBSD has
identical libc.a compatability than WRS may have at any time.

Unix file system? Well, which varient, but again FreeBSD has it now,
just a matter of porting it to the WRS environment.

What is the point? The point is that as WRS has tightned up on 'free
support' for BSP  providers, other packages become more attractive
in terms of porting. If it is just as much hassle to port a BSD
derivative, and get just as much support, ie. none, then other than
customers demanding the WRS products, there's no basic reason for
choosing WRS product over some other alternative.

Customer's of RTOS products can be 'educated' in directions not
sympathetic to WRS products just as easily as towards WRS products.
At current WRS prices, there are several competitors which can give
the same performance, give 'unix file system' support, and have
POSIX compliance. Where can WRS make the difference?

1) Has longevity in the market place gives lots of real world
experience.
2) Needs current competative pricing on development packages. Everyone
knowns that Cygnus is the porting house for the development tools.

3) Needs stand on you head customer support, including BSP providors if
they are considered 'customers' (see above quote).

4) Needs to realize that as there are more RTOS customers there are more RTOS
providers and the attitude that 'we're the only ones in town' must
change.

A few years ago the sales pitch of 'we've got libc.a compatibility'
may have sold a few, but now that's done by everone.  DOS file system???
RT-11??? I've written 2 file system packages for both of these as well.
This of course was back in the stone age and the machines were advanced
abaci. WRS could possible make use of 'the thundering HURD' file system.
But they seem more inclined to tighten up on products than go for
the gusto. (Shared memory?? Again present in other RTOS's for
several years in one form or another, MMU support, Virtual Memory??
Again these have been found elsewhere).

The main reason that many companies do not use the 'free' packages,
if they know of them at all, is the cost to port and support. However,
WRS has in some cases given less support, in my opinion, than these
packages which only have USENET as their support agency.
- -- 

John Clark
wa137@sdcc12.ucsd.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Spurious Interrupt:  What is it?
Date: Thu, 27 Jan 1994 14:12:41 GMT
From: edski@phx.mcd.mot.com (Ed Skinner)
Organization: Motorola Computer Group, Tempe, Az.
Message-ID: <1994Jan27.141241.27336@phx.mcd.mot.com>
References: <9401241519.AA04066@tadpole.tadpole.com> <hjbCK82wH.Dv2@netcom.com>
Sender: news@phx.mcd.mot.com

     Spurious Interrupts may also be seen when the hardware is pushed
outside the normal bounds of operation, such as when the VMEbus is
mega-stressed with work and the MPU is unable to initiate the IACK
cycle for an extended period.  In such situations, the MPU's request
to acquire the bus in order to do the IACK may take too long and an
on-board "bus acquisition" timer may pop.  Also, in some cases the
interrupting device may suffer strange aberrations when its request
is not acknowledged for an extended period and, among other things,
simply forget that it was requesting an interrupt.  A "Spurious
Interrupt" is seen in either case by the responding MPU.
     These situations are outside the bounds of what we would consider
normal operation.  Unfortunately, contemporary designs with lots of
processors and shared RAM makes for very busy busses, and long delays
in acquiring the bus are more and more common.  In the extreme these
cause Bus Errors (68K), Data Access Exceptions (88K), and spurious
interrupts, all of which may be due to bus acquisition time-outs, may
occur.
     The telling clue in all cases is that the failing operation "SHOULD"
have been successful.  That is, the Bus Error or Data Access Exception is
to an address that "SHOULD" have be legitimate.  The time-out on the IACK
is more difficult to detect.  Many board designs will "latch" some status
about the origin of the exception.  In particular a bus-acquisition time-
out should be high on the list of "things to check."
- -- 
#include <disclaimer.h>
Ed Skinner, Customer Education Services, Motorola Inc., USA(602)438-3956
Internet: edski@phx.mcd.mot.com

---------------------------

Newsgroups: comp.os.vxworks
Subject: TCP/IP recovery
Date: Fri, 28 Jan 1994 22:46:44 GMT
From: sterrett@manta.nosc.mil (Anthony E. Sterrett)
Organization: NCCOSC RDT&E Division, San Diego, CA
Message-ID: <1994Jan28.224644.4292@nosc.mil>
Sender: news@nosc.mil

Hi y'all

I'm work on some client/server routine and my client
needs the ability to recover the connection.

My approach is first I setsockopt with SO_REUSEADDR
so I can reuse the port. Next I close the ofending socket po
1. I setsockopt with SO_REUSEADDR so I can reuse the port.
2. close the socket number .
3. Reopen, rebind. successfully.
4. attempt to reconnect using connect
	The attempt to connect fails. 

Does anybody know how to recover the connect. 
Tony NRaD

---------------------------

Newsgroups: comp.os.vxworks
Subject: vxWorks Shell Metqlanguage availability
Date: Fri, 28 Jan 1994 22:51:33 GMT
From: doug@neopath.wa.com (Doug Carlton)
Organization: NeoPath Inc.
Message-ID: <1994Jan28.225133.4354@neopath.wa.com>
Reply-To: doug@neopath.wa.com
Sender: news@neopath.wa.com

I am interested in finding some third-party tools to help
us in testing (V&V) our vxWorks 5.0.2 application.

Is there a commercially produced (and tested) version of the
public domain vxRsh remote shell execution program?

Is there a vxWorks shell metalanguage available? Something like
tcl??

Your time and consideration are appreciated.

- ---
+-------------------------------+--------------------------------------+
| Doug Carlton                  | If everyone is a victim who are      +
| doug@neopath.wa.com           | the perpetrators?????                +
|                               +--------------------------------------+
| (206) 455-5932                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

---------------------------

Newsgroups: comp.os.vxworks
Subject: Multicast under vxWorks?
Date: Thu, 27 Jan 94 22:54:19 GMT
From: mcdowell@exlogcorp.exlog.com (Steve McDowell)
Organization: Baker Hughes INTEQ, Inc.
Message-ID: <1994Jan27.225419.21221@exlog.com>
Sender: mcdowell@exlog.com (Steve McDowell)

Is anyone aware of any available software to support IP multicast
(as described in RFC-1054) under vxWorks? 

I'm interested in a port for either 5.1 or 5.1.1 on either 
Force sun[2,3]ce or cpu-30 boards..

Thanks in advance.

- -- 
Steve McDowell			
Baker Hughes INTEQ, Inc.		bzero(brain_buffer, sizeof(brain));
Houston, Texas USA		 		
	

---------------------------

End of New-News digest
**********************

From rayssd!ssd.ray.com!fjr@uunet.uu.net  Sat Jan 29 22:22:20 1994
From: "Fred J. Roeber" <fjr@ssd.ray.com>
Date: Sat Jan 29 22:22:29 PST 1994
Subject: Re:  VxWorks networking
Bryn Doehr asked about details on the VxWorks networking and how
to improve performance.  As Hwa-Jin Bae mentioned, the WRS code is
very similar to the standard BSD Tahoe networking code.  For insight
into how the code works, a good reference is "The Design and Implementation
of 4.3BSD UNIX" by Leffler and others.  This book is one of the leading
references on UNIX design issues.  Chapter 11 in particular has a lot
of information on the networking implementation.  Of course, to get
much better throughput out of the networking code, one of the best
solutions is to bypass a lot of it by using the raw ethernet input
protocol input hook to look at the raw input data.  Doing this has
been discussed in this forum before in the not to distant past so
I won't go into more depth.  Fred

   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 177                  |
   |  Portsmouth, RI  02871-1087  (401) 842-4205           |
   |                   fjr@ssd.ray.com                     |

From daemon@vxw.ee.lbl.gov  Sun Jan 30 04:01:37 1994
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 30 04:01:45 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 30 04:01:28 PST 1994

        Subject: Is select () interruptible?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Is select () interruptible?
Date: 29 Jan 94 21:07:45 MST
From: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore)
Message-ID: <1994Jan29.210748.27028@hellgate.utah.edu>
Reply-To: moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore)

I've set up a loop around a call to select.  The last argument to
select () is  0 i.e., wait forever.

I've also set up an interval timer that is delivering a SIGALRM every
15th of a second.  The call to select () never returns.

Is this the expected behavior under VxWorks?  Under Unix, select ()
would return EINTR after the SIGALRM was handled.

- -- 
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush

---------------------------

End of New-News digest
**********************

From leonid@rst.hellnet.org  Sun Jan 30 06:40:09 1994
From: leonid@rst.hellnet.org (Leonid Rosenboim)
Date: Sun Jan 30 06:40:20 PST 1994
Subject: Re: Is select () interruptible?
Dear fellow networkers, please try to specify your VxWorks version
and relevant hardware configuration to avoid ambiguities.

>I've also set up an interval timer that is delivering a SIGALRM every
>15th of a second.  The call to select () never returns.
>
>Is this the expected behavior under VxWorks?  Under Unix, select ()
>would return EINTR after the SIGALRM was handled.

Under VxWorks 5.0.x, signals do not interrupt system calls, including
select().

In VxWorks 5.1.x however, this has changed, a signal can happen anytime
and will interrupt a system call, be it read() or select(), but the
signal handler has to decide how to continue, if the signal handler
returns, the task will resume into the system call, i.e. will go on
waiting. If that is not desired, the signal handler has to perform a longjmp()
to a know point where it will contiue execution abandoning that system call.

Please note that select() is implemented with a semaphore, this
means that a signal will interrupt a task waiting for a semaphore,
or message queue too.

-----------------------------------------------------------------------
Leonid Rosenboim                           Phone: +972-3-67-00-321
R S T  Software Industries Ltd.            Fax:   +972-3-67-24-498
P.O.Box 8077, Ramat-Gan 52180, Israel      E-Mail: leonid@RST.HellNet.Org

From moore@defmacro.cs.utah.edu  Sun Jan 30 10:06:24 1994
From: moore@defmacro.cs.utah.edu (Timothy B. Moore)
Date: Sun Jan 30 10:06:33 PST 1994
Subject: Re: Is select () interruptible?
Thanks.  I am using VxWorks 5.1.  Your longjmp () solution is what I
had determined I needed to do.

Tim

From daemon@vxw.ee.lbl.gov  Mon Jan 31 04:01:47 1994
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 31 04:01:59 PST 1994
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 31 04:01:37 PST 1994

        Subject: Re: Is select () interruptible?
        Subject: Re: WRS is listening
        Subject: Re: GCC MIPS Tool Chain
        Subject: Re: Multicast under vxWorks?
        Subject: Re: TCP/IP recovery
        Subject: Re: socket ioctl?
        Subject: Re: Modems and/or DES on VME
        Subject: Re: port of vxWorks to multiple custom boards

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Is select () interruptible?
Date: Mon, 31 Jan 1994 01:37:42 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH0Iu.HyM@netcom.com>
References: <1994Jan29.210748.27028@hellgate.utah.edu>

In article <1994Jan29.210748.27028@hellgate.utah.edu> moore%defmacro.cs.utah.edu@cs.utah.edu (Tim Moore) writes:
>
>I've set up a loop around a call to select.  The last argument to
>select () is  0 i.e., wait forever.
>
>I've also set up an interval timer that is delivering a SIGALRM every
>15th of a second.  The call to select () never returns.
>
>Is this the expected behavior under VxWorks?  Under Unix, select ()
>would return EINTR after the SIGALRM was handled.

this is the expected behavior under vxworks and this behavior is not
compatible with unix.  in general, vxworks signal and system call
facilities do not support call restart as in SA_INTERRUPT, SV_INTERRUPT
in unix/posix.  vxworks does not really use the concept of system calls
as in the other operating systems which use trap based system call
interface.  and although some facilities in vxworks are hacke up
to support some support for "restart", almost all system functions
are not aware of such facilities.  vxworks system calls (functions)
are just normal C functions -- think of vxworks as just a glorified
C program, where system calls (like select()) are  subroutines
inside the program (rather than a unix-or-other-realtime-os-like
trap-based system calls).

hwajin

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: WRS is listening
Date: Mon, 31 Jan 1994 01:45:24 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH0vo.Ip5@netcom.com>
References: <9401271633.AA05298@maureen.VisiCom.COM> <1994Jan28.161315.21494@den.mmc.com>

In article <1994Jan28.161315.21494@den.mmc.com> geger@phantom.den.mmc.com (George Eger (303) 971-6974) writes:
>
>If WRS is listening, I think they should consider they might be missing 
>out by charging 10x more for the RTL's.  IMHO, I think they'd get a
>lot more volume with relatively little support cost by expanding the number
>of targets their kernel is running on with cheaper pricing.
>

wrs is only able to charge as much as what they charge because there
seem to be enough military contractors, large corporations, government
subsidized laboratories and eductional institutions with big bucks to spend.

it's all economics and matter of momentum.  if you can get away with
current pricing scheme why bother changing it?

in the mean time, there are many other operating systems with similar
feature-sets as vxworks selling for much less bucks.  i doubt wind river
will change their pricing and marketing strategy unless they're forced
to do so by competition.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC MIPS Tool Chain
Date: Mon, 31 Jan 1994 01:47:11 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH0yo.Iu6@netcom.com>
References: <9401271728.AA04022@helios> <BRADLEY.94Jan27122828@gaia.den.mmc.com> <4544@shaman.wv.tek.com>

In article <4544@shaman.wv.tek.com> wesw@orca.WV.TEK.COM writes:
>
>   GNU fully supported MIPS processors since their 2.0 release, and it
>   is integrated into their current environment.  We've found the binaries
>   generated to be comperable to (and sometimes better than) the MIPS
>   compilers for our code.  The last time we compared the two was last year,
>   just before we got rid of our last MIPS host.  It would be best to compile
>   your code with both compilers and compare the two in size and performance
>   for yourself.

we all believe this.  anything else is just marketing b.s.
as they say, wind river "is listening". bravo!

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Multicast under vxWorks?
Date: Mon, 31 Jan 1994 01:48:30 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH10v.J04@netcom.com>
References: <1994Jan27.225419.21221@exlog.com>

In article <1994Jan27.225419.21221@exlog.com> mcdowell@exlogcorp.exlog.com (Steve McDowell) writes:
>
>Is anyone aware of any available software to support IP multicast
>(as described in RFC-1054) under vxWorks? 

the work involved in supporting this in vxworks is so trivial that
it boggles minds to realize that wrs has not done so for the past
several years...

hopefully they're listening... or better yet doing something about it.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP/IP recovery
Date: Mon, 31 Jan 1994 01:49:52 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH135.J4r@netcom.com>
References: <1994Jan28.224644.4292@nosc.mil>

In article <1994Jan28.224644.4292@nosc.mil> sterrett@manta.nosc.mil (Anthony E. Sterrett) writes:
>
>My approach is first I setsockopt with SO_REUSEADDR
>so I can reuse the port. Next I close the ofending socket po
>1. I setsockopt with SO_REUSEADDR so I can reuse the port.
>2. close the socket number .
>3. Reopen, rebind. successfully.
>4. attempt to reconnect using connect
>	The attempt to connect fails. 
>

make sure the other end is accepting for new connections at this point.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: socket ioctl?
Date: Mon, 31 Jan 1994 01:54:23 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH1Ap.JGv@netcom.com>
References: <2hlm5j$b9v@mail.fwi.uva.nl>

In article <2hlm5j$b9v@mail.fwi.uva.nl> smagt@fwi.uva.nl (Patrick van der Smagt) writes:
>HI!
>
>I'm trying to port my SYSV/BSD socket code to VxWorks.  I encountered
>a problem with raising signals on socket input, which can be done
>using
>
>#if SYSV
>  if (ioctl(d_learn_socket, I_SETSIG, S_RDNORM|S_INPUT))
>  {
>        perror("setup_learn ioctl()");
>        panic_exit();
>  }
>#elif BSD
>  if (fcntl(d_learn_socket, F_SETOWN, getpid()) == -1)
>  {
>        perror("fcntl F_SETOWN");
>        panic_exit();
>  }
>  if (fcntl(d_learn_socket, F_SETFL, FASYNC) == -1)
>  {
>        perror("fcntl F_SETFL");
>        panic_exit();
>  }
>#endif
>
>
>However, VxWorks doesn't know fcntl nor I_SETSIG (I'm running
>VxWorks 5.0.2).  Is there a solution to this problem?
>

you can't do this in vxworks 5.0.2, or later releases for that matter..
wind river is hopefully listening and fixing this problem in their
future posix-smart releases.  in general, in currently released
versions of vxworks, doing simple unix compatible things may work
for you, but if you start doing tricky things assuming that vxworks
is somehow compatible with posix or unix, you're wasting your time.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Modems and/or DES on VME
Date: Mon, 31 Jan 1994 01:57:07 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH1F8.JuJ@netcom.com>
References: <9401201711.AA01036@helios>

In article <9401201711.AA01036@helios> mea@mclean.sparta.com (Mike Anderson) writes:
>
>  On a separate, yet related, topic, does anyone have information of 
>anyone who has implemented a VME board that supports DES (Data Encryption 
>Standard) either in hardware?  I have software versions of the algorithms,
>but was looking for hardware to take the load off my VxWorks systems.

if you're not married to VME, you might be able to talk to hybrid networks,
inc. in cupertino, california.  we implemented a wireless 10mbit/sec RF
ethernet emulation in Sbus/SS1, part of which included a DES (and other
downloaded encryption) in hardware.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: port of vxWorks to multiple custom boards
Date: Mon, 31 Jan 1994 02:29:34 GMT
From: hjb@netcom.com (squeedy)
Organization: PEACEFUL STAR, Oakland, CA
Message-ID: <hjbCKH2xA.MIG@netcom.com>
References: <geoff.759614388@wrs.com> <chris.759642320@wrs.com> <60337@sdcc12.ucsd.edu>

In article <60337@sdcc12.ucsd.edu> wa137@sdcc12.ucsd.edu (john e. clark) writes:
>In article <chris.759642320@wrs.com> chris@wrs.com (Chris Ford) writes:
>+
>+Hello, regarding problems encountered when installing 3rd party BSPs...
>+
>+Using BSP Porting Kit 1.1 FCS, developers can create BSPs for VxWorks
>+5.1.x that will not clobber other BSPs when installed.  To be assured
>+that 3rd party VxWorks BSPs meet Wind River standards, insist that their
>+BSPs are validated by Wind River.  (BSP validation is a service offered
>+to VxWorks BSP Porting Kit customers).
>
>And how much does this 'service' cost? FreeBSD has better 'machine'
>separation than WRS's Porting Kits. What's more FreeBSD is more likely
>to have posix compliance if someone bothered to take the time to do
>so than WRS's kernel may ever have. What's more FreeBSD has
>identical libc.a compatability than WRS may have at any time.
>

w.r.t cost -- wrs is free to charge as much as they want.  market needs
to decide if their product is worth it.  i personally don't.  vxworks
is a fun, useful tool, but the price structure is ridiculous.  unless
you're a big-time government military contractor or rolling in dollar 
bills, i don't know how you'd justify the cost.  the vast majority
of the market seems to disagree with me -- they absolutely love it
and are willing to pay!  

w.r.t freebsd -- it's too big for a lot of work vxworks is being used for.
it is also not as scalable, has too much unix junk in it, hacked to
death by too many ...  code quality varies a lot.  the h.w. independence
layer is no better than vxworks.  in some ways vxworks is better.
in some ways freebsd wins.  but in terms of overall portability
vxworks wins hands down.  just look at the list of boards and architectures
vxworks runs on.  it takes a couple of days (max! by a competent programmer)
to bring up vxworks on a new board.

>Unix file system? Well, which varient, but again FreeBSD has it now,
>just a matter of porting it to the WRS environment.
>

so, go ahead and do it.
we'd all be very grateful.

>What is the point? The point is that as WRS has tightned up on 'free
>support' for BSP  providers, other packages become more attractive
>in terms of porting. If it is just as much hassle to port a BSD
>derivative, and get just as much support, ie. none, then other than
>customers demanding the WRS products, there's no basic reason for
>choosing WRS product over some other alternative.

freebsd and vxworks are very very different beasts.

>
>Customer's of RTOS products can be 'educated' in directions not
>sympathetic to WRS products just as easily as towards WRS products.
>At current WRS prices, there are several competitors which can give
>the same performance, give 'unix file system' support, and have
>POSIX compliance. Where can WRS make the difference?
>
>1) Has longevity in the market place gives lots of real world
>experience.

???

>2) Needs current competative pricing on development packages. Everyone
>knowns that Cygnus is the porting house for the development tools.

cygnus is kissing up to free software foundation's ass to make profit
out of free software phenomena.  i have nothing against them, except that
they don't seem to be too honest in their business practice --
they distribute their modified versions of gnuware to 
their customers way in advance than others -- 
which in my opinion is just a little greedy trick
to make money -- instead of putting up the modified code on the ftp sites
as soon as they're qualified enough to be released to their customers.
if it's all free, why play games?

gnu compiler stuff is great -- and by all means use them.  but
do not pay stupid amount of money.  you can always get it running
for nothing.

if you want to support gnu, give money direct to f.s.f.  if you don't
support gnu, use their compilers anyway, they're great.

>
>3) Needs stand on you head customer support, including BSP providors if
>they are considered 'customers' (see above quote).
>
>4) Needs to realize that as there are more RTOS customers there are more RTOS
>providers and the attitude that 'we're the only ones in town' must
>change.
>
>A few years ago the sales pitch of 'we've got libc.a compatibility'
>may have sold a few, but now that's done by everone.  DOS file system???
>RT-11??? I've written 2 file system packages for both of these as well.
>This of course was back in the stone age and the machines were advanced
>abaci. WRS could possible make use of 'the thundering HURD' file system.
>But they seem more inclined to tighten up on products than go for
>the gusto. (Shared memory?? Again present in other RTOS's for
>several years in one form or another, MMU support, Virtual Memory??
>Again these have been found elsewhere).
>

if you have these reasons, why use vxworks at all?  it puzzles me
that people buy vxworks, spend all that money and later complain
that it's not like unix...

it's just a glorified realtime monitor.  it's not unix.
do you really want all those features in your embedded system
that handled 500 mega bytes of input load per second and has
to be "on-time"?  it's insane to duplicate unix inside vxworks...
why not just use unix for unix's features and use vxworks for
what it provides?

or better yet, if you like intel architecture use QNX.

>The main reason that many companies do not use the 'free' packages,
>if they know of them at all, is the cost to port and support. However,
>WRS has in some cases given less support, in my opinion, than these
>packages which only have USENET as their support agency.
>

wind river support has gone thru its ups and downs ... more downs
recently.  they simply do not have enough knowledgable people answering
tech support questions...  they should go back to rotating development
engineers on techsupport duty (as in the good old days).  if there was
a single most important feature in vxworks in its early days, it was
this quality of support.  not there any more folks!  but your mileage may
vary.

---------------------------

End of New-News digest
**********************

From visicom!VisiCom.COM!trest@lbl.gov  Mon Jan 31 07:14:01 1994
From: Mike Trest <trest@visicom.com>
Date: Mon Jan 31 07:14:10 PST 1994
Subject: RTOS Professional Survey UPDATE
"My motivation was, and remains, to raise the level of understanding
of the career paths and opportunities available to the experienced
RTOS processional." ..mike..

In the first 15 days of the survey, I have received messages
from 10 new organizations and 107 individuals.  The response
from organizations on the previous mailings has been mostly like:

   "Keep my company's name in your distribution,
    we are looking for experieced RTOS professionals."

>From these comments, I think we are seeing a slight upward
trend in positions available (compared with 6 months ago).  
The need for RTOS Professionals is not shrinking, it is growing!

=======================================+++===============================
RECENT COMMENTS RECEIVED:
=======================================+++===============================
"There are no changes in the job description I just sent you. 
I do appreciate what you are doing.
. . .
"Mike,  this is quite a large job that you have carved out here.  
good luck.  I think it will really help in several areas.
. . . 
"Just out of curiosity, why the special interest in these three? Is
it personal? Why not, for instance, VRTX, which is more popular
than any of these?
. . .
[Ed. The announcement was sent to:
     vxwexplo@lbl.gov   (VxWorks users)
     psosuser@isi.com   (pSOS users)
     embed@synchro.com  (Embedded Systems users)
No particular priority or business interests motivated my 
exclusion of VRTX only my lack of knowledge about an
appropriate EMAIL service method.]
. . .
"Thanks for the service you provide!
I saw your notice via the pSOS mail list.
. . .
"Please STOP sending the distribution.  Thank you.
. . .
"This support for the profession is very commendable.
. . .
"Thank you for providing this service at no cost and with
no strings attached.  I can't imagine how much extra work
this must cost you.
. . .
"We received 3 reponses, of which we interviewed 2 and hired one
candidate that you referred to us.  
[Ed. I only pass along your EMAIL to those who have asked to
be put on the distribution list.]

=======================================+++===============================
If you want to participate, this is the way I will be working this cycle:
=======================================+++===============================

1. If you employ RTOS professionals in your organization, please EMAIL
me a simple description of your organization, your typical RTOS 
requirements, and how an interested individual may contact you.  

If you have current needs, please indicate.  If you have no current 
openings, please state "FOR INFORMATION ONLY" somewhere in your message.  
I encourage organizations to send me an EMAIL even if you do not have 
any current openings.

2. Ever EMAIL received in response to item 1, will be forwarded on
to a distribution list of individuals who express an intrest in
hearing about organization who employ RTOS professionals.

3. If any individual wants to be copied on EMAIL received, please
send me a message and I will put you on the distribution list.

4. Anyone on the distribution list who wants to contact any of
the oragnizations who send me EMAIL must do so directly.

5. I WILL NOT GIVE A COPY OF THE DISTRIBUTION LIST TO ANYONE.
Don't even ask.

6. I will provide a moderator/editor service for all messages
received.  I plan filter out flames and other meaningless messages
to keep the distribution list clean.

7. This is not an official function of VisiCom Laboratories, Inc.
I am acting as an individual.  However, VisiCom may, from time
to time, submit its own EMAIL which will, like other organizations
will be submitted to the dristribution list.

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
VisiCom Laboratories            Fax:   619 457 0888
10052 Mesa Ridge Court          San Diego, CA 92121
====================================================

From mea@mclean.sparta.com  Mon Jan 31 11:17:14 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 31 11:17:27 PST 1994
Subject: Re: Shared Memory Network
Hi Rajesh,

  Yes, my target is the hkv960.

Thanks,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From mea@mclean.sparta.com  Mon Jan 31 11:52:28 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 31 11:52:45 PST 1994
Subject: Re: Shared Memory Network

Hi Folks!

  Sorry for the mis-posting.

Regards,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From mea@mclean.sparta.com  Mon Jan 31 14:02:34 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 31 14:02:43 PST 1994
Subject: Re: shared backplane communications
Greetings!

>  
> Help!  We are running a sparc 2ce as a slot 0 controller running unix
> and an HK-MIPS V3500 in the same chassis running vxWorks.  My question is,
> how can i signal the sparc from the V3500 that data is available for the
> sparc to display?  I would also like to perform similar operations from the
> unix side to the vxWorks side.  Any help with this problem would be greatly
> appreciated!!
> 

Well, first you can get the VMEbus support patches from Force for the 2CE.
These patches will enable you to receive and generate interrupts via the
SPARC over VME.  Then you'll have to map some VMEbus physical memory into the 
SPARC's virtual memory (unless you want to move the data via Ethernet).
Once this is done, you'll have to write ISRs for both VxWorks and UNIX
to deal with the communications.  Pick a couple of interrupt levels (one
for the SPARC->HKV3500 and one for the return) and fire away.  Be forewarned,
however, the bus interface speed of the 2CE is not a stellar performer.  I've
seen numbers that barely push 3 MBytes per second with more realistic 
applications in the 1.5 MBytes/sec range.  The 3E (?) or the newer SPARC 10
flavor may be a better choice (Force assures me that these boards have a better 
bus interface).  Alternatively, use an SBus-VMEbus adapter with DMA from
either Perfomance Tech or Bit-3.  Even that route is faster than what I've
seen on the 2CE straight to the VME.

Hope this helps,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From mea@mclean.sparta.com  Mon Jan 31 14:34:31 1994
From: mea@mclean.sparta.com (Mike Anderson)
Date: Mon Jan 31 14:34:40 PST 1994
Subject: Re: Shared Memory Network
Greetings!

> Submitted-by: rodin33!wgsu13!jdeangcd@uunet.uu.net (Joe DeAngelo)
>  
> 
> I am using an MVME147 and a Cyclone i960 card in a VME rack.
> I am using the shared memory network between them, but the
> '147 card is a real-time controller which needs real-time 
> access to peripheral devices which are memory mapped into
> VME address space. We want the 147 card to be the only bus
> master in order to assure bus access.
> 	This requires the shared memory for the network, etc.
> to be on the cyclone card. We cannot get the sm network to 
> function in this configuration. Has anyone else tried to get
> this to work? (Anchor, etc. on other than CPU 0)???
> 	This has been called into Wind River, with little
> response.
> 

Part of the problem you're seeing is related to the fact that the Cyclone
card is based on a "little-endian" i960 whereas the 147 is "big-endian".
This means that the byte ordering is completely backwards between the
two boards.  0x12345678 from the 147 looks like 0x78563412 from the i960.
Now, I thought the Cyclone had a "bp" driver that dealt with the endianness
issues so 68ks and i960s could coexist.  But, I'm not sure if they have an
"sm" driver for 5.1.x flavors though.  If Cyclone does have a big-endian
"sm" driver, then you might have to either locate the sm backplane on the
147 or on a "neutral" board such as a regular VME memory board.  I can't
lay my hands on my Cyclone 960 manual presently, but you might want to 
check yours to see if the VME slave interface is big or little endian.

So much for my $.02,

===============================================================================
     __       Real-Time System Development, Integration, Training and Services
    //\\                                                                   
   //  \\     Mike Anderson  
  // /\ \\    Director, Real-Time Systems                         
 // /  \ \\   SPARTA, Inc.                  Voice   : (703) 448-0210 ext. 235 
//   \    \\  7926 Jones Branch Drive       FAX     : (703) 734-3323  
\\    \   //  Suite 900                     EMAIL   : mea@mclean.sparta.com 
 \\ \  / //   McLean, VA 22102              
  \\ \/ //                             "Software development is like making
   \\  //                               a baby... You can't make a baby in one
    \\//                                month by impregnating nine women.
     --  "Pride in Performance"         Some things just take time."
=============================================================================== 
                                      

From bwb@one.one.com  Mon Jan 31 15:19:12 1994
From: bwb@one.com (Bruce Baker)
Date: Mon Jan 31 15:19:24 PST 1994
Subject: X.25
Are there implementations of X.25 in VxWorks?  If so, I would appreciate some
technical product literature.  We are an OSI supplier and run our stack
over X.25 in other environments.  We received an inquiry about this
configuration for our VxWorks OSI product, but aren't familiar with the
available X.25 implementations.

Thanks.

--Bruce

======================================================================
Bruce W. Baker
Open Networks Engineering, Inc. (ONE)        Voice:     (313) 996-9900
777 E. Eisenhower Parkway, Suite 650         FAX:       (313) 996-9908
Ann Arbor, MI  48108                         Internet:  bwb@one.com
======================================================================

From sblachma@aoc.nrao.edu  Mon Jan 31 18:24:53 1994
From: Steve Blachman <sblachma@aoc.nrao.edu>
Date: Mon Jan 31 18:25:02 PST 1994
Subject: MVME-147 SCSI problem

We are using an MVME-147 computer with a Seagate WREN VII 1Gb disk on the
local SCSI bus.  Since we added two DAT tape drives, the SCSI drivers
occasionally hang forever in sbicProgBytesIn(), polling for a bit to be set
in the Western Digital SCSI controller (a bad real-time coding practice IMHP).

This hang does not (necessarily) occur on the first write, but may take
quite a while to happen.  It does not happen (is rare?) when the disk
is alone on the SCSI bus.  It happens when ANY other device is added to
the SCSI, even if it is powered down.  We are runing vxWorks 5.1.1, but we
do experience this under 5.0.2.

We can make it happen more (or less) frequently by swapping 147s.  It is also
more frequent if our output rate to disk is higher  We can write to a DAT
tape drive with no problems, but the data rates to DAT are lower, so maybe
we just haven't seen it.

The problem seems unimpressed by changes in overall SCSI cable length.

We think the bus is properly terminated.

A quick peek with a scope on the SCSI shows no obvious problems with voltage
levels or ringing.

Does anyone know if there is a problem with the SCSI port on the 147 or with
the WREN VII?  I have little experience with SCSI, is SCSI often flakey?

Thanks,
Steven Blachman

From bob@zeus.jupiter.com  Mon Jan 31 18:36:52 1994
From: Bob Schulman <bob@zeus.jupiter.com>
Date: Mon Jan 31 18:37:08 PST 1994
Subject: Re: GCC MIPS Tool Chain
Algorithmics of England sells a GCC-based set of tools which work well
for vxWorks cross-development. This set of tools includes a floating point
library.

They can be reached at
	dom@algor.co.uk
(That's mail to Dominic Sweetman, their President).

bob

From thor@thor.atd.ucar.edu  Mon Jan 31 23:00:20 1994
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Mon Jan 31 23:00:28 PST 1994
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 4020
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor        37126 Jun 12  1992 ansilib01
-rw-r--r--  1 thor        18913 Jun 12  1992 ansilib02
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6  1991 dhrystones01
-rw-r--r--  1 thor        19170 Apr  1  1993 dirlib01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         2453 Mar 10  1993 gcc+68040
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor        12086 Jan  7 14:42 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
-rw-r--r--  1 thor        10747 Nov  3 11:54 libg++-2.5-src.patch
lrwxrwxrwx  1 root           20 Jan 20 07:28 libg++-2.5.1-src.patch -> libg++-2.5-src.patch
lrwxrwxrwx  1 root           20 Jan 20 07:28 libg++-2.5.2-src.patch -> libg++-2.5-src.patch
-rw-r--r--  1 thor         1568 Nov  3 11:54 libgcc2-2.5.0.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.2.patch
lrwxrwxrwx  1 root           19 Jan 20 07:28 libgcc2-2.5.4.patch -> libgcc2-2.5.2.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.5.patch
-rw-r--r--  3 thor         1545 Nov  3 11:55 libgcc2-2.5.6.patch
lrwxrwxrwx  1 root           15 Jan 20 07:28 libio-2.5.1.patch -> libio-2.5.patch
lrwxrwxrwx  1 root           15 Jan 20 07:28 libio-2.5.2.patch -> libio-2.5.patch
-rw-r--r--  1 thor         1228 Dec 29 09:51 libio-2.5.patch
lrwxrwxrwx  1 root            6 Jan 20 07:28 libx11 -> libX11
-rw-r--r--  1 thor         3515 Mar 16  1993 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor       829713 Dec 17 08:10 ntpv3.1.tar.gz
-rw-r-----  1 thor      1010176 Nov  8 13:42 ntpv3.tar.gz
-rw-r--r--  1 thor         1082 Dec 14 09:09 objc.patch
-rw-r--r--  1 thor        19593 Dec  8 10:43 ping01
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Jan 20 07:28 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Jan 20 07:28 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        41196 Oct 16  1992 stevie01
-rw-r--r--  1 thor        35279 Oct 16  1992 stevie02
-rw-r--r--  1 thor        35278 Oct 16  1992 stevie03
-rw-r--r--  1 thor        35012 Oct 16  1992 stevie04
-rw-r--r--  1 thor        34502 Oct 16  1992 stevie05
-rw-r--r--  1 thor        37476 Oct 16  1992 stevie06
-rw-r--r--  1 thor        30073 Oct 16  1992 stevie07
-rw-r--r--  1 thor        31562 Oct 16  1992 stevie08
-rw-r--r--  1 thor        37360 Oct 16  1992 stevie09
-rw-r--r--  1 thor        20662 Oct 16  1992 stevie10
-rw-r--r--  1 thor        25717 Oct 16  1992 stevie11
-rw-r--r--  1 thor        28075 Oct 16  1992 stevie12
-rw-r--r--  1 thor        31852 Oct 16  1992 stevie13
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1  1992 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-rw-r--  1 root       416642 Jan  7 14:41 tclvx7.0v4.tar.gz
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        19912 Aug 27  1992 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor         5608 Dec  2  1992 veclist01
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22  1991 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22  1991 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22  1991 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22  1991 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22  1991 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22  1991 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22  1991 vwcurses07
-rw-r--r--  1 thor         5491 Dec  8 10:40 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16  1992 wdog_class