From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 24 Sep 93 07:13:08 EDT Subject: Linux-Development Digest #122 Linux-Development Digest #122, Volume #1 Fri, 24 Sep 93 07:13:08 EDT Contents: Need help for a new pc-unix user. (Tri Tran) Re: port of Linux to the upcoming PowerPC? Free manual available (Charles T Wilson -- Personal Account) /config (Daniel J Thumim) Re: Linux Slowly Dying Off? (Jay Beavers) Format of assembly code under Linux... (Christopher Lindsey) Re: To all device driver writers; boot-time messages. (Donald J. Becker) Re: linux & 3c501 ? experiences ? (Donald J. Becker) Re: NetWare protocol stacks? (Derek Fawcus) Re: AHA1542c Compatible with Linux??? (Stefan Strecker) updated rlogin/rlogind/telnetd for 0.99pl13 (Charles Hedrick) Re: No smart serial boards??? (Alan Cox) GPL and Linux device drivers (Alan Cox) Re: To all device driver writers; boot-time messages. (Lars Wirzenius) ---------------------------------------------------------------------------- Crossposted-To: gnu.gnusenet.test,comp.unix.sysv386,comp.unix.sysv.r3,comp.unix.pc-clone.32bit,biz.sco.general From: tran@f18sun5.nwc.navy.mil (Tri Tran) Subject: Need help for a new pc-unix user. Date: Thu, 23 Sep 1993 23:53:51 GMT Hi all, Could someone please direct me to a FAQ on how to install/run Unix on my pc-clones. I'm new to this sort of thing and would like as much help as I can get. My main concern is the hardware compatibility for my system; available drivers for my hardware. I've seen linux mention alot in posting but don't know anything about it. I'm assuming that it is a popular version of unix for pc? What about Unixware or SCO? Any help at all is greatly appreciated. Please response by email. Thanks. Tri Tran Hardware configuration: 486DX-50 MB with ISA & VL-bus slots 16 Megs of RAM UMC chip set Ultra14F SCSI controller Diamond Stealth Pro VLB graphic card Maxtor SCSI hard drives Mitsumi cd-rom drive ------------------------------ From: ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) Crossposted-To: comp.os.linux.misc Subject: Re: port of Linux to the upcoming PowerPC? Free manual available Date: 24 Sep 1993 01:21:08 GMT In article <1993Sep23.161218.8408@ncsu.edu> nsyslaw@straylight.acs.ncsu.edu (lou Williams) writes: >Hansruedi Heeb (heeb@watson.ibm.com) wrote: >: In article SHOVERST@atc.sp.paramax.com (Shane Hoversten) writes: >: >In article heeb@watson.ibm.com (Hansruedi Heeb) writes: > >I believe there is a *free* manual, but it's from Motorola, and it only covers >the MPC-601 processor, not the entire PowerPC system. You're right...a coworker of mine ordered one from Motorola. > >It gives tech details, instruction sets, timing diagrams, pinouts, etc for >(hopefully?) those wishing to (dirty word, ahead) clone the MPC-601? At the >very least it should give _more_ than enough detail for programming the low >levels of the processor. Don't know about pinouts, but the rest is there. This is a list of what's available from Motorola's Literature Distribution Center (LDC): 1. PowerPC Brochure, (BR1135/D).........................................Free 2. PowerPC 601 RISC Microprocessor, Technical Summary, (MPC601/D).......Free 3. PowerPC 601 Hardware Specification, (MPC601EC/D).....................Free 4. PowerPC Software Overview (compilers, assemblers, simulators, loaders & debuggers), (SDP/D)........................................Free 5. PowerPC C Compilation System, Product Review, (CCOMPSTM/D)...........Free 6. PowerPC Fortran Compilation System, Product Review, (FTRANCOMPSTM/D).Free 7. PowerPC Architectural Simulator, Product Review, (PPCARCH32/D).......Free 8. PowerPC 601 Programmer's Reference Guide, (MPC601PRG/D)..............Free 9. PowerPC 601, User's Manual, (MPC601UM/AD)............................$6.50 10. PowerPC Development Tools Catalog, (MPCTOOLBK/D).....................$4.50 You can call toll free, 1-800-441-2447 to order. You can also write this address: Motorola Communications Mgr. OE42 Motorola Literature Distribution Center P.O. Box 20912 Phoenix, AZ, 85036-9938 -- /-----------------------------------------------------------------------\ | Tom Wilson | "I can't complain, but sometimes | | ctwilson@rock.concert.net | I still do." | | | -Joe Walsh | ------------------------------ From: dthumim@athena.mit.edu (Daniel J Thumim) Subject: /config Date: 24 Sep 1993 02:07:54 GMT 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. 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. 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. How's that sound? -- |)an Thumim dthumim@mit.edu ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.misc From: sxjcb@alaska.edu (Jay Beavers) Subject: Re: Linux Slowly Dying Off? Date: Fri, 24 Sep 1993 02:56:42 GMT In article <27t2au$3v1@samba.oit.unc.edu> mdw@sunSITE.unc.edu (Matt Welsh) writes: >It's not dying off... not at all. It's simply stabilizing. Things aren't >changing as rapidly, which is a sign of maturity. So, like, CP/M is really really mature now? ;-) ------------------------------ From: cl27111@uxa.cso.uiuc.edu (Christopher Lindsey) Subject: Format of assembly code under Linux... Date: 24 Sep 1993 03:20:30 GMT Does anyone know what the formatting requirements are for using inline assembler under C or just as an assembler program under Linux? I'm talking about directives, things like requiring a % before registers, etc... Thanks, Chris P.S. This is to write some high-speed graphics routines... ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: To all device driver writers; boot-time messages. Date: Thu, 23 Sep 1993 04:20:28 GMT In article , David Wright wrote: >>>>>> "DJB" == Donald J Becker writes: > DJB> any code. I think Linux device drivers should be as clear as possible while > DJB> remaining concise. I'm talking about _loadable_ device drivers, where an > DJB> object code module is distributed seperately from the kernel, and can be > DJB> loaded into the kernel at the user-level after the kernel has booted. If > DJB> Linux 1.00 has that as a standard feature we will likely see a considerable > DJB> number of proprietary device drivers. > > You don't need loadable device drivers for this to happen. All you have >to do is ship the *.o files for people to be able to create proprietary >device drivers. This is how it is done under SCO Unix, which does not do >dynamic device loading. This hasn't happened to Linux yet, so I wouldn't worry >about dynamic loading making the situation any worse. I think you are mistaking the Linux kernel GPL for the GLPL that the libraries are covered by. With the GLPL a link kit distribution with proprietary object files is fine, but the GPL prohibits such a distribution under the "derivative work" clause. Even if you excised every copyrighted inlined function from your object code, you code is still designed to work intimately with and inseparably from the Linux kernel. As such, most courts would consider your link kit distribution as a subterfuge, designed only to avoid the clearly stated terms of the GPL. A dynamically loaded device driver is a step removed from a linked-in device driver. Some courts might consider it as just another program run under Linux, which the Linux GPL clearly does not cover. This is more likely if the dynamically loaded device driver method is described as a standard interface, rather than as a carefully documented method of linking additional code to the kernel. (I think such a Linux-specific interface would fall under the Linux GPL, but it is a dangerous grey area.) -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ Crossposted-To: comp.os.linux.misc From: becker@super.org (Donald J. Becker) Subject: Re: linux & 3c501 ? experiences ? Date: Fri, 24 Sep 1993 02:33:18 GMT 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, just because it works fine on your 8088 doesn't mean it's OK hardware. I know what I'm talking about: "seen it, been there, done it". But in a fit of madness I wasted a whole day updating my 3c501 driver and then trying to track down a few more of the 3c501 glitches. It now works well enough to NFS mount filesystems, but the receiver still occasionally hangs. I'm mostly certain that this is a hardware bug. When it hangs, the next set of outgoing packets will reset the board, but that's only useful if you have something occasionally generating outgoing packets. I'll let this out for "pre-alpha" testing, under the following conditions: This is unsupported code. I know my usual copyright says all the code is unsupported, but this is _really_ unsupported. I DON'T want to see bug reports, and I'll accept bug fixes only if I'm in a good mood that day. I don't want to see a fest of "Linux ethercards for sale" postings. A bunch of people have picked dozens of "dumpster special" 3c501s, and they hope to sell them at rip-off prices. A 3c501 is barely worth the shipping cost, and if I see people trying to sell them here by claiming "supported by Linux" I _will_ flame them. They are _not_ supported by Linux. I don't want to flamed later for putting out bad software. I don't know all all of the 3c501 bugs, and I know this driver only handles a few that I've been able to figure out. It has taken a long, intense effort just to get the driver working this well. That said, ftp.super.org:/pub/linux/pre-alpha/3c501. Jumper your card to 0x280, using pl13, add the 3c501.o to the OBJS line in net/inet/Makefile, uncomment the 3c501 line in linux/config.in, 'make config; make' as usual. AutoIRQ works, DMA isn't used, the autoprobe only looks at 0x280, the debug level is set with the third boot-time argument. You'll probably want to change the default EL_DEBUG to '2'. [[ I'm probably going to regret this. I'm going on a much-needed vacation next week, so don't phone in your thanks, mail with cash and goodies will do just fine. ]] -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ From: df@eyrie.demon.co.uk (Derek Fawcus) Subject: Re: NetWare protocol stacks? Date: Sun, 12 Sep 1993 23:29:00 +0000 In article <26vlee$evu@samba.oit.unc.edu> jem@sunSITE.unc.edu (Jonathan Magid) writes: >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 $$. 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? DF -- Derek Fawcus (G7FVS) df@eyrie.demon.co.uk ------------------------------ From: strecker@goofy.zdv.Uni-Mainz.DE (Stefan Strecker) Subject: Re: AHA1542c Compatible with Linux??? Date: 24 Sep 1993 08:48:55 GMT > I've looked on the hardware compat list and it only lists the 1542 and 1542B. > Does anybody know if the C is compatible? I already went through purchasing I'm running Linux pl12 from Slackware 1.0.2 with a AHA1542c and 4 primary partitions on my SCSI drive (one is msdos). My root device is a IDE drive with a small 16MB root partition. I had to disable the AHA BIOS option 'BIOS System controlling bootup INT 19h' or something to make Linux recognize the SCSI drive and with this setup I also can reach my msdos partition easily as drive D: under msdos. I don't have any experience with tape drives or CD-ROMs but in addition to the above I disabled the AHA floppy disk controller as someone stated it might hurt some tape drives ?! Steve ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: updated rlogin/rlogind/telnetd for 0.99pl13 Date: 24 Sep 93 05:40:36 GMT A few days ago I mentioned that I had updated versions of rlogin, rlogind, and telnetd that should be used with 0.99pl13 (because of changes in the pty packet mode). Someone pointed out that my rlogin did not handle CR transparently. I've fixed it. Thus you might want to take a new copy from athos.rutgers.edu:/pub/linux/telnet-rlogin.tar.z I'm not uploading this to the archive sites. There are already so many different versions of various network utilities that I'd rather see a net2 maintainer put these into the standard distribution, rather than have me add to the clutter. I'd very much appreciate it if anyone adding this to a new version of the net2 utilities would explicitly mention that you're including fixes for the pl13 packet mode, just so I know you've got it. (It should be safe to use this code on pl12. Since the definition of DOSTOP and NOSTOP has been reversed, there ought to be a compatibility problem. But due to other bugs, DOSTOP and NOSTOP weren't actually generated under pl12 and earlier.) To review: telnetd and rlogind are simply recompiled with the fixed termios.h (the definitions of DOSTOP and NOSTOP had been reversed). [To the net2 maintainer: it would be been to use your telnetd source, not mine. Just recompile.] rlogin is a major revision, using termios tty handling rather than the bsd sgtty emulation. (The sgtty emulation didn't handle ixon correctly.) This code will work with both normal and netBSD TCP/IP. ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: No smart serial boards??? Date: Fri, 24 Sep 1993 09:26:55 GMT I talked to Accent a long time ago about multiport boards. I got a 4 dumb port board in the end. It does the job and since my ports are mostly low speed (1x38400 1x1200(mouse) 2x1200(tnc) 1x9600(terminal) I have no real problems. Accent however do the Accent-Async 8i, which on talking to their man about drivers includes a full set of programming specs for the on board stuff (80186) and a load of other stuff. Not every vendor is a facist code hoarder. In fact I've been very pleased with my accent card and the level of service provided. Alan ------------------------------ Crossposted-To: gnu.misc.discuss From: iiitac@swan.pyr (Alan Cox) Subject: GPL and Linux device drivers Date: Fri, 24 Sep 1993 09:34:44 GMT In article <1993Sep23.042028.29146@super.org> becker@super.org (Donald J. Becker) writes: >I think you are mistaking the Linux kernel GPL for the GLPL that the libraries >are covered by. With the GLPL a link kit distribution with proprietary object >files is fine, but the GPL prohibits such a distribution under the "derivative >work" clause. Even if you excised every copyrighted inlined function from your >object code, you code is still designed to work intimately with and >inseparably from the Linux kernel. As such, most courts would consider your >link kit distribution as a subterfuge, designed only to avoid the clearly >stated terms of the GPL. This would suprise me a great deal. I fail to see why any device driver in binary form supplied for Linux would have anything to do with the GPL. If I write a program for MSDOS I'm not subject to microsofts rules either - and there is no difference. The Linux device driver api is defined precisely, the DOS int21 api is defined precisely. Shipping a version of Linux that _required_ this driver is a different matter altogether. So long as it is a device you can use eg here is the linkable module for blah-de-blah netware client requestor for example, but don't need it then no problems. Alan iiitac@pyr.swan.ac.uk ------------------------------ From: wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) Subject: Re: To all device driver writers; boot-time messages. Date: 24 Sep 1993 13:39:36 +0300 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? -- 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 ------------------------------ ** 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 ******************************