From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan Biocca) Subject: testing new exploder This is a test of the new vxworks exploder. From rmk@iss-ipc3.ssd.ray.com Xxx Oct x xx:xx:xx 1991 From: rmk@iss-ipc3.ssd.ray.com Subject: Scsi and/or Serial drivers Greetings, We are going to be adding SCSI and serial cards to our VME system that uses Radstone modules. Our current configuration is one of their dual-ethernet EMPP cards with a CPU3A 68030 processor. The SCSI and serial modules are "intelligent" cards which are controlled through a dual-port RAM. Commands are written into the dual-port memory, and the internal processor takes over and does what is necessary. When the command is complete, the module interrupts the processor back via a VME interrupt. We are trying to add this to VADSWorks 2.0, if that makes any difference. It's based on VxWorks 5.0 with enhancments. We've already done the ports to the EMPP and CPU3A modules. My question is, has anyone written a driver, either for SCSI or serial, that communicates with an "intelligent" module of this sort. Any help or pointers to sources would be appreciated. Thanks in advance. Rich ---------------------------------------------------------------------- * Rich Kulakowski * Raytheon Submarine Signal Division * * * 1847 West Main Road, Mail Stop 177 * * rmk@sgfb.ssd.ray.com * Portsmouth, RI 02871-1087 * * * (401) 847-8000 (X4210) * ---------------------------------------------------------------------- From wrs!yuba!carl@uunet.uu.net Xxx Oct x xx:xx:xx 1991 From: wrs!yuba!carl@uunet.uu.net (Carl Chesbrough) Subject: Re: Scsi and/or Serial drivers Rich, I have done a SCSI port to the Radstone SCSI-1 board for a customer in Michigan. I did this port as a consultant, before I joined WRS. The port was originally done to vxWorks 4.0.2, and then upgraded to 5.0. I am not sure if this would help, but it might be a starting point. I will make sure it is OK with my customer if I give you a copy if you are interested. Their target was a Sundstran (?) optical drive in a full MIL spec. system. Let me know if you are interested, -Carl C. Chesbrough Wind River Systems 1010 Atlantic Avenue Alameda, CA 94501 (510) 814-2157 From interf!atlas!argus!brackett@uunet.uu.net Xxx Oct x xx:xx:xx 1991 From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett) Subject: new expolder I liked the the old exploder better. The new exploder sends everything out with the same mail return address. If I want to respond personally to the sender I have to enter his address by hand. This only works if the user has given me his address (I see the Submitted by line in the header). Upon occasion I have had better luck with the return address than the address given by the user. I also keep track of things by the users address in my mailbox files. What's the deal guys? P.S. The request address is bogus! It just bounces back to the sender. ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |U. S. Naval Observatory |Voice:202 653 0945 | |34th and Massachusetts Ave. NW |FAX: 202 653 0941 | |Building 52 | | |Washington, DC 20392-5100 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan Biocca) Subject: New Exploder Thanks for the comments on the New Exploder, Todd. (He likes the old one better...) We can make the return address on the exploder anything you (the user group) wants. I set it up (it was an original requirement) so that a reply goes back to the exploder instead of the original author -- I think we want to see more of the conversation than just the original request. Todd was right about the vxwexplo-request adress -- it was crossed up in the changeover and has been fixed now. The submitted-by header line is one I made up -- it is determined by scanning the sender's message for one of the from lines -- it should be a pretty good address. Perhaps there is another better use of header lines that would improve things -- a reply-to or something along those lines. Alan K Biocca AKBiocca@lbl.gov From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: From and Reply exploder addresses I can add a reply-to address to the exploder output. What is the preference -- if I add this feature what should go in the 'from' vs the 'reply-to' addresses? 'Votes to vxwexplo-request@lbl.gov' Discussion to vxwexplo@lbl.gov Alan K Biocca From hebo@mbari.org Xxx Oct x xx:xx:xx 1991 From: hebo@mbari.org (Bob Herlien) Subject: Re: From and Reply exploder addresses > ********** > I can add a reply-to address to the exploder output. What is the preference -- > if I add this feature what should go in the 'from' vs the 'reply-to' > addresses? > > 'Votes to vxwexplo-request@lbl.gov' > > Discussion to vxwexplo@lbl.gov > I think that the 'reply-to' field should point to the originator of the message. For those messages in which a followup to the exploder is appropriate, it's easy to enter 'cc: vxwexplo@lbl.gov'. I remember that address. The converse is not true. For those messages in which a followup to the exploder is not appropriate, I don't want to manually enter the originator's address; I want 'r' to send the message directly to him/her. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From interf!atlas!argus!brackett@uunet.uu.net Xxx Oct x xx:xx:xx 1991 From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett) Subject: Re: From and Reply exploder addresses Ditto to Bob Herlien's comments. From mea@sparta.com (Mike Anderson) Xxx Oct x xx:xx:xx 1991 From: mea@sparta.com (Mike Anderson) Subject: Re: From and Reply exploder addresses I'm infavor of which ever line will allow Sun mailers and mailtool to get the sender's address when I say "reply to...". Mike Anderson "It is useless for sheep to pass resolutions in favor SPARTA, Inc. of vegetarianism while wolves remain of a different mea@sparta.com opinion." (703) 448-0210 William R. Inge, D.D. 1860-1954 From scotth@rocco.labs.tek.com Xxx Oct x xx:xx:xx 1991 From: scotth@rocco.labs.tek.com Subject: Re: From and Reply exploder addresses > Ditto to Bob Herlien's comments. > I feel exactly the opposite. It's often the case that a posted query causes me to say to myself "That's interesting, I wonder what the others will have to say." I usually don't have the answer but am interested. Not enough to ask the question in the first place, but curious and hoping to grab a useful tidbit when it comes by. If the return address is that of the submitter, then I'm forced to reply to the sender with "please post summary to the mailing list" or "did you get anything useful?". It's too easy to underestimate others' interest and reply only to the sender. Whichever is the easiest is what we'll all do, most of the time. If it's harder to reply to the list than to the individual, the list, in my opinion, will suffer. It's easier to judge that a reply should only be sent to an individual than it is that reply should be sent to the entire group. Therefore, I'd like to suggest that we err on the side of sending to the entire group. Like Bob says, it's easy to enter addresses. It sounds like it's a problem that postings don't carry their submitter's return address unless it's generated by the exploder as the return address. Is there any other way of propogating the return address, so that it would be easy to copy and paste into a "To: " string? This would eliminate the need to remember addresses. I want 'r' to send the message to the exploder. Scott Herzinger scotth@crl.labs.tek.com Computer Research Lab, Tektronix, Inc. PO Box 500 MS 50-662, Beaverton, OR 97077 From bard@ssd63.ssd.loral.com Xxx Oct x xx:xx:xx 1991 From: bard@ssd63.ssd.loral.com (James Woodyatt) Subject: Re: From and Reply exploder addresses I concur with Mr. Herzinger. I vote to leave the From: line pointing to the Exploder for the reasons he mentioned, and for the reason that it makes it easier for me to separate the mail from the Exploder from the rest of my mail -- I don't have to muck around with remembering subject lines. __________________________________________________________________ | | James Woodyatt VOICE: (415) 852-5429 | Space Systems/Loral (M/S G87) FAX: (415) 852-6286 | 3825 Fabian Way E-MAIL: bard@cutter.ssd.loral.com | Palo Alto, CA 9430 | From lapp@waterloo.hp.com Xxx Oct x xx:xx:xx 1991 From: lapp@waterloo.hp.com (Dave Lapp) Subject: Re: From and Reply exploder addresses I prefer 'reply' to send the message to the original poster not the list. I also feel that its pretty easy to 'cc' the list. (Its also what I'm used to with other lists which I'm on :-) Dave Lapp lapp@waterloo.hp.com From cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991 From: cruise@cfht.hawaii.edu (Bill Cruise) Subject: From and Reply exploder addresses I cast my vote to have the "From:" line point back to the exploder. Most of us do the easiest thing -- whatever our mailer does when we hit "r". If all replies go to the sender, all the exploder will be is a series of questions with no answers. Many of the replies are of general interest. If not, it is easy enough to get the sender's address and enter it in the reply, or in a new message. However, replying to the sender should be the exception. Bill Cruise Canada-France-Hawaii Telescope From jason@wrs.com Xxx Oct x xx:xx:xx 1991 From: jason@wrs.com (Jason Cotton) Subject: reply address My $.02: I suspect that for the majority of the exploder community, the convenience thing is over-rated. Both sunview and X allow one to quickly grab a snippet of text (e.g., the original sender's e-mail address) and paste it back as the destination address. Maybe I underestimate the number of users who work from terminals primarily. My own preference is for the reply-to to default to the Exploder. It's easier for me to delete mail that I'm not interested in than to ken the message of mail I never see. Also, I feel that we should be in the habit of thinking "Do I really have something meaningful to say on this issue?". Knowing that one's reply will be broadcast might eliminate some of the casual banter kinds of replies. Regarding the latest deluge of Exploder mail, I've seen several requests from people wishing to be unsubscribed. It appears that they mailed to the wrong address. Is this correct, or is the Exploder broadcasting mail that it should not be? Also, what is the function of the address "vxwexplo-list"? Is this an Exploder internal? Lastly, maybe we should conduct a vote (to a non-broadcasted address) on what the default reply-to should be. After 2-3 days, tally the votes, and in the finest US tradition, the majority rules... Sincerely, Jason Cotton (jason@wrs.com) p.S. Maybe the next generation mailers will have different reply commands for getting to the sender or the destination (not always strictly yourself). I wonder if there is some way to structure all of this so that the (g)roup reply command in elm could automatically broadcast back to the exploder, while the (r)eply command would just target the originator of the message. Of course, many people probably do not have or use elm. Sigh. From smb@afterlife.ncsc.mil Xxx Oct x xx:xx:xx 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Subject: Exploder vs. newsgroup I suggest that the exploder be ditched altogether. There's a wonderful Usenet news system out there that will allow you to easily either follow up to the news group or reply to the author. This mail exploder is hardly efficient, especially as the readership and volume continue to increase. Let's get into the 1990's. However, until then, can the 8 lines of advertisement be removed from exploded messages? Also, there are 2 "Error" lines in the header. Steve smb@afterlife.ncsc.mil From tweadon@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991 From: tweadon@lodestar.gb.nrao.edu (TIM WEADON) Subject: Re: From and Reply exploder addresses I like the exploder just the way it is! I never remember any address, whether it be the exploder or my own. I have often wanted to comment on a certain issue or wanted to get comments on other issues that cross the exploder. The way it was before was confusing, at least to me, as to "exactly" where do I send this reply to. Presently it is spelled out very clearly and the default reply goes to the exploder. I believe if it is asked on the exploder, taking up my time to get curious about it, then it should be answered on the exploder. Tim Weadon National Radio Astronomy Observatory (NRAO) P.O. Box 2 Green Bank, WV. 24944 304-456-2120 tweadon@nrao.edu From tweadon@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991 From: tweadon@lodestar.gb.nrao.edu (TIM WEADON) Subject: VxWorks Driver for the National Instruments 1014B GPIB VME card. I am looking for a software driver for the National Instruments 1014b GPIB card. I heard that David Lambert at SCC Laboratories has one available for the public. I don't have his proper e-mail address, if you have a driver for a GPIB card that would work in a 68030 system (mine is an mvme147s) or know David's e-mail could you let me know. Thank you Tim Weadon tweadon@nrao.edu 304-456-2120 From dwells@fits.cx.nrao.edu Xxx Oct x xx:xx:xx 1991 From: dwells@fits.cx.nrao.edu (Don Wells) Subject: Re: Exploder vs. newsgroup the vxWorks Users Group Exploder writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ People who want the From: line to point to the exploder should consider this absurdity which is produced by the default action of mail packages. The From: line _must_ point to the originator, the Reply-To: line is the only question which should be debated. The Sender: line should point to the exploder to direct error messages back to the owner of the exploder, not to originators. > I suggest that the exploder by ditched altogether. We need an exploder to support the people who don't have newsfeeds. > ... Usenet news system ... allow[s] ... either follow up to the > news group or reply to the author. I myself prefer news to exploders, and you have given one of the reasons. Because I monitor a wide range of subjects, a more important reason to prefer news is that it sorts the traffic into categories, and my newsreader uses those categories for default folder names. > This mail exploder is hardly efficient, > especially as the readership and volume continue to increase. Actually, exploders _are_ fairly efficient in terms of bandwidth. The VxWorks mailing list contains many entries which are mailing lists (e.g., the exploder sends one message to NRAO, where it explodes internally to a list of 15 individuals). In addition, smart mailers like sendmail notice when there is more than one person on a particular machine, and they only send one copy to the mailer daemon on the other machine. However, exploders are inefficient in terms of diskspace, because mail systems store a separate copy for each user, unlike news which has only one copy. Experience shows that exploders are hard to maintain when lists hit somewhere around 200 entries; this exploder is near to the limit right now. =-=-= I second the motion ! =-=-= I estimate that about 200 people are reading this traffic now, it might even be 300. My guess is that perhaps half of this readership have newsfeeds, and would use that means if given a chance. I also estimate that with this number of readers we could win under the requirements of the formal USENET voting procedure (100 more yes votes than no votes). I recommend that we create the newsgroup "comp.realtime.vxworks". I further recommend that a bi-directional gateway to the exploder be established so that people who don't have newsfeeds, or who don't like news, can still be full participants. Meanwhile, I suggest that those of you who have newsfeeds check out the "comp.realtime" newsgroup. Many articles in "comp.realtime" discuss VxWorks! I suspect that some of the authors of the articles are unaware of this exploder. Donald C. Wells Associate Scientist dwells@nrao.edu National Radio Astronomy Observatory +1-804-296-0277 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From hmp@frc2.frc.ri.cmu.edu Xxx Oct x xx:xx:xx 1991 From: hmp@frc2.frc.ri.cmu.edu Subject: Re: Exploder vs. newsgroup >I suggest that the exploder be ditched altogether. There's a wonderful Usenet >news system out there that will allow you to easily either follow up to the >news group or reply to the author. This mail exploder is hardly efficient, >especially as the readership and volume continue to increase. Let's get >into the 1990's. I agree that a newsgroup would be much more convenient for many, but there may be some that for some reason can not access the usenet news system. This was discussed a while back, and the word at the time was that the group wasn't quite large enough to warrant a newsgroup. Is this still the case? Also, I think there are some newsgroups, like gnu.gcc.*, that exist in parallel as a mailing list. Wouldn't that be the best of both worlds? >However, until then, can the 8 lines of advertisement be removed from >exploded messages? Also, there are 2 "Error" lines in the header. I agree. The extra header and footer lines surrounding exploder messages are, IMHO, distracting and unnecessary. -Henning From JZ01%swtexas.bitnet@Csa3.LBL.Gov Xxx Oct x xx:xx:xx 1991 From: JZ01%swtexas.bitnet@Csa3.LBL.Gov Subject: RE: VxWorks Driver for the National Instruments 1014B Labmert's e-mail address is: lambert@sscvx1.bitnet lambert@sscvx1.ssc.gov Janusz Zalewski From tadusa!tadtec!ma@uunet.uu.net Xxx Oct x xx:xx:xx 1991 From: tadusa!tadtec!ma@uunet.uu.net Subject: Reply address I vote for a vote ! I would vote for replies to the exploder, or alternatively... There could be one group for queries, and one for replies. The exploder would send replies to both the asker of the query, and the reply group. You could choose whether or not you wanted to subscribe to the reply group. Maybe this is a bit OTT ! Mark Armitage email: ma@tadtec.uucp Technical Projects Manager phone: +44 223 423030 Tadpole Technology plc fax: +44 223 420772 From voreck@ssd49.ssd.loral.com Xxx Oct x xx:xx:xx 1991 From: voreck@ssd49.ssd.loral.com (Rick Voreck) Subject: Re: From and Reply exploder addresses Hey, Fellow Explodees, In regards to how to mark return addresses on exploder messages, how about this little excerpt from the "man mail" page : Reply (R) Reply to originator. Does not reply to other recipients of the original message. reply (r) Takes a message list and sends mail to the sender and all recipients of the specified mes- sage. The default message must not be deleted. If I am not mistaken, this means that if we put the original message creator in the "From:" field and the exploder in the "cc:" field, then if you use "r" to respond (as I usually do and apparently most others, too) then the exploder will get a copy, the originator will get 2 copies (slight bug) in the default, and if you want to make a private response, you just use the alternate response command "R". I have not tested this. I think this answers almost all of the concerns I saw voiced on the exploder except the one about sorting messages by originator. In that regard, is there some kind of a homebrew or other utility for this ? Could it be modified to account for this ? _________________________________________________________________________ | | | Rick Voreck VOICE: (415) 852-5939 | | Space Systems/Loral (M/S G87) FAX: (415) 852-6286 | | 3825 Fabian Way E-MAIL: voreck@ssd49.ssd.loral.com| | Palo Alto, CA 94306 | | | |_________________________________________________________________________| From froloff@pioneer.arc.nasa.gov Xxx Oct x xx:xx:xx 1991 From: froloff@pioneer.arc.nasa.gov (Walt Froloff) Subject: Re: From and Reply exploder addresses i concurr with Bill Cruise ... the replies are very helpfull Walt Froloff LESC-NASA Life Sciences From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: Re: Exploder vs. newsgroup I endorse the idea that we work toward starting a newsgroup 'comp.realtime.vxworks'. This discussion has taken place at the various user group meetings and one thing is quite clear: Many users don't have the capability or the patience to deal with netnews. It will be necessary to have both a newsgroup and an exploder, perhaps with an interconnect. Alan K Biocca I have already removed the extra lines prior to the message -- and there is only one errors-to line on the transmitted message -- something else must be adding Steve M Burinsky's second one. From froloff@pioneer.arc.nasa.gov Xxx Oct x xx:xx:xx 1991 From: froloff@pioneer.arc.nasa.gov (Walt Froloff) Subject: vote to reply-to vxwexploder to we all benefit my vote is to explode replies walt From mea@sparta.com Xxx Oct x xx:xx:xx 1991 From: mea@sparta.com (Mike Anderson) Subject: East Coast VxWorks Users Group Meeting Greetings! I have been reviewing the list of confirmed attendees to the East Coast meeting and I know of several folks who have talked about attending, but haven't responded to Christina Goette from WRS as of yet (1 800 545-WIND). In order for us to properly size the refreshments and lunch, we need to at least get a head count (you can then pay at the door). For folks who may have been missed by the mailing list or received blank mail due to exploder illness, here are the details of the meeting: :::::::::::::::::::::: Begin Included Message :::::::::::::::::::::::::::: From wrs!mac_smtp!Christina_Goette@uunet.UU.NET Tue Aug 20 14:38:56 1991 Subject: None To: vxwexplo@Csa2.LBL.Gov Subject: Time:10:01 AM OFFICE MEMO Date:8/20/91 Dear VxWorks Users Group Members: We are pleased to announce that the VxWorks Users Group is planning to meet again on Tuesday, September 10, 1991, in conjunction with BUSCON East. Following is a tentative agenda for the meeting. Welcome WRS Update VxWorks Discussion Issues Forum/Birds of a Feather VxWorks UG Futures Discussion Mike Anderson of Sparta, Inc. will chair the meeting. If you have comments or suggestions, please contact either myself at 800/545-WIND, or Mike Anderson at Sparta, 703/448-0210 ext.235 or by e-mail at mea@sparta.com. If you have any issues or applications to present, please contact Mike. The meeting will be held at: The Madison Hotel 15th and M Streets Northwest Washington D.C., 20005 800/424-8577 or 202/862-1740 The meeting is scheduled from 8:30 a.m.- 5 p.m. with luncheon at noon. The meeting room will be posted in the hotel lobby under - VxWorks Users Group. To cover facility expenses there will be a $50 charge to attend. Please make checks payable to the VxWorks Users Group. Hotel reservations may be made at The Madison Hotel at a special discounted rate of $145. You may call The Madison directly at 800/424-8577 or 202/862-1740 to reserve a room. Please try to make your reservations by August 23, and be sure to let them know you are with the Wind River Systems group in order to receive the reduced rate. Please be sure to RSVP to me at Wind River Systems, 800/545-WIND or by e-mail at tina@wrs.com. Sincerely, Christina Goette Wind River Systems, Inc. :::::::::::::::::::::: End Included Message :::::::::::::::::::::::::::: If any of the attendees would be willing to present information about their VxWorks applications (I've already contacted some of you who were known to me, but this is a general call) or would like to discuss some issue in particular such as why signals under VxWorks are still so pathetic and what are the users doing to circumvent these problems, please contact me ASAP. Those of us in the VxWorks user community are always eager to learn from others. What may seem trivial to you may be decidedly non-trivial to others. The current list of speakers and topics looks like: Jayne Johnson Hughes Network Systems Low-level IP-layer efforts on the i960 Patrick Wolf Duke Univ Med Ctr Duke's uses of VxWorks Mike Anderson Sparta device driver issues WRT i960 VxWorks We could certainly use 2-3 others to help round out the discussions. It doesn't have to be elaborate. Thanks for your help and patience, East Coast VxWorks Users Group Meeting Chairman and Stuckee =============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessamist fears that this is true." J.B. Cabell =============================================================================== From steve@titan.tsd.arlut.utexas.edu Xxx Oct x xx:xx:xx 1991 From: steve@titan.tsd.arlut.utexas.edu (Steve Glicker) Subject: Re: vote to reply-to vxwexploder to we all benefit I vote _not_ to vote to the vxwexplo mailing list, but perhaps to vxwexplo-request or some other internet address. -steve From cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991 From: cruise@cfht.hawaii.edu (Bill Cruise) Subject: VxWorks Driver for the National Instruments 1014B GPIB VME card. We too remain interested in a driver for a National INstruments 1014 GPIB card. If anyone follows up on Tim Weadon's request, please post it to the exploder. Our card doesn't have a 'b' suffix, and our system is a SparcEngine. However, any vxWorks code is of interest to us. Bill Cruise Canada-France-Hawaii Telescope From fjr@iss-ipc1.ssd.ray.com Xxx Oct x xx:xx:xx 1991 From: fjr@iss-ipc1.ssd.ray.com Subject: Re: East Coast VxWorks Users Group Meeting I saw Mike's agenda for the User Group meeting. I'd like to throw out some of the issues that we are interested in for consideration: 1) Toolset issues. WRS plans for GNU support. GDB policy; use as a task level debugger vs use as a system level debugger. Possible X windows gdb version. Potential profiling type tool support. 2) IO issues. Need for efficient backplane IO (and possible multiprocessor support). Aynchronous IO plans. Support for other protocols and networks (e.g. XTP and FDDI). 3) Timing issues. Support for synchronized time (possibly using NTP or XNTP). Support for finer grained clock or possible countdown type scheduling. 4) Future release plans. Plans for bug fixes vs major feature releases vs releases that are just for new target/host pairs. Some idea of planned additions and their priorities. Best methods for bug fix propagation. 5) Reliable system support. What is planned to increase system reliability or allow improved error recovery. As an example, how could resource reclamation be supported (e.g. memory recovery on process termination). 6) VxWorks archive status. Wondering why archives of Exploder traffic no longer available. 7) Support for program unload allowing debugging using a load - test - unload development cycle. 8) VxWorks and Ada. Usage level and interest in VADSWorks. I realize this list is pretty rough but just thought it might serve as a start for people to put together lists of other subjects there is interest in discussing at next weeks user group meeting. See everyone there. ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From OWENS@lodtm.llnl.gov Xxx Oct x xx:xx:xx 1991 From: OWENS@lodtm.llnl.gov Subject: use of exploder Since a separate address is provided for comments (ie. which address goes where .. etc.) it would be appreciated (by me, anyway) if this sort of thing could be kept off of the regular exploder. It's getting to be something of a bother to search through 15 or so messages I am getting each day just to find the one or two that actually deal with software/hardware issues. Thanks, Doug Owens From hebo@mbari.org Xxx Oct x xx:xx:xx 1991 From: hebo@mbari.org (Bob Herlien) Subject: Re: East Coast VxWorks Users Group Meeting Fred Roeber brings up a number of good issues for discussion at the East Coast meeting. Kind of makes me wish I were going. I hope someone posts a good summary onto the exploder. Here's some more thoughts: 1) NTP. I now have NTP sort of working on VxWorks. I ported ntp, rather than xntp, because (a) it's smaller, and hence an easier port, and (b) xntp requires async I/O, which isn't available in VxWorks. It's not in good enough shape yet to release to the archives, but I'll share it with anyone who can't wait. I'm still considering a port of xntp (which conforms to version 2 of the NTP spec; ntp conforms to version 1). 2) Toolsets. We're still waiting for gdb support on HP. I'm very interested in WRS's long-term plans for tools and for HP support. 3) I'd like to see a change to sysClkConnect() and sysAuxClkConnect(). Currently, you can't ADD yourself to the list of routines to be called at a clock tick; you can only REPLACE the routine that was called. Sure, you can call your function from usrClock(), but then your routine must be linked into the system; it's not loadable. I'd like the connect functions to maintain a list of functions to call, and call them all at the clock tick. Not too hard to do. You can then also add a sysClockDisconnect() call. 4) A pet peeve of mine. The directory structure of config/all and config/target sucks. config/all/configAll.h assumes you only have one target. We have 4 target CPU's from 2 different vendors. I've mercilessly hacked our Makefiles to look for different configAll's but it's non-standard. Here's one vote for moving configAll.h into config/target and doing away with config/all. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: Double Articles, etc DO NOT SUBMIT to vxwexplo-list@vxw.ee !! Some of you may have noticed double-notes from some submitters, or notes that did not come from the exploder but came from the submitter. This happens when the submitter incorrectly sends to vxwexplo-list@vxw.ee. This may also happen if the submitter does a 'reply all'. Please DO NOT send via the -list address -- this is an internal list address and it causes the sender to receive all errors, skips the automatic archiving process, etc, and undermines the new exploder capabilities. We realize (especially now) that not everyone agrees on how the addressing should work on the exploder -- please send comments to the -request address, we are collecting them. We have received and processed a large number of 'unsubscribe' requests lately, so apparently lots of folks don't want to hear about how to run the exploder, so lets keep the exploded comments to a real low level. How about this -- if you really want to explode your comments on the exploder, you also must put a vxworks-related general-information paragraph in the note just to keep the traffic on subject. For those who have read this far I have a question -- is there much interest in a speeded up float-to-ascii conversion routine? We have done one that uses the 68881/2 coprocessor and is vastly faster than vxWorks sprintf, though not as flexible. We use it for writing floating point to ascii type data files. Any interest? If so email me at AKBiocca@lbl.gov. One more tidbit -- we are working on setting up anon ftp to make available the exploder traffic -- it is being automatically archived in one month chunks with an annual index. In a few days I'll review all the exploder comments received so far and make some adjustments to the exploder operations. Thanks, Alan K Biocca (AKBiocca@lbl.gov) From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: sublist exploders We encourage users to form exploder sublists at their sites and make this system more responsive and efficient for the vxworks community. There are already a number of such lists that help deliver our traffic. One down side of this is bad addresses that exist on the sublists. I need to develop a list of the sublists so I can refer change requests and bouncing addresses to the proper sublist. This database will contain the mailing address of the sublist and the mailing list of the local administrator of the sublist. In order to develop this list I request the sublist administrators to send this info to vxwexplo-reqeust. Thanks, Alan K Biocca From wrs!yuba!ricks@uunet.uu.net Xxx Oct x xx:xx:xx 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Subject: Re: configAll.h Bob Herlien, RE: configAll.h sucks Hmmm... We have over 50 targets in our config directory and it works fine for us. Perhaps there is some mechanism you are misunderstanding? Rick ricks@wrs.com From KADIONIK@frcpn11.in2p3.fr Xxx Oct x xx:xx:xx 1991 From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik) Subject: Re: configAll.h We use different kinds of target CPU, and he have not problems with configAll.h . Perhaps, you may have troubles with the cc compiler because VxWorks versions >= 5.0.1 use the Gnu cc , the other the cc compiler. If you have different version of target BSP, be carefull because they may use different kind of cc comilers (gcc, cc) ! Puisse cela vous aider.... Sincerely ; Patrice Kadionik, doctor engineer student. C.E.N.B.G. Bordeaux, France. From hebo@mbari.org Xxx Oct x xx:xx:xx 1991 From: hebo@mbari.org (Bob Herlien) Subject: Re: configAll.h Ricks@wrs.com writes: > Hmmm... > We have over 50 targets in our config directory and it works fine for us. > Perhaps there is some mechanism you are misunderstanding? > OK, maybe I don't understand the intended use. Since ALL targets include , how do you include different VxWorks facilities in your load image? Different boards in our system need different levels of network support (NFS, RPC, none), file systems, etc. We had one WRS engineer tell us that we're supposed to create a generic configAll.h, and #undef the stuff we don't want in config.h for each board. That is, in my opinion, bad coding practice; and in fact, violates our internal coding standards. Instead, I created different configAll.h's in different subdirectories of , and hacked Makefile to point to them. In a similar vein, how do you create different load images for CPU's of the SAME type? For each target type there's only one subdirectory and hence one Makefile and one config.h. We have three CPUs of one type, and need to build systems for each that are configured differently. I created subdirectories of and hacked the Makefile to understand where it's at and create the vxWorks loadable image in the subdirectory. What am I missing? ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From harry@verdix.com Xxx Oct x xx:xx:xx 1991 From: harry@verdix.com Subject: Re: configAll.h Rick: >Bob Herlien, > >RE: configAll.h sucks > >Hmmm... >We have over 50 targets in our config directory and it works fine for us. >Perhaps there is some mechanism you are misunderstanding? > >Rick >ricks@wrs.com I also need to enable/disable select vxWorks features on a board by board basis. Having a single config/all/configAll.h for different boards needing vxWorks kernels with different features required, for me, some hacking. Apparently WRS has evolved a way of supporting multiple and different vxWorks kernels since you are able to configure over fifty targets with different vxWorks features using a single all/configAll.h file. The key here is generating kernels with DIFFERENT features where configAll.h provides the precompilation information to incorporate these features. For example, using all/configAll.h, how does one produce a kernel for one target having the vxWorks shell and produce a kernel not having the vxWorks shell for another target? Is your method documented anywhere? I am unable to find it in your programmers guide. Will you share your method with Bob and I? harry harry@verdix.com From hmp@frc2.frc.ri.cmu.edu Xxx Oct x xx:xx:xx 1991 From: hmp@frc2.frc.ri.cmu.edu Subject: VxWorks header files I'm discovering more inconsistencies in vxWorks header files, mostly in the area of function prototype declarations that exist in more than one file. We've seen other messages to this effect in this group; what I would like to ask today is how people are working around this, presumbaly until WRS releases an updated set. So far, I've been commenting out the duplicate declarations, using an ad hoc method to determine which header file should contain the real version. In some cases, the declarations are slightly different, so I'm not real happy with this. What are others out there doing in this regard? -Henning From hebo@mbari.org Xxx Oct x xx:xx:xx 1991 From: hebo@mbari.org (Bob Herlien) Subject: Re: VxWorks header files We've noticed inconsistent header files, too, and have been dealing with it the same way you have (ad hoc). In many cases, it's obvious what the declaration should be (e.g., const was added to the declaration). Sometimes you can look at the manual. But it sure would be nice to get an authoritative update from WRS. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From lambert@grumpy.ssc.gov Xxx Oct x xx:xx:xx 1991 From: lambert@grumpy.ssc.gov (David Lambert) Subject: VxWorks header files We have had the same sort of problems. The "ANSIfication" of the header files seems to be the base of the problem. All WRS fixes so far, are: "patch and wait for the next release". Fortunately, so far, all are easy to work around. At least WRS have given us most ANSI headers. We have had to make our own for our host (SUN)! Next: How about a C++ class library for VxWorks? From fjr@iss-ipc1.ssd.ray.com Xxx Oct x xx:xx:xx 1991 From: fjr@iss-ipc1.ssd.ray.com Subject: Re: configAll.h Bob Herlien had some problems using configAll.h. WRS gets it to work. We also support multiple boards and don't find it too bad. The key is to set the "default" configuration in configAll and then use the local config.h file to tailor the default to the particular board by using a set of #define and #undefine statements. It is a bit of a pain to figure out all the possible option settings although it helps that all the options start with "INCLUDE_". It probably would be helpful if Wind River included a brief synopsis of all the INCLUDE variables, their purpose, and their default settings. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991 From: cruise@cfht.hawaii.edu (Bill Cruise) Subject: VxWorks header files >> Subject: VxWorks header files >> Submitted-By: lambert@grumpy.ssc.gov (David Lambert) >> Next: How about a C++ class library for VxWorks? --------------------------- Yes, please do full C++ support for vxWorks. The present system is to get the ANSI headers from the archive, put in some C++ wrappers, and then keep tweeking this mess when bugs appear. Also, each user must go through the experience of finding out which C++ features work and which don't work in the target environment. Some can be hacked in with workarounds (anyone interested in new, free, or stdargs?), but many neat features are just not available to us. Any other votes for C++ support? This seems to be the time on the exploder when we vote. Bill Cruise Canada-France-Hawaii Telescope From mclark@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991 From: mclark@lodestar.gb.nrao.edu (MARK H. CLARK) Subject: VxWorks header files Yes, one strong vote for full C++ support for vxWorks. I have been delaying working on vxWorks and doing all my prototyping on our host machines in C++ while waiting for vxWorks to give me the compiler and proper header files. Mark H. Clark mclark@nrao.edu National Radio Astronomy Observatory P. O. Box 2 Green Bank, WV 24944-0002 From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: Re: configAll.h One solution to the multiple configuration problem is to use the provided shadow facility from WRS. This tool creates a mirrored directory structure that contains links to the real files in the original structure. To use that in this context you create shadows at the ../config directory level, one for each target-group that will share a common configAll.h arrangement -- a common set of facilities. This is probably a smaller collection since many targets will need the same facilities. These shadow subdirectories would be named appropriately to reflect their group-characteristics, perhaps like '../config_full', 'config_no_nfs', 'config_nfs', etc. After building the shadow directory go into the shadow's config/all subdir, where you'll find links to all the files including configAll.h. Convert configAll.h to a real file and change it according to the requirements. Go to the target cpu subdirectory of the shadow tree and make the new vxworks. This requires no makefile hacking -- in fact you only have one copy of each makefile and everything else uses symbolic links to share those copies. The shadow tool is very useful to solve many classes of problem like this one. Alan K Biocca BEVALAC Controls Group From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: Re: configAll.h One solution to the multiple configuration problem is to use the provided shadow facility from WRS. This tool creates a mirrored directory structure that contains links to the real files in the original structure. To use that in this context you create shadows at the ../config directory level, one for each target-group that will share a common configAll.h arrangement -- a common set of facilities. This is probably a smaller collection since many targets will need the same facilities. These shadow subdirectories would be named appropriately to reflect their group-characteristics, perhaps like '../config_full', 'config_no_nfs', 'config_nfs', etc. After building the shadow directory go into the shadow's config/all subdir, where you'll find links to all the files including configAll.h. Convert configAll.h to a real file and change it according to the requirements. Go to the target cpu subdirectory of the shadow tree and make the new vxworks. This requires no makefile hacking -- in fact you only have one copy of each makefile and everything else uses symbolic links to share those copies. The shadow tool is very useful to solve many classes of problem like this one. Alan K Biocca BEVALAC Controls Group From scotth@rocco.labs.tek.com Xxx Oct x xx:xx:xx 1991 From: scotth@rocco.labs.tek.com Subject: Re: VxWorks header files > Next: How about a C++ class library for VxWorks? This is an interesting topic. Has anyone built such a library? We (Tektronix) are working on a handful of data structures, tools, and application-domain- specific class libraries that will be used with VxWorks, but no object- oriented interface to VxWorks itself, yet. I'd be interested in a discussion of what such a library would look like, what model(s) of intertask synchronization/communication might be supported on top of VxWorks primitives, etc.. I'm also interested in how other developers are approaching problems specific to embedded systems where some special constraints exist. Here are a couple issues worth discussing: - proprietary hardware; memory areas are not contiguous; - total memory size is limited, esp. RAM. System executes out of ROM; unused functions should not be linked; - constant objects should be in ROM; - efficient ways to write C++ code so that an unnecessarily expensive processor is not required to make the system "fast enough" and so that unnecessary memory requirements are eliminated. The first two problems aren't C++ specific, but new solutions are possible and necessary. The second issue is especially important: It is common practice to implement many member functions in a single source file which is compiled to produce a single object file. The UNIX a.out object file format and linker don't support function granularity so the entire object file is linked even if only one or two functions are used. This is a common problem when using C++ class libraries. The third problem has several dimensions. One is the desire to place invariant data in ROM. The problem is that objects need to be constructed, initially. These implies run-time semantics and RAM. However, once constructed, they remain unchanged, so it would be nice to put them in ROM. Besides the "it would be nice" reason, it is essential to minimize initialization time that an user must wait when the instrument is powered on. This can be several minutes on some instruments' software when constructing complex networks of global objects. Not a good selling point! Do this topics interest others? Discussion? Scott Herzinger scotth@crl.labs.tek.com Computer Research Lab, Tektronix, Inc. PO Box 500 MS 50-662, Beaverton, OR 97077 From OWENS@lodtm.llnl.gov Xxx Oct x xx:xx:xx 1991 From: OWENS@lodtm.llnl.gov Subject: 68040 floating point This goes back to my interest in developing loadable programs with the gcc compiler .. thanks to all that replied. It turns out I had problems getting ld to create an output file because the -o option was in the wrong place in the command line. This a.out type file was still not quite what I wanted but I did manage to produce a loadable image from it. The main reason I want to be able to do this sort of thing is to test some routines on a 68040 board (MVME 167), since vxWorks is not yet available, I was looking for an alternative method to load and test (benchmark) software. I am using an MVME147 with the Motorola ROMs at the present time since the 167 has not arrived. These ROMs provide an environment suitable for executing simple programs ( I am hoping the 167 ROMs are similar ). In the meantime I have been reading the literature on the 68040 and its floating point capabilities. It does not provide the transcendentals and this is not a problem in my application. More bothersome is the lack of FINT and FINTRZ which seem to show up regularly in gcc generated code. Is there a compiler available which can generate inline floating point code compatible with the 68040? Thanks, Doug Owens Lawrence Livermore National Lab From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Subject: fast float to ascii FPU function There was quite a bit of interest in the fast floating to ascii routine I mentioned last week, and it is fairly short, so I'll put it out here. Send comments to AKBiocca@lbl.gov. Alan K Biocca /* here is a fast floating point to ascii converter we developed for the ** BEVALAC control system for storing control system state. ** ** This work done by Loren Shalz, Alan Biocca, and Maurice McEvoy. ** ** ** ftoa converts float to decimal ascii using the MC68881/2 Floating_Point ** Coprocessor. It utilizes a single line of assembly language to access ** the FPU's floating point to packed BCD. The remainder of the code is ** written in C. The WRS 5.0.1 release gnu cross tools were used (based ** on gcc 1.37). Your mileage may vary -- TEST THESE ROUTINES THOROUGHLY. ** ** ftoa must be compiled with the gnu compiler because cc's assembler ** does not recoginze the k factor(precision) in the inline fmovep command. ** cc68k -c -o ftoa.vx ftoa.c ** ** If any code before the fmovep is changed be sure to get the assembler ** output and verify that value has been put into fp0, that a3 still ** has the address of packed_bcd and that d4 still has precision. ** Adjust fmovep appropriately if any changes are observed. ** ** See the MC68881 Floating-Point Coprocessor Users Manual for the ** packed decimal real format produced by the fmovep. The following ** defines aid in cracking that format to produce the decimal ascii. */ #define MANTISSA_SIGN ( ( unsigned char ) ( 1 << 7 ) ) #define EXPONENT_SIGN ( ( unsigned char ) ( 1 << 6 ) ) #define NAN_BITS ( ( unsigned char ) ( 3 << 4 ) ) #define ASCII_ZERO ( ( unsigned char ) 0x30 ) #define RIGHT_NIBBLE ( ( unsigned char ) 0xf ) #define NIBBLE_SIZE ( ( unsigned char ) 0x4 ) #define PACKED_BCD_SIZE 12 int ftoa( value, precision, width, string ) float value; /* value to be converted to decimal ascii */ int precision; /* 1 <= precision(no. significant digits) <= 17 */ int width; /* minimum size of returned string. String is left */ /* adjusted with blank fill if necessary */ char *string; /* pointer to string to receive converted value */ /* format returned is [-]d.dddddddddddddddde[-]ddd */ /* so string should be sized to hold at least the /* larger of width or precision + 7 characters */ /* plus a terminating null. Trailing zeros in the */ /* mantissa and zero exponents are dropped */ /* ftoa returns the length of string */ { unsigned char packed_bcd[PACKED_BCD_SIZE]; register float v = value; register int p = precision; register int w = width; register char *s = string; register unsigned char *c = &packed_bcd[0]; int i; int trailing_zeros; int trailing_blanks; int right_adjuster; unsigned char next_digit; asm( " fmovep fp0,a3@{d4}" ); /* convert to packed bcd. */ if ( precision < 1 ) precision = 1; if ( precision > 17 ) precision = 17; if ( ( c[0] & NAN_BITS ) != 0 ) { strcpy( s, "NAN" ); return; } /* unpack mantissa--always return at least 1 digit and '.' */ if ( ( c[0] & MANTISSA_SIGN ) != 0 ) *s++ = '-'; /* mantissa sign */ *s++ = ( c[3] & RIGHT_NIBBLE ) + ASCII_ZERO; /* most sign. digit */ *s++ = '.'; /* decimal point */ trailing_zeros = 0; --precision; /* 1st digit unpacked above */ right_adjuster = NIBBLE_SIZE; c = &packed_bcd[4]; for ( i = 0; i < precision ; ++i ) /* unpack rest of digits */ { next_digit = ( c[i/2] >> right_adjuster ) & RIGHT_NIBBLE; if ( next_digit == '\0' ) ++trailing_zeros; else trailing_zeros = 0; *s++ = next_digit + ASCII_ZERO; if ( right_adjuster == 0 ) right_adjuster = NIBBLE_SIZE; else right_adjuster = 0; } s = s - trailing_zeros; /* unpack exponent--drop it if it is zero. */ c = &packed_bcd[0]; if ( ( ( next_digit = ( c[0] & RIGHT_NIBBLE ) ) + c[1] ) != 0 ) { *s++ = 'e'; /* nonzero exponent */ if ( ( c[0] & EXPONENT_SIGN ) != 0 ) *s++ = '-'; if ( next_digit != 0 ) { *s++ = next_digit + ASCII_ZERO; /* 3 digit exponent */ *s++ = ( c[1] >> NIBBLE_SIZE ) + ASCII_ZERO; } else if ( ( next_digit = ( c[1] >> NIBBLE_SIZE ) ) != 0 ) *s++ = next_digit + ASCII_ZERO; /* 2 digit exponent */ *s++ = ( c[1] & RIGHT_NIBBLE ) + ASCII_ZERO; /* 1 digit exponent */ } if ( ( trailing_blanks = width - ( s - string ) ) > 0 ) /* blank pad */ for ( i = 0; i < trailing_blanks; ++i ) *s++ = ' '; *s = '\0'; return s - string; } From maf@verdix.com Xxx Oct x xx:xx:xx 1991 From: maf@verdix.com Subject: Re: VxWorks header files > I'm also interested in how other developers are approaching problems specific > to embedded systems where some special constraints exist. Here are a couple > issues worth discussing: > > - proprietary hardware; memory areas are not contiguous; > - total memory size is limited, esp. RAM. System executes > out of ROM; unused functions should not be linked; > - constant objects should be in ROM; > - efficient ways to write C++ code so that an unnecessarily expensive > processor is not required to make the system "fast enough" and so that > unnecessary memory requirements are eliminated. > > The first two problems aren't C++ specific, but new solutions are possible and > necessary. The second issue is especially important: It is common practice to > implement many member functions in a single source file which is compiled to > produce a single object file. The UNIX a.out object file format and linker > don't support function granularity so the entire object file is linked even if > only one or two functions are used. > > This is a common problem when using C++ class libraries. > > The third problem has several dimensions. One is the desire to place invariant > data in ROM. The problem is that objects need to be constructed, initially. > These implies run-time semantics and RAM. However, once constructed, they > remain unchanged, so it would be nice to put them in ROM. Besides the "it > would be nice" reason, it is essential to minimize initialization time that an > user must wait when the instrument is powered on. This can be several minutes > on some instruments' software when constructing complex networks of global > objects. Not a good selling point! As a tool vendor selling Ada into the embedding systems community, we (Verdix) have faced this exact set of problems. To provide our customers with the kind of tools they wanted, we developed our own object format (based on a.out) and linker. To address the non-contiguous memory problem, the linker allows separate specification of location for each section of each object file. The linker permits mapping of sections to locations in ROM and RAM. Runtime support is used to copy from ROM to RAM, if desired (see static data issues below). Our Ada compiler emits one object file for each Ada package, resulting in a similar scenario in which many unused functions are linked in. To combat this problem, our compiler generates additional information into our object files which allows our linker to selectively eliminate routines (and data) which are not referenced. The data initialization/storage problem requires close cooperation between compiler, linker, and runtime. Storing invariant data in ROM can be safely achieved if the compiler knows the value of an object at compilation time and also knows that the object will never change. In Ada, an object can be declared explicitly as a "constant", even if its value is potentially dynamically determined. Exactly which initializations a compiler can reduce to statically initialized constants will depend on the compiler's optimization capabilities. Of course, we also want to initialize static objects which are not constants. While the same compilation techniques are used to determine their initial values, they cannot be stored in ROM because they must be writable. By adding an additional "constants" section to our object format, we allow our compiler to distinguish between true constants and static data. The linker then allows separate specification of ROM locations for constants and static data. For static data, a second location is given in RAM and runtime code is used to copy the static data from ROM to RAM. Concern about static initialization (called "pre-elaboration" in the Ada community) has been significant enough that we recently added a directive to our compiler which allows users to request generation of warnings for any initialization that requires code generation. I don't know how well these approaches would map onto C++, particular those regarding constants and initialization. Ada allows explicit identification of invariant data and associates an implicit (potentially null) initialization with every entity. I don't know if C++ compilers receive sufficient information for them to perform this type of optimization. Marc Friedman maf@verdix.com From maf@verdix.com Xxx Oct x xx:xx:xx 1991 From: maf@verdix.com Subject: Re: East Coast VxWorks Users Group Meeting > 4) A pet peeve of mine. The directory structure of config/all and > config/target sucks. config/all/configAll.h assumes you only have > one target. We have 4 target CPU's from 2 different vendors. I've > mercilessly hacked our Makefiles to look for different configAll's > but it's non-standard. Here's one vote for moving configAll.h into > config/target and doing away with config/all. The all directory works well when one needs to build similar systems for different targets. I prefer the approach of using multiple all directories when differently configured systems are required. Marc Friedman maf@verdix.com From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) To: vxworks_users Subject: Subnets The current vxWorks system requires multi-cpu crates to dedicate a whole subnet to the backplane to communicate with the secondary processors there. In many cases this is an undesirable waste of address space -- using 250+ addresses for one or two secondary processors. One solution is referred to as 'proxy arp'. In this mode the gateway cpu recognizes more than one IP address on the its ethernet port and relays these packets to the subsidiary processors on the secondary net. It is then acting as a 'bridge', in effect. Is there much interest in this problem within the exploder community?? Alan K Biocca BEVALAC Controls Group From rg@msel.unh.edu Wed Sep 11 17:00:25 1991 From: rg@msel.lbl.gov (Roger Gonzalez) Date: Wed Sep 11 17:00:32 PDT 1991 Subject: Re: Subnets > > The current vxWorks system requires multi-cpu crates to dedicate a whole > subnet to the backplane to communicate with the secondary processors there. > In many cases this is an undesirable waste of address space -- using 250+ > addresses for one or two secondary processors. The Powers That Be have decreed that I may not have a subnet, because it wastes too many addresses. (Our subnet mask is 255.255.252.0. Argh.) Is it possible to use some "officially unassigned" throwaway addresses for the backplane subnet? Is there any address range that is designated as temporary local addresses? I was planning on using 90.0.0.*, having my development system route all such addresses to the vxworks cage(s), and also having a bridge upstream from me filter out all accesses to these addresses. (What is 90.0.0.*? Anyone I might want to talk to? :-) a) Would this work? b) Is it a good idea? I haven't had to try this yet because we still only have one target CPU. We're planning on using passels (passles?) of them, though, so count me in as another person interested in faster backplane communications! -Roger "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra Roger Gonzalez - rg@msel.unh.edu UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) From wrs!yuba!ricks@uunet.uu.net Wed Sep 11 19:48:47 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Date: Wed Sep 11 19:48:53 PDT 1991 Subject: Re: configAll.h OK. The intended use of the files all/configAll.h and target/config.h: The combination of these two files, at compile time, determines the final configuration of the vxWorks executable image. The optional modules that may be added on top of the base kernel are specified in these files. Examples are the shell, and network support. The configAll.h file is used to define a standard baseline of functionality that is to be shared between all targets that you work on. The delivered version of this file is the same as the file used at WRS on a daily basis. In this version, most features are "turned on". This is because we must test these features on all targets, if applicable. The config.h file is used to alter the baseline for a specific target, or specific functionality set within targets. In this file, additional features can be "turned on". Baseline features can also be "turned off", which is done by the (dreaded) #undef statement. If the "turn off feature" mechanism is distasteful to you, or you find that you are turning off too many features, there is a simple solution. Simply edit configAll.h and create your own baseline. You may even wish to deselect *ALL* features! Note that when deselecting a feature in this file, do not erase the line that selects it. Instead *move* the line down into the EXCLUDE area, where it will not be compiled, but is still readily available for viewing. An important point to note is that both the header files we have been discussing are delivered in source form to you. This means you are free to modify them however you wish to suit your tastes or peculiar environment. If you do stike out on your own, keep in mind that you may make support issues difficult. If our documentation did not explain this mechanism effectively, our apologies. Configuration management is an important issue here at WRS. We are always looking at ways to make all our lives easier. Rick From smb@afterlife.ncsc.mil Wed Sep 11 22:41:01 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Wed Sep 11 22:41:07 PDT 1991 Subject: Re: Subnets Date: Wed, 11 Sep 91 15:45:56 PDT From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Subnets Submitted-By: biocca@bevsun.bev.lbl.gov (Alan K Biocca) The current vxWorks system requires multi-cpu crates to dedicate a whole subnet to the backplane to communicate with the secondary processors there. In many cases this is an undesirable waste of address space -- using 250+ addresses for one or two secondary processors. Am I missing something here? Netmasks need not align with octet boundaries. You could specify your netmask to be 0xfffffffe, which creates a subnet containing only 2 hosts. ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov Could we please dispense with this annoying advertisement! Steve From smb@afterlife.ncsc.mil Wed Sep 11 22:55:02 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Wed Sep 11 22:55:08 PDT 1991 Subject: Re: Subnets Date: Wed, 11 Sep 91 17:00:35 PDT Subject: Re: Subnets Submitted-By: rg@msel.lbl.gov (Roger Gonzalez) Is it possible to use some "officially unassigned" throwaway addresses for the backplane subnet? Is there any address range that is designated as temporary local addresses? I was planning on using 90.0.0.*, having my development system route all such addresses to the vxworks cage(s), and also having a bridge upstream from me filter out all accesses to these addresses. (What is 90.0.0.*? Anyone I might want to talk to? :-) From what I can find at nic.ddn.mil, the class A network 90.0.0.0 has not been assigned (yet). If you are connected to the internet, one of the rules you must abide by is using only registered addresses. If I chose to use the network number 128.3.0.0 for my VxWorks cage(s), you folks at lbl.gov would be a bit miffed because I would be using addresses reserved for your use. There are plenty of unassigned addresses, but none of them are throw-aways. The internet lives with a single, 32-bit address space. Just play in you own little (reserved) corner, please :-). Steve From bernard@aar.alcatel-alsthom.fr Thu Sep 12 05:49:09 1991 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Thu Sep 12 05:49:15 PDT 1991 Subject: TAS problem ? It seems I have problems with multi-processor TAS on MV147: /*---------------------------------------------------------------------------*/ target 1 target 2 char tasByte tasBusAdr = offset (target1) + &tasByte while ( vxTas (&tasByte) == 0 ); while ( sysBusTas (tasByteAdr) == 0 ); . . . using critical resource . . (no blocking operations) . tasByte = 0 *tasByteAdr = 0 /*---------------------------------------------------------------------------*/ ... it works a few moments and then target1 and target2 loops in the while statement. Can anybody help ? Thanks for comments, any help would be appreciated .. -- Olivier ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ----------------------------------------------------------- From bernard@aar.alcatel-alsthom.fr Thu Sep 12 05:59:53 1991 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Thu Sep 12 06:00:00 PDT 1991 Subject: bug with select 5.0 I think there is a bug in the select function with VxWorks 5.0. This bug seems to occur when file descriptors exceed 31. In this case, select does the following: - waits for an event on file descriptors (OK) - returns 1 + (number of file descriptors > 31) - 1 !! - flags ALL file descriptors > 31 as ready I join the code which show the problem. Am I doing something wrong or is it really a bug ? Thanks for comments. -- Olivier ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ----------------------------------------------------------- /*---------------------------------------------------------------------------*/ PROGRAM /*---------------------------------------------------------------------------*/ #include "vxWorks.h" #include "stdioLib.h" #include "ioLib.h" #include "types.h" #include "selectLib.h" #include "pipeDrv.h" /*---------------------------------------------------------------------------*/ void selectTest (fdMax) int fdMax; { fd_set set; int firstFd, fd; int res; FD_ZERO (&set); pipeDevCreate ("pipeTest1", 10, 100); pipeDevCreate ("pipeTest2", 10, 100); firstFd = open ("pipeTest1", O_RDWR); FD_SET (firstFd, &set); printf ("first fd = %d, ", firstFd); /* I open file descriptors until fd = fdMax */ do { fd = open ("pipeTest2", O_RDONLY); FD_SET (fd, &set); printf ("fd = %d, ", fd); } while (fd < fdMax); res = select (fd, &set, NULL, NULL, NULL); printf ("\nselect = %d\n", res); for (fd = firstFd; fd <= fdMax; fd++) if (FD_ISSET (fd, &set)) printf ("file #%d ready\n", fd); } /*---------------------------------------------------------------------------*/ /* I use this function to send a message to "firstFd" */ void selectSend (fd) int fd; { write (fd, "mes", 4); } /*---------------------------------------------------------------------------*/ RESULTS /*---------------------------------------------------------------------------*/ LouisI > sp selectTest,31 LouisI > first fd = 14, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, fd = 31, LouisI > selectSend 14 value = 4 = 0x4 LouisI > select = 1 <- OK, one fd was selected file #14 ready <- OK, this fd was # 14 THIS WORKS !!! (no fd > 31) /*---------------------------------------------------------------------------*/ LouisI > sp selectTest,32 LouisI > first fd = 13, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, fd = 31, fd = 32, LouisI > selectSend 13 select = 1 <- OK, one fd was selected file #13 ready <- OK, this fd was # 13 file #32 ready <- ERROR !!! this one was not selected ! THIS DOES NO WORK (fd > 31) /*---------------------------------------------------------------------------*/ LouisI > sp selectTest,33 LouisI > first fd = 13, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, fd = 31, fd = 32, fd = 33, LouisI > selectSend 13 select = 2 <- ERROR !!, one fd was selected !! file #13 ready <- it was this one file #32 ready <- ERROR !! file #33 ready <- ERROR !! THIS DOES NOT WORK (fd > 31) /*---------------------------------------------------------------------------*/ From jjohnson@hns.com Thu Sep 12 06:06:08 1991 From: jjohnson@hns.com (Jayne Johnson) Date: Thu Sep 12 06:06:17 PDT 1991 Subject: Re: Subnets Yes!yes!yes! In the system we're putting together a network of multiple subnets. I have a similiar situation the current Vxworks networking configuration is inadequate. The networking in our configuration doesn't have VME to access other networks , I have T1 bridge. I have been looking into implementing Proxy Arp also. Yes, I am interested and would like Vxworks to incorporate this standard. Please keep me informed. Thanks in advance. Jayne Johnson Hughes Network Systems 11717 Exploration Lane Germantown , Md 20874 tel : 301-428-2714 email : jjohnson@hns.com From bernard@aar.alcatel-alsthom.fr Thu Sep 12 06:13:11 1991 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Thu Sep 12 06:13:17 PDT 1991 Subject: f68881 We had this bug a few months ago. I join the answer which helped us a lot: From marc@sun-valley.Stanford.EDU Fri Sep 7 21:45:40 1990 Received: from crcge1.cge.fr by ouragan.cge.fr, Fri, 7 Sep 90 21:45:39 +0200 Received: from inria.UUCP by crcge1.cge.fr, Fri, 7 Sep 90 21:45:36 +0200 Received: from Sun-Valley.Stanford.EDU by inria.inria.fr (5.64+/89.0.8) via Fnet-EUnet id AA12929; Fri, 7 Sep 90 18:58:09 +0200 (MET) Received: by sun-valley.Stanford.EDU (4.1/inc-1.0) id AA13667; Fri, 7 Sep 90 09:39:56 PDT From: marc@sun-valley.Stanford.EDU (Marc Ullman) Message-Id: <9009071639.AA13667@sun-valley.Stanford.EDU> To: bernard@ouragan (Olivier Bernard) Cc: vxwexplo@csa1.LBL.Gov Subject: Re: problems with IT routines and -f68881 flag In-Reply-To: Your message of "Fri, 07 Sep 90 13:55:12 +0100." <9009071155.AA06468@ouragan.cge.fr> Date: Fri, 07 Sep 90 09:39:55 MDT Status: R > >However this routine can make the system reboot >if it is compiled with the -f68881 option. You should note that this >routine does *not* use any float. In fact, as far as I can understand, >the compiler puts a "FMOVEM.X #<>,($00000,A6,D0.W*1)" assembler line >at the beginning of EACH function. Why ? and why does this reboot VxWorks ? >Moreover, it seems that the system fails on particular conditions >(eg: when another task is running, etc ...) > >/*---------------------------------------------------------------------------* > / > >// compiled with -f68881 option > > _auxClkRoutine: >74f4dc 4e56 0000 LINK .W A6,#0 >74f4e0 dffc 0000 0000 ADDA .L #$00000,A7 >74f4e6 48d7 0000 MOVEM .L #<>,(A7) >74f4ea f236 f000 0170 0000 0000 FMOVEM.X #<>,($00000,A6,D0.W*1) // ??????? > ??? >74f4f4 52b9 0074 f500 ADDQ .L #1,tickAuxLib.o_data >74f4fa 7000 MOVEQ #$0,D0 >74f4fc 4e5e UNLK A6 >74f4fe 4e75 RTS > >// compiled without -f68881 option > > _auxClkRoutine: >74f368 4e56 0000 LINK .W A6,#0 >74f36c dffc 0000 0000 ADDA .L #$00000,A7 >74f372 48d7 0000 MOVEM .L #<>,(A7) >74f376 52b9 0074 f388 ADDQ .L #1,tickAuxLib.o_data >74f37c 7000 MOVEQ #$0,D0 >74f37e 4e5e UNLK A6 >74f380 4e75 RTS > >/*---------------------------------------------------------------------------* > / > > >So ... don't mix in the same module functions treating floats (and thus >needing the -f68881 flag) with functions called at interrupt level ... (am I r > ight) > > >Any comments ? This is a well known problem. The cause: YOU ARE USING THE WRONG COMPILER! Use GCC rather than CC. CC, in is infinite wisdom, sticks unecessary floating point instructions in every subroutine and does not remove them unless you turn on optimization (-O) which unfortunately you can't do if you need the -g option (in case you are using dbxWorks). The reason the system reboots (or hangs) is that the ISR is being invoked while the 68881/2 is in the middle of executing a FP instruction. In order to save the state of the FP coprocessor so that the interrupted FP instruction can be resumed, a FSAVE instruction must be executed BEFORE any new floating point operations can be performed. Failing to do so will cause the CPU to issue FP coprocessor Protocol Violation exception which is bad news. If your ISR really neeeds to do FP operations, it has to execute an FSAVE instruction in its prolog. (I believe WRS has added an option to intConnect that now allows you to do this). When switching tasks, this step is performed for you automatically by the kernel when the new task has the FP_USED bit set. --Marc Ullman Stanford University From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Thu Sep 12 06:17:48 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Thu Sep 12 06:17:55 PDT 1991 Subject: Re: Subnets The subject of subnets was addressed at the East Coast user group meeting this week. Mike Anderson gave a very good talk on how to set up networking by dedicating a class C IP address to each crate and each network. For those who can't afford to do this and need to use subnets to conserve IP addresses, Dave Wilner of Wind River said that they were going to be putting in the proxy arp support that would allow people to use one IP address without having to explicitely set up subnets. A few months ago we went through the grief of setting up subnetting correctly. It was not trivial to get it all working since nobody seems to have written down all the rules that must be followed (we did get a lot of good pointers from people on the exploder and usenet). Using proxy arp would be the easiest approach if you can wait for the WRS implementation. It was not clear to me when that might be available. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From hmp@frc2.frc.ri.cmu.edu Thu Sep 12 06:40:00 1991 From: hmp@frc2.frc.ri.cmu.edu Date: Thu Sep 12 06:40:08 PDT 1991 Subject: Re: VxWorks header files > >We have had the same sort of problems. The "ANSIfication" of the header >files seems to be the base of the problem. All WRS fixes so far, are: >"patch and wait for the next release". Fortunately, so far, all are easy to >work around. At least WRS have given us most ANSI headers. We have had to >make our own for our host (SUN)! Would you be willing to share those SUN header files with us? -Henning From mkannan@hns.com Thu Sep 12 07:15:37 1991 From: mkannan@hns.com (Mangala Kannan) Date: Thu Sep 12 07:15:47 PDT 1991 Subject: Re: Subnets I am very much interested in knowing about this. I raised a question in the East coast users group meeting to know more about it. We have multiple interfaces in our project for which this concept might be useful. Please keep me posted. Thanks in advance Mangala Kannan Hughes Network systems 11717 Exploration Lane, Germantown MD 20878 email : mkannan@hns.com mangala From hill@luke.atdiv.lanl.gov Thu Sep 12 08:02:46 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Sep 12 08:02:53 PDT 1991 Subject: Re: TAS problem ? Some huerikon CPUs dont implement vxTas() properly on the VME bus. The problem occured because they didnt force the test and set to occur without intervening VME cycles. The result was a test at the desired location and a set at a spurious location left by the last VME access. From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Thu Sep 12 08:16:48 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Thu Sep 12 08:16:59 PDT 1991 Subject: Re: TAS problem ? Oliver, It appears that you may be using a local dual port memory location on one of your boards for the TAS byte. The alternative would be to use some location on a global memory card. With the approach I think you are taking then the MVME147 has to have the HW support for indivisible operations and contention from both the backplane and the local processor. We don't use 147s but our RADSTONE boards have options (in their VME interface controller) as to whether to support indivisible operations to local dual port. If possible, it is better to put multiprocessor variables in global memory since it keeps access to the flags from one CPU from affecting local operation of the other (if the flag is in one procs dual port, then attempts to get the flag by the other should lock out memory access from the local CPU too which can really slow down operation). Hope this helps. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From biocca@bevsun.bev.lbl.gov Thu Sep 12 08:57:21 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Sep 12 08:57:31 PDT 1991 Subject: Re: Subnets ----- Begin Included Message ----- From rg@msel.unh.edu Wed Sep 11 17:00:25 1991 The Powers That Be have decreed that I may not have a subnet, because it wastes too many addresses. (Our subnet mask is 255.255.252.0. Argh.) Is it possible to use some "officially unassigned" throwaway addresses for the backplane subnet? Is there any address range that is designated as temporary local addresses? I was planning on using 90.0.0.*, having my development system route all such addresses to the vxworks cage(s), and also having a bridge upstream from me filter out all accesses to these addresses. (What is 90.0.0.*? Anyone I might want to talk to? :-) a) Would this work? b) Is it a good idea? ----- End Included Message ----- The best alternative at the moment is to use part of a legal subnet for your backplane. To do this set up the vme crate as though it has a legal subnet for your network. Set up your host with host routes only for those specific addresses in use on your backplane, and point those routes to the vxWorks gateway processor for that crate. The subnet addresses should be unique -- they should not be used by any other hosts. This way you use only as many addresses as you need. One arrangement is to have a single subnet assigned to you for all your crates -- you can divide it up and thus only use one subnet for them all. Another solution is to use some addresses from a special purpose subnet. For example, at LBL we have a number of point-to-point links that need IP addresses even though no one ever sees the addresses except the link ends. A subnet is used for all of these addresses and some of them could be used for purposes like vxWorks. The downside of this solution is that only that host can reach those secondary processors. Other hosts needing to reach them must also have the host routes, and this becomes a maintenance problem if very many are involved. Additionally, the secondaries will have difficulty talking with hosts that are really on the subnet they think they're on -- they'll expect these hosts to be on the backplane. We need a better solution, but this does work for now. ----- Begin Included Message ----- Subject: Re: Subnets Submitted-By: smb@afterlife.ncsc.mil (Steve M. Burinsky) Am I missing something here? Netmasks need not align with octet boundaries. You could specify your netmask to be 0xfffffffe, which creates a subnet containing only 2 hosts. Could we please dispense with this annoying advertisement! ----- End Included Message ----- Steve is correct -- netmasks need not align with octets. The netmask must be constant for the net, though, so you cannot move it on the wire unless you have your own wire. We ran that way at the BEVALAC for awhile and found that we had to hack SunOS in our router to handle differing netmasks -- there is a field in the ifconfig to specify netmask but in the kernel there was only one variable for all interfaces. This could be solved by buying a real router, or perhaps newer SunOS or some other OS would not have this problem. If you don't have your own wire you can still change the netmask of the backplane. Two bits probably isn't enough for most things, because 00 and 11 are reserved for broadcasts leaving only room for two hosts and one must be the gateway. The host and routers still have a major problem. They have difficulty differentiating packets headed toward the secondaries and determining which gateways to point them at. To do this each route needs its own netmask, or host routes are necessary (one route for each secondary processor). Per route netmasks aren't supported by most workstations, but many routers would handle this. Host routes are, as mentioned above, a maintenance hassle. The biggest problem with all of this is the confusion factor. It doesn't seem all that complicated but it turns out to be hard to diagnose problems and seemingly unimportant changes in configuration often cause subtle problems or total deadlock. The vxWorks manager must work closely with site network administration, and educate them in the complexities of routing lots of small networks. I have found in practice that this complexity leads to single- person maintenance -- backup people cannot debug failures. I'll condense the advertisement. Alan K Biocca BEVALAC Controls Group From hebo@mbari.org Thu Sep 12 08:57:25 1991 From: hebo@mbari.org (Bob Herlien) Date: Thu Sep 12 08:57:37 PDT 1991 Subject: Re: Subnets > > Am I missing something here? Netmasks need not align with octet boundaries. > You could specify your netmask to be 0xfffffffe, which creates a subnet > containing only 2 hosts. > In answer to Alan Biocca's original question, YES!, we're quite interested in proxy arping to allow routing through vxWorks. In response to Steve Burinsky's reply above, I don't know enough about routing and subnetting to know whether your solution is adequate in general, but I suspect not. As an example, let me describe our system. We have two buildings, a ship, and are building an ROV (robot submarine) to be deployed from the ship, all of which have or need Internet connectivity. To get from the outside world to the CPU's on the ROV (doing so is a goal of the design) requires getting to our router on the Internet, routing via a T1 microwave link to the ship, going though its router to a vxWorks crate on board ship, going through a vxWorks-vxWorks SLIP link (using a 4MB synchronous fiber-optic connection to the ROV), and finally reaching the vxWorks crate on the ROV, which may have multiple CPU's communicating via backplane IP. Our standard subnetting is 8 bits. We use an 8-bit subnet for each building, and one for the ship (which has other computers connected to Internet). I'm not sure how many subnets I need in the above scenario, but I suspect that it will not be possible to assign only a 2-bit subnet mask at the final level, and still be able to reach it from the upstream levels. Can anybody clarify for me? I am interested in proxy arping, aren't I? ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From hebo@mbari.org Thu Sep 12 09:26:28 1991 From: hebo@mbari.org (Bob Herlien) Date: Thu Sep 12 09:26:34 PDT 1991 Subject: Re: bug with select 5.0 > > I think there is a bug in the select function with VxWorks 5.0. This > bug seems to occur when file descriptors exceed 31. In this case, select does > the following: > [description deleted] I can verify that there is a select() bug in 5.0. I haven't been able to fully characterize it, which is why I haven't turned in a bug report. But I can describe its behavior in NTP (Network Time Protocol), which I have been porting to vxWorks. After initialization, the ntpd task goes into a forever loop in which it calls select() looking for a read from two file descriptors. When I first ported it, there were quite a few files open, so the two bits in question formed the mask 0x11000 (33 bits long). Things worked correctly; that is, it would return with a mask of either 0x1000 or 0x10000 (only one read completes at a time). I then deleted a couple of open files, and NTP broke! What happened is that the readfds mask became 0x5000 (31 bits). When select() returned, it always returned both bits set, even though only one read had completed. I made NTP work by using a global variable to indicate which read really completed, but the erroneous select() behavior is still there. My bug report seems to differ from Oliver's though, in that in my case, it only works if fds > 32, while Oliver says it breaks in that case. In any case, I'm happy that Oliver has found a test case to demonstrate the bug. When WRS fixes the bug, will somebody please post the patch? I'll then try it out on NTP to see if it's the same bug. Thanks. P.S. NTP is now basically working, with a few bugs. I'll put it on the archive within the next few weeks. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From biocca@bevsun.bev.lbl.gov Thu Sep 12 09:33:38 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Sep 12 09:33:46 PDT 1991 Subject: Re: TAS problem ? ----- Begin Included Message ----- Subject: TAS problem ? Submitted-By: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) It seems I have problems with multi-processor TAS on MV147: ... it works a few moments and then target1 and target2 loops in the while statement. Can anybody help ? ----- End Included Message ----- A Good quick check of how good the documentation and hardware on a CPU is to look up TAS in the card's manual. If they have not included a section on this problem area they may not have given enough care to have solved the tricky problems correctly... There is a control register on the MV147 that causes TAS to work correctly with on-board memory. It effectively causes all TAS instructions to arbitrate the VME bus even if the address of the location is onboard. This is required to insure that TAS is uninterrupted by remote access to local memory. There is a discussion of the problem and solution in the MV147 manuals. Using external memory avoids this problem since all processors must arbitrate the VME bus to gain access. Alan K Biocca BEVALAC Controls Group From ddrg%mentor.gandalf.ca@Csa2.LBL.Gov Thu Sep 12 09:41:35 1991 From: ddrg%mentor.gandalf.ca@Csa2.LBL.Gov (Duncan Glendinning) Date: Thu Sep 12 09:41:43 PDT 1991 Subject: Re: Subnets jjohnson@hns.com writes: > Yes!yes!yes! > In the system we're putting together a network of multiple subnets. I > have a similiar situation the current Vxworks networking configuration > is inadequate. The networking in our configuration doesn't have VME to > access other networks , I have T1 bridge. I have been looking into > implementing Proxy Arp also. Yes, I am interested and would like > Vxworks to incorporate this standard. > > Please keep me informed. Thanks in advance. > > Jayne Johnson > Hughes Network Systems > 11717 Exploration Lane > Germantown , Md 20874 > tel : 301-428-2714 > email : jjohnson@hns.com We too woulld be very interested in solving this problem. Requiring a private subnet poses a number of problems, particularly when producing a product that may end up in someone else's network. -- Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca Gandalf Data Ltd. Voice: (613) 723-6500 Nepean, Ontario Fax: (613) 226-1717 Canada K2E 7M4 From marc@sun-valley.stanford.edu Thu Sep 12 10:32:16 1991 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Thu Sep 12 10:32:22 PDT 1991 Subject: Re: Subnets >> Am I missing something here? Netmasks need not align with octet boundaries. >> You could specify your netmask to be 0xfffffffe, which creates a subnet >> containing only 2 hosts. >> >We have two buildings, a ship, and are building an ROV (robot submarine) >to be deployed from the ship, all of which have or need Internet connectivity. >To get from the outside world to the CPU's on the ROV (doing so is a goal >of the design) requires getting to our router on the Internet, routing via >a T1 microwave link to the ship, going though its router to a vxWorks >crate on board ship, going through a vxWorks-vxWorks SLIP link (using >a 4MB synchronous fiber-optic connection to the ROV), and finally reaching >the vxWorks crate on the ROV, which may have multiple CPU's communicating >via backplane IP. > >Our standard subnetting is 8 bits. We use an 8-bit subnet for each building, >and one for the ship (which has other computers connected to Internet). I'm >not sure how many subnets I need in the above scenario, but I suspect that it >will not be possible to assign only a 2-bit subnet mask at the final level, >and still be able to reach it from the upstream levels. Can anybody clarify >for me? I am interested in proxy arping, aren't I? We have been using a four bit subnet mask (ffffff0) for over two years. This provides up to sixteen levels of subnets below one class C network. We have networks that are curretly four layers deep and they work fine with full interconnection between every host both on the subnets and above. The trick is to get the routing tables set up corectly. The VxWorks targets all have a default route to pass any packet destined for a host they don't know about to the target just upstream. And they have a route for each subnet below them specifying that said packets should be forwarded to the processor immediately down stream of them. --Marc Ullman Stanford University From SMEG%bnr.ca@Csa2.LBL.Gov Thu Sep 12 11:15:59 1991 From: SMEG%bnr.ca@Csa2.LBL.Gov (M.A.) Date: Thu Sep 12 11:16:06 PDT 1991 Subject: re: Subnets Here is an IP addressing scheme that may be what you are looking for... The 127.* network is available for use within your host only. Just define your hosts to be the whole rack. The one thing that you *cannot* do is send or receive a packet with 127 network source or destination address outside of your host. Consider a rack of 4 vxWorks targets, one of which has an ethernet chip. Each card talks to the others using backplane IP with the 127 net addresses. External equipment can talk to one of the cards using the external IP address that is consistent with that sites subnetting scheme. Of course, if you had an external host that wanted to reach a card other than card 0 (see diagram below), it would be a two step operation. Eg. to log in to the shell on card 2 from a workstation out on the ethernet, the user would have to rlogin (or telnet) to card 0 (90.128.0.3) and then rlogin to card 2 (127.0.1.2). ie. cards 1, 2 and 3 could never send a packet to or receive a packet from the ethernet directly. The IP address configuration of the interfaces would be as follows: (Looking down at the rack from above) :---------------------------------------------------------------: : 127.0.1.0 : 127.0.1.1 : 127.0.1.2 : 127.0.1.3 : : (backplane) : (backplane) : (backplane) : (backplane) : :---------------------------------------------------------------: : : : : : : : : : : : : : : : : : : : : : : : : : : card 0 : card 1 : card 2 : card 3 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :---------------------------------------------------------------: 47.0.1.2 (ethernet) The nice thing is that you only have to configure one IP address per rack (the externally visible ethernet interface) and your system knows how to contact each card without configuration. Hope this helps ...Maarten... ps. don't assign 127.0.0.1 to a backplane interface, that is typically used for local loopback. -- Maarten Koning - Bell-Northern Research - Ottawa, Canada - smeg@bnr.ca From biocca@bevsun.bev.lbl.gov Thu Sep 12 11:19:22 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Sep 12 11:19:30 PDT 1991 Subject: Newsgroup Creation I have been asked to consider making a Usenet newsgroup Comp.realtime.vxworks. While I endorse the newsgroup idea, and if one is created will consider the task of building the connection between the newsreader and the mailing list (which will shrink but not go away). I have my hands full with the exploder, however, and someone who is more familiar with the newsgroup creation process should take that task. Do we have a volunteer who is experienced with this??? Alan K Biocca BEVALAC Controls Group From lapp@waterloo.hp.com Thu Sep 12 14:07:28 1991 From: lapp@waterloo.hp.com (Dave Lapp) Date: Thu Sep 12 14:07:35 PDT 1991 Subject: Re: Subnets >We have two buildings, a ship, and are building an ROV (robot submarine) >to be deployed from the ship, all of which have or need Internet connectivity. >To get from the outside world to the CPU's on the ROV (doing so is a goal >of the design) requires getting to our router on the Internet, routing via >a T1 microwave link to the ship, going though its router to a vxWorks >crate on board ship, going through a vxWorks-vxWorks SLIP link (using >a 4MB synchronous fiber-optic connection to the ROV), and finally reaching >the vxWorks crate on the ROV, which may have multiple CPU's communicating >via backplane IP. > >Our standard subnetting is 8 bits. We use an 8-bit subnet for each building, >and one for the ship (which has other computers connected to Internet). I'm >not sure how many subnets I need in the above scenario, but I suspect that it >will not be possible to assign only a 2-bit subnet mask at the final level, >and still be able to reach it from the upstream levels. Can anybody clarify >for me? I am interested in proxy arping, aren't I? Subnetting should do what you want. The important things are, as someone already mentioned, getting the routes set up correctly and getting the subnet masks within your subnetted network correctly set. Subnetting does everything proxy arp can do and is considered the 'proper' way of doing things. If I understand correctly your configuration is something like: router (on dry land) | | microwave link | V router (on the ship) | -------------------------------- | | | | Other computers on | the ship | vxWorks crate on ship | | | | | | | | | | | | fiber to ROV | | vxWorks crate on ROV | | | | CPUs in ROV The way subnetting works is to split a network up (surprise surprise). It sounds as though you have a class C (or equivalent) range of addresses assigned to this ship. Lets assume that this network is 193.1.1.0 To the land based router the ship will still appear to be a single class C network. What you need is a seperate subnet for each crate and the another subnet (or maybe more) for the network of host systems on the ship. Lets assume that you have no more then 14 CPUs in any one crate. (Why 14 ? Because its best to avoid hosts with addresses of 0 or 1's :-) Lets further assume you have no more then 14 systems on the ship (counting the router and one vxWorks CPU (which is really another router) but excluding the other CPUs in the crates). These assumptions aren't needed to make subnetting work but help in explaining it. Given these assumptions you can use a subnet mask of 255.255.255.240 This splits your class C network into 16 subnets (193.1.1.0 to 193.1.1.240) That is subnet 0 has addresses from 193.1.1.0 to 193.1.1.15, subnet 1 has addresses in the range 193.1.1.16 to 193.1.1.31, ... and subnet 16 has addresses in the range 193.1.1.240 to 193.1.1.255. Now: 1) Assign the backplane interface on th CPUs in the ROV crate addresses in the range 193.1.1.0 to 193.1.1.15 (ie. subnet 1 (avoid 193.1.1.0 and 193.1.1.15 :-)) 2) Assign the backplane interface on the CPUs on the ship addresses on subnet 2. (Avoid .16 and .31) 3) Assign the all systems on the ship connected to the router (including the vxWorks board) addresses on the 3rd subnet. (Avoid ...) 4) Assign the point to point interfaces (ie the 2 ends of the fiber link and the 2 ends of the microwave link) addresses from the 4th subnet. 5) Set the subnet mask (on all interfaces) for all systems, vxWorks CPUs and the router on the ship and ROV to 255.255.255.240. 6) Set a default route on all the CPUs in the ROV pointing to the board which has the fiber link. (Except the board with the fiber link) 7) Set a default route on the CPU in the ROV which has the fiber link which points to the other side of the fiber link. (ie the address on subnet 4) 8) Set a default route on all the CPUs in the crate on the ship pointing to the board connected to the router. (Except once again the board connected to the router) 9) Set a route to subnet 1 on all the CPUs in the crate on the ship pointing to the board with the fiber link. (Except the board with the fiber link.) 10) Set a route to subnet 1 on the fiberlink board in the crate on the ship which points to the other side of the fiber link. (ie points to the address of the other end of the fiberlink on subnet 4) 11) Set default routes in all the systems on the ship pointing to the router. 12) Set routes to subnet 1 and 2 in all the systems and the router on the ship pointing to the vxWorks board connected to the router. 13) On the router on the ship make the default route point to the router on land. The routes on land don't need to change. Its the job of the equipment on the ship/ROV to route the messages appropriately. That (or some variation) should do what you want. That all looks pretty complicated but once its set up it should work properly. Hope I haven't confused you (and that I got it all right :-) Dave Lapp lapp@waterloo.hp.com Standard Disclaimer etc... From wrs!schuylkill!bob@uunet.uu.net Thu Sep 12 16:05:01 1991 From: wrs!schuylkill!bob@uunet.uu.net Date: Thu Sep 12 16:05:08 PDT 1991 Subject: Re: bug with select 5.0 There is indeed a known bug in VxWorks 5.0 select, which can be worked around by setting the width argument to select to its maximum value (FD_SETSIZE = 256). The bug causes the read and write fd_sets to be zero'ed incorrectly, so the bits initially set sometimes are incorrectly returned to the user. Setting width = 256 will cause all the bits to be zero'ed correctly. Bob Cohen Wind River Systems From wrs!yuba!kent@uunet.uu.net Thu Sep 12 18:29:56 1991 From: wrs!yuba!kent@uunet.uu.net (Kent Long) Date: Thu Sep 12 18:30:02 PDT 1991 Subject: Re: bug with select 5.0 > > There is indeed a known bug in VxWorks 5.0 select, which can be worked > around by setting the width argument to select to its maximum value > (FD_SETSIZE = 256). > The bug causes the read and write fd_sets to be zero'ed incorrectly, so the > bits initially set sometimes are incorrectly returned to the user. > Setting width = 256 > will cause all the bits to be zero'ed correctly. > > Bob Cohen > Wind River Systems I just want to add that this bug is now fixed in the VxWorks 5.0.2 (for gcc) and 5.0b (for native tools) releases. - kent Kent Long Wind River Systems From KADIONIK@frcpn11.in2p3.fr Thu Sep 12 22:31:01 1991 From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik) Date: Thu Sep 12 22:31:07 PDT 1991 Subject: subnet problems *************************************************** * Subjet : subnet problems * *************************************************** Hi ! I have actually problems with the subnet addressing. We have an IP class B address for all the CNRS Nuclear Physic labs (134.158.) and have a subnet mask that permit to distinguish each lab from the other. It have been attributed to us the submask : 255.255.248.0 (0xfffff800). I have a VME crate with a MVME 147 card for Ethernet acces and a MVME 165 card for its VSB possibilities (and other VME/VSB cards for data acquisition). I have declared my two targets in the /etc/hosts and /etc/hosts.equiv . The host IP address is : 134.158.83.1 (subnet mask :0xfffff800) The MVME card IP address is : 134.158.84.2 . It is the gateway for access to the backplane network. I actually have choosen to attribute to the backplane network the IP address 134.158.144.00 with a subnet mask of 255.255.255.0 . The MVME 147 card has also the backplane IP address 134.158.144.1 and the MVME 165 card, the backplane IP address 134.158.144.2 . --------------------------------------------------------------------------- On the Unix side, I have declared the MVME 147 card as gateway. ( # route add 134.158.144.0 134.158.84.2 1) For the MVME 147 boot parameters, I have entered : inet on ethernet : 134.158.84.2:fffff800 inet on backplane : 134.158.144.1:ffffff00 host inet : 134.158.83.1 For the MVME 165 boot parameters, I have entered : inet on backplane : 134.158.144.2:ffffff00 host inet : 134.158.83.1 gateway : 134.158.144.1 All the two cards boot properly. I have after declared a default routing for the MVME 165 : vw_165-> routeAdd "0", "134.158.144.1" --------------------------------------------------------------------------- I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1 and 134.158.84.2) from the MVME 165 card but I can't acces to the other hosts (for example 134.158.83.2) from the MVME 165 card. I can from the MVME 147 card. So, what is the problem ? Why can I not reach the 134.158.83.2 host from the MVME 165 for example ? Thank's. Patrice. kadionik@frcpn11.in2p3.fr ------ ------ | lys | | rose | | SUN | | SUN | ------ ------ ** 134.158.83.1 ** 134.158.83.2 ** ** ** ** ************************************************** ** Ethernet network 134.158.80.0:fffff800 ** ** 134.158.84.2 ------ | lily | GATEWAY |VME147| ------ ** 134.158.144.1 ** ** backplane network 134.158.144.0:ffffff00 ************************************************** ** ** 134.158.144.2 ------ | rosy | |VME165| ------ From pat@wrs.com Fri Sep 13 02:26:58 1991 From: pat@wrs.com (Patrick Boylan) Date: Fri Sep 13 02:27:08 PDT 1991 Subject: Re: subnet problems Patrice, In refernce to your question: > > On the Unix side, I have declared the MVME 147 card as gateway. > ( # route add 134.158.144.0 134.158.84.2 1) > ... > > I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1 > and 134.158.84.2) from the MVME 165 card but I can't acces to the other > hosts (for example 134.158.83.2) from the MVME 165 card. > I can from the MVME 147 card. > > So, what is the problem ? > Why can I not reach the 134.158.83.2 host from the MVME 165 for example ? > > > Thank's. > > > Patrice. > kadionik@frcpn11.in2p3.fr > Your gateway from the boot host must be working if both targets are booting correctly. To access other hosts you may need to add the gateway to the route table of these hosts also. Is the gateway registered in the route table on the other host ("rose")? If not try adding it. Use: rose% route add net 134.158.144.0 134.158.84.2 1 Hope that helps. - Patrick -- Patrick Boylan Wind River Systems 1010 Atlantic Ave. Alameda, CA 94501 pat@wrs.com (415)748-4100 From mea@sparta.com Fri Sep 13 04:42:19 1991 From: mea@sparta.com (Mike Anderson) Date: Fri Sep 13 04:42:26 PDT 1991 Subject: Re: Subnets Alan, Yes, judging from the responses at the East Coast VxWorks Users Group meeting (thanks to all that attended and especially the folks I was able to sucker err... convince to speak for us!) there is a considerable interest in proxy arp as well as other solutions to solve some of the problems associated with deep network heirarchies. Having subnets does solve some of the problems such as the address space issue, but for many of the current SBCs that have on 128 Bytes of NV RAM then the new 5.x NV RAM options (target name, etc.) make the use of subnets untenable (e.g., 192.9.200.1:FFFFFFC0 is a lot of bytes). Clearly, something like proxy arp would be a viable alternative. I find it interesting that a fair amount of the discussions I've been having lately with folks seem to center around the use of VxWorks as a general purpose operating system rather than just a real-time environment. Evidence this discussion. The true real-time purists believe that real-time and networks are mutually exclusive terms. But here we are talking about a proxy arp daemon for use under VxWorks. A decidedly non real-time sort of facility. In fact, I'm seeing more of a push for things like MMU support (virtual memory on a real-time system !?!) and other such elements that would have been unthinkable 1-2 years ago. Mind you, I don't think these directions are bad (I was using VxWorks as a general purpose O/S 4 years ago in Ada as the alpha site for VADSWorks running distributed simulations) I just find it curious. BTW, for those folks out there who where using ProNet-80 boards under 4.0.2 and were disappointed to find that WRS discontinued support under 5.x, I have some good news. I have just finished re-integrating ProNet support back into 5.0.1 (including boot ROMs to boot from ProNet) and would be happy to send the hacked Makefiles and resurrected ProNet code (there's a lot of non-obvious stuff you have to do to get it to work with 5.x) to anyone who's interested. =============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessamist fears that this is true." J.B. Cabell =============================================================================== ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov From mea@sparta.com Fri Sep 13 04:50:28 1991 From: mea@sparta.com (Mike Anderson) Date: Fri Sep 13 04:50:35 PDT 1991 Subject: Re: Subnets Greetings, One thing that I used at one point in time was class "D" addresses. The addresses looked like "224.xxx.xxx.xxx" and seemed to work with VxWorks and SunOS just fine. As I understand it, 224 addresses are experimental ones and are typically used for testing IP Multicast internally on LANs (i.e., no one on the Internet has a registered class D address). This might be O.K. for you to use without worrying about sucking up someone's mail. Also, just make sure that your gateway doesn't advertise any routes to these addresses (i.e., static entries in routing tables rather than using routed or gated on those machines that will talk to your VxWorks hosts) and the Internet will be unaware of the existence of your real-time boxes. Good Luck, =============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessamist fears that this is true." J.B. Cabell =============================================================================== ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov From KADIONIK@frcpn11.in2p3.fr Fri Sep 13 05:06:50 1991 From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik) Date: Fri Sep 13 05:06:58 PDT 1991 Subject: subnet problems, precision Hi ! I have omitted to say in my request that the host "lys" (134.158.83.1) uses the NIS for the network administration. So, the host "rose" (134.158.83.2) should know that "lily" (134.158.84.2) is the gateway for the backplane network (134.158.144.0)... From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Fri Sep 13 06:17:20 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Fri Sep 13 06:17:26 PDT 1991 Subject: Re: Subnets Below are two different questions about subnets. > Am I missing something here? Netmasks need not align with octet boundaries. > You could specify your netmask to be 0xfffffffe, which creates a subnet > containing only 2 hosts. > >Our standard subnetting is 8 bits. We use an 8-bit subnet for each building, >and one for the ship (which has other computers connected to Internet). I'm >not sure how many subnets I need in the above scenario, but I suspect that it >will not be possible to assign only a 2-bit subnet mask at the final level, >and still be able to reach it from the upstream levels. Can anybody clarify >for me? I am interested in proxy arping, aren't I? As I said in an earlier posting, we could find no published rules on subneting but after a lot of research, and trying something like the scheme above to no avail but getting a different subnetting scheme to work, I think some pertinent rules are: 1) Subnets are meant to break a flat address space into a two level hierarchy where there is a single network connecting a bunch of independent networks. For example, an ethernet connecting a bunch of crates with backplane networks. There has to be a consistent value for the subnet mask value throughout a subnetted network. You can't keep splitting the address to get a tree type interconnection. 2) The main interconnection network is one subnet and each of the independent nets is a network. In the example the ethernet is one subnet and the backplanes are each subnets. 3) To the outside world, the whole network looks like it is all part of one IP address; the subnets are transparent. If you have a host (e.g. a SUN) bridging between the embedded ethernet and the outside world, then it is the only host that needs to know that the embedded network is subnetted. 4) While subnet masks don't need to be octet aligned, there is some question as to whether all network SW will handle unaligned masks. In particular, we have heard that SUNs can't. 5) The "host" part of a subnetted address should not take on the values 0 or all ones since these are used in various implementations for broadcasts. The main point above is two. If you have a lot of crates connected by ethernet, your subnet mask has to allow enough host identifiers to address all of the ethernet interfaces on all of the crates. This basically means that you never could have more subnets than hosts on a given subnet since you wouldn't be able to satisfy the interconnection rule if you did. For all intents and purposes, you will always have as many of more bits in the host part of the subnet mask than in the subnet part if you want to make maximum use of subnets. Hope this helps (I'm assuming its right but like I said, its hard to get the real facts on this stuff). Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From biocca@bevsun.bev.lbl.gov Fri Sep 13 08:38:56 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Fri Sep 13 08:39:01 PDT 1991 Subject: Re: Subnets > Submitted-by: Fred Roeber (fjr@iss-ipc1.ssd.ray.com): (Condensed) > > I think some pertinent rules are: > > 1) Subnets are meant to break a flat address space into a two level hierarchy > where there is a single network connecting a bunch of independent networks. > For example, an ethernet connecting a bunch of crates with backplane > networks. There has to be a consistent value for the subnet mask value > throughout a subnetted network. You can't keep splitting the address to > get a tree type interconnection. Actually, you can. The depth of the tree is limited, but the model of the internet is based on these addresses and is certainly not limited to two levels. In fact, if you have 254 subnets in your address you can build any tree that has that many nodes. It is not limited to two levels. Subnetting makes the routing easier -- looking at a few bits tells which gateway to forward to. The subnet mask must be consistent on each wire -- not throughout the entire system. It is in fact possible to change subnet masks each time you cross a router. We ran the BEVALAC on a labwide 6 bit subnet, 10 bit host net and we made our control wire 10 bit subnet, 6 bit host. This allowed us to take each subnet given us by the network folks on the 6/10 net and turn it into 16 10/6 subnets. The primary difficulty here is having a router that can handle differing subnets on different interfaces. We hacked SunOS 3.5 to handle this correctly. It may be fixed in later versions, we haven't done that since we moved to a 8/8 subnets where there was more address space before upgrading. Using a commercial router instead of a server would solve this problem in any case. > 4) While subnet masks don't need to be octet aligned, there is some question > as to whether all network SW will handle unaligned masks. In particular, > we have heard that SUNs can't. We have significant experience here with Suns, and this is not a problem. Suns handle unaligned netmasks fine. The labwide 6/10 network has 700+ hosts and many of those are Suns. Alan K Biocca BEVALAC Controls Group From biocca@bevsun.bev.lbl.gov Fri Sep 13 08:46:29 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Fri Sep 13 08:46:37 PDT 1991 Subject: Re: subnet problems, precision Submitted-by: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik) I have omitted to say in my request that the host "lys" (134.158.83.1) uses the NIS for the network administration. So, the host "rose" (134.158.83.2) should know that "lily" (134.158.84.2) is the gateway for the backplane network (134.158.144.0)... I don't see how NIS is going to help here. NIS doesn't install routing in the kernel. That must be done with route add commands at boot time or by root. The problem is that you have added 'networks' to your environment by adding secondary processors. The boot host has a route, but the other hosts also need one. The hosts in your net should have a default route pointing to a router that connects to the next layer up of network. IF that router has a route to your backplane network via the gateway then all hosts everywhere will be able to get to the crate. In summary, either each host must have a route, or the gateway they point to must have one. Alan K Biocca BEVALAC Controls Group From lapp@waterloo.hp.com Fri Sep 13 09:25:44 1991 From: lapp@waterloo.hp.com (Dave Lapp) Date: Fri Sep 13 09:25:50 PDT 1991 Subject: Re: Subnets > > Submitted-by biocca@bevsun.bev.lbl.gov Fri Sep 13 08:38:56 1991 > Submitted-by: biocca@bevsun.bev.lbl.gov (Alan K Biocca) > > > Submitted-by: Fred Roeber (fjr@iss-ipc1.ssd.ray.com): (Condensed) > > > > I think some pertinent rules are: > > > > 1) Subnets are meant to break a flat address space into a two level hierarchy > > where there is a single network connecting a bunch of independent networks. > > For example, an ethernet connecting a bunch of crates with backplane > > networks. There has to be a consistent value for the subnet mask value > > throughout a subnetted network. You can't keep splitting the address to > > get a tree type interconnection. > > Actually, you can. The depth of the tree is limited, but the model of the > internet is based on these addresses and is certainly not limited to two > levels. In fact, if you have 254 subnets in your address you can build any > tree that has that many nodes. It is not limited to two levels. > Multi level subneting is certainly possible. > > The subnet mask must be consistent on each wire -- not throughout the entire > system. It is in fact possible to change subnet masks each time you cross > a router. We ran the BEVALAC on a labwide 6 bit subnet, 10 bit host net and > we made our control wire 10 bit subnet, 6 bit host. This allowed us to > take each subnet given us by the network folks on the 6/10 net and turn it > into 16 10/6 subnets. The primary difficulty here is having a router that > can handle differing subnets on different interfaces. We hacked SunOS 3.5 > to handle this correctly. It may be fixed in later versions, we haven't > done that since we moved to a 8/8 subnets where there was more address > space before upgrading. Using a commercial router instead of a server > would solve this problem in any case. > And given the BSD based network code in the vxWorks it is best if the subnet mask is consistent for all interfaces when using a vxWorks system as a router as well. Dave Lapp Standard Disclaimer etc... From wrs!mac_smtp!Leigh_Barker@uunet.uu.net Fri Sep 13 09:47:59 1991 From: wrs!mac_smtp!Leigh_Barker@uunet.uu.net (Leigh Barker) Date: Fri Sep 13 09:48:06 PDT 1991 Subject: Christina Goette :Unknown M GatorMail-Q Christina Goette :Unknown M Received: by mac_smtp.wrs.com; 13 Sep 91 07:09:11 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA20876; Fri, 13 Sep 91 07:00:48 PDT Received: from vxw.ee.lbl.gov by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24346; Fri, 13 Sep 91 05:53:43 -0400 Received: by vxw.ee.lbl.gov (4.1/s2.2) id AA12679; Fri, 13 Sep 91 02:27:13 PDT Date: Fri, 13 Sep 91 02:27:13 PDT Message-Id: <9109130927.AA12679@vxw.ee.lbl.gov> Errors-To: uunet!lbl.gov!vxwexplo-errs To: vxworks_users@vxw.ee.lbl.gov From: uunet!lbl.gov!vxwexplo (the vxWorks Users Group Exploder) Subject: Re: subnet problems Submitted-by pat@wrs.com Fri Sep 13 02:26:58 1991 Submitted-by: pat@wrs.com (Patrick Boylan) Patrice, In refernce to your question: > > On the Unix side, I have declared the MVME 147 card as gateway. > ( # route add 134.158.144.0 134.158.84.2 1) > .. > > I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1 > and 134.158.84.2) from the MVME 165 card but I can't acces to the other > hosts (for example 134.158.83.2) from the MVME 165 card. > I can from the MVME 147 card. > > So, what is the problem ? > Why can I not reach the 134.158.83.2 host from the MVME 165 for example ? > > > Thank's. > > > Patrice. > kadionik@frcpn11.in2p3.fr > Your gateway from the boot host must be working if both targets are booting correctly. To access other hosts you may need to add the gateway to the route table of these hosts also. Is the gateway registered in the route table on the other host ("rose")? If not try adding it. Use: rose% route add net 134.158.144.0 134.158.84.2 1 Hope that helps. - Patrick -- Patrick Boylan Wind River Systems 1010 Atlantic Ave. Alameda, CA 94501 pat@wrs.com (415)748-4100 ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov From wrs!mac_smtp!Leigh_Barker@uunet.uu.net Fri Sep 13 09:48:07 1991 From: wrs!mac_smtp!Leigh_Barker@uunet.uu.net (Leigh Barker) Date: Fri Sep 13 09:48:19 PDT 1991 Subject: Christina Goette :Unknown M GatorMail-Q Christina Goette :Unknown M Received: by mac_smtp.wrs.com; 13 Sep 91 07:11:38 Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86) id AA20911; Fri, 13 Sep 91 07:03:16 PDT Received: from vxw.ee.lbl.gov by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08347; Fri, 13 Sep 91 07:55:23 -0400 Received: by vxw.ee.lbl.gov (4.1/s2.2) id AA12862; Fri, 13 Sep 91 04:42:30 PDT Date: Fri, 13 Sep 91 04:42:30 PDT Message-Id: <9109131142.AA12862@vxw.ee.lbl.gov> Errors-To: uunet!lbl.gov!vxwexplo-errs To: vxworks_users@vxw.ee.lbl.gov From: uunet!lbl.gov!vxwexplo (the vxWorks Users Group Exploder) Subject: Re: Subnets Submitted-by mea@sparta.com Fri Sep 13 04:42:19 1991 Submitted-by: mea@sparta.com (Mike Anderson) Alan, Yes, judging from the responses at the East Coast VxWorks Users Group meeting (thanks to all that attended and especially the folks I was able to sucker err... convince to speak for us!) there is a considerable interest in proxy arp as well as other solutions to solve some of the problems associated with deep network heirarchies. Having subnets does solve some of the problems such as the address space issue, but for many of the current SBCs that have on 128 Bytes of NV RAM then the new 5.x NV RAM options (target name, etc.) make the use of subnets untenable (e.g., 192.9.200.1:FFFFFFC0 is a lot of bytes). Clearly, something like proxy arp would be a viable alternative. I find it interesting that a fair amount of the discussions I've been having lately with folks seem to center around the use of VxWorks as a general purpose operating system rather than just a real-time environment. Evidence this discussion. The true real-time purists believe that real-time and networks are mutually exclusive terms. But here we are talking about a proxy arp daemon for use under VxWorks. A decidedly non real-time sort of facility. In fact, I'm seeing more of a push for things like MMU support (virtual memory on a real-time system !?!) and other such elements that would have been unthinkable 1-2 years ago. Mind you, I don't think these directions are bad (I was using VxWorks as a general purpose O/S 4 years ago in Ada as the alpha site for VADSWorks running distributed simulations) I just find it curious. BTW, for those folks out there who where using ProNet-80 boards under 4.0.2 and were disappointed to find that WRS discontinued support under 5.x, I have some good news. I have just finished re-integrating ProNet support back into 5.0.1 (including boot ROMs to boot from ProNet) and would be happy to send the hacked Makefiles and resurrected ProNet code (there's a lot of non-obvious stuff you have to do to get it to work with 5.x) to anyone who's interested. =============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessamist fears that this is true." J.B. Cabell =============================================================================== ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov ********** This is a user group mailing list for vxWorks related topics Submit articles to vxwexplo@lbl.gov for 'explosion' Send subscription requests & comments to vxwexplo-request@lbl.gov From kevinf@verdix.com Fri Sep 13 10:15:57 1991 From: kevinf@verdix.com (D. Kevin Faust) Date: Fri Sep 13 10:16:04 PDT 1991 Subject: VxWorks ethernet drivers Does anybody out there have source code, in the public domain, for a Motorola 374 ethernet card (MVME374) ? Kevin Faust kevinf@verdix.com From rjn@snowbird.labs.tek.com Fri Sep 13 10:23:30 1991 From: rjn@snowbird.labs.tek.com (Jim Nusbaum) Date: Fri Sep 13 10:23:38 PDT 1991 Subject: Subnets Mike Anderson wrote: > I find it interesting that a fair amount of the discussions I've been >having lately with folks seem to center around the use of VxWorks as a >general purpose operating system rather than just a real-time environment. >Evidence this discussion. The true real-time purists believe that >real-time and networks are mutually exclusive terms. But here we are >talking about a proxy arp daemon for use under VxWorks. A decidedly >non real-time sort of facility. In fact, I'm seeing more of a push for things >like MMU support (virtual memory on a real-time system !?!) and other such ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Actually I doubt MMU support is desired for virtual memory implementations. It is desireable for memory protection and segmentation. MMU's allow one to set up memory spaces on which the MMU will enforce access constraints. This is very desireable for mission critical systems, systems where more than one 'application' must run on the same processor and use the same memory and for situations where user code is going to be downloaded into a system which is also running an oem application (we don't want the user code to crash our software, just theirs). It does however require a different kernel implementation strategy. Kernel calls can generally no longer be just function calls, but must be processor traps that put the processor into supervisory mode. Jim Nusbaum, Computer Research Lab, Tektronix, Inc. [ucbvax,decvax,allegra,uw-beaver,hplabs]!tektronix!crl!rjn rjn@crl.labs.tek.com (503) 627-4612 From bernard@aar.alcatel-alsthom.fr Fri Sep 13 10:43:28 1991 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Fri Sep 13 10:43:39 PDT 1991 Subject: C++ on VxWorks We've been developping a mobile robot research project with C++ for now two years and are very pleased with this language. We are very interested in a C++ class library for VxWorks which gives access to the system components via class interface (semaphores, tasks, etc). Maybe a difficult point of the language is that the user may sometimes lose the control of the code produced by the compiler: a few time ago, we were very surprised because a task was taken 90 % of the CPU. This was because this task called a method which declares an array of objects: In "C" In "C++" struct bar class bar { { int x; public: int y; bar () { x = y = 0; } }; protected: int x,y; }; void foo () void foo () { { bar barTable[10000]; bar barTable[10000]; .... ... } } function cost = a few micro-sec function cost = a few SECONDS !!! (10000 constructor and destructor call each time) ... of course there is a solution to avoid this .. but it is not always easy to think of what the compiler is doing. It would be nice to have tools which give the programmer the complexity of the generated code. A problem with ATT 2.0 C++ - problems with static data (class members) which are declared as common in the a.out file ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ----------------------------------------------------------- From rg@msel.unh.edu Fri Sep 13 10:46:33 1991 From: rg@msel.lbl.gov (Roger Gonzalez) Date: Fri Sep 13 10:46:45 PDT 1991 Subject: Re: Subnets I'm getting lost. All I want is this: __________________________________________________ campus net - netmask 0xfffffc00 | le0 | | sparc 132.177.131.33 other workstations for development | le1 |______________________________________________ internal development net | | ======= vme crate ======= vme crate ||||||| ||||||| target cpus target cpus running vxworks running vxworks I have no control over the campus net. I have to request an address whenever I want to put a new machine up. The campus Net Dictators have told me that they don't want to let me have any subnets. How can I set this up? All this subnetting talk has made my head swim. Can I request a range of addresses from the Dictators, and set up routing on a per-host basis? Please help me! (All I have right now is one target CPU - but I'm trying to plan for the future) -Roger "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra Roger Gonzalez - rg@msel.unh.edu UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) From biocca@bevsun.bev.lbl.gov Fri Sep 13 14:13:52 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Fri Sep 13 14:13:59 PDT 1991 Subject: Subnet Confusion From Roger Gonzalez - rg@msel.unh.edu: > All I want is this: > > __________________________________________________ campus net - netmask 0xfffffc00 > | le0 | | > sparc 132.177.131.33 other workstations for development > | le1 > |______________________________________________ internal development net > | | > ======= vme crate ======= vme crate > ||||||| ||||||| > target cpus target cpus > running vxworks running vxworks > > > I have no control over the campus net. I have to request an address whenever > I want to put a new machine up. The campus Net Dictators have told me that > they don't want to let me have any subnets. Then request addresses for your secondary processors on some subnet. If they won't give you the whole subnet you'll just have to work with host routes and a piece of a subnet. Each crate's secondaries must be within one subnet, but the crates don't have to have the same subnets. It doesn't matter much which subnet. They must have one subnet for special purposes like links that is nearly empty. Perhaps you could convince them to setup one subnet for all the vxWorks users on the entire campus. Or for all the special networks. Shiva/Fastpath boxes often need subnets, and they waste most of the addresses. Use part of one of those that they're not using. You need valid onsite unique addresses. Normally with a subnet in each crate you'd just setup your gateway with a single net route for each backplane pointed at the vxworks gateway for that crate. You will instead have to put a host route in your .33 gateway for each secondary processor pointing to the crate that cpu is in. You'll have to put a host route for each of those secondary processors in every development workstation pointing to your .33 router. You'll also need default routes in the vx gateways pointing to .33, and defaults in the secondaries pointing to their gateway. Just remember that in order for a packet to be delivered each node it passes through must correctly figure out where to send it next. One hop at a time. Either it must match a host route exactly or the netmasks are applied to find a net route to use. If nothing matches it forwards to 'default' which is the route to host 0.0.0.0. VxWorks doesn't assume a default route so you'll have to install one where you want it. Alan K Biocca BEVALAC Controls Group From wrs!yuba!ricks@uunet.uu.net Fri Sep 13 14:25:42 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Date: Fri Sep 13 14:25:58 PDT 1991 Subject: Re: Subnets or is it MMU? Hey you folks have splintered this subnet discussion into an MMU discussion. Please use an appropriate subject line for those of us without ESP! Tanks, Rick From psm%helios.nosc.mil@nosc.mil Fri Sep 13 15:43:07 1991 From: psm%helios.nosc.mil@nosc.mil Date: Fri Sep 13 15:43:14 PDT 1991 Subject: Re: Subnet Confusion > >From Roger Gonzalez - rg@msel.unh.edu: > > > All I want is this: > > > > __________________________________________________ campus net - netmask 0xfffffc00 > > | le0 | | > > sparc 132.177.131.33 other workstations for development > > | le1 > > |______________________________________________ internal development net > > | | > > ======= vme crate ======= vme crate > > ||||||| ||||||| > > target cpus target cpus > > running vxworks running vxworks > > > > > > I have no control over the campus net. I have to request an address whenever > > I want to put a new machine up. The campus Net Dictators have told me that > > they don't want to let me have any subnets. We had much the same situation and solved it by creating a bootleg net (we made up our own net ID) for our internal development net. The only machines that knew about it were the gateway sparc and the other development machines. Assuming that you have system administration priviledges on your development sparcs, you should be able to do the same. The gateway was, obviously, the passive variety. From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Mon Sep 16 05:15:41 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Mon Sep 16 05:15:49 PDT 1991 Subject: Re: Subnets Last week I sent out a post on subnet "rules". As several people pointed out you can make the TCP/IP software handle networks that break some of the rules I had proposed. I should have mentioned that one of our intents was to have a network that required minimal additional configuration. If you set up your network according to the rules I outlined, you can run the systems with no additional configuration information beyond what is supplied on the boot line (i.e. backplane address, ethernet address, gateway address). I think one of the good things about the network software is that it can be set up, as people have shown in some of the postings, to do so much more than originally intended. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From Christina_Goette@mac_smtp.WRS.COM Tue Sep 17 11:15:30 1991 From: Christina_Goette@mac_smtp.WRS.COM (Christina Goette) Date: Tue Sep 17 11:15:45 PDT 1991 Subject: East Coast Users Group Meet Subject: Time:11:22 AM OFFICE MEMO East Coast Users Group Meeting Date:9/17/91 A hearty thanks to Mike Anderson and Sparta for orchestrating and chairing an interesting Users Group meeting! Minutes and an attendee list are currently in progress and will be sent out (over the exploder if the minutes are not too lengthy) soon. If you have any questions in the mean time please don't hesitate to contact me via e-mail at tina@wrs.com or telephone: 800/545-9463. Christina Goette From marc@sun-valley.stanford.edu Tue Sep 17 15:05:11 1991 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Tue Sep 17 15:05:22 PDT 1991 Subject: Re: building bootroms for 68k using gcc on SPARC >Has anyone made the necessary changes to the vxWorks makefiles to sucessfully >build bootroms on SPARC stations for 68K targets, using "gcc" configured as a >cross compiler? >I've successfully built working kernels, but my bootroms don't work. I have modified the source code for config/mv133 and config/mv147 so that I can build boot roms with "gcc -O -Wall". My 147 roms work. My 133 ones don't. I have not tracked down why. If any one knows what the problem is I'd be interested in hearing about it. Let me know if you are using either of these two targets. --Marc Ullman Stanford University From rg@msel.unh.edu Wed Sep 18 05:27:10 1991 From: rg@msel.lbl.gov (Roger Gonzalez) Date: Wed Sep 18 05:27:21 PDT 1991 Subject: another bootrom question I am faced with having to reprogram new boot roms in order to include the ethernet driver for my hardware. Unfortunately, my prom burner (a Bytek S-125) is only a 16 bit machine and can only burn up to two proms at once. Has anyone written any code to make hex files suitable for downloading in two steps to a 16 bit burner? -Roger "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra Roger Gonzalez - rg@msel.unh.edu UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) From hebo@mbari.org Wed Sep 18 08:40:45 1991 From: hebo@mbari.org (Bob Herlien) Date: Wed Sep 18 08:40:51 PDT 1991 Subject: Re: another bootrom question I've written a small program to take an S-record file and split it into n pieces at every nth byte (for n=2, into even-odd bytes; for n=4, low-middle-middle-high bytes, etc). Unfortunately, I didn't have the S record specification when I wrote it, so by the time I made it work, it was pretty well hacked. But you're welcome to try it. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From stan@rti.com Wed Sep 18 11:33:38 1991 From: stan@rti.com (Stan Schneider) Date: Wed Sep 18 11:33:45 PDT 1991 Subject: Re: another bootrom question Some time ago, I also wrote an S-record to rom-image program. You're welcome to it as well. It accepts multiple s-record files, and produces rom images of any size for any width bus. -- 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 rg@msel.unh.edu Wed Sep 18 11:52:42 1991 From: rg@msel.unh.edu (Roger Gonzalez) Date: Wed Sep 18 11:52:49 PDT 1991 Subject: Re: another bootrom question Bob- Sounds good... I'd love to look at it! -Roger "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra Roger Gonzalez - rg@msel.unh.edu UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) From marc@aplpy.jhuapl.edu Thu Sep 19 09:57:15 1991 From: marc@aplpy.jhuapl.edu (Marcus Gates) Date: Thu Sep 19 09:57:25 PDT 1991 Subject: Please add me to vxWorks mailing list We are using vxWorks 5.0.2 with development on sun workstations. From proton!baumann@ucrmath.ucr.edu Thu Sep 19 10:20:16 1991 From: proton!baumann@ucrmath.ucr.edu (Michael Baumann) Date: Thu Sep 19 10:20:26 PDT 1991 Subject: 1553 card/driver Hello all: I am searching for one of 2 things: A driver or pointers to assitance in developing same for a Radstone PMV 68EE MBI-1 1553 Bus interface. -or- I am also willing to accept pointers to other board/driver pairs (Same functionality) Adv-Thanks-ance Michael Baumann Radiation Research Lab |Internet: baumann%proton.UUCP@ucrmath.UCR.EDU Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077| From biocca@bevsun.bev.lbl.gov Thu Sep 19 11:02:47 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Sep 19 11:02:54 PDT 1991 Subject: Welcome new users Last night I put out a notice on comp.realtime advertising our exploder. This morning I added about twenty new users (and one is a list) to the list. Welcome to the new users of the vxWorks exploder. Alan K Biocca BEVALAC Controls Group VxWorks Users Group Exploder Maintainer From hill@luke.atdiv.lanl.gov Thu Sep 19 16:52:48 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Thu Sep 19 16:52:58 PDT 1991 Subject: Re: 1553 card/driver sorry, we dont use 1553 IO here. However I used to do 1553 over GPIB when I worked for an aircraft manufactuer. Do you use 1553 as a multidrop IO bus? If so why did you choose 1553 over comercial multidrops like the one provided by allen bradley? Jeff From hebo@mbari.org Mon Sep 23 11:09:58 1991 From: hebo@mbari.org (Bob Herlien) Date: Mon Sep 23 11:11:57 PDT 1991 Subject: NTP for VxWorks I have just uploaded a port of NTP (Network Time Protocol) version 1 to the archives at thor.atd.ucar.edu. I placed it in file ntp.vx.tar.Z (a compressed tar file) in directory /pub/incoming. This is the first time I've put anything in the archives, so I don't know how it gets from /pub/incoming to /pub/vx. If I need to notify the archive administrator, or I need to send a different type of file (shar?), someone please let me know. The ntp.vx.tar.Z file contains two different but related pieces of code. When you unpack it, you'll find directories ./usrTime and ./ntp. UsrTime contains a set of Unix-compatible functions to maintain time. It includes gettimeofday(), settimeofday(), time(), stime(), asctime(), ctime(), gmtime(), localtime(), and adjtime(). It also contains a couple of user interface functions (date(), gmtset()) to get/set time from the user level, as well as drivers for the MK48T02 real-time clock chip as configured for the SBE VPU-30 (yes, I know that the archives already had MK48T02 drivers. I did mine before I saw them). The ./ntp directory contains, of course NTP. NTP requires usrTime -- it needs the Unix time functions. Even if you don't want the complexity and accuracy of NTP, though, usrTime is quite useful by itself. I like having "date" available from the vxWorks shell. The NTP port probably still has some bugs. I won't be able to work on it for at least a month, so I'm uploading it now so that the people who have been waiting for it can get started; maybe even fix some bugs :-). I've been able to keep clock sync with my Unix host with sub-millisecond accuracy, though. ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From hill@luke.atdiv.lanl.gov Tue Sep 24 11:12:38 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Tue Sep 24 11:12:48 PDT 1991 Subject: program access to vxWorks system information We would like to obtain the information printed by memShow() in binary form. I dont see any way to get the number of free bytes into my variable other than reassigning stdout, calling memShow(), and then parsing the text in the file. Has anyone solved this problem? Could WRS rearrange the memShow routine so that it first calls a routine which fetches the info in binary form and then another which printf's it on std out? I believe that a similar problem exists with the information available from spy. Jeff From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Tue Sep 24 11:15:38 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Tue Sep 24 11:15:56 PDT 1991 Subject: LANCE bugs Greetings, We have been having sporadic problems with our ethernet software hanging up. Others have mentioned this in the past. In an effort to find out what the problem was, I posted a question to the Usenet tcp/ip group. I received some helpful responses that may be of information to others in this group. The bottom line is that if your ethernet board is not designed just right, the LANCE interface to the ethernet can freeze and nothing short of a HW reset will fix it. Thats the breaks I guess. Fred ---------- Article: 17449 of comp.protocols.tcp-ip From: fjr@sgfb.ssd.ray.com (Fred J. Roeber) Subject: LANCE chip bug Date: 20 Sep 91 15:48:21 GMT I am not sure this is the correct news group but figured I would give it a try. We are using certain hardware cards for our ethernet network. These cards use the AMD LANCE chips for packet generation. What we are finding is that periodically the LANCE seems to hang and stops sending and receiving packets. In some cases, a software chip reset clears things up but in others only a HW reset will fix things. I have heard from others of rumors of similar problems. Indeed, I have noticed in the SGI ethernet driver that they have support for software access to the chip reset line and take a lot of care to work around "LANCE problems". What I am wondering is whether there is some known LANCE bug that causes these problems. I find it hard to believe that this would be the case since typical workstations don't seem to hang for this reason and I can't imagine that all the vendors drivers have the special error recovery stuff that SGI put in. Does anybody have any pointers on this subject. If people send to me I'll post a summary. Thanks in advance. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From ching@brahms.AMD.COM Sat Sep 21 15:24:29 1991 From: ching@brahms.AMD.COM (Mike Ching) To: fjr@sgfb Subject: Re: LANCE chip bug Newsgroups: comp.protocols.tcp-ip In-Reply-To: <472@sgfb.ssd.ray.com> Organization: Advanced Micro Devices; Sunnyvale, CA Cc: Status: R The LANCE requires a system that can guarantee that maximum memory latency does not exceed 25.6us for a single transaction. The latency requirement can be as low as 3.7us for worst case conditions, ie., data chaining, large packet, and polling required. The bug is that the LANCE does not fail gracefully when denied access to memory and a reset is required to restore operation. Mike Ching From lars@cmc.com Sun Sep 22 02:22:31 1991 59:35 PDT Date: Sat, 21 Sep 91 22:59:35 PDT From: lars@cmc.com (Lars Poulsen) To: fjr@sgfb Subject: Re: LANCE chip bug Organization: CMC (a Rockwell Company), Santa Barbara, California, USA Status: R (1) Do you ever have memory bus contention ? LANCE does not recover well from bus timeouts. (2) Do you do segmented buffer chaining ? Segments under a hundred bytes are prone to hang in hardware race conditions. SGI have my respect - the kluge you describe is justified with LANCE hardware. But USUALLY a chip reset software sequence will get it going again. (Our code, too, has many comments referring to "deaf lance problem".) -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM From dennis@westford.ccur.com Mon Sep 23 11:23:32 1991 To: "Fred J. Roeber" Subject: Re: LANCE chip bug In-Reply-To: Message from fjr@sgfb.ssd.ray.com (Fred J. Roeber) <472@sgfb.ssd.ray.com> . Date: Mon, 23 Sep 91 11:10:48 EDT From: dennis@westford.ccur.com Message-Id: <9109231110.aa24505@nexus.westford.ccur.com> Status: R From: fjr@sgfb.ssd.ray.com (Fred J. Roeber) Date: 20 Sep 91 15:48:21 GMT [ ... ] is that periodically the LANCE seems to hang and stops sending and receiving packets. In some cases, a software chip reset clears things up but in others only a HW reset will fix things. [ ... ] The major problem with the LANCE is that it requires very short latencies to get to its memory; this is a result of having a tiny I/O silo. This is why you get LANCE implementations with private memory for the chip (SGI, Concurrent, certainly others). This causes the chip to just give up. In some implementations, the private memory is used only for the descriptors; access to descriptors is, in fact, more critical than for data buffers (when chaining, you must get to the next descriptor and then the data to find the next byte to send). You can sense this problem by checking the TXON and RXON bits in csr 0, and resetting the chip if either are reset. Dennis Rockwell Concurrent Computer Westford MA From bdoerr@aplpy.jhuapl.edu Tue Sep 24 12:59:03 1991 From: bdoerr@aplpy.jhuapl.edu (Bryan S. Doerr) Date: Tue Sep 24 12:59:12 PDT 1991 Subject: Serial Driver for Z8530 Hi: We're using VxWorks 5.0.1 on a MVME-147S board and have a question about interfacing to serial I/O devices (asynchronous). It uses the Z8530 chip for serial I/O. It appears that that VxWorks serial driver (tyCoDrv & tyLib) returns through the kernel after every interrupt. This causes excessive time to be spent in the kernel and results in poor performance overall for the board. My question is this. Has anybody written a serial driver that doesn't return through the kernel. It doesn't have to be written to supply a stdio interface - it just has to be efficient. Bryan S. Doerr JHU/APL bdoerr@aplpy.jhuapl.edu 301-953-5000 x8920 From hmp@frc2.frc.ri.cmu.edu Tue Sep 24 14:57:52 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Tue Sep 24 14:58:07 PDT 1991 Subject: Unreliable sigRaise() 'code' parameter delivery I'm using sigRaise() calls to signal a type of event, identifying the particular instance by supplying different values for the 'code' parameter. The trouble is, the signal handler does not always receive this code correctly; sometimes it appears as 0. In the sigRaise call, the 'code' parameter is hardwired, and in the signal handler, I have put a logMsg right at the beginning to print out the value, so I don't think there's a way my code could be corrupting it. Has anyone else run into this? How about advice on debugging it? Thanks, -Henning From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Wed Sep 25 06:19:52 1991 From: fjr@iss-ipc1.ssd.ray.com Date: Wed Sep 25 06:20:06 PDT 1991 Subject: Re: Serial Driver for Z8530 ----- Begin Included Message ----- Bryan S. Doerr writes It appears that that VxWorks serial driver (tyCoDrv & tyLib) returns through the kernel after every interrupt. This causes excessive time to be spent in the kernel and results in poor performance overall for the board. My question is this. Has anybody written a serial driver that doesn't return through the kernel. It doesn't have to be written to supply a stdio interface - it just has to be efficient. ----- End Included Message ----- I think that the issue is simply that if you use the VxWorks driver to do raw terminal IO, the driver will return to the task with an outstanding read request after every character is input; indeed this is not fast. The solution is to modify the user task to do a block read periodically. In this case, the driver will return any data that it has buffered in its internal buffers all at once. This greatly reduces the scheduling overhead and seems to be almost as efficient as possible (note, terminal should be set to raw mode). The trick is figuring out how often to read the data. Read it too fast and you introduce more scheduling overhead, too slow and the internal buffers can overflow. If you know the IO rate on the channel you should be able to figure out how long it would take to overflow the terminal buffers. The buffer size is also configurable so you could use bigger buffers if you want. Hope this helps. Fred From gordon@tpocc.gsfc.nasa.gov Wed Sep 25 06:34:41 1991 From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller) Date: Wed Sep 25 06:34:52 PDT 1991 Subject: Re: Unreliable sigRaise() 'code' parameter delivery I too have experienced this problem with sigRaise. In my tests, the parameter passed is only zeroed out if the signal is blocked when sigRaise is called. I have a open call to WRS about this. I will post more information/work around (I hope) when I get it. I worked around the problem, by not calling sigBlock. Not a good fix, but I was able to move some things around to get it to work for now. If you want to talk about it more, drop me a line. Gordon Miller gordon@tpocc.gsfc.nasa.gov Integral Systems, Inc. 1100 West Stree Laurel, MD 20707 (301) 497-2416 fax: (301) 498-8260 From jjohnson@hns.com Wed Sep 25 07:02:32 1991 From: jjohnson@hns.com (Jayne Johnson) Date: Wed Sep 25 07:02:49 PDT 1991 Subject: Connection failure detection with Berkeley sockets I have noticed strange behaviour from the socket api and was wondering if anyone in the Users group has seen this already. Given the following scenario: 1. card A creates a non-blocking socket for listening 2. card B creates a non-blocking socket and initiates a connection request to card A. 3. card A receives a connection indication from the select() from card B 4. card A accepts the connection request from card B. 5. card B receives a connection confirmation from the select() from card A. 6. card A and card B exchange messsages 7. an operator resets card A ( on purpose , to simulate card failures ) 8. card B gets an indication from the select() My question is as follows , how can an application determine when a connection has been broken ? Should select() get an indication? Should I set a socket option (like out-of-band data ? ). Should I read the socket control block structure state field? Is there a message passed between the TCP and socket api which can be forwarded up to the application interface when connections are closing? I need to find out when a connection has failed as soon as possible since my system has redundant cards ( which already have connections established ) and I can easily switch over to the redundant card when a connection indication is received. I prefer to treat the socket api like a black box and not read the socket control block structure. I have been reading the RFCs , Steven's book on UNIX network programming, Lefler's book on BSD , Comer's book on TCP/IP and there doesn't seem to have any literature on this subject. I also have instituted a failure management scheme which uses 'ping' and periodic echo messages to determine who is alive and well in the network. However the failure management system is much slower than connection indications. Any thoughts? Any literature? Thanks in advance for your help and insight. Jayne F. Johnson Hughes Network Systems 11717 Exploration Lane Germantown, Md 20874 email : jjohnson@hns.com phone : 301/428-2714 From biocca@bevsun.bev.lbl.gov Wed Sep 25 08:00:38 1991 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Wed Sep 25 08:00:44 PDT 1991 Subject: VxExploder Article Rejection Incoming articles that contain the exploder trailer are rejected. This helps prevent errant bounces from being re-exploded. This also means that when editing articles for resubmission make sure to remove the trailers -- ... Thanks, Alan K Biocca PS: Mike Anderson -- please edit and resubmit your article. From OWENS@lodtm.llnl.gov Wed Sep 25 08:58:00 1991 From: OWENS@lodtm.llnl.gov Date: Wed Sep 25 08:58:09 PDT 1991 Subject: Printing From vxWorks targets Being somewhat new to Unix, I am not sure of the best method to access the printer connected to my host Sun workstation from a target system. I know that there are ways such as rcmd() or rlogin(); the documentation on rcmd is sketchy (an example would be nice). It seems likely that someone else has already found the best approach or maybe already implemented a vxWorks 'lpr' command. If so I would appreciate hearing about how it was done. Thanks, Doug Owens , Lawrence Livermore National Labs 415 422-7616 From hill@luke.atdiv.lanl.gov Wed Sep 25 09:41:54 1991 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Wed Sep 25 09:42:06 PDT 1991 Subject: Re: Connection failure detection with Berkeley sockets > how can an application determine when a connection has been broken? I assume we are talking about TCP here. If so, the only way I have been able to determine if a TCP/IP connection has been lost is to periodically send a NOOP message over the connection. TCP/IP seems to give timely notification of disconnect only if it has a message to deliver. You can also try the socket option `KEEPALIVE'. However the internal delay associated with it seems to be very long (hours or even days). Jeff From hmp@frc2.frc.ri.cmu.edu Wed Sep 25 10:53:58 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Wed Sep 25 10:54:08 PDT 1991 Subject: i960 boards? Hello all, I was recently asked about VxWorks support of i960-based boards, and had only a vague answer to offer - I am aware of a Heurikon VME board that fits the bill, but that's it. Specific questions: a) Are there any other vendors who make i960-based boards that are supported by VxWorks? b) Could active users of the Heurikon (or other) board share their experience? What's the development environment? Is there a cross compiler (gcc), debugger etc? Thanks, -Henning From omni!hwajin@apple.com Wed Sep 25 11:08:46 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Sep 25 11:09:00 PDT 1991 Subject: Re: Serial Driver for Z8530 Your message dated: Wed, 25 Sep 91 06:20:11 PDT >I think that the issue is simply that if you use the VxWorks driver to do >raw terminal IO, the driver will return to the task with an outstanding >read request after every character is input; indeed this is not fast. The >solution is to modify the user task to do a block read periodically. In >this case, the driver will return any data that it has buffered in its >internal buffers all at once.> This greatly reduces the scheduling overhead >and seems to be almost as efficient as possible (note, terminal should be >set to raw mode). The trick is figuring out how often to read the data. >Read it too fast and you introduce more scheduling overhead, too slow and the >internal buffers can overflow. If you know the IO rate on the channel you >should be able to figure out how long it would take to overflow the terminal >buffers. The buffer size is also configurable so you could use bigger >buffers if you want. Hope this helps. Fred In VxWorks 5.0 or later there is a hook routine that lets you specify a flag character to look for before returning ty input to the task. All input is buffered until this flag character is encountered, at which point the buffer data is passed onto the task. This is handy for implementing a protocol like SLIP but can also be used to implement a line-mode ty discipline for the shell (by telling the ty driver to buffer input until a newline character is read). If your application can use this facility it will greatly reduce CPU overhead. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From lapp@waterloo.hp.com Wed Sep 25 11:33:27 1991 From: lapp@waterloo.hp.com (Dave Lapp) Date: Wed Sep 25 11:33:38 PDT 1991 Subject: Re: i960 boards? > > Submitted-by hmp@frc2.frc.ri.cmu.edu Wed Sep 25 10:53:58 1991 > Submitted-by: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) > > > Hello all, > > I was recently asked about VxWorks support of i960-based boards, and had only > a vague answer to offer - I am aware of a Heurikon VME board that fits the > bill, but that's it. Specific questions: > a) Are there any other vendors who make i960-based boards that are supported > by VxWorks? > Yes I believe Tadpole makes a 960 based board. They have ported vxWorks to it. We had one to look at but I didn't us it so I can't comment on it. I don't have their address but they advertise in various trade rags (they're in England but have an office in the states) > b) Could active users of the Heurikon (or other) board share their experience? > What's the development environment? Is there a cross compiler (gcc), > debugger etc? > We use HP9000's (surprise, surprise) but the tools seem to be available on a lot of other machines including DEC, Sun, IBM, and PC's running Interactive Unix. This I'm concluding from the directories on the distrib. tapes we get with the tools. The tools are gnu. You get a pretty complete set of tools and some people prefer the gnu stuff. The tools do seem to work very well. There is a (beta) version of vxgdb for the 960 and it works OK as well. I've never used vxWorks on a 68K but I gather that the functionality is quite similar on a '960 although new stuff is available for 68K a bit before the '960. We used Heurikon boards as development targets for a while 'til we got our own hardware. They worked quite well. We did have a problem with Heurikon's interpretation of little-endian and big-endian - they were swapping 16 bit words but not bytes when going across the buss or something but that was to be fixed in (at the time) future revs. > > Thanks, > > -Henning > Your welcome. Dave Lapp Standard Disclaimer etc. The above are my opinions - not Hewlett's or Packard's or necessarily anybody else who works for HP. From omni!hwajin@apple.com Wed Sep 25 11:34:23 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Sep 25 11:34:47 PDT 1991 Subject: Re: Connection failure detection Your message dated: Wed, 25 Sep 91 07:02:53 PDT >My question is as follows , how can an application determine when a connection >has been broken ? In TCP based applications there is really no quick way to discover "when a connection has been broken". The reason is that you really don't know that the connection is broken. Berkeley based TCP's have a timeout (I forget the exact value but several minutes) routine that eventually detects that absence of traffic on a given connection and closes the connection. A commonly praticed kludge for better dectection of this situation is to use socket option SO_KEEPALIVE, which causes TCP code to send out a TCP segment which contains a lie (receive_next field is less than what's actually received -- N.B. 4.2 and 4.3 have different definitions of this message). The other side should respond to this message if it's alive. After several trials of sending KEEPALIVE TCP will abort the connection if nothing is received. This is really a necessary hack in TCP because people who designed the protocol seems to think that you're never supposed to assume that the other side is dead without conclusive evidence (i.e. using simple timeout routine is not sufficient), which is very important in fact if you're on Internet (or worse milnet) and try to telnet to a host in Spain. A slow ACK or lack of data transfer over a telnet connection doesn't mean that the other side is gone. Given the realtime constraint of the application, an acceptable kludge would be: 1. measure the worst case transmit time of a minimal TCP segment in your environment (e.g. ethernet) 2. decide how much delay you can tolerate in your application before finding out if the remote peer is gone. 3. code your application to send an application level I'm-Alive message to the other side as often as the delay you can derive from #1 and #2. 4. if you don't get I'm-Alive message, you can assume that the other guy is gone. (with certain amount of risk) -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From jjohnson@hns.com Wed Sep 25 11:37:07 1991 From: jjohnson@hns.com (Jayne Johnson) Date: Wed Sep 25 11:37:22 PDT 1991 Subject: Re: i960 boards? Greetings, I have been working in the i960 environment for about 1 year. So far the only vendors of Vxworks BSP seem to be Heurikon and Cyclone. Both manufacturers supply various single board computer cards and VME based I/O cards . As far as the development environment tools: Intel supplies a GNU compiler with the VxWorks development license. So far the biggest complaint I have is the gdb tools aren't stable, but this isn't Intel's fault. GNU tools aren't mature to date. The development environment we have here at Hughes is Apollo workstations supporting BSD 4.3 and merging towards OSF tools. We already use Motif and have ported GNU onto the apollo. There are other compilers which support the i960 family (KA, KB, CA, SA ) one that really looks good is of course the Microtek C compiler which supports ANSI and it's debugger, but it sure is expensive. All in all the GNU tools are good and Intel has a special staff in Oregon optimizing the compiler for the RISC architecture. As far as emulators , so far we are using the STEP,Inc ICE. It's a pretty basic emulator nothing to write home about. I would suggest Applied Microsystems Emulator it sure looks and feels good. It's got alot more analysis tools. You should call them up for a demo. Let me know how it goes, I feel so all alone . VxWorks is starting to migrate to RISC so I'm sure the kinds of experiences we are having are going to be shared by the SPARC and MIPS users. From omni!hwajin@apple.com Wed Sep 25 12:10:24 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Wed Sep 25 12:10:38 PDT 1991 Subject: Re: Printing From vxWorks targets Your message dated: Wed, 25 Sep 91 08:58:13 PDT > Being somewhat new to Unix, I am not sure of the best method >to access the printer connected to my host Sun workstation from >a target system. I know that there are ways such as rcmd() or >rlogin(); the documentation on rcmd is sketchy (an example would >be nice). It seems likely that someone else has already found >the best approach or maybe already implemented a vxWorks 'lpr' >command. If so I would appreciate hearing about how it was done. SunOS man page (man 3 rcmd) gives: int rcmd(ahost, inport, locuser, remuser, cmd, fd2p) char **ahost; int inport; char *locuser, *remuser, *cmd; int *fd2p The only difference in VxWorks version seems to be the first arg, which is a "char *" rather than "char **". So to use "lpr" to print "file" which is on a UNIX machine, rcmd("machinename", 514, "username", "username", "/usr/ucb/lpr < file", &error_fd); 514 is the remote shell daemon's port number (as in /etc/services for the "shell" entry). The usual permission authentication using /etc/hosts.equiv and ~/.rhosts are done by the rcmd() and rshd so be sure to have proper permission stuff in those files. If you want to write a command that passes stdin input to the remote command you'll need to save the socket returned by rcmd() and pass the data read from stdin to that socket. Result of the command can be read from this socket (stdin) and error_fd (stderr). -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From ast0!monolith!mak@ub.com Wed Sep 25 12:12:48 1991 From: ast0!monolith!mak@ub.com (Mark Kroft) Date: Wed Sep 25 12:13:01 PDT 1991 I recently started using the FP co-processor, and have another problem with it. None of the standard FPCP vectors are initialized with VxWorks, so when I get a FPCP inexact result, I get a 'Trap to uninitialized vector number 49' error. Is there something I am not doing to that should initialize these vectors? What is supposed to be done in this case Mark Kroft Applied Signal Technology From wrs!yuba!ricks@uunet.uu.net Wed Sep 25 12:42:04 1991 From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek) Date: Wed Sep 25 12:42:14 PDT 1991 Subject: Re: i960 boards? We at WRS have been working with the Heurikon, Tadpole, and Cyclone VME boards, which are all based on the i960ca. Our product support for the i960 is based on the GNU C compiler as delivered from Intel. The boards and tools all seem to be working fine and exhibit very good performance. Rick From wrs!schuylkill!bob@uunet.uu.net Wed Sep 25 15:45:41 1991 From: wrs!schuylkill!bob@uunet.uu.net Date: Wed Sep 25 15:45:53 PDT 1991 Subject: Re: Unreliable sigRaise() 'code' parameter delivery > > I too have experienced this problem with sigRaise. In my tests, the > parameter passed is only zeroed out if the signal is blocked when > sigRaise is called. I have a open call to WRS about this. I will post > more information/work around (I hope) when I get it. I worked around > the problem, by not calling sigBlock. Not a good fix, but I was able to > move some things around to get it to work for now. > > If you want to talk about it more, drop me a line. > > Gordon Miller gordon@tpocc.gsfc.nasa.gov > Integral Systems, Inc. > 1100 West Stree > Laurel, MD 20707 > (301) 497-2416 Gordon is right - this is a known bug in our signal implementation. We have a mechanism that keeps track of "pending" signals - ie if a signal is raised while the signal is blocked (for example, if the handler for that signal is currently running), the signal is marked as pending, and the handler will be called when the signal becomes unblocked (when the current signal handler completes). Unfortunately, the implementation doesn't keep track of the code that's passed in to sigRaise when the signal is blocked, and a default code of NULL is passed to the signal handler when the signal becomes unblocked. This is internal spr #723. Sorry for all the confusion. Bob Cohen Wind River Systems, Inc. bob@wrs.com From leonid@amil.co.il Thu Sep 26 00:37:18 1991 From: leonid@amil.co.il (Leonid Rosenboim) Date: Thu Sep 26 00:37:30 PDT 1991 Subject: Re: Printing From vxWorks targets I have written a simple function that reads the SUN's YP hosts table into VxWorks using rcmd. Should be fairly simple to convert it to lpr or whatever else you might wish for. ------------ #include #include #include #include #include hostRead() { char server[16], user[16] ; char line[80] ; char addr[20], name[4][16] ; char cmd[] = "ypcat hosts" ; char *p ; FILE *f ; register int fd, i ; strcpy(server, sysBootHost) ; remCurIdGet( user, NULL ) ; printf("Host: %s, User: %s\n", server, user) ; fd = rcmd (server, /*remotePort*/ 514, /*localUser*/ user, /*remoteUser*/ user, cmd, /*fd2p*/ NULL ) ; if( fd < 0 ) { perror("rcmd") ; return(fd); } f = fdopen(fd, "r") ; while( fgets(line, 79, f) == line ) { /* puts(line) ; */ p = index(line, '#') ; if( p != NULL ) *p = '\0' ; fd = sscanf(line, "%s %s %s %s %s", addr, name[0], name[1], name[2], name[3] ) ; for( i=0, fd--; fd>0; fd--) { (void) hostAdd(name[i++], addr) ; } /*for*/ } /* while */ return(fclose(f)); } -------- --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Phone: +972-3498-201 | --------------------------------------------------------------------- From hmp@frc2.frc.ri.cmu.edu Thu Sep 26 05:01:43 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Thu Sep 26 05:01:54 PDT 1991 Subject: Re: Unreliable sigRaise() 'code' parameter delivery >Gordon is right - this is a known bug in our signal implementation. We have a >mechanism that keeps track of "pending" signals - ie if a signal is raised while >the signal is blocked (for example, if the handler for that signal is currently >running), the signal is marked as pending, and the handler will be called when >the signal becomes unblocked (when the current signal handler completes). >Unfortunately, the implementation doesn't keep track of the code that's passed in >to sigRaise when the signal is blocked, and a default code of NULL is passed to >the signal handler when the signal becomes unblocked. This is internal spr #723. >Sorry for all the confusion. Thanks for the official word on that, Bob. Now, I'm curious: Could I have found this out via some other way (read: documentation) before actually running into the problem? The 5.0 release notes don't seem to mention it, neither do the man page or technotes 1-23. I'm wondering what other kind of known bugs are out there waiting for me; I'd love to just browse a list of them so I don't waste my time trying to track them down myself. This forum sort of serves in that capacity, but in the end it's WRS who know these things much better than any of us users. -Henning From tadusa!tadtec!ma@uunet.uu.net Thu Sep 26 05:16:06 1991 From: tadusa!tadtec!ma@uunet.uu.net Date: Thu Sep 26 05:16:15 PDT 1991 Subject: Re: i960 boards? Hi, >a) Are there any other vendors who make i960-based boards that are supported > by VxWorks? Yes, Tadpole Technology sells the TP960V, an i960CA VME board with SCSI + Ethernet, and a variety of SRAM, DRAM, EPROM & Flash EEPROM configurations. For more info, either email me or contact our Austin,TX office on 512-338-4221, or our San Jose office on 408-441-7920. (Sorry for the Ad.) Mark Armitage email: ma@tadtec.uucp Technical Projects Manager phone: +44 223 423030 Tadpole Technology plc fax: +44 223 420772 From srm%matrx@mcnc.org Thu Sep 26 07:48:27 1991 From: srm@matrx.matrix.com (Steve Morris) Date: Thu Sep 26 07:48:36 PDT 1991 >Gordon is right - this is a known bug in our signal implementation. We have a > > [description deleted] > >the signal handler when the signal becomes unblocked. This is internal spr #723. >Sorry for all the confusion. >Bob Cohen >Wind River Systems, Inc. >bob@wrs.com This brings up something I've been wanting for a long time... A *buglist* would save everyone hours/days/nights/weekends of grief. As it is now, we all are rediscovering bugs that are probably known bugs. Steve Morris Matrix Corp. srm@matrix.com From thor@surt.atd.ucar.edu Thu Sep 26 08:16:24 1991 From: thor@surt.atd.ucar.edu (Richard Neitzel) Date: Thu Sep 26 08:16:37 PDT 1991 Subject: Ntp Thanks to Bob Herlien of the Monterey Bay Aquarium Research Institute, ntp has been ported to VxWorks. Currently the ONLY way you can get it from the archive is via ftp. The file is /pub/vx/ntp.vx.tar.Z. I will try and get a version that can be emailed ready by week's end. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. From ast0!monolith!mak@ub.com Thu Sep 26 09:36:18 1991 From: ast0!monolith!mak@ub.com (Mark Kroft) Date: Thu Sep 26 09:36:29 PDT 1991 Subject: FPCP trap to uninit vector > I recently started using the FP co-processor, and have another >problem with it. None of the standard FPCP vectors are initialized >with VxWorks, so when I get a FPCP inexact result, I get a >'Trap to uninitialized vector number 49' >error. Is there something I am not doing to that should initialize >these vectors? What is supposed to be done in this case >Mark Kroft >Applied Signal Technology In response to my own article, I found out what the problem is. 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,# 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. Mark Kroft Applied Signal Technology mak!ast0@ub.com From Glen_Nakamoto.G034@qmgate.mitre.org Thu Sep 26 13:43:59 1991 From: Glen_Nakamoto.G034@qmgate.mitre.org (Glen Nakamoto) Date: Thu Sep 26 13:44:20 PDT 1991 Subject: Vxworks System Memory Subject: Time:4:35 PM OFFICE MEMO Vxworks System Memory Date:9/26/91 Does anyone know how to shift system memory around under VxWorks? I am using a Radstone 68-33 CPU (68030) with two memory banks. The system memory (PLB) starts at 0x0 and goes up to 0x0FFFFF (1 Mbyte). I also have a second memory bank (ILB) that starts at 0x100000 and goes up to 0x4FFFFF (4 Mbytes). I want the system memory to start at 0x100000 and extend upwards 4 Mbytes. I'm willing to have the PLB RAM available for partitioning (via memPartCreate) later if needed. According to Radstone and WRS, all I need to do is to change the following macros in /config/RS33target/config.h (and make corresponding changes in Makefile): From To LOCAL_MEM_LOCAL_ADRS 0x0 0x100000 LOCAL_MEM_SIZE 0x10000 0x400000 RAM_TEXT_LOW_ADRS 0x001000 0x101000 RAM_TEXT_HIGH_ADRS 0x090000 0x190000 When I make these changes, I cannot boot the system. Is there other parameters that need to be tweeked before this works or is it just not possible? In case you want to know, the PLB RAM is not visible from the VMEbus but the ILB is. VxWorks creates some buffers (mbufs) in system memory and passes these addresses to my FDDI controller for DMA purposes. Because the memory is not visible, the controller (in master mode across the VMEbus) does not successfully transfer/read the data. If I can move system memory to the ILB RAM section, I should be able to eliminate this problem. Thanks for any assist. Glen Nakamoto MITRE Corporation Bedford, MA (617) 271-3032 (617) 271-2721 (fax) From muts@fysap.fys.ruu.nl Fri Sep 27 06:01:25 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Fri Sep 27 06:03:36 PDT 1991 Subject: Switched from version 4.x to 5.0: ls and ll problem We just switched from 4.x to 5.0; cd and pwd work fine, and when I am in the right directory I can load an object, so cd really functions. However, ls and ll give an error and tell they cannot find ".". Is this a (known) bug, or have I forgotten something? _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov Fri Sep 27 08:20:26 1991 From: georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov (Georg Feil) Date: Fri Sep 27 08:22:38 PDT 1991 Subject: Re: Vxworks System Memory > When I make these changes, I cannot boot the system. Is there other parameters > that need to be tweeked before this works or is it just not possible? Sounds like you need to rebuild your boot PROMS, since they'll still try to use the old memory. Georg. From heyes@dadev.cebaf.gov Fri Sep 27 09:06:48 1991 From: heyes@dadev.cebaf.gov Date: Fri Sep 27 09:07:06 PDT 1991 Subject: Re: Switched from version 4.x to 5.0: ls and ll problem Hi, it is a known bug I think. Try lsOld... From matthieu@vega.laas.fr Fri Sep 27 09:24:51 1991 From: matthieu@vega.laas.fr (Matthieu Herrb) Date: Fri Sep 27 09:25:09 PDT 1991 Subject: Re: Switched from version 4.x to 5.0: ls and ll problem We had the same problem with an NFS server that was a gould (encore) PN 6040 under UTX 2.1 and not a sun. And never found a workaround other than not using it with wxworks. It must be some incompatiblity in the NFS client code that is not fully conformant to sun's definition. Matthieu From litwin@robotics.jpl.nasa.gov Fri Sep 27 09:37:35 1991 From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Date: Fri Sep 27 09:37:45 PDT 1991 Subject: Re: Switched from version 4.x to 5.0: ls and ll problem I don't know about ll, but the problem with ls has something to do with VxWorks supporting a local file system -- maybe compatible with MSDOS? At any rate, WRS tells me that the command "lsOld" should be used by us for now. I don't know what their future plans are concerning this. Todd Litwin Jet Propulsion Laboratory (818) 354-5028 litwin@robotics.jpl.nasa.gov From muts@fysap.fys.ruu.nl Fri Sep 27 09:58:50 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Fri Sep 27 09:59:09 PDT 1991 Subject: Switched from version 4.x to 5.0: ls and ll problem >>Op Fri, 27 Sep 91 09:07:10 PDT schreef u: > it is a known bug I think. Try lsOld... Indeed, lsOld works. ls and ll work after I added 'nfsMount' too. I was looking in the old manpages accidently. Thanks, _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From muts@fysap.fys.ruu.nl Fri Sep 27 10:31:17 1991 From: muts@fysap.fys.ruu.nl (Peter Mutsaers) Date: Fri Sep 27 10:31:28 PDT 1991 Subject: Thanks for replies concerning ls and ll I got already several replies concering ls not working on 5.0. Thanks for that. However, a cause was that I still was looking in the 4.x man pages. In the new man-pages I found lsOld, which worked, and found out that for ls and ll to work I must have an nfs mounted filesystem. After I mounted the filesystems with nfs, everything was fine. _________________________________________________________________________ Peter Mutsaers. RUU physics dept. Heidelberglaan 5, Utrecht, Nederland muts@fysap.fys.ruu.nl |================================================ tel: (+31)-(0)30-533880 | " Trust me; I know what I'm doing. " From omni!hwajin@apple.com Fri Sep 27 12:15:04 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Fri Sep 27 12:15:14 PDT 1991 Subject: Re: Switched from version 4.x to 5.0: ls and ll problem >I don't know about ll, but the problem with ls has something to do with >VxWorks supporting a local file system -- maybe compatible with MSDOS? I think you're right. As I recall the old ls() used to open the filesystem device and send down dir-entry ioctl to the device specific ioctl routine. The new one does something different which works for locally supported filesystems (MSDOS, RT11) but not for NFS or FTP/RSH files. Indeed a very old and well known problem. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From omni!hwajin@apple.com Fri Sep 27 12:23:09 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Fri Sep 27 12:23:21 PDT 1991 Subject: Re: FPCP trap to uninit vector >00e04c f201 9000 FMOVE .L D1,# > 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. The code looks pretty suspicious. Since floating point libraries are written differently in most cases it's hard to tell what happened here. If you used SunOS C compiler with -f68881 option, the compiler would have probably used the ".il" stuff (inline FP assembly code). I think in some old versions of their code FPCR was used to set the rounding mode (in mode control part of FPCR) and the code you mention looks like an attempt to set the value back to the original value. Looking at the new inline code in /usr/lib/f68881/libm.il, there seem to be a better way with fewer instructions anyway. Perhaps someone knowledgable about FP stuff can clarify? I'm pretty intrigued... -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California From wrs!yuba!kent@uunet.uu.net Fri Sep 27 18:55:25 1991 From: wrs!yuba!kent@uunet.uu.net (Kent Long) Date: Fri Sep 27 18:55:41 PDT 1991 Subject: Re: FPCP trap to uninit vector > 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,# > 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 4.0.2, 5.0 and 5.0b: pMathPatch = irint + 0x18; *pMathPatch = (short) 0xf21f; pMathPatch = irint + 0x1a; *pMathPatch = (short) 0x4b80; For VxWorks 5.0.1 and 5.0.2: pMathPatch = mathHardIrint + 0x18; *pMathPatch = (short) 0xf21f; pMathPatch = mathHardIrint + 0x1a; *pMathPatch = (short) 0x4b80; I think the quick unraveling of this ancient bug demonstrates that this exploder, and the User's Group in general, are valuable resources to us here at Wind River, as well as our customers. Thanks for your (collective) interest and diligence! - kent Kent Long (kent@wrs.com) Wind River Systems From smb@afterlife.ncsc.mil Sun Sep 29 19:07:51 1991 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Sun Sep 29 19:08:00 PDT 1991 Subject: Status of comp.realtime.vxworks? What's the status of trying to establish a news group (comp.realtime.vxworks?) and the necessary link to keep the mailing list available for those without news feeds? Exploder traffic volume seems to be increasing; and I'd much prefer reading it as news than as mail. Steve smb@afterlife.ncsc.mil From hmp@frc2.frc.ri.cmu.edu Mon Sep 30 10:49:51 1991 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Mon Sep 30 10:50:04 PDT 1991 Subject: {MIN,MAX}DOUBLE Hello all, what would you say is the proper header file to reference for the definition of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a SparcStation,for a 68k board, and the default values in /usr/include/values.h are too large (according to gcc). I've looked in the vxWorks and gcc-include trees, to no avail. Short of a standard header file, what would be the correct values to use? Thanks, -Henning +-------------------+-----------------------------+--------------------------+ |Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center| |Research Programmer|(412) 268-7088 |Carnegie-Mellon University| +-------------------+-----------------------------+--------------------------+ If you aren't part of the solution, you're part of the precipitate. From dmorse@sun-valley.stanford.edu Mon Sep 30 18:56:58 1991 From: dmorse@sun-valley.stanford.edu Date: Mon Sep 30 18:57:08 PDT 1991 Subject: Re: {MIN,MAX}DOUBLE >Submitted-by hmp@frc2.frc.ri.cmu.edu Mon Sep 30 10:49:51 1991 >Submitted-by: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) > >Hello all, > >what would you say is the proper header file to reference for the definition >of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a >SparcStation,for a 68k board, and the default values in /usr/include/values.h >are too large (according to gcc). I've looked in the vxWorks and gcc-include >trees, to no avail. >Short of a standard header file, what would be the correct values to use? > >Thanks, > >-Henning Henning, You should be using the ANSI Standard C macros defined in the header file "float.h", which is included with "gcc". The macros in question are DBL_MIN and DBL_MAX. The double-precision values are #define DBL_MIN 2.225073858507201e-308 #define DBL_MAX 1.797693134862316e+308 which should be correct for any floating-point processor that conforms to the IEEE floating-point standard. The macros for single-precision floats are #define FLT_MIN 1.17549435e-38f #define FLT_MAX 3.40282347e+38f The header file containing all the integer macros is "limits.h". Two excellent references for the Standard C library and all the standard header files (15 total) are 1. ``Standard C, Quick Reference Series,'' P. J. Plauger and Jim Brodie, Microsoft Press, 1989. 2. ``The Standard C Library,'' P. J. Plauger, Prentice-Hall, 1992. The first one is relatively cheap. Dennis Morse Office: 415.723.1260 Stanford Aerospace Robotics Laboratory Lab: 415.723.3608 Department Aeronautics & Astronautics Durand Building, Room 250 Stanford, CA 94305 E-mail: dmorse@sun-valley.stanford.edu From omni!hwajin@apple.com Mon Sep 30 20:26:18 1991 From: hwajin@omni.com (Hwa-Jin Bae) Date: Mon Sep 30 20:26:27 PDT 1991 Subject: Re: {MIN,MAX}DOUBLE Your message dated: Mon, 30 Sep 91 10:50:08 PDT >what would you say is the proper header file to reference for the definition >of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a >SparcStation,for a 68k board, and the default values in /usr/include/values.h >are too large (according to gcc). I've looked in the vxWorks and gcc-include >trees, to no avail. >Short of a standard header file, what would be the correct values to use? Try looking at SunOS file /usr/lib/f68881/libm.il which contains IEEE/ANSI floating point standard interface routines in assembly. Routines max_normal() and min_normal() tell you normalized numbers you should be able to use for MINDOUBLE and MAXDOUBLE. Since my version of VxWorks is very old and doesn't have mathALib I don't know if VxWorks supports these functions. -- Hwa-Jin Bae Interphase West hwajin@omni.com Santa Clara, California