Subject: Linux-Development Digest #576 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Fri, 25 Mar 94 03:13:11 EST Linux-Development Digest #576, Volume #1 Fri, 25 Mar 94 03:13:11 EST Contents: Re: Afserver for Transputer under Linux ??? (Gerrit Nieuwenhuizen) Re: probs with ide drive identification (Mark Lord) Xterm problem w/ 1.0 (bryan wright) tcpdump: why is the -p flag reversed in meaning? (Paul Tomblin) Re: Printer Problems -- ANSWERS (Pete Keyes) Afserver for Transputer under Linux ??? (Kai Dittmann) Re: Proposal - Coordinating bug fixes with enhancements. (J.S. van Oosten) Re: GOD SPEAKS ON LINUX! (-J.P.A.Vierinen-) Re: in libc-4.5.21? (Christer Weinigel) Re: Interrupts?? (Timo Giesselmann) PTY bug? (Daniel S. Ridge) Re: Proposal - Coordinating bug fixes with enhancements. (John Plocher) Re: LINUX port to a transputer system (Frank Gleason) ---------------------------------------------------------------------------- From: nieuwhzn@dxgsia.cern.ch (Gerrit Nieuwenhuizen) Subject: Re: Afserver for Transputer under Linux ??? Date: Thu, 24 Mar 1994 12:57:45 GMT The most recent version I could find with archie was on alf.uib.no in directory /pub/Linux/kernel and is called transputer-04.tar.gz. Have fun and let the net know if there are any new developments. I'm especially interested in the gcc port someone talked about. This could trigger me to get my own transputer system (formerly hooked up to an Atari ST) going again. Greetings, Gerrit Gerrit J. van Nieuwenhuizen CERN-PPE-IO Building 595, R-004 CH-1211 Geneve 23 Switzerland nieuwhzn@dxgsia.cern.ch (or NIEUWHZN@VXWA80.CERN.CH) tel.: +41 22 767 4740 fax : +41 22 782 4897 ------------------------------ From: mlord@bnr.ca (Mark Lord) Subject: Re: probs with ide drive identification Date: 24 Mar 1994 18:51:24 GMT In article <2m25raINNj54@mailhost.uni-koblenz.de> rausch@informatik.uni-koblenz.de writes: >as I'm currently working on the IDE driver for Linux 68k, I've faced a >problem with the 'identify' command; I'm using this (optional) command >to gather cyl/head/sectors information from the drives, but I've not yet >managed to extract the drive's name/revision etc. The docs I have say >it's just plain ascii data, but that seems to be wrong ... Take a look at my "IDE Performance Package" -- it includes code that issues and interprets/displays the drive identification thingie. The text strings returned are in "BIG-endian" byte order, and the drive-name in particular is sometimes right-justified (40 char field) rather than left justified. Here is a code extract: +#if VERBOSE_DRIVEID + +char *cfg_str[] = +{ "", " HardSect", " SoftSect", " NotMFM", " HdSw>15uSec", " SpinMotCtl", + " Fixed", " Removeable", " DTR<=5Mbs", " DTR>5Mbs", " DTR>10Mbs", + " RotSpdTol>.5%", " dStbOff", " TrkOff", " FmtGapReq", "", +}; + +char *SlowMedFast[] = {"slow", "medium", "fast"}; +char *BuffType[] = {"?", "1Sect", "DualPort", "DualPortCache"}; + +#define YN(b) (((b)==0)?"no":"yes") + +static void rawstring (char *prefix, char *s, int n) +{ + printk(prefix); + if (*s) { + int i; + for (i=0; i < n && s[i^1] == ' '; ++i); /* strip blanks */ + for (; i < n && s[i^1]; ++i) + if (s[i^1] != ' ' || ((i+1) < n && s[(i+1)^1] != ' ')) + printk("%c",s[i^1]); + } +} + +static void dmpstr (char *prefix, unsigned int i, char *s[], unsigned int maxi) +{ + printk(prefix); + printk( (i > maxi) ? "?" : s[i] ); +} + +static void dump_identity (unsigned int dev, unsigned short ib[]) +{ + int i; + char dashes[] = "\n+-------------------------------------------------------------------+\n"; + printk (dashes); + printk ("hd%c: Drive Identification Info:\n", dev+'a'); + rawstring (" Model=",(char *)&ib[27],40); + rawstring (", FwRev=",(char *)&ib[23],8); + rawstring (", SerialNo=",(char *)&ib[10],20); + printk ("\n Config={"); + for (i=0; i<=15; i++) if (ib[0] & (1<dev); + + if (inb_p(HD_STATUS)&(BUSY_STAT|ERR_STAT)) + printk (" hd%c: multiple mode not supported\n", dev+'a'); + else { + insw(HD_DATA,(char *)ib,64); /* get first 128 ID bytes */ + sti(); +#if VERBOSE_DRIVEID + dump_identity(dev, ib); +#endif /* VERBOSE_DRIVEID */ + if (ib[27]) { + int i; + for (i=27; i<= 46; i++) + ib[i] = (ib[i]>>8) | (ib[i]<<8); + printk (" hd%c: %-.40s (%dMB IDE w/%dKB Cache)\n", + dev+'a', (char *)&ib[27], ib[1]*ib[3]*ib[6] / 2048, ib[21]>>1); + } + insw(HD_DATA,(char *)ib,64); /* flush remaining 384 ID bytes */ + insw(HD_DATA,(char *)ib,64); + cli(); + insw(HD_DATA,(char *)ib,64); + } + do_hd_request(); + return; +} + -- mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482 ------------------------------ From: bryan@pedro.phys.Virginia.EDU (bryan wright) Subject: Xterm problem w/ 1.0 Date: Tue, 22 Mar 1994 18:29:19 GMT Hi Folks, This morning, I tried upgrading from 0.99pl15a to 1.0. Everything seemed to work fine, except that I could no longer re-define keys in an xterm. I have the following lines in my .Xdefaults file: *VT100.Translations: #override F11: string("\033OP") \n \ KP_Divide: string("\033OQ") \n\ KP_Multiply: string("\033OR") \n\ KP_Subtract: string("\033OS") \n\ KP_Add: string("\033Ol") \n\ KP_7: string("\033Ow") \n\ KP_8: string("\033Ox") \n\ KP_9: string("\033Oy") \n\ KP_4: string("\033Ot") \n\ KP_5: string("\033Ou") \n\ KP_6: string("\033Ov") \n\ KP_1: string("\033Oq") \n\ KP_2: string("\033Or") \n\ KP_3: string("\033Os") \n\ KP_0: string("\033Op") \n\ KP_Decimal: string("\033On") \n\ KP_Enter: string("\033OM") \n These generate the standard VT200 keypad escape sequences. This works fine under 0.99pl15a and earlier, but fails under 1.0. The keypad keys under 1.0 seem to be "hard-wired" to generate a different set of escape sequences, and xterm doesn't want to re-define them based on the resources in my .Xdefaults. (I'm running Xfree 2.0, by the way.) For the time being, I've gone back to 0.99pl15a, but I'd like to be able to use the latest version of the kernel. Does anyone have any suggestions? Thanks, Bryan -- =============================================================================== Bryan Wright |"If you take cranberries and stew them like Physics Department | applesauce, they taste much more like prunes University of Virginia | than rhubarb does." -- Groucho Charlottesville, VA 22901 | (804) 924-6814 | bryan@sphinx.phys.virginia.edu =============================================================================== ------------------------------ From: ptomblin@gandalf.ca (Paul Tomblin) Subject: tcpdump: why is the -p flag reversed in meaning? Date: 23 Mar 1994 11:07:05 -0500 I can't find anything about who ported tcpdump to linux, but I was wondering why whoever did it REVERSED the meaning of the -p flag. If you look at pcap-pf.c or pcap-snit.c, they both say: if (pflag == 0) |= PROMISC; and in pcap-linux, it says: if (pflag) ifr.ifr_flags |= IFF_PROMISC; I found this out quite by accident, and ftped the source yesterday to verify. -- Paul Tomblin, Head - Automation Design Group. Gandalf Canada Limited This is not an official statement of Gandalf, or of Vicki Robinson. "Hello, this is Linus Torvalds, and I pronounce Linux as Linux" ------------------------------ From: pjk@cyphyn.radnet.com (Pete Keyes) Subject: Re: Printer Problems -- ANSWERS Date: Wed, 23 Mar 94 04:03:22 GMT Ken Kopilevich (kirill@crl.com) wrote: : :: tsx-11.mit.edu ^^^^^^^^^^^^^^^ Minor typo, tsx-11.mit.edu : sunsite.unc.edu : ftp.funic.fi ^^^^^^^^^^^^ Minor typo, ftp.funet.fi Pete : : Good Luck ! [much other relevant stuff deleted] : : Steve : ------------------------------ Date: 23 Mar 1994 23:13:00 +0100 From: k.dittmann@anarch.ping.de (Kai Dittmann) Subject: Afserver for Transputer under Linux ??? Hello... i search for a port of the AlienFile-Server (AFServer) for a single T805 Board and a little TRAM-Network under Linux. Does anyone know where i find them ?? I want use this thing to run my port of POV-Ray under Linux on a single T805 Transputer... Or, does anyone know how i find another port of POV for Transi ? I have a little Transputernetwork with one T805 and 3*T425 and i want to get all my Chips to work, because, this nettwerk runs currently without any usefull solution or software and takes at this moment only very much dust and energy... kai dittmann ## CrossPoint v2.93 ## ------------------------------ From: jvoosten@compiler.tdcnet.nl (J.S. van Oosten) Subject: Re: Proposal - Coordinating bug fixes with enhancements. Date: Wed, 23 Mar 1994 01:48:20 GMT Harvey J. Stein (hjstein@sunset.huji.ac.il) wrote: : The way I see it, there are two general classes of changes that are : made, namely bug fixes & enhancements. I don't see it as strict: a lot of time short enhancements are included, often a few lines of code that run faster or better as it should be, but you can also see them as fixes then. And in most cases, enhancements are shipped together with bugsfixes in a single patch, and otherwise your coherency with the "real" sources would break down very soon. : My idea is to use a version number scheme that basically marks where : the enhancements occur. It wouldn't be so different than the current : method of numbered & lettered patch levels, except that there would be : meaning in when the numbers & letters change. : We could keep track of enhancements versus bug fixes by having : versions consisting of four numbers (like internet addresses). We'd : have Linux Version a.b.c.d, where c & d would be left out when they're : zero. The meaning would be as in the following example: : Version Status : 1.0 Major release (only bug fixes). : 1.0.0.1 Enhancement added. : 1.0.0.2 Bug fix. : 1.0.0.3 Bug fix. : 1.0.0.4 Bug fix. : 1.0.1 Last minor release before new enhancement (could be the same : as version 1.0.0.4). : 1.0.1.1 Enhancement added. : 1.0.1.2 Bug fix. : 1.0.1.3 Bug fix. : 1.0.1.4 Bug fix. : 1.0.1.5 Bug fix. : 1.0.2 Minor release, only bug fixes, could be same as 1.0.1.5 : . : . : . : 1.1 Major release. Needlessly complex. Heck, if I save those patches on MS-DOS floppy I want to spend a few letters on the word 'kernel' or 'linux' or something like that, not a big row of numbers ! : Maybe pl would be a minor release, : just including bug fixes, pl would represent an : enhancement when is a-l & bug fixes only from m-z, so that : pl is the same as pl, where is the last : kernel in the pl series, after bug fixes have been going in for : afew lettered releases. Excuse my sarcasm, but how are you going to explain to a relative new person in Linux that pl103f could actually be newer than pl103q ?? : Or, we could use even and odd. Even numbered patch levels could be : the kernels where enhancements go, and odd numbered patch levels could : be bug fix only kernels. I think I like this last alternative the best. Hmm, and get questions like: "I've seen pl103a, b, c & e, but where's 'd' ?" : If people want to make this even stronger, they could even do as was : done with version 1.0, namely having well defined times where : enhancements are allowed in. Now there's a point here. Since we're now (hopefully) released from the 'taming' as we were slowing growing to 1.00 with 0.99.14abcd.. 0.99.15abcd.. because we were running out of version numbers :-), we could now do this: - New features in linux Like new drivers, code for advanced things like rpc, and other stuff we come up with, are held back to a new major release, that increases the version number by 1 (so the next major would be linux 2.0) - fixes etc. increase the version by a hundreth, so we get linux 1.01, 1.02, 1.03 and so on. - The last fix _before_ a new major release gets number x.99, to indicate that no newer fixes are expected for this release level. This would be a stable, thoroughly debugged version you could use on the machines at work, for example. The version (x+1).00, .01 .02 .. will be used as the next development platform. My .02 J. v. O. -- Sometimes I wonder if this whole universe isn't anything more than a simulation on a BIG computer. And they just might press Ctrl-C any time now... -- My PGP public key [version 2.3] (you know when, why and how...) : mQCNAi1lYqsAAAEEAMCgUKS7DxyGF8D7QIGYXxRuh2n9Q2+5gIrrb1n9iOl4Xlgo cO8Y3DE71J5K6WhlpEGDqXZIwY/Xx8mxq80ZHJ3n0pHOUxOQGdxxMT1mrKotjE4Y wmGqnQhMhpcCKgT/5+5xhuMEluyGQqjyud3PCDogJCC/Sia7eO9+56e/13btAAUR tC1KLlMuIHZhbiBPb3N0ZW4gPGp2b29zdGVuQGNvbXBpbGVyLnRkY25ldC5ubD4= =3brb ------------------------------ From: jvi@uwasa.fi (-J.P.A.Vierinen-) Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc Subject: Re: GOD SPEAKS ON LINUX! Date: 24 Mar 1994 13:36:00 GMT Carlos Myers (myers_c@ab.wvnet.edu) wrote: : In article <24FEB199429594568@up.there.above>, God@Up.There.Above (God) writes: : > THIS IS THE VOICE OF THE LORD! -Stuff Deleted- Hahahahahah...Here we have one looser again! By the way, do you know what CapsLock mean? :-) -JuHa *-------------------* **** *---------------------------* * - M U L T I M E D I A For Mac & PC & Amiga * * - U N I X & Linux OS For PC (386&486) * * * * Juha P.A. Vierinen - (jvi@chyde.uwasa.fi) * * (jvi@freeport.uwasa.fi) * *------------------------------------------------------* ------------------------------ From: y93chrwe@odalix.ida.liu.se (Christer Weinigel) Subject: Re: in libc-4.5.21? Date: 22 Mar 94 05:13:48 GMT toman@darkwing.uoregon.edu (Joseph Toman) writes: >Hi, I am trying to compile various source code packages for "Lee-noocks" :) >and I don't seem to have the ANSI C standard include file . It is >neither in Slackware 1.1.2 nor in libc-4.5.21 on tsx-11. Where can I find it? When I got this error, I noticed that gcc searches for include files in /usr/local/lib/gcc-include. This directory did not exist on my machine; I guess this is a problem with Slackware 1.1.2. Well, anyway this solved the problem for me. The line for cpp fixed some other problems I've had. ln -s /usr/lib/gcc-lib/i486-linux/2.5.8/include /usr/local/lib/gcc-include ln -s /usr/lib/gcc-lib/i486-linux/2.5.8/cpp /lib/cpp /Christer Weingel ------------------------------ From: tgie@sun2 (Timo Giesselmann) Subject: Re: Interrupts?? Reply-To: tgie@tet.uni-hannover.de Date: Thu, 24 Mar 1994 22:34:16 GMT Pieter.Verhaeghe (pive@uia.ac.be) wrote: : Probably a confusing subject, but let me explain the problem: : I have a notebook, which starts beeping and flashing (a led) whenever : the batteries are low. This didn't work under Linux, so I started to : disassemble the BIOS. I'm rather convinced that everything happens : in the DOS interrupt 8 which does the following : jump to the int 8 location : [...] : read a certain port number and put the result in AL : according to the value of AL beep/flash or do nothing : [...] : iret : My question is: how can I implement this behaviour in Linux? : (or better: does there exists a skeleton for implementing this?) : Thanks : Pieter With DOS (resp. the BIOS), interrupt 8 is invoked 18.2 times a second by the hardware. You should write a user mode driver. It is described in the Kernel Hackers Guide very well. A user mode driver is just a normal process running under Linux that is allowed to access the ports. You may write an infinite loop that sleeps e.g. for 10 seconds and then checks the port and invokes any action when battery is empty, then sleeps again. So you don't need to patch the kernel. This Watchdog process may be invoked by the system startup rc file. -- Timo Giesselmann tel.: +511/797098 e-mail: tgie@tet.uni-hannover.de ------------------------------ From: newt@eng.umd.edu (Daniel S. Ridge) Subject: PTY bug? Date: 24 Mar 1994 17:52:02 GMT Is there a bug in the kernal pty handling that would keep me from running SLIP over a pty line? I have been unable to do this. The symptom is that if I start a SLIP session on a pty line, I am unable to connect to any of the ports on the server machine (not just from my machine, but from any machine. I can't even sit down at the console of the server and telnet loopback. It prints "login:" and then immediatly closes the connection. Has anyone else had this problem? Will I not be able to SLIP over a pty line? Thanks, Dan Ridge (newt@eng.umd.edu) ------------------------------ From: plocher@attaboy (John Plocher) Subject: Re: Proposal - Coordinating bug fixes with enhancements. Date: 24 Mar 1994 00:48:39 GMT : - New features in linux Like new drivers, code for advanced things like rpc, : and other stuff we come up with, are held back to a new major release, From a systems view, there are two kinds of changes: 1) Major ones that change existing interfaces 2) minor ones that only change implementations of an existing interface. Tying into this discussion, as long as the device driver <==> kernel interface was unchanged, I could use any driver version with any kernel version. The Golden Rule would be that you can *never* delete functionality from an interface without potentially breaking ALL existing code. Thus, a well defined interface can be more important than several quick-hack generations of implementations. In the distributed development world that Linux is evolving in, the definition of strong interfaces (POSIX, COSE/1170, STREAMS/sockets...) is a powerful tool. We should strive to use it... Just my opinions... -John ------------------------------ From: frankg@halcyon.halcyon.com (Frank Gleason) Subject: Re: LINUX port to a transputer system Date: 23 Mar 1994 02:51:35 GMT Antoni.Baranski@si.hhs.nl (Baranski, A.S.) writes: >Hi World, > I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland. >During my summer holliday I am planning on making a port of LINUX onto a T800 >transputer subsystem which plugs into my PC. >Thanx >------------------------------------------------| >Baranski, A. S. | Haagse HogeSchool | >E-Mail: | Sector Informatica | >Antoni.Baranski@si.hhs.nl | Student Software Engineering | >------------------------------------------------| You may wish to look at the Minix port available on ftp.inmos.co.uk:software/os The source has not been released yet but you may be able to get it if you ask. I would be interested if you get it. Minix uses the isever and does run under Linux. frankg@halcyon.com ------------------------------ ** 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 ******************************