From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 11 Nov 93 09:13:13 EST Subject: Linux-Development Digest #219 Linux-Development Digest #219, Volume #1 Thu, 11 Nov 93 09:13:13 EST Contents: Kernel accounting patches w/ 13 ALPHA (Louis P. Kruger) Re: 16550A handling in serial.c (Harald Koenig) Re: new Berkeley DB - anyone? (Tommy Thorn) Re: Latest STABLE versions of kernel and net source? (Norbert Kuemin) Progress on DIP? (Kenneth Topp) Re: Latest STABLE versions of kernel and net source? (Mike Horwath) Re: [Q] Big modem installation for Linux? (Robb Pfister) Re: 16550A handling in serial.c (Matthew Dillon) PD COBOL - Source WANTED (Reid Allen Forrest) Re: REQ: MIDI driver for YAMAHA CBX-T3 (Mark A. Davis) Re: WANTED: COBOL compiler (Robert Broughton) Re: GCC crashing Linux: kernel bug (ULMANN Jean-Marie) Re: CD-ROM Driver for LMS CM-205 (Kai Petzke) Re: Yet another core dumps name suggestion (Ian McCloghrie) Re: [Q] Big modem installation for Linux? (Keith Lovatt) ---------------------------------------------------------------------------- From: lpkruger@flagstaff.Princeton.EDU (Louis P. Kruger) Subject: Kernel accounting patches w/ 13 ALPHA Date: Wed, 10 Nov 1993 02:26:33 GMT I'm trying to apply the accounting patches which were written for kernel 99.12. They also worked with 99.13 with a little bit of hacking. Under 13p, I've managed to get everything to compile except for the following line: ac.ac_btime=CT_TO_SECS(current->start_time)+startup_time; This appears in the function acct_process. The reason it doesn't work is the global variable startup_time present in previous kernels no longer exists. Can someone tell me what purpose this variable served so I can try to finish the patching? Thanks a lot! Louis ------------------------------ From: koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) Subject: Re: 16550A handling in serial.c Date: 10 Nov 93 10:39:58 GMT Another UART question (I have 4 16550As): the normal UARTS do probing for the start bit synchronously with 16 times the baud rate (for 50 baud this is 800 Hz or 1.25ms). Are any (pin compatible?) UARTs known which have a better time resolution on start bit detection? if not pin and plug compatible, are there any pc cards with such uarts? Thanks, Harald -- Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) All SCSI disks will from now on be required to send an email notice 24 hours prior to complete hardware failure! ------------------------------ From: tthorn@daimi.aau.dk (Tommy Thorn) Subject: Re: new Berkeley DB - anyone? Date: 10 Nov 1993 15:28:15 +0100 rene@renux.frmug.fr.net (Rene COUGNENC) writes: >Ce brave Christian Kuhtz ecrit: >You are right, there is a problem whith the system include files (not the >program ones), I just hacked features.h to define: No, you are wrong. The problem lies in the fact that Berkeley DB comes with system include files, namely cdefs.h as could be seen in what I posted. The easy fix: remove the symlink to cdefs.h in include. Anyway, with risk of being flamed by pseudo.net.police, here is a patch to apply after doing what the ../db/PORT/README tells you to do. diff -u2 --recur linux/Makefile Linux/Makefile --- linux/Makefile Wed Nov 10 15:12:29 1993 +++ Linux/Makefile Mon Nov 8 18:07:01 1993 @@ -12,9 +12,8 @@ rec_seq.o rec_utils.o -MISC= +MISC= snprintf.o ${LIBDB}: ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC} - ar cq $@ \ - `lorder ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC} | tsort` + ar rcs $@ ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC} ranlib $@ Only in linux/include: cdefs.h diff -u2 --recur linux/include/compat.h Linux/include/compat.h --- linux/include/compat.h Wed Nov 10 15:12:41 1993 +++ Linux/include/compat.h Mon Nov 8 17:42:26 1993 @@ -118,5 +118,5 @@ #define LITTLE_ENDIAN 1234 /* LSB first: i386, vax */ #define BIG_ENDIAN 4321 /* MSB first: 68000, ibm, net */ -#define BYTE_ORDER BIG_ENDIAN /* Set for your system. */ +#define BYTE_ORDER LITTLE_ENDIAN /* Set for your system. */ #endif diff -u2 --recur linux/include/db.h Linux/include/db.h --- linux/include/db.h Tue Oct 12 20:25:26 1993 +++ Linux/include/db.h Mon Nov 8 17:40:48 1993 @@ -41,4 +41,5 @@ #include +#include #define RET_ERROR -1 /* Return values. */ -- Tommy.Thorn@daimi.aau.dk Staff-programmer Aarhus University, Ny Munkegade 116 Phone: +45 89423223 DK-8000 Aarhus C, Denmark. Fax: +45 86135725 PGP Public Key fingerprint: E7B1175FC30D9E96B67AF61D89A70A1F ------------------------------ From: kuemin@srapc101.alcatel.ch (Norbert Kuemin) Subject: Re: Latest STABLE versions of kernel and net source? Reply-To: norbert.kuemin@alcatel.ch Date: Wed, 10 Nov 1993 14:31:12 GMT Gregory Gulik (gulik@mink.mot.com) wrote: : Is there an FTP site that has the absolute latest kernel : and net software? Watch out for /mirror/linux/slackware and try linux0.99pl13 (SLS 1.1.0) i've work now with this and tin 1.2. NO PROBLEMS if found this mirror of slackware at nic.switch.ch =======================================+======================================= +----------V----------+ Eltech. ING HTL|EMAIL: norbert.kuemin@alcatel.ch | A L C A T E L | Norbert Kuemin |DEC: PSI%(0228)4795123920::ZAD_KUEMIN +---------------------+ Alcatel STR |X.400: c=CH a=arCom p=Alcatel S T R CH-8804 Au/ZH | s=Kuemin g=Norbert =======================================+======================================= ------------------------------ From: toppk@bray1a.its.rpi.edu (Kenneth Topp) Subject: Progress on DIP? Date: 10 Nov 1993 15:47:10 GMT Reply-To: toppk@rpi.edu Hello, Is there anyone working on dip? I believe that a feature lacking in this program is the computer responding to being giving an IP that is different each time. This happens in many cases with a serial link. I think that DIP should have support for BOOTP. Any knowledge of work towards that end would be appriciated. Kenneth Topp toppk@rpi.edu ------------------------------ From: root@jacobs.mn.org (Mike Horwath) Subject: Re: Latest STABLE versions of kernel and net source? Date: 10 Nov 1993 14:03:19 GMT Gregory Gulik (gulik@mink.mot.com) wrote: : Is there an FTP site that has the absolute latest kernel : and net software? : I'm running pl13+net2debugged, but I'm having a few problems : and I'd like to try something newer. : -greg : gulik@cig.mot.com (Gregory Gulik) [NeXT] [MIME] ftp ftp.funet.fi cd /pub/OS/Linux/kernel/linux look in there for the newest and greatest (and sometimes not so great). -- Mike Horwath IRC: Drechsau BBS: Drechsau LIFE: lover root@jacobs.mn.org drechsau@jacobs.mn.org Jacob's Ladder 612-588-0201 UUCP, UseNet, Linux files, BBS ------------------------------ From: rpfister@cheeta.messaging.cs.mci.com (Robb Pfister) Subject: Re: [Q] Big modem installation for Linux? Reply-To: rpfister@cheeta.messaging.cs.mci.com Date: Wed, 10 Nov 1993 15:40:05 GMT IIn article <2bo97j$lvs@belfort.daimi.aau.dk>, Jesper Bach Larsen wrote: > >As headline says, I wan't to run a Unix installation, preferable Linux, as it >is free, with multiple modem lines. By multiple I mean in the amount of >30-50 modems. I suppose I will have to purchase somekind of hardware support >for this project. My question is: what would be the most effective (measured >in system-resources) installation? What kind of system-resource is required >for this (particular RAM recomendations, special I/O interfaces etc.) Sounds like a terminal server, and a bank of modems would be the best bet. This isn't cheap, but will also give you flexibility to add even more modems, or even another Linux Box. Robb ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: 16550A handling in serial.c Date: 10 Nov 1993 10:43:37 -0800 In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: :Another UART question (I have 4 16550As): : :the normal UARTS do probing for the start bit synchronously with :16 times the baud rate (for 50 baud this is 800 Hz or 1.25ms). : :Are any (pin compatible?) UARTs known which have a better :time resolution on start bit detection? : :if not pin and plug compatible, are there any pc cards with such uarts? : :Thanks, :Harald : :-- :Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) Not that I know of, and even if they did it would not make the uarts work any better. The 16x baud start bit synchronization is used to synchronize to the center of each incomming bit. A 1/16 bit time offset will make NO difference. Generally the uart detects the start bit, then counts 8 clocks to move to the center of the start bit, then checks it again (false start bit detection), then clocks in the data bits every 16 clocks thereafter. Some uarts will also check the data to either side of the center to detect 'noise', but there are very few real world situations nowadays where that kind of noise detection is meaningful since modems reclock their data. A long time ago when there were only FSK modems at 600 baud or less the FSK demodulation would be directly converted and not reclocked by the modem, so 'noise' detection would be meaningful, but that is no longer the case. Detection of a new start bit normally occurs after the center point in the stop bit is detected, allowing the sender to be as much as 1/2 bit out of phase with the receiver without the receiver missing a beat. This feature is a thousand times more important then a 32x sampling rate, and all UARTs have it. -Matt ------------------------------ From: raf4482@TAMUTS.TAMU.EDU (Reid Allen Forrest) Crossposted-To: comp.os.linux.help Subject: PD COBOL - Source WANTED Date: 10 Nov 1993 13:58:42 -0600 Article 345 of alt.cobol: Path: TAMUTS.TAMU.EDU!not-for-mail From: raf4482@TAMUTS.TAMU.EDU (Reid Allen Forrest) Newsgroups: alt.cobol Subject: Re: PD ANSI 6.5 COBOL? Date: 10 Nov 1993 13:55:13 -0600 Organization: Texas A&M University, College Station Lines: 26 Message-ID: <2brgv1$hc6@TAMUTS.TAMU.EDU> References: <2b7f0o$c1d@TAMUTS.TAMU.EDU> <931109.85020.PETE618@delphi.com> NNTP-Posting-Host: tamuts.tamu.edu In article <931109.85020.PETE618@delphi.com>, wrote: >About the 6.5 COBOL ... I can't direct you to the person who has the code, but >The developer of the product is (was?) terminally ill with AIDS. The release 7 >documentation for the product stated that the source was being released into >the public domain (because he couldn't do it himself anymore) and kept on a >BBS in the Atlanta area. I can't for the life of me remember the name but will >contact in a day or two with it. Sorry I can't be of more help on an immediate >basis. I have the 6.50 distribution. It's an alright compiler. It is limited to 25 compiles, though. The name of the BBS is AV/Sync in Atlanta, Georgia. The Sysop's name is Bill Tullis. I'm not sure if this BBS is still around, though. I tried contacting it a while back, but could not find the number. I don't know if another distribution of COBOL650 gave the number or not. Does anyone know if the release 7 came with source? Or did it come with other useful information? I'm pretty desperate for the source to this or another COBOL compiler. I plan on porting a compiler to Linux, and will support and distribute it. Somebody, PLEASE PLEASE help me out with a source. There are many people who want/need a Linux COBOL compiler. Maybe a project like this is what we COBOL programmers need to "bring COBOL back" into the mainstream. Thanks in advance, Reid Forrest raf4482@tamuts.tamu.edu ------------------------------ From: mark@taylor.wyvern.com (Mark A. Davis) Subject: Re: REQ: MIDI driver for YAMAHA CBX-T3 Date: Wed, 10 Nov 1993 19:42:05 GMT dudek@acsu.buffalo.edu (The Cybard) writes: >I just got that YAMAHA "Hello Music" kit for the PC. It has a connection >that connects to the regular serial "COM" port. It comes with a driver for >MS-Windoze, but I would also like to use it under Linux. I was wondering >if some kind soul could write a driver for this device, or perhaps help me. >(I barely know how to program basic stuff in C.) Thanks. It is highly likely that your keyboard is NOT using MIDI. MIDI requires a special baud rate which most standard clone serial ports do not support. A MIDI driver would, of course, be a very nice addition (perhaps for MPU cards or the SoundBlaster type of adapters) but you would also need some software to use it too :) -- /--------------------------------------------------------------------------\ | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 | | Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp | \--------------------------------------------------------------------------/ ------------------------------ From: Robert_Broughton@mindlink.bc.ca (Robert Broughton) Subject: Re: WANTED: COBOL compiler Date: 11 Nov 93 01:26:33 GMT > Harald Koenig writes: > > I talked to an AccuCobol sales droid and a programmer at the GUUG'93 > (german UNIX users group meeting) end of September because a friend > is looking for COBOL on Linux for some commercial applications > (moving from a DG-NOVA to finally shut down the good old nova). > > This guy told me that there would be no support on those free UNIX versions > which is important for them when they hit bugs while porting their apps > and there won't be a real market (any interesst at all, free UNIX > only a toy for students etc.). > > In about half an hour I could convince him (at least I think so) that > just support is one of the strengths of Linux if he can afford the cost > for a modem and ~$2 per day for news and mailing. > > maybe if more people show interesst in running AccuCobol this could be one > of the first real commercial apps (since porting won't be that difficult > if the system does conform to POSIX and ANSI-C as I was told). I agree. You can email one of their sales/marketing guys at acucobol!bob@uunet.uu.net. I've worked with AcuCOBOL on SCO and it is an EXCELLENT product. The AcuCOBOL people are also very agressive about porting (they've even ported to Coherent) so it wouldn't be much of an effort for them to do a Linux port. -- *-*-*-*-*-*-*-*-*-*-* Robert Broughton Robert_Broughton@mindlink.bc.ca "We calm and reassure. We embrace people with the message that we're all in it together. That our leaders are infallible and that there is nothing, absolutely nothing wrong." - Miles Drentell, _thirtysomething_ ------------------------------ From: ulmann@platon.emi.u-bordeaux.fr (ULMANN Jean-Marie) Subject: Re: GCC crashing Linux: kernel bug Date: Wed, 10 Nov 1993 23:49:49 GMT I had the sig-11 problem that I used to fix by disabling the external cache (386DX40). It was so slow I decided to buy new cache. The problem has never showed up since (2 months). Hope it helps. -- Jean-Marie Ulmann ulmann@platon.emi.u-bordeaux.fr ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: CD-ROM Driver for LMS CM-205 Date: 10 Nov 1993 21:50:28 GMT In <2bp9op$m5j@urmel.informatik.rwth-aachen.de> cfranck@messua.informatik.rwth-aachen.de (Carsten Franck) writes: >Hi there! >I am trying to disassemble the DOS device driver for the LMS CM-205 >CD-ROM in order to write a device driver for Linux. I am just doing the same thing. I am two weeks away an alpha release of an driver for this CD ROM. If you are interested, I can e-mail you a copy of my commented disassembly, as well as some information about the MS-DOS interface MSDEX. The latter can also be found on ftp.gwdg.de, directory: /pub/linux/cdrom/test, or similiar. I have a working C programme, to access the drive from user mode under Linux. Two big things are left: - Implement the driver into the kernel (likely to happen this weekend) - The raw frames on CD are 0x930 bytes each, the cooked data sectors only 0x800. The remaining bytes contain error correction bits. In case of read errors, they might help to recover the sector. This seems to be done by the DOS driver, not by the hardware (however, the manual states, that you could set the drive also to cooked mode, but the DOS driver does not). Kai -- Kai wpp@marie.physik.tu-berlin.de Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, than make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Subject: Re: Yet another core dumps name suggestion Date: 10 Nov 93 21:17:09 GMT thompson@sun.cuug.ab.ca (Bruce Thompson 295-5967(w) or 229-3370(h)) writes: >Now to the other issue, core file sizes. I've got a couple of ideas, >both with pros and cons. The first idea is to make the core file a >link into the swapped image of the process. This would consume swap >space, but not file-system space. It should also speed core file The problem with this is that, sometimes, the reason a process dies (and thus dumps core) is because it ran out of memory (malloc() returned 0). If you leave this core 'file' in swap space, you've not solved anything, you're STILL out of memory, and the next process that tries to malloc() something is ALSO going to die. -- /~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /~\ |~\ |~> | | <~ | email: ian@ucsd.edu Net/2, USL 0! \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club ------------------------------ From: klovatt@klnet.lugroid.com (Keith Lovatt) Subject: Re: [Q] Big modem installation for Linux? Date: Thu, 11 Nov 1993 00:13:57 GMT Jesper Bach Larsen (jbl@daimi.aau.dk) wrote: : As headline says, I wan't to run a Unix installation, preferable Linux, as it : is free, with multiple modem lines. By multiple I mean in the amount of : 30-50 modems. I suppose I will have to purchase somekind of hardware support : for this project. My question is: what would be the most effective (measured : in system-resources) installation? What kind of system-resource is required : for this (particular RAM recomendations, special I/O interfaces etc.) How about using terminal servers then have the connections via telnet? I'm sure you could quite easily pick up a few used ones fairly cheaply, then just dedicate each port to the required ip address. This could work well for a number of issues, ie easier if you get more hosts. Keith. -- Keith Lovatt | Willowdale, Ontario, Canada klovatt@klnet.lugroid.com | Voice: +1 416 447 2707 klovatt@klnet.UUCP | "Once a Lugroid, doe.utoronto.ca!klnet!klovatt | Always a Lugroid." ------------------------------ ** 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 ******************************