From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 16 Sep 93 08:13:09 EDT Subject: Linux-Development Digest #100 Linux-Development Digest #100, Volume #1 Thu, 16 Sep 93 08:13:09 EDT Contents: Re: SMC Ultra... :-( (Donald J. Becker) Re: Test of the Intel 8254 shut-down/parity-check command (Donald J. Becker) Re: NetWare protocol stacks? (Donald J. Becker) To all device driver writers; boot-time messages. (Donald J. Becker) Re: Suggestion for slap (and other packet protocols as well) (Michael O'Reilly) Re: WABI for linux? (Andrew Bulhak) Re: UPS for Linux (Greg Wettstein) Kernel totaly in machine code? (Craig T Manske) GDB 4.8 and g++ 2.4.5 ok? (Harri Pasanen) Re: Kernel totaly in machine code? (David Kastrup) Re: What do people think about /config? (Miquel van Smoorenburg,,,) ---------------------------------------------------------------------------- From: becker@super.org (Donald J. Becker) Subject: Re: SMC Ultra... :-( Date: Wed, 15 Sep 1993 13:33:58 GMT In article <276de0$kus@nntp.hut.fi>, Mika Matti Jalava wrote: >We just bought an SMC Ultra ethernet card for our lab. We thought it >was just a newer version of the Elite (which is a 8013), but >disappointingly it has some obscure 8216 chip. Is there any >development work going on with this thing or do we have to go on with >the old 8003? A small number of SMC Ultra reports (and driver requests ;->) are starting to appear. There are still few enough people that have gotten them that I don't feel a need to write a driver. And all of the usual reasons (not enough time, no documentation, no hardware) apply as well. I do have a preliminary data sheet on the SMC91C90, which I probably picked up while doing research on "high performance" (nobody claims "low performance";->) network interfaces. Is this the chip used in the SMC Ultra? -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: Test of the Intel 8254 shut-down/parity-check command Date: Wed, 15 Sep 1993 13:45:13 GMT [[I've trimmed down the "Newsgroups:" to just COLD.]] In article , Jesus Monroy Jr wrote: >Newsgroups:comp.os.os2.programmer.misc,comp.os.linux.development,comp.os.minix, > comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.sys.ibm.pc.hardware, > comp.sys.ibm.ps2.hardware [[ Other bogus info deleted ]] Sigh... it appear that netcom's posting software is broken again. Could someone dash off a quick note to postmaster@netcom.com? -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: NetWare protocol stacks? Date: Wed, 15 Sep 1993 13:58:30 GMT In article <26vlee$evu@samba.oit.unc.edu>, Jonathan Magid wrote: >In article <26ubjn$e90@panix.com>, Thor Lancelot Simon wrote: >>IPX is a hack on XNS. A free XNS implementation is available from BSD. If you >>could reverse-engineer the differences between XNS and IPX, it likely wouldn't >>be too tough. >> >>Of course, I worked for a firm which was considering this as a product once. >>Novell refused to sell their protocol specs, and the decision came down that >>reverse-engineering IPX wasn't worth the man-hours or potential legal >>problems. Your mileage (and this _is_ Linux, so I hope it does!) may vary. > >I believe that this has changed; when Novell joined COSE, it had to make >all protocols and standards that the vendors were going to share (like >IPX) open. > >The IPX docs are available, but they cost $$. Are these just the docs for IPX, or they document the transport layer and the basic services? I've read (hearsay) that it's just the latter. To put this in terms that more people would understand, it's like documenting IP or even TCP/IP, but not revealing the protocol or semantics for NFS, telnet, and ftp. -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: becker@super.org (Donald J. Becker) Subject: To all device driver writers; boot-time messages. Date: Wed, 15 Sep 1993 14:56:06 GMT Chance Reschke and I were preparing for yet-another-Linux-talk, this one for the MU-SPIN conference, when the topic happened on the boot-time messages. He had a few suggestion: We should be more clearer and more consistent in the message text. The sound driver in particular use the word "Detecting...", which many people have mistaken for "Found...". Use "Probing for ... not found" to avoid this problem. If we are consistent enough, we can write a shell script that optionally substitutes for the kernel 'make config'! It could automatically include drivers based on the devices and filesystems that were detected. I'll add my own suggestions: Report any vital parameters, even if you have unwisely hardcoded them. I just spent about an hour tracking down a busmouse problem, only to find it was on the wrong IRQ. The owner would have solved this himself if it had been reported at boot-time. (The better solution here would be to use autoIRQ and/or allow a boot-time override. What say, busmouse driver writers?) The reported values should probably include the base I/O and memory addresses, the IRQ with a note like "guessed", "assigned" or "autoIRQ". All drivers should have a 'static char* version= "...";' string. Beta or debugging versions should print this version string out at boot-time. Finally a related wish-list entry: a version of 'make config' that builds the {autoconfig.h, .config} files without asking the questions. This can be used by people that edit the 'config.in' defaults directly and don't want to answer all of the questions again. Comments? Suggestions? -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: Suggestion for slap (and other packet protocols as well) Date: 16 Sep 1993 03:34:54 GMT Olaf Titz (uknf@rzstud1.rz.uni-karlsruhe.de) wrote: : In article <276555$pvq@uniwa.uwa.edu.au>, : Michael O'Reilly wrote: : > I still can't see why the header needs to be unique. The headers are : > checksumed, and a bad checksum causes scanning to resume from 1 byte : > into the corrupt header (i.e. simply skipping the SOH). : > This should fix all the problems w/o overheads, right? : No, the problem is that if one packet arrives truncated, the *next* : packet's SOH gets lost and by scanning forward the next packet is lost : too. As Jeff has pointed out already, in this case you need to scan : backwards. Well, I was trying to say just what jeff said. We did discuss this some time ago.. : What has led to this ideas in the first place were some lock-ups I had : with term. After I had established a stable connection and already : downloaded a portion of a file with reasonable throughput, I got : increasingly many timeouts - looked like buffer overruns but I had set : baudrate low enough for the line - and eventually timeouts forever. : The remote term kept resending packets after 15 secs (timeout 150) and : the local term kept not answering, as to be seen from the modem LEDs. : (It didn't send C_STATS to the tmon client either.) Of course this : could be caused by a bug in term but it could also be caused by my : (proven) lossy line via a propagation of errors from one packet to : another - finally through the whole window. (Again, perhaps I'm : competely off, but these are just thoughts.) Yes, this is possible. And yes, I've seen it. It usually happens with machines the insert soft flow control characters.. : > Nahh. You want it the other way around. Define (frinstance) 'A' to be : > SOH, and then escape every occurence of 'A' in the data. i.e. replace : > 'A' in data with '^' 'A'+33 (still haven't bothered checking if 33 is : > a generator for the mod 256 ints). Your 'common' case is SOH, your : > uncommon case is 'A' in data. : This could be argued with statistcal analysis of the data. Assuming : data in packets is uniformly distributed (reasonable assumption if : data is compressed), and discounting escapes (reasonable if line is : transparent, the one escape for the escape character itself is not : that important) you can assume every 256th character to be an "A". : Thus SOHs are more common than in-packet "A"s if packets including : headers are (in average) smaller than 256. This is surely the case for : interactive jobs. I'm not sure about file transfer, but probably you : are right - perhaps it's better to escape the "A" in-packet. : (Hmmm, when starting to write the last paragraph I assumed I would get : the opposite result :-) :-) Grin. I was just about to mention that's the way I was arguing.. :) : Olaf Michael. ------------------------------ From: acb@yoyo.cc.monash.edu.au (Andrew Bulhak) Subject: Re: WABI for linux? Date: Thu, 16 Sep 1993 02:29:48 GMT wheelusc@cse.fau.edu (Chuck Wheelus) writes: >I saw, sometime back, that there were a group of programmers working on >a WABI like program for linux. Does anyone have some info. on the >status/name/availability of this program? The project is called Wine; it is currently under development (you can [sort of] run Solitaire on it at this stage, but not much else, and it crashes in certain cases). If you are interested in working on it, subscribe to the WABI channel of the linux-activists mailing list. Wine will go into alpha in the near future. Andrew Bulhak | acb@yoyo.cc.monash.edu.au | "Either Mr Dahmus is a Unix ignorant or he Monash Uni, Clayton, | believes that the other a.f.c. readers are." Victoria, Australia | -- Dan Pop, on alt.folklore.computers. ------------------------------ Date: Wed, 15 Sep 1993 11:42:51 CDT From: Greg Wettstein Subject: Re: UPS for Linux > I have not been able to get the ups-2.45.2 with patches posted to Sunsite > to come close to compiling. There seem to links made to wrong directories, etc. To Clarence and whoever else may be listening.... I just got done installing UPS. It seems to be an excellent debugger and my thanks to Rick for doing the port. Be careful when installing this package on filesystems which only support 14 character filenames, e.g. minix. In the ups sub-directory there are a .c and a .h file which extract with filenames longer than 14 characters. The one that I had trouble with specifically was ci_compile_expr.. The .c file ends up overwriting the .h file and when the package is compiled one ends up with an infinite include recursion which typically causes cpp to run out of memory. My fix was to rename the files ci_comp_exp.. A better solution is to probably use a 30 character minix filesystem or alternatively ext2fs or xiafs. I didn't happen to have a spare partition around at the time and took the path of least resistance. Once over this hurdle the package compiled cleanly and seems to work as it should. Good luck. As always, Dr. G.W. Wettstein Oncology Research Div. Computing Facility Roger Maris Cancer Center UUCP: uunet!plains!wind!greg Fargo, ND 58122 INTERNET: greg%wind.UUCP@plains.nodak.edu Phone: 701-234-2833 ====================================================================== `The truest mark of a man's wisdom is his ability to listen to other men expound their wisdom.' -- GWW ------------------------------ From: albion@csd4.csd.uwm.edu (Craig T Manske) Subject: Kernel totaly in machine code? Date: 16 Sep 1993 07:49:59 GMT I was just wondering why parts of the kernel aren't in machine code? It seems to me that at least the hard drive stuff would be much faster if it were totaly in machine code. This question came to mind after see a friend of mine's os/9 box, who's OS is totaly machine code. Just one of thoes things I ponder. :) Albion albion@csd4.csd.uwm.edu ------------------------------ From: hpasanen@cs.hut.fi (Harri Pasanen) Subject: GDB 4.8 and g++ 2.4.5 ok? Date: 16 Sep 1993 08:11:58 GMT I've had zero luck in trying to debug a small C++ program using GDB v4.8. The problem is that it runs out of memory every time (8Mb ram + 16Mb swap). It happily loads the program, but when I try to set a breakpoint, it then just goes a way for a while, reports unable to allocate 12 bytes, and dies. I can't really imagine it would need all that memory, but if it does, how much would be enough? Note that I've had no problems with plain C programs. Does the newest GDB compile out of the box for linux? The latest binary I've seen is 4.8. Thanks, Harri ------------------------------ From: dak@hathi.informatik.rwth-aachen.de (David Kastrup) Subject: Re: Kernel totaly in machine code? Date: 16 Sep 1993 10:45:15 GMT albion@csd4.csd.uwm.edu (Craig T Manske) writes: >I was just wondering why parts of the kernel aren't in machine code? It >seems to me that at least the hard drive stuff would be much faster if it >were totaly in machine code. >This question came to mind after see a friend of mine's os/9 box, who's >OS is totaly machine code. It has to do with the GNU C compiler. If you examine the code closely, you will note that in several files GNU Assembler templates are used. As opposed to conventional Assembler inline possibilities, the GNU C compiler has full information about registers (and possible register reassignments, and possible addressing modes...) and so inline Assembly code will not confuse the optimizer. Since very little Assembler suffices thus to get the really hard things done properly, this is pretty acceptable (although most of the templates I have seen are way to restrictive: telling, for example, the C compiler which registers to use, which it could better figure out for itself). Also, note that data structures in pure Assembly code are likely to be less sophisticated (due to worse overview in Assembler), so that coding "the same" in C and Assembler will have a speed advantage for Assembler (when its finally working), but it is much more probable that you will choose efficient algorithms and data structures if a compiler instead of an assembler helps you in prganizing things. -- David Kastrup dak@pool.informatik.rwth-aachen.de Tel: +49-241-72419 Fax: +49-241-79502 Goethestr. 20, D-52064 Aachen ------------------------------ From: miquels@caution.cistron.nl.mugnet.org (Miquel van Smoorenburg,,,) Subject: Re: What do people think about /config? Date: Thu, 16 Sep 93 10:25:00 In article <748100210snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes: >As anyone has noticed, there are many programs that have >configuration files. And, these configuration files all have their >own format. I've been thinking that we can do better than that. I absolutely agree here. You know that the Linux netwerking code also uses /conf, and that all configuration files in /etc, /usr/etc etcetera are links into that directory. This was something I made up during one of my _long_ telephone sessions with Fred van Kempen (thank God it's local tariff) but most people seem not to be very happy with it. The new idea most peope have now is to move all binaries out of /etc into /sbin, ditto for /usr/etc, so that /etc and /usr/etc only contain configuration files. But what about /lib, /usr/lib? That still does not put config files into one place.. >We create a standard configuration file format, and a set of programs >that "compile" the standard format into each idiosyncratic file. And >optionally, we can have a program that edits these files, just to >add some gloss to the system. > >And, all these files go in /config. Only configuration files go in >/config. Maybe this could even be one big database, or otherwise a set of files with the same layout. Something like a 'generic resource file' with a consistent format. I heard they implemented something like this on the Next. One big database containing all system information. >When people make a change to a file in /config, they run "make" to >install that change. The makefile takes care of translating into the >idiosyncratic format and signalling/restarting any daemons. > >And, no matter what kind of idiosyncratic file you've got to create, >you can add comments to the config file (e.g. /etc/passwd cannot have >comments, but /config/passwd can). Now, how about the idea that Domain/OS uses: special configuration files like /etc/passwd aren't files, but file system objects. If you read them you read an object, and you can't write to them. I propose something like a 'user FS' here, but then 'user FILES'. A special file type that, when opened for reading, connects to a daemon in user space that knows about the global database and the format for this file. Maybe this file can be a generic file with a special bit set, so that the daemon can read the 'real' file to get the file template and then generate the 'virtual' file. I believe that something like this has already been written - this sounds a lot like the 'loopback devices' (correct me if I'm wrong). If you do it right, for every new configuration file you only have to create a template and put it into place.. For the password file, this would mean that it will be very easy to create our 'own' version of NIS passwords _without_ changing any user level code.. and numerous other uses could be thought up. >I'm open to suggestions (including the suggestion that it's a stupid >idea :). I intend to write the code for this after I hear what >people think of it. > The idea is good. And certainly in the beginning easier than adding kernel features for it. >Here's my current design for the configuration file format: > [ fine design deleted ] >Example: > >;comment >[section label] >name=value >name1=value line 1\ >value line 2 >;blank lines are fun to look at but meaningless, > >;but blank lines in the middle of a value *are* significant. >name2=value line 1\ >\ >value line 3 > >;the following is in error because it is not part of a name=value pair. >name > >[another section label] >;note that the following is really "anothername=another value". >another name=another value > Hehe - and we call it SYSTEM.INI :-) :-) >Semantics: > [ deleted. The idea of using perl scripts here is tempting. Hmm, gotta learn perl sometime :-) ] >-russ What canst *thou* say? >Crynwr Software Crynwr Software sells packet driver support. >11 Grant St. 315-268-1925 Voice | LPF member - ask me about >Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. > > Mike. -- | Miquel van Smoorenburg, | | Chips - the dope of the nineties. You may carry them with you, | | but they are more expensive per kilo than cocaine. | ------------------------------ ** 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 ******************************