From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 21 Oct 93 08:13:16 EDT Subject: Linux-Development Digest #177 Linux-Development Digest #177, Volume #1 Thu, 21 Oct 93 08:13:16 EDT Contents: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (Patrick Schaaf) Re: Libc 4.4.4 and new sig 11's (not ram chips) (Rafal Boni) RE: UNIX trademark now X/Open (Martyn.Cox@juts.amdahl.com) 10/26/93 530 PM, BA Computer Industry Beginnings (Jesus Monroy Jr) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (Andrew "Fuz" Lih) Re: /dev not needed? (Jay Carlson) Re: Use 'jargon' reader for FAQ (Brian McCauley) Re: Fonts for virtual consoles (Andrew J. Cosgriff !) Re: Libc 4.4.4 and new sig 11's (not ram chips) (Helmut Geyer) Need tty information (K-JAMZ) Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ? (Derek Fawcus) Re: UNIX trademark now X/Open (Thomas Uhl) ---------------------------------------------------------------------------- Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc From: bof@wg.saar.de (Patrick Schaaf) Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: Wed, 20 Oct 1993 19:02:05 GMT cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) writes: >[on MAC files and their forks, and how they might map to files under Linux] Would it be a Bad Thing to have files that, in addition to being a normal file (the data fork), implement the various directory ops? i.e. access the data fork as 'foo`, and other forks as 'foo/thingie` and so on? having strange ideas... Patrick -- California uber alles!!!!!!!!!!!!!!!!!!!!!!111111111!!!!!!!!!!!! ------------------------------ From: rkb55989@uxa.cso.uiuc.edu (Rafal Boni) Subject: Re: Libc 4.4.4 and new sig 11's (not ram chips) Date: 20 Oct 1993 04:57:06 GMT bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) writes: >Ok.. here's the situation: >Sunday night (the day the new c libraries were sent out), I installed >ld.so.3 and libc 4.4.4. This should include the new include files, >the extra-xxxx and the image-4.4.4. I did this after I installed ld.so.3 >and then installed the new g++ stuff. Basically I installed anything >that looked like part of the upgrades announced in comp.os.linux.announce. >Everything works fine except for seyon: >Upon loading seyon everything pops up fine, but upon klicking on any >button in the control box I get a sig11 error from seyon. Now I KNOW signal >11 is supposed to be a memory error. But before installing libc4.4.4 >I had no such error EVER with seyon. It is no an error that will >happen every time seyon is loaded. >The only system changes were the installation of libc, lib.so.3, >and recompiling linux 0.99.pl13 with the new libraries. >Has anybody else had this problem? Hmm... I had the same problem with 386BSD and NetBSD... Looked at the assembly that Linux [then pl6, I think] GCC put out, compared it to the assembly 386BSD and NetBSD put out, and THEY WERE ALL THE SAME. I didn't ever get around to looking deeper into it, because my BSD box had a drive crash... What I'd guess is: Previous Linux libs [or previous kernels] might have done something that changed some boundary condition [in the case of the libs], or allowed stray memory accesses [in the case of the kernel]. If I remember correctly, the problem had something to do with blank lines in the [phonebook/setup/whatever] files that Linux uses... >Just thought I'd bring it up. >Byron Faber: >Linux system: >MCC Interim release with kernel pl10+. Since upgraded to pl13. >386/40 AMD bios >8 meg ram. >8 meg swap partition >4 meg swap file. >170 Meg drive.. >WD8003E ethernet board and net-2 >(standard setup I guess..) Seen on: Worked [same assembly as BSD]: NetBSD/386BSD systems Linux SLS pl's 6 - 9 [lost track later] 486/33 AMI BIOS AMD 386/40 8 Meg RAM/32 Meg swap 8Meg RAM/16Meg swap part. ... no netcard/3c503 [it changed] --rafal ------------------------------ From: Martyn.Cox@juts.amdahl.com Subject: RE: UNIX trademark now X/Open Date: 21 Oct 1993 05:26:39 -0400 Reply-To: Martyn.Cox@juts.amdahl.com I obtained my XPG/4 Specs from: X/Open Ltd PO Box 109 Penn High Wycombe Bucks HP10 8NP England There are several manuals, separately orderable: System Interfaces and Headers, Commands etc... Incidentally, a system can be said to conform to XPG/4 without being formally branded. Hence, LINUX could deliver XPG/4 functionality, be said to do so; and there would be no financial implications. ------------------------------ Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware,comp.sys.ibm.ps2.hardware From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: 10/26/93 530 PM, BA Computer Industry Beginnings Date: Wed, 20 Oct 1993 04:11:26 GMT Forwarded for Peter. --jmj * please forward this announcement within the Bay area * * and post to any appropriate internal aliases * Bay Area Computer History Perspectives "Beginnings of the Computer Industry: Implementing ERMA" a panel discussion with Jack Goldberg, Herman Moss, and Tony Russo 5:30 PM, Tuesday, Oct. 26 Auditorium International Building SRI International 333 Ravenswood Ave. Menlo Park (directions at end) This discussion covers the transition to the beginning of the modern computer industry. Back in 1950, when the ERMA project for bank automation began between Stanford Research Institute and Bank of America, an industry did not yet exist. No commercial computers were available. Compilers had not been invented. Core memory hadn't been developed. Transistors were not reliable enough yet for building systems. And logic was usually wired in hardware. That was the period of last month's program in this series. By 1956, when General Electric was selected by the Bank to implement the ERMA prototype on a commercial computer, everything had changed, and the basis of an industry was in place. General purpose computers were on the market, programs were being developed for these machines, and hardware and software were separated. ERMA was GE's introduction to commercial computing, undertaken without the knowledge or consent of GE senior managment, and itself became the occasion for more technical development---such as the first simulation of one computer (the GE ERMA system) on another computer (an IBM 704). In this program, Jack Goldberg will comment on the transition in the ERMA story from SRI to GE, from the hardwired prototype to the general purpose computer. Herman Moss will then pick up the story from the view of the GE development team, as a GE programmer on ERMA. And then Tony Russo will discuss the applications story, from his experience as a Bank of America programmer working on the project. For each part of the history some of the topics may be the same: the goals, the risks, the state of technology, the available tools, the people involved, their backgrounds, daily routine, setbacks and breakthroughs, and the critical role of customer input. ================================================================================ ERMA was in daily use at the Bank of America for eleven years, from 1959 until 1970. Here is the text of the retirement message from the last ERMA system in 1970, which has been preserved in the ERMA exhibit at the Bank of America Technology Center in Concord: A MESSAGE TO ALL MY CO-WORKERS FROM ERMA IN MY ELEVEN YEARS OF SERVICE TO THE BANK OF AMERICA, I HAVE BEEN PRIVILEGED TO WORK WITH SOME OF THE BANK'S FINEST EMPLOYEES. FROM PEOPLE LIKE EMMETT JENKINS, DICK DAVIS, JOHN COOMBS, AND MANY MORE WHO WERE WITH ME FROM THE BEGINNING, TO BOB LEE AND ALL OF MY CURRENT CO-WORKERS WHO ARE ASSISTING ME IN THE PROCESSING OF TRAVELLERS CHEQUES---MY FINAL APPLICATION---I CAN ONLY SAY THANK YOU. TOGETHER WE HAVE MADE GREAT STRIDES IN BANKING. AND I CANNOT HELP BUT FEEL, AS THE FIRST COMPUTER SYSTEM TO BE USED FOR BANKING APPLICATIONS, THAT MY RETIREMENT BRINGS TO CLOSE AN HISTORIC ERA. TO BE THE FIRST IN SOMETHING IS A GREAT ACHIEVEMENT, AND I AM VERY PROUD. BUT MY SUCCESS COULD NOT HAVE BEEN POSSIBLE WITHOUT THE HELP OF SO MANY FINE PEOPLE. ALTHOUGH THE END OF AN ERA IS NEAR, AND WE WILL SOON PART, I WILL NEVER FORGET MY FRIENDS, AND I WISH YOU ALL THE GREATEST SUCCESS IN THE FUTURE. TO MY CURRENT---AND FINAL---ASSISTANTS, I BID FAREWELL--- MY BEST TO ALL, ERMA ================================================================================ Bay Area Computer History Perspectives is a series of programs organized by Peter Nurkse and Jeanie Treichel, of Sun Microsystems, to explore and record our local Bay area computer history. Programs are videotaped for the archives of The Computer Museum in Boston, which maintains collections on the history of the international computer industry. This program is open to the public and free of charge. Suggestions for further programs are welcome, and can be faxed to Jeanie Treichel at 415/691-0756, or e-mailed to nurkse@eng.sun.com. If you are willing to appear on a panel, or can contact someone whom you suggest be included, that additional information would be very helpful. ================================================================================ Directions to SRI International from highway 101 northbound: take Willow Rd. exit in Menlo Park, and go west over 1 mile to Middlefield. Turn right on Middlefield, and follow it about 3/4 mile to Ravenswood. Left on Ravenswood to the main entrance at 333 Ravenswood, half way down the block. Follow signs to the International Building, enter the courtyard, and then go through the Exhibit Hall doors on the right. Or from highway 101 southbound in Menlo Park: take Marsh Rd. west 1 mile to Middlefield, turn left on Middlefield and go south about 1 mile to Ravenswood, then right on Ravenswood to 333 Ravenswood. Follow signs to the International Building, enter the courtyard, and then go through the Exhibit Hall doors on the right. ------------------------------ From: lih@news.cs.columbia.edu (Andrew "Fuz" Lih) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 20 Oct 1993 20:29:05 -0400 In article , Patrick Schaaf wrote: >cshaulis@news.delphi.com (CSHAULIS@DELPHI.COM) writes: >>[on MAC files and their forks, and how they might map to files under Linux] > >Would it be a Bad Thing to have files that, in addition to being a normal >file (the data fork), implement the various directory ops? i.e. access the >data fork as 'foo`, and other forks as 'foo/thingie` and so on? > >having strange ideas... Not so strange: that's how the Apple UNIX File System in the Columbia AppleTalk Package does it. It's been in active use for over 5 years now. -- `''' Andrew "Fuz" Lih Columbia University c @@ lih@cs.columbia.edu Central Research Facilities Tech Staff \ - Whenever anyone says, "theoretically", they really mean, "not really" ------------------------------ From: nop@orodruin.ccs.neu.edu (Jay Carlson) Subject: Re: /dev not needed? Date: Wed, 20 Oct 1993 06:57:05 GMT In article <1993Oct19.004449.629@bhhome.ci.net> bill@bhhome.ci.net (Bill Heiser) writes: sweh.womble@spuddy.UUCP (Stephen Harris) writes: >Was in the shower and had this strange idea: >/dev isn't really needed anymore. Most (all?) of the functionality it >provides could be done using extensions to /proc filesystem. Oh come on now! If LINUX starts going off on tangents like this, we might as well forget being able to consider it a "unix" ... I guess it comes down to what is "Unix". "UNIX" is a trademark of, uh, I can't remember now, so it's not that. Is the filesystem structure defined by, say, V7 UNIX, the test for Unix-ness? If so, did you have the same objection to /usr/ucb, /var, /sbin and /proc? That's in historical order, I think. /usr/ucb and /proc are probably strawmen. Those directories added new functionality. /var and /sbin were and are, in many people's eyes, gratuitous renamings. SysVR4 of course has horribly mangled the fs in ways too numerous to mention :-) I, for one, will go no further with LINUX if it strays far from "standard unix" (I realize there are many unix variants, but I've yet to see one that didn't use /dev :-) I'd like the ability to stray from standard unix, as long as it's still possible to run My Favorite Tools on Linux. I'd love to see operating system progress come out work on this package. -- Jay Carlson nop@io.com nop@ccs.neu.edu Flat text is just *never* what you want. ---stephen p spackman ------------------------------ From: bam@wcl-l.bham.ac.uk (Brian McCauley) Subject: Re: Use 'jargon' reader for FAQ Date: 20 Oct 1993 08:31:35 GMT Reply-To: B.A.McCauley@bham.ac.uk In article ehhchi@maroon.tc.umn.edu (Ed H. Chi) writes: In article you write: >But a hypertext version is unlikely to cut down lazy posts. With the >exisiting FAQ one can often guess a few keywords from the lazy ********s >Subject: lines and find the answer in the FAQ in <30s using the emacs >incremental search. I doubt any hypertext system could reduce this time. For any of this reader stuff to work, it would have to be as easy as posting to the net. It's as simple as that. If it takes them 3 min to type in an article, then the system needs to be easy enough for them to get an answer in 3 min. And the answer needs to be hand-delievered to their doorstep. BEGIN irate ranting But my point is that it's aready *quicker* to look in the FAQ - but it requires *thought*. These people are not only undervaluing other people's time but refusing to think. Unix (and particularly Linux) is a thinking-person's OS - those who refuse to think should be encouraged to either change their ways or go back to DOS. We can only hope that each person only makes the mistake once. A mailbox containing 10 "See FAQ" responses and 6 copies of the FAQ will usually get the message over. It is very important that if you see a question from the FAQ posted that you don't answer it - just say see FAQ or send them the FAQ if you think they may not have it. Being "helpful" to these people is doing everyone (including them) a diservice. END irate ranting -- \\ ( ) No Bullshit! | Email: B.A.McCauley@bham.ac.uk . _\\__[oo from | Phones: +44 21 471 3789 (home) .__/ \\ /\@ /~) /~[ /\/[ | +44 21 627 2171 (voice) 2175 (fax) . l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37 # ll l\\ ~~~~ ~ ~ ~ ~ | A1 93 FE EA BE E3 2A 91 ###LL LL\\ (Brian McCauley) | More: finger bam@wcl-rs.bham.ac.uk ------------------------------ From: ins407x@mdw057.cc.monash.edu.au (Andrew J. Cosgriff !) Subject: Re: Fonts for virtual consoles Reply-To: ins407x@aurora.cc.monash.edu.au Date: Wed, 20 Oct 1993 08:24:16 GMT In article <1993Oct19.145902.2416@sifon.cc.mcgill.ca> fnord@cs.mcgill.ca (Andrew KUCHLING) writes: >In article <2a0mhm$gih@trane.uninett.no> hta@uninett.no (Harald T. Alvestrand) writes: >>1) Will the console patch that allows font loading enter the "standards >> track" of Linux any time soon? >>2) If not, is anyone working on an alternative mechanism? > > So, I agree that VC fonts should become part of the standard Linux >kernel. > > I agree too. Enough people want this feature to make it worthwhile, and it is a real waste to have to repatch every new kernel (why re-invent the wheel?) It would be nice to be able to have standard fonts like xterm supports in the kernel, plus custom fonts. For example: [etc.] Actually, if you take a look at svgalib, there's a subdir with a program called 'restorefont' that will change the VGA textmode font - no kernel patches necessary - all those fonts I used to use in 80x25 textmode under MSDOS look cool in 100x40 under Linux (100x40 on an ET4000 uses a 9x16 grid, like 80x25 ;-) Unfortunately it changes the font for each VC tho', so fontpak is better in that respect. Enjoy, Andrew. -- - Andrew J. Cosgriff - andrew@bing.apana.org.au ins407x@aurora.cc.monash.edu.au "Death? Life? I never did understand Zen." ------------------------------ From: geyer@polyhymnia.iwr.uni-heidelberg.de (Helmut Geyer) Subject: Re: Libc 4.4.4 and new sig 11's (not ram chips) Date: Wed, 20 Oct 93 10:04:49 GMT denouden (denouden@xs4all.hacktic.nl) wrote: :>: :>: Upon loading seyon everything pops up fine, but upon klicking on any :>: button in the control box I get a sig11 error from seyon. Now I KNOW signal :>: 11 is supposed to be a memory error. But before installing libc4.4.4 :>: I had no such error EVER with seyon. It is no an error that will :>: happen every time seyon is loaded. :>: :>: The only system changes were the installation of libc, lib.so.3, :>: and recompiling linux 0.99.pl13 with the new libraries. :>: :>: Has anybody else had this problem? :>: :>Same here... This behaviour is worked upon. The older versions of the seyon binaries are reported to work. There exist some simple (if temprorary) fixes: A binary compiled without optimization will work properly as a statically linked binary will. So recompile seyon with removed -O2 from the Makefile. Helmut :>Cheers, :>Jan den Ouden -- ============================================================================== Helmut Geyer geyer@kalliope.iwr.uni-heidelberg.de ------------------------------ Date: Wed, 20 Oct 1993 06:02:00 EDT From: K-JAMZ Subject: Need tty information I am writing shells that will be used to tell people that they are not permitted to use a computer when they log in. I also am using syslog() to record when they try to login. I need to know where I can get the tty of the process. Something like ttyent.h in SunOS. I am knew to this so if you can help me I would appreciate this. I would also like to know where I can get the man pages for the entire library and function calls in /usr/include Thanks ahead of time. -Ken WIlcox ------------------------------ From: df@eyrie.demon.co.uk (Derek Fawcus) Subject: Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ? Date: Thu, 21 Oct 1993 00:35:00 +0000 In article clau@acs.ucalgary.ca (Christopher Lau) writes: >df@eyrie.demon.co.uk (Derek Fawcus) writes: >> In article <1993Oct8.044610.1783@falcon.DIALix.oz.au> >> root@falcon.DIALix.oz.au (Darren Gilchrist) writes: >> >> I've seen these questions about the Cyrix chip raised a number of times, >> so here's the bumph: >> > >These seem to apply to the Cyrix Cx486DRx^2 clock-doubled part as well.. [ my intro to cache control registers deleted ] >So, you have to do it in that order? Would the follow pseudo-assembly >be correct: > >index .def 0x22 >data .def 0x23 > > out index, 0xc0 > out data, 0x13 ; this is the default setting under DOS >; do I need a NOP or something here? > out index, 0xc1 > out data, 0x00 >; do I need a NOP or something here? > out index, 0xc6 > out data, 0x00 ; disable non-cacheable region looks ok, the NOP's aren't needed as the IO is all on chip, therefore no bus settle time required. >I've written a loadable module for Linux which implements something like >the above. It *seems* to work (benchmark scores increase, but nowhere >near what I'd expect them to..). > >Is there anything else I've missed out? [ more of my article deleted ] >> CCR0 is a set of bits as follows: >> >> BIT NAME >> >> 0 NC0 If 1 sets the first 64k of each 1M boundary as >> non-cachable. > >Anyone know what the benefit of this is? I've found that under DOS, if >I turn this bit *OFF*, my performance decreases a bit.. any ideas why? > >> 1 NC1 If 1 sets 640k to 1M as non-cachable > >NC1 is set by the DOS driver software.. Unix definitely won't benefit from >this, but shouldn't caching the system and video ROMs improve DOS performance >a bit? (my benchmarks don't show any difference) I'd expect that for linux you'd want that area left cachable. >> 4 FLUSH If 1 enables FLUSH# input - don't alter. > >This is turned on. It forces cache invalidation when DMA occurs. > >> >> 5 BARB If 1 enables flushing of the internal cache when hold >> state is entered. > >This is turned off- I'm not sure that it shouldn't be turned ON though.. >Cyrix recommends turning it off if your system asserts HOLD too much. That supprises me, it seems to suggest that on the DRx2, the FLUSH line has some extra on chip circuitry. On the 'DLC this line seems to be intended for when you have a motherboard designed specifically for it. On the DLC, the BARB seems to be intended for then it's replacing a 386. >> I would suggest that you enable the BARB option listed above, as this may >> flush the cache whenever DMA occurs (assuming that DMA causes the uP to >> enter the hold state). You could also set NC1 if and try both values in >> CO to see which is best. > >The documentation for the Cx486DRx^2 states that the HOLD signal usually >activates during DRAM refresh and bus mastering.. this would force >invalidation at every DRAM refresh- so you'd effectively be without cache, >since it's almost always invalid. I'd have to look up the details of the various support chips, but I'd expect at least one of the to implement refresh that doesn't put the processor into HOLD (i.e some sort of hidden/transparent refresh). In this case the HOLD line should only be asserted during DMA. >Apparently the DRx^2 is supposed to handle cache coherency differently than >the DLC (they don't say exactly how), but they don't recommend using the DLC >on motherboards not designed for it.. you're supposed to get a DRx^2 instead. So it would seem, although I've heard that the DLC can be used in place of a 386. One thing I've just noticed, if you're going to use software cache flushing, there are a could of instructions to do this (instead of using in/out's). DF -- Derek Fawcus (G7FVS) df@eyrie.demon.co.uk ------------------------------ From: uhl@sun1sun1.rz.fh-heilbronn.de (Thomas Uhl) Subject: Re: UNIX trademark now X/Open Date: 20 Oct 93 20:57:07 GMT I am interested in this document. but i cannot connect to uiunix.ui.org. I tried several times. The machine must be down. Thomas ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************