From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 25 Sep 93 13:13:11 EDT Subject: Linux-Development Digest #127 Linux-Development Digest #127, Volume #1 Sat, 25 Sep 93 13:13:11 EDT Contents: Linux 0.99pl9 (SLS 1.01) and 3Com EtherLink 16? Any hope? (Donald Burr) Re: NetWare protocol stacks? (Donald J. Becker) Re: Mouseless X for Linux notebook (Matthias Urlichs) Re: [Q] biff and comsat? (Michael O'Reilly) fixed in.ftpd (Charles Hedrick) Re: linux & 3c501 ? experiences ? (Cameron L. Spitzer) Re: /config (Andreas Klemm) Re: To all device driver writers; boot-time (Andreas Klemm) Re: To all device driver writers; boot-time (Lars Wirzenius) Re: To all device driver writers; boot-time (Brandon S. Allbery) PC for linux (TODOROV Krassimir) g++: running out of virtual memory! (Tim W. Johnson) Re: Intelligent Serial I/O: DIY (Matthias Urlichs) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux From: dburr@sbanet.netmail.com (Donald Burr) Subject: Linux 0.99pl9 (SLS 1.01) and 3Com EtherLink 16? Any hope? Date: Sat, 25 Sep 1993 00:16:59 GMT Hello, Linuxers!! I just purchased a new Ethernet card for my 386DX/40 clone. It is a 3Com EtherLink 16, a 16-bit ISA Ethernet card with both an AUI port and a BNC connector. I'm running Linux 0.99pl9, as distributed with SLS 1.01, and would like to get Linux running using this card, so that I can start building my dream of a home Ethernet network. I would like to use the BNC connector, since I've got other devices that use ThinNet cabling. However, I do have a transceiver that plugs into the AUI port, so I can use that if needed. A few questions: (1) Is there a driver for this card, for Linux 0.99pl9? If so, (A) Where can I get it? (FTP site) (B) How do I install it? (if it's not obviously documented in README) (2) If there isn't a driver for 0.99pl9, is there a driver for 0.99pl10 or any of the other newer versions of Linux? (A) If so, where can I get it? (B) How do I install it? (if it's not obviously documented in README) (3) If there isn't ANY driver for this card... (A) Is this card sufficiently compatible/similar with another type of network card, that I can use the driver for that other card? (B) Where can I get it, and how do I install it? (C) If no drivers that exist will work, is there any hope of MAKING a driver for this card? (i.e. are the spec's available, or is it a case like with Diamond video boards, where they won't release the info necessary to program it) Please respond to me here at dburr@sbanet.netmail.com. THANK YOU!! -- __ _ __ Donald Burr, System Admin. / ) // / / ) Santa Barbara Area Network / / ________ __. // __/ /--< . . __ __ INTERNET: /__/_(_) / / <_(_/|_, Derek Fawcus wrote: >The IPX docs are available for free. Novell have a document describing >what is needed to implement a router, this describes the IPX protocol. > >Perhaps you were refering to the NCP documentation? When people say "IP networking", they are talking about the whole suite of protocols including UDP, TCP, ARP, ICMP, telnet, ftp, and often NFS, rexec, etc. Likewise when they say IPX they mean the IPX protocol stack in common use, not "just enough to implement a router". I my opinion, documenting the very lowest layer and then calling the whole -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: Mouseless X for Linux notebook Date: 25 Sep 1993 01:23:02 +0200 In comp.os.linux.development, article <1993Sep19.200915.404@cs.wisc.edu>, austin@aura.cs.wisc.edu (Todd Austin) writes: > > p.s. here's a tool us small memory types could use -- run gprof on > an executable, recording the frequency of time spent in each executed > procedure for a "typical" usage of the program, then feed this information > back into "ld" so it could order procedures in the text in decreasing order > of frequency of time executed. This would minimize the internal fragmentation > found in allocated pages, thus maximizing the utilization of allocated > physical ram pages. I suspect the typical program's working set size would > decrease dramatically. > Doesn't work. The object file structure as used by Linux and virtually every other Unix system in existence is such that there's no clear boundary between procedures. Thus the linker cannot reorder them. It would be able to reorder object files but I don't think that buys you enough. It might be possible to convince gcc/ld to use a better file format, though. -- If you're a real good kid, I'll give you a piggy-back ride on a buzz-saw. -- W. C. Fields -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: [Q] biff and comsat? Date: 25 Sep 1993 04:24:57 GMT Stephen R. van den Berg (berg@pool.informatik.rwth-aachen.de) wrote: : In article <1993Sep18.020212.7553@nrao.edu>, : Rafal Maszkowski wrote: : >Johannes Grosen (grosen@argv.cs.ndsu.nodak.edu) wrote: : >: In article <1993Sep16.141819.23697@nrao.edu> rzm@oden.oso.chalmers.se (Rafal Maszkowski) writes: : >: >Have anybody ported biff and comsat (are these 2 enough to get : >: I have `ported' them to my machine but there really isn't any need if you : >: are running `bash' as your shell. Check the `MAIL' and `MAILPATH' : >to run it. I tried from both inetd.conf and standalone. As far as I : >understand comsat listens on udp 512 - : Correct. : > but which program is sending : >user@offset there? : If you simply use procmail as the default mail-delivery agent, it will do : the sending for you. Most mail-delivery agents will do it for you, you simply have to tell them to do so. By default, smail doesn't have it compiled it, so add COMSAT to the HAVE list. Sendmail, I have no idea. Michael. ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: fixed in.ftpd Date: 25 Sep 93 06:00:18 GMT I've uploaded a fixed copy of in.ftpd to tsx-11. Since their incoming is not visible, I've also put it in athos.rutgers.edu:/pub/linux/ftpd.tar.z. The only difference between this and the net-2 version is that this fixes a bug causing "data connection: illegal seek" when sending data over a slow link. Source and executable. (The makefile and order of a couple of includes had to be changed because of differences in include files and libraries between when net-2 was issued and now. While it's built with shadow password defined, I have no idea whether shadow passwords actually work or not.) Somebody mentioned having fixed this already. But since they didn't feel moved to give us the fix, and I was getting fed up with not being able to get files from my Linux server, I decided to fix it myself. (By the way, one could argue that the bug is actually in the kernel. However I'd rather have ftp working for the moment, and the change should be harmless even if the kernel is fixed. The problem is that write on a network connection may not send all the bytes the user asked for. I'm inclined to think that unless non-blocking I/O is set, the kernel ought to block until it has sent everything. ftpd was coded to treat a short count as an error. Interestingly, ftp is coded to handle short counts.) ------------------------------ Crossposted-To: comp.os.linux.misc From: cls@truffula.sj.ca.us (Cameron L. Spitzer) Subject: Re: linux & 3c501 ? experiences ? Date: Sat, 25 Sep 1993 06:11:44 GMT In article <1993Sep24.023318.23188@super.org> becker@super.org (Donald J. Becker) writes: >OK, there seems to be a number of 3c501 fans out there, and a few of them >insist on telling my why it isn't so bad. They are wrong [...] I'm speaking only for myself here, of course, but I believe 3Com advises against installing a 3C501 in a new system, mostly for the same reasons Donald has discussed. You probably won't be happy with the 3C501 in your Linux box. The data sheet is marked "(obsolete)" on 3Com's Developers' Order Form, and the board is not part of 3Com's program for sending free Technical Reference Manuals to people who need them. The decade-old things are nearly indestructible, but that's about all they've got going for them any more. I hope you find our *modern* boards equally sturdy, and I want to hear about it if you don't. The Network Adapter Division design team sincerely appreciates the *excellent* feedback we've got from the Linux community. Cameron home: cls@truffula.sj.ca.us <-- my Linux box work: camerons@NAD.3Com.com <-- please send 3C5[07]9-related mail here. ------------------------------ From: andreas@knobel.knirsch.de (Andreas Klemm) Subject: Re: /config Date: 25 Sep 1993 13:49:47 -0000 dthumim@athena.mit.edu (Daniel J Thumim) writes: >I was just following the discussion on the /config proposal, and it seems >that everyone has a different idea of what's being talked about. Hi, here my ideas of what's to to. Short: keep it as it is. >Taking into account the advantages and criticisms that people mentioned, >here is a suggestion for how /config could be used. I hope that everyone >will like it (yeah, right 8-) but if not maybe it will at least steer the >discussion in a more useful direction. >Here is what would need to be done: >- Define a new "user-friendly" configuration file format, as was > described in the original post. For example, /config/passwd could > allow comments in the standard way, and allow individual fields to > be specified for each entry, e.g. username=root, uid=0, gid=0, etc. > These new-style configuration files could be kept in /config or any > other desirable location. >- For each set of configuration files, write two utilities to translate > back and forth between new-style configuration files and actual files > used by user programs (e.g. translate /config/passwd to /etc/passwd > and back). Alternatively, one utility could be written that reads a > "format description file" of some sort and performs the conversion. A waste of time and i-nodes. Today certainly many people have got books and read articles about Unix, so everyone has a good idea, where the system files are and what has to be inside ... What about the people who install Linux for educational reasons ? In work they have to deal with real Unix Systems and the files in /config don't help much in other Unix environments. So don't confuse people with unnecessary additionally files and formats .... It's better you learn one stanmdard. It helps you more in later work ... I think the few system files one have to know (/etc/passwd /etc/shadow /etc/group) are not more difficult than MS-DOS config.sys trickeries if you have to handle lots of cards and drivers. >Thus, in effect, the /config directory becomes a source tree for config- >uration files, and the translation utilities are used to "compile" the >useable config programs from the sources. >Let me just invent a bit of terminology to make this easier. I'll call >the new-style config files "sources" and the actual config files used by >user programs as "raw config files". >This system will work for everyone, as far as I can tell: >- Those who edit the raw config files and like it will continue to do > so. They don't need /config or the translation utilities. >- Those who DON'T like to edit raw config files but already have > systems set up which rely on them will be able to get the translation > utilities, "de-compile" their existing config files into sources, > and future changes can be made by editing the new-style config files > and compiling them (a Makefile could be used to install them in the > proper places). >- New users can be given well commented sources, and all the utilities. > Those who prefer to use raw config files will be able to delete all > of this and edit them directly, while those who like the source format > will be able to edit the sources and run "make" to effect the changes. - in my eyes - better proposals: 1) keep it simple ... keep things as they are. It worked over twenty years. 2) Do more useful stuff.... There are many online manual pages missing in Linux. Or there are manual pages, that looks for me as not fitting the program releases in Linux.... That's the real stuff new users need ! Up to date man pages ... Not new config files ! 3) Write a working sysadm shell, that allows people to easily add or delete users ... or other wanted things. But please don't fill the filesystem with uneccessary things. In another thread some weeks ago we discussed filesystem standards for Linux. Soon we get SVR4 binary compatibility. Let's work on those things to make Linux look more like the new SVR4 standard. Really more important in my eyes. Things like that are in my eyes as meaningless and disturbing as the again and again starting discussions in german newsgroups about German Umlaute and those who think it's more comfortable to read Gl"uckwunsch than Glueckwunsch. ^^ ^^ -- Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH andreas@knobel.knirsch.de ___/\/\/ andreas@sunny.wup.de (Unix Support) ------------------------------ From: andreas@knobel.knirsch.de (Andreas Klemm) Subject: Re: To all device driver writers; boot-time Date: 25 Sep 1993 13:59:04 -0000 bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >In article <27ussj$nnn@nms.telepost.no> tor@spacetec.no writes: >>In article lc8@kruuna.Helsinki.FI, wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) writes: >>>grif@ucrengr.ucr.edu (Michael Griffith) writes: >>>> These type of issues have been already taken care of by the syslog >>>> mechanism. >>> >>>How well does syslog work during booting? >> >>Seems to work very well, here's an excerpt from my /usr/adm/messages : >Um, I think his point is that syslog display levels don't help you hide >informational messages you'd rather not see during the time when syslogd isn't >running yet (and, often, init isn't running yet either!). But although syslogk is started in /etc/rc.local it shows the initial startup messages beginning with console and serial stuff ... Console: colour EGA+ 80x25, 8 virtual consoles Serial driver version 3.96 with no serial options enabled tty00 at 0x03f8 (irq = 4) is a 16450 Isn't that good enough ? Seems to be, that the kernel is buffering or holding these messages as if waiting for a tool like syslogk ;-) BTW: how does it realy work ? syslogk logs messages that are already displayed when the utility itself wasn't started ... -- Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH andreas@knobel.knirsch.de ___/\/\/ andreas@sunny.wup.de (Unix Support) ------------------------------ From: wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) Subject: Re: To all device driver writers; boot-time Date: 25 Sep 1993 17:19:02 +0300 andreas@knobel.knirsch.de (Andreas Klemm) writes: > But although syslogk is started in /etc/rc.local it shows the initial > startup messages beginning with console and serial stuff ... It does, indeed. As you guessed, the kernel is buffering the messages so that they can be logged to a file. > Isn't that good enough ? No, because they're still printed to the console. The point, the only and single and simple and easy to understand (or so I thought; I obviously need to work on my writing skills) point, is that I would prefer if there were fewer noise messages printed during bootup, preferably so that only messages that require my attention are printed. -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) It doesn't matter who you are, it's what you do that takes you far. --Madonna ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: To all device driver writers; boot-time Date: Sat, 25 Sep 1993 15:46:31 GMT In article <281ir8$hkh@knobel.knirsch.de> andreas@knobel.knirsch.de (Andreas Klemm) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>Um, I think his point is that syslog display levels don't help you hide >>informational messages you'd rather not see during the time when syslogd isn't >>running yet (and, often, init isn't running yet either!). > >But although syslogk is started in /etc/rc.local it shows the initial >startup messages beginning with console and serial stuff ... I know it does. But I, personally, would prefer not to see some of the informational verbosity at *boot* time. Afterward is a bit too late; it's already scribbled noise all over the screen :-) This is not merely a frivolous request: the later informative messages can cause previous possibly important information to scroll off the screen. I had this problem back when I was trying to diagnose a problem which turned out to be a mis- addressed SCSI drive --- I had to boot in 50-line mode and it was only just *barely* enough to retain the SCSI probe information. If I'd needed to see anything from before that point I'd have been in trouble. (Yes, I can get it after the boot... if the message at the start of the boot isn't what causes a panic late in, or after, the boot. Makes it hard to diagnose some problems....) >BTW: how does it realy work ? syslogk logs messages that are >already displayed when the utility itself wasn't started ... Console messages get written into a 4K ring buffer as well as to the screen. The first reads of the log after an open return the entire contents of the buffer; subsequent reads only return new messages. See the definitions of sys_syslog() and printk(). (The code for /proc/kmsg just invokes sys_syslog() to do the work, at least in 0.99pl9.) This, BTW, is what makes keeping message levels difficult: there would have to be "magic cookies" in the log to indicate the start of a new message and its log level. And, as has already been noted, there's no way at present to indicate the start of a new message, so potentially *all* uses of printk() would have to be examined and changed to implement message boundaries and levels. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: todorov@cui.unige.ch (TODOROV Krassimir) Subject: PC for linux Date: Sat, 25 Sep 1993 16:15:59 GMT Hello, Linux Users. I dont know if it is easy to answer to my questions, may be it is in the FAQ-s. What PC must I have to run linux on it? Or maybe is-it easier to enumerate what the PC MUST NOT HAVE? Ex.: - less than ??? MBytes RAM, and - a computer ???? bus, and - a ???? hard disk model ?????, and ..... Thank you for your answers! -- Krassimir ------------------------------------------------------------------- Krassimir TODOROV | Tel: + 41 (22) 705 7635 Centre Universitaire d'Informatique | Uni Dufour | Fax: 320 2927 24 rue du General-Dufour | 705 7659 CH-1211 Geneva 4 | SWITZERLAND | E-mail:todorov@cui.unige.ch ------------------------------------------------------------------- ------------------------------ From: de727@cleveland.Freenet.Edu (Tim W. Johnson) Subject: g++: running out of virtual memory! Date: 25 Sep 1993 16:54:47 GMT I am trying to compile a simple c++ program with g++ (gnu gcc 2.4.5) Whenever I try to compile the program I get the following message: int main(int, char **) not enough virtual memory I am running the latest version of slackware on my 386-33 wth 12MB of ram and a 10MB swap partition. Surely this is enough memory to compile with. I would appreciate any ahelp. Send responses to ( johnson@gwyne.nlu.edu) PS: forgive the typos I havent figured out the bakspace key yet. -- Tim Johnson Internet Address: johnson@gwyne.nlu.edu - Real Programmers Do It With One Register. ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: Intelligent Serial I/O: DIY Date: 25 Sep 1993 13:32:11 +0200 In comp.os.linux.development, article , clay@haapi.mn.org (Clayton Haapala) writes: > > I would agree ISA is fine, but I would like to add the requirement that it > understand IRQs > 9, so it doesn't collide with all the other cruft we already > have in the computer. This does require the 16-bit extender in order to reach > the IRQ pins, but I don't believe it requires everything to be implemented as > a 16-bit data path. Be nice, though, and maybe not very much greater in cost. Hmm, and then there's the 8/16 bit problem... which some 8-bit cards avoid by not using A0. Time to redo the Linux tty handling so that such a card, with driver, fits into the kernel in the first place... -- Do not be angry with me if I tell you the truth. -- Socrates Tell the Truth and run. -- Yugoslav proverb -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ ** 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 ******************************