From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 24 Sep 93 22:13:18 EDT Subject: Linux-Development Digest #126 Linux-Development Digest #126, Volume #1 Fri, 24 Sep 93 22:13:18 EDT Contents: WANTED!!! PAS-16 SCSI OR EQUIVALENT DRIVER (Le Mauvais Sophiste) Re: GPL and Linux device drivers (Tim Smith) Re: To all device driver writers; boot-time messages. (Risto Kankkunen) Re: To all device driver writers; boot-time (Brandon S. Allbery) /config (Russell Nelson) To all device driver writers; boot-time (Russell Nelson) Re: CORRECTED NEW multiple sector transfer for IDE drives (Brian Stempien) Re: Intelligent Serial I/O: DIY (Clayton Haapala) Re: Make >1.44M floppies standard in kernel? (Rafal Maszkowski) Re: To all device driver writers; boot-time messages. (Lars Wirzenius) Re: QIC-80 Tape driver status (Doug Mayfield) Introcuing Chinese tty for Linux operating system (STUD001@TWNMOE10.Edu.TW) ---------------------------------------------------------------------------- From: myddryn@netcom.com (Le Mauvais Sophiste) Subject: WANTED!!! PAS-16 SCSI OR EQUIVALENT DRIVER Date: Fri, 24 Sep 1993 20:13:55 GMT There has been a whole lot of demand for a scsi driver for the Pro audio spectrum card. I have heard passing mention of a generic driver that will work with this card. WHERE IS IT? WHO is working on it? If you need help, we will provide. Just tell us SOMETHING. -- "Maturity is a slow death." "If Jesus died for our sins, would it not be disrespectful to live a life without sin, thus rendering his sacrifice in vain?" - Jules Feiffer Adam Sussman - myddryn@netcom.COM - asussman@ucsd.edu Chairman, UCSD chapter of the ACM ------------------------------ From: tzs@hardy.u.washington.edu (Tim Smith) Crossposted-To: gnu.misc.discuss,misc.legal.computing Subject: Re: GPL and Linux device drivers Date: 24 Sep 1993 21:38:52 GMT [Added: misc.legal.computing] 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. Name a single lawyer who agrees with that. If I write code that calls someone else's functions, and distribute it, but do not distribute the code to those functions, GPL does not apply to me because I am not using any code that is under GPL. I don't care what agreement has been made between FSF and the people who use my code -- two parties cannot make a contractual agreement to bind a third a party. The only risk I would face would be a copyright infringement suit. So, let's look at copyright infringement. Here's what Chisum & Jacobs say in _Understanding Intellectual Property Law_: To infringe an exclusive right of copyright, and accused work must (1) derive from the copyrighted work, directly or indirectly, and (2) be substantially similar en expression to the copyrighted work. ... The second element--substantial similarity in expression-- depends on average lay observer or listener response. I think you are going to have a seriously difficult time convincing an average lay observer that code that *calls* a function from a library or kernel every dozen lines or so is substantially similar to the library or kernel implementation of those functions. The subterfuge argument might work against someone who takes some GPL'ed software, splits it up, and distributes the two parts, and tries to claim that they don't have to GPL their part, but if I were distributing a proprietary driver, I would distribute *only* the driver. I would not distribute anything else at all. This would save me from the subterfuge argument, because if the FSF lawyer tried to introduce GPL at the trial, my lawyer would object on the grounds of irrelevance. My lawyer would win this objection, unless FSF's lawyer could show a reason for GPL to apply. For him lawyer to show that, he has to show that I've done something that I can't do without some sort of license -- in short, he has to show that I've done something that violates FSF copyright. Thus, he has to get past that substantial similarity hurdle *before* we get to the issue of GPL and whether I've done some sort of subterfuge. There is an approach that the owners of the GPL'ed code might try. People are able to use copyright to prevent people using characters from their books or movies without authorization, and you could try to argue that the names and calling sequences of functions in a library or kernel are like characters in a book, but this seems kind of farfetched. There has to be a certain amount of creativity in there, and I don't think a court is going to be very impressed with something of the form "void foo(int bar, char * spam)" as a form of creative expression! --Tim Smith ps: how interested are people in these issues? One of the requirements at this law school is that students spend a term or two researching and writing a serious paper on some legal topic before graduation. I've been looking for something to do, and although I've been leaning toward a look at why grace periods were removed from recording acts (yes, when computer nerds go to law school, they become legal nerds, who become attracted to arcane and obscure things in law...), it could be interesting to instead look into some of the legal issues involving GPL'ed software. ------------------------------ From: kankkune@klaava.Helsinki.FI (Risto Kankkunen) Subject: Re: To all device driver writers; boot-time messages. Date: 25 Sep 1993 00:37:21 +0300 >>I quite agree with this suggestion, although I'd use slithgly longer >>prefixes ("Info:", "Warning:", and "ERROR:", perhaps). >These type of issues have been already taken care of by the syslog >mechanism. Perhaps we could add a severity field to printk so that >the interface between the kernel and syslogd can be more useful. I once suggested to Linus that we'd use printk(KERN_INFO "Hi there!\n"), where KERN_INFO is #define KERN_INFO "<6>". printk would log that to syslogd and could change the <#> part to a suitable English prefix. He didn't like it. I suggested this instead of having a separate argument to printk so that the messages could be converted to the new scheme gradually: any messages without the <#> would get a default severity level added by printk. Multiple printk's that form a single message are a problem with this method, though. Maybe it's better to have printk(fmt, ...) and printks(severity, fmt, ...). >>What about making all merely informational bootup messages optional? >>That would make the bootup screen less cluttered and it would be >>easier to spot problems. I also suggested having an ioctl that, instead of a single on/off switch like currently, would set the level above which messages would be printed directly to the screen in addition to be logged. This is important for you to see the last messages before the machine panics out and syslogd has already died. The default level for this switch could be set so that the bootup screen wouldn't be too messy. When syslogd is started, it can change the level so that only the panic messages end up to the console. -- It's that time of the year again ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: To all device driver writers; boot-time Date: Fri, 24 Sep 1993 21:20:31 GMT 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!). ++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: nelson@crynwr.com (Russell Nelson) Subject: /config Date: Fri, 24 Sep 93 18:48:51 GMT In article <27tkpq$i0r@senator-bedfellow.MIT.EDU> dthumim@athena.mit.edu writes: [ proposal deleted -- news://27tkpq$i0r@senator-bedfellow.MIT.EDU ] How's that sound? Well, it's basically the same as what I proposed, 'tho arguably better-explained. The problem is that there are three kinds of files that you need to maintain: o databases, e.g. /etc/passwd, /etc/group. o free-format parameterized files, e.g. /etc/bootptab, /etc/termcap. o command-language files, e.g. /etc/startup.nos, /etc/rc*. The latter are the really difficult problem. They're hard to maintain with a form-oriented program, so you're pretty much limited to editing them with a text editor. Yes, we need a system administration tool. It has to be pretty and easy to use. And, it needs to be extensible, so that new programs may be added without modifying the program. I *think* the program should be based on TCL. One problem with that is that TCL doesn't have a book on programming in TCL. Yes, there are the drafts, but they don't describe the *current* TCL. And yes, I'm willing to work on it, but again, there's no point in working in a vacuum. -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. ------------------------------ From: nelson@crynwr.com (Russell Nelson) Subject: To all device driver writers; boot-time Date: Fri, 24 Sep 93 18:53:03 GMT 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 : vmlinux: Console: colour EGA+ 80x25, 8 virtual consoles vmlinux: Serial driver version 3.96 with no serial options enabled vmlinux: tty00 at 0x03f8 (irq = 4) is a 16450 vmlinux: tty01 at 0x02f8 (irq = 3) is a 16450 vmlinux: lp_init: lp1 exists (0), using polling driver vmlinux: Configuring Adaptec at IO:330, IRQ 11, DMA priority 5 vmlinux: scsi0 : Adaptec 1542. vmlinux: Adaptec 1542scsi : 1 hosts. vmlinux: Vendor: FUJITSU Model: M2263S-512 Rev: 01A5 vmlinux: Type: Direct-Access ANSI SCSI revision: 02 vmlinux: Detected scsi disk sd0 at scsi0, id 0, lun 0 vmlinux: scsi : detected 1 SCSI disk 0 tapes 0 CD-ROM drives total. vmlinux: Memory: 15140k/16384k available (540k kernel code, 384k reserved, 320k data) vmlinux: Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M vmlinux: 3c503 probe at 0x300: 02 60 8C A7 AB 8E vmlinux: eth0: 3C503 with shared memory at 0xcc000-0xcdfff, vmlinux: dl0: D-Link pocket adapter: probe failed at 0x378. vmlinux: Calibrating delay loop.. ok - 16.77 BogoMips (tm) Pretend I'm a luser (you don't have to work very hard at it). Which of these do I need to worry about? Is it a problem that the serial options aren't enabled? The D-Link pocket adapter probe failed. Is that going to hurt anything else? -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. ------------------------------ From: stempien@cs.wmich.edu (Brian Stempien) Subject: Re: CORRECTED NEW multiple sector transfer for IDE drives Date: Fri, 24 Sep 1993 22:49:25 GMT Has anyone done tests between the patch by Mark Lord and this one?? I like the first one's test output, does this one have the IDE drive output?? What about the speedups, reliability, and dropped interupts of both. -- Brian Stempien Western Michigan University Email: stempien@cs.wmich.edu Voice: (616)-387-5848 ------------------------------ From: clay@haapi.mn.org (Clayton Haapala) Subject: Re: Intelligent Serial I/O: DIY Date: Fri, 24 Sep 1993 02:26:16 GMT In article jonb@specialix.com (Jon Brawn) writes: >The sort of technology I had in mind is 16450/16550 UARTs, some RAM and an >Intel 80x86 processor (easy availability of development tools), possibly with >some LEDs for debugging purposes, on an ISA host card (yep, ISA has >sufficient bandwidth), arranged to give a dual-ported interface allowing >both the host '386/486 and the I/O processor access to the RAM and the UARTs. > 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. -- Clay Haapala "Well, there was the process of sitting around clay@haapi.mn.org and wishing I had more computer stuff." -- Dilbert ------------------------------ From: rzm@oden.oso.chalmers.se (Rafal Maszkowski) Subject: Re: Make >1.44M floppies standard in kernel? Date: Fri, 24 Sep 1993 20:04:02 GMT Brett Person (person@plains.NoDak.edu) wrote: : In article <27a56a$h9a@hermes.acs.ryerson.ca> ylam@acs.ryerson.ca (York Lam - ACPS/F93) writes: : > Are there any plans in making the floppy patches, for extra : >tracked/sectored disks, a standard part of the kernel? It never patched : Probably not. > 1.44 floppies are unreliable enough that they probably : shouldn't be used at all. Really? I agree if you mean additional tracks but what about using one long sector on each track instead of lots of smaller ones? R. -- Rafal Maszkowski rzm@oso.chalmers.se rzm@mat.torun.edu.pl <-finger for public snail: Omgangen 464-82, 412-80 Goteborg, Sweden; tel: +46-31-7780831 key Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - S.J.Lec ------------------------------ From: wirzeniu@cs.Helsinki.FI (Lars Wirzenius) Subject: Re: To all device driver writers; boot-time messages. Date: 24 Sep 1993 23:43:49 GMT spj@ukelele.gcr.com (Guru Aleph_Null) writes: > Since most Linux boxes I assume are running on color displays, throw some > color into there [- - -] I have a tendency to feel annoyed by displays that look like Xmas colors. I could agree that using a different color for errors might be good, but having the informational stuff be in a different color would be very much distracting. > How about teeing them into a file into /usr/log/boothistNN that say, keeps > ten copies of the last reboot console-messages? This can already be done with the procfs (the first time you read /proc/kmsg you get the bootup messages). -- 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 ------------------------------ Crossposted-To: comp.os.linux.help From: mayfield@phobos.cs.ucdavis.edu (Doug Mayfield) Subject: Re: QIC-80 Tape driver status Date: Sat, 25 Sep 1993 00:58:47 GMT Christopher Lau (clau@acs.ucalgary.ca) wrote: : Anyways, back to the topic at hand, I've discovered the cause of most : of my problems with ftape- I buy my tapes preformatted, but the tape : manufacturer in its infinite wisdom, didn't write a bad-block map to : the tape.. That may be the difference here. I have now been using the ftape package with med-light usage and I buy un-formatted tapes, format them with a DOS box with software that seems to put bad-block maps on the tape. Then when I use them with Linux I have yet to find any problems. I'm not saying that it is perfect, but it seems fine to ME. :-) DM. : c4 : -- ------------------------------ From: STUD001@TWNMOE10.Edu.TW Crossposted-To: tw.announce,tw.comp.unix Subject: Introcuing Chinese tty for Linux operating system Date: Sat, 25 Sep 93 10:02:26 EST I am pleased to make this announcement for a friend, Wu-Chung Wang ( twchiu2@phys.ntu.edu.tw) who creates this great work. "chdrv03.tar.gz" is a Chinese tty package (so called a Chinese system from DOS's view) for Linux. If you like a Chinese style console and wouldn't like to bother to run X plus Chinese xterm, this package is for you. TO INSTALL: step0: download me from sunsite or NCTUCCCA (See below) step1: cd /usr/src; zcat chdrv03.tar.gz|tar xvf - step2: cd /usr/src/chinese; make install (This assume chdrv03.tar.gz file is in /usr/src) TO RUN: This package is in sort of client/server mode. You can place "ttyserver" in your /etc/rc.local if you like. Or on the command line, type "ttyserver". This program will run as a daemon. You then can really enter the Chinese graphic mode by typing "ccc" from any of the virtual consoles. Note only this console turns into Chinese mode. Here "ccc" program acts as a client program. LAST NOTE: As the author mentioned, this package is still in the early ALPHA. The author likes to see any comments from you. ========================================================================== Begin2 Title = Chinese system for Linux (ie Chinese tty) Version = 0.3pl1 ALPHA Desc1 = A Chinese tty program to turn ascii console to 8-bit Desc2 = Chinese one for your Linux host. So far, this package Desc3 = a *NOT* compatible to vt100/vt102 yet. Also printing Desc4 = function isn't implemented. (This means you can't use Desc5 = this package to send Chinese docs to printer). Author = Yu-Chung Wang AuthorEmail = twchiu2@phys.ntu.edu.tw Maintainer = Yu-Chung Wang MaintEmail = twchiu2@phys.ntu.edu.tw Site1 = NCTUCCCA.edu.tw Path1 = /Chinese/YuanInfo/Linux File1 = chdrv03.tar.gz FileSize1 = 401,516 bytes (including necessary Chinese fonts) Site2 = sunsite.unc.edu Path2 = /pub/Linux/Incoming File2 = chdrv03.tar.gz FileSize2 = 401,516 bytes (including necessary Chinese fonts) Required1 = Required2 = Required3 = Required4 = CopyPolicy1 = GNU GPL CopyPolicy2 = Keywords = Chinese for Linux, Chinese tty, Chinese system Comment1 = extremely ALPHA :-) Comment2 = This package makes NO change to the Linux kernel. Comment3 = Comment4 = RelFiles1 = RelFiles2 = RelFiles3 = Entered = 21SEP93 EnteredBy = Tzeng Ruey Yuan CheckedEmail = stud001@twnmoe10.edu.tw End ------------------------------ ** 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 ******************************