From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 17 Sep 93 10:30:20 EDT Subject: Linux-Development Digest #104 Linux-Development Digest #104, Volume #1 Fri, 17 Sep 93 10:30:20 EDT Contents: Re: program in vgalib (Fritz Ganter) Re: [RFI]: Scientific/Engineering Software on Linux (K J MacDonald) Kernel config (Re: To all device driver) (Olaf Titz) Re: Test of the Intel 8254 shut-down/parity-check command (Pat Mackinlay) Re: Let's have a prog to restore screen state! (Howlin' Bob) Re: Let's have a prog to restore screen state! (Howlin' Bob) Re: Let's have a prog to restore screen state! (Brandon S. Allbery) Re: Anybody ever try crashme on Linux? (Michael Chapman K8/EIS1. Tel. 1662) Re: [Q] biff and comsat? (Johannes Grosen) Re: To all device driver writers; boot-time messages. (Dominik Kubla) Re: Parallel Port sound drivers - how compatiable? (Dominik Kubla) ---------------------------------------------------------------------------- From: ganter@fvkmapc02.tu-graz.ac.at (Fritz Ganter) Crossposted-To: comp.lang.c Subject: Re: program in vgalib Date: 17 Sep 1993 09:05:20 GMT Android (benjie@quack.kfu.com) wrote: : New with vgalib on linux. Is there a way to program the computer in C : so that it could draw me a dot at a position (x,y) on the screen? I : am using gcc with vgalib on linux. Sure, why not? Look into /usr/src/vgalib/vgatest.c , this should be example enough. : Benjie Fritz. -- Fritz Ganter Graz University of Technology, Austria Email: ganter@fvkmapc02.tu-graz.ac.at, ganter@fvkmads02.tu-graz.ac.at HAM-Radio: OE6FAD@OE6XYG.AUT.EU, OE6FAD@OE6FAD.AMPR.ORG Phone: +43 316 873-7222 (Office), +43 316 663243 (home) ********** Linux... try it, use it, love it. ************ ------------------------------ Crossposted-To: comp.os.linux.misc From: kenny@festival.ed.ac.uk (K J MacDonald) Subject: Re: [RFI]: Scientific/Engineering Software on Linux Date: Fri, 17 Sep 1993 09:53:44 GMT Divya Alok Sundaram (sundaram@cps.msu.edu) wrote: : Hi y'all, : I am collecting a list of software packages that people have installed : and used successfully under Linux/X. I am interested in hearing about : installations and other tips that Linux-cummunity might want to know. : I hope to consolidate this in the form of a "FAQ" ... : Things in particular: : Name of software (and what it does). : Location and what files are needed .... : Source available? : How big is the source? The binaries? : Does it have printed docs? : How about Online Docs? Man pages? : How much memory is required for it? : Hints and tips when re-compiling, installing, configuring or : using the package : Idiosyncracies and bugs : Comments : I have not found a good source to go to when looking for software : packages to perform given tasks ... for example, I started to look : for a PD Neural Nets package and had to go rummaging through all : sorts of stuff to find what I needed (after I looked through the : nnet-FAQ). It would be helpful to have a list of packages that : you could flip through to find what you needed relatively quickly : by doing a name/subject search! Perhaps much of this is already being done by Jeff Kopmanis and his Linux Software Map (LSM). I strongly recommend the LSM to be the 'One True' list of software available for Linux. If we can keep it up to date and accurate it's potential is enormous. Get it from your favourite Linux ftp site ! Kenny. -- ============================================================================== Kenneth MacDonald E-mail: kenny@ed Dept. of Geology & Geophysics "Allow me to introduce myself, Major Dennis University of Edinburgh Bloodnok, International Christmas Pudding ------------------------------ From: uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz) Subject: Kernel config (Re: To all device driver) Date: 17 Sep 1993 10:21:09 GMT In article <1993Sep15.145606.17303@super.org>, Donald J. Becker wrote: > 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. >... > 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 This reminds me of one major gripe I have about the kernel Makefile structure... the purpose of "make" (to recompile only what is necessary) is broken by "make config", which seems to include "dep" and "clean" afterwards and has to recompile everything. You know this when you have tried to compile a 99.12 kernel without quota support, it fails after 50 min. of compiling (yes, my machine is not that fast - but I remember the days of 0.11 with a 10 minute kernel compile...) in the final link step and you have to re-make almost everything :-( Related to this: one Makefile for every subdir has its advantages, but also the big drawback of wasting much time (with the current number of subdirs, a "make all" even without any changes takes a nontrivial amount of time to recognize this fact) and memory (three nested makes, all of which have data segments...) What do others think about one big Makefile for all of the kernel? Olaf -- olaf titz o olaf@bigred.ka.sub.org praetorius@irc comp.sc.student _>\ _ s_titz@ira.uka.de LINUX - the choice karlsruhe germany (_)<(_) uknf@dkauni2.bitnet of a GNU generation what good is a photograph of you? everytime i look at it it makes me feel blue ------------------------------ From: mackinla@cs.curtin.edu.au (Pat Mackinlay) Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.sys.ibm.pc.hardware,comp.sys.ibm.ps2.hardware Subject: Re: Test of the Intel 8254 shut-down/parity-check command Date: 17 Sep 93 09:29:21 GMT jmonroy@netcom.com (Jesus Monroy Jr) writes: > This is a condensed version of the posting. Although you wouldn't know it... [much crap deleted] > What does this prove? Mainly that Jesus Monroy Jr doesn't know what else to do with his time but annoy others. Does he *REALLY* think that people in all the groups posted to give a flying fig about their DRAM refresh timing? Even if they did, it's more likely they'd find what they needed from an Intel tech. reference... > Namely that the RAM refresh is controllable via > the i8254 timer on the IBM/ISA architecture. Gee duh, and all this time I thought my mouse controlled my refresh... Will someone shut this guy up? -- Pat -- Alien lands on head, gives birth to mutant. ------------------------------ From: gt8134b@prism.gatech.EDU (Howlin' Bob) Subject: Re: Let's have a prog to restore screen state! Date: 17 Sep 93 08:14:53 GMT kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes: >>P.S. until these drivers can get the card *out* of any mode that >> other programs put the card into, like XFree86 and dosemu, then >> they're not much use. And don't say that all programs will have >> to use kernel services to switch modes; that's not practical for >> dosemu. >I think every program should absolutely switch through kernel, even if >via a really low-level ioctl that takes an array of port/value pairs or >something general enough like that. This would make it possible for the And you would have even the X server do this? I surely wouldn't. Remember that bank switching is something that would affect screen "normality," yet I wouldn't want the X server having to do a bunch of ioctl()s every time my mouse crossed a bank boundary. >kernel to maintain the current state of the card, allow programs to >query some write-only registers from the kernel's (or driver's) copy of VGA shouldn't have any write-only registers. EGA/CGA/MDA do, of course, but those aren't problems: if the kernel is only responsible for restoring the mode to the default text mode (not the user-application inflicted mode), it can go with a very simple standard procedure. EGA/CGA/MDA are known quantities; your FooSVGA isn't. >the register value, and thus make it possible to return to a known state >and mode. But for this to work reliably, any direct access to ports >should be disallowed. I think it's just too costly to go with this scheme. On my localbus ET4000 (on a 486/33), X is tolerably fast. I wouldn't want it any slower. I can run Castle Wolfenstein 3-D under dosemu at a very comfortable speed; with the overhead of trapping all port accesses and translating them into ioctl()s and context switching, etc., you could count the pixels as they changed. The same goes for fractint; it runs very nicely under dosemu, but with this OS overhead it would crawl. Even if you got this register-tracking scheme working, I surely wouldn't use it. I'm unhappy enough with the speed penalty that dosemu incurs with V86 mode + I/O bitmap checking. I'd be happy with a scheme like the following: 1) there is a kernel driver for every card type 2) It may or may not offer user-visible mode switching. I don't really care. What's important is that it does two things: save any necessary information upon bootup (i.e. font memory), and be smart enough to switch into the proper text mode upon demand. 3) If a console switch away from a console in GRAPHICS mode occurs, the kernel driver restores the screen state to the default text mode. We should be careful of doing things "right" at the expense of simple usability. Performance should *not* suffer. Also, sometimes having it done at all is more important that doing it right (see *BSD and shared libraries). -- Robert Sanders Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b Internet: gt8134b@prism.gatech.edu ------------------------------ From: gt8134b@prism.gatech.EDU (Howlin' Bob) Subject: Re: Let's have a prog to restore screen state! Date: 17 Sep 93 08:25:11 GMT joel@rac1.wam.umd.edu (Joel M. Hoffman) writes: >Would this work (again, pardon my general ignorance of these matters): >A process would enter V86 mode and call C000:0003, but trap all access >to the regs and to the screen memory, watching everything that "Trapping access" to screen memory is a bit complicated. To keep a single coherent memory image, you have to know how bank switching works on that particular card. To do it without that knowledge, well, I don't want to see the multi-megabyte trace that this would produce. >happens. The information learned would be stored somewhere for future >use. Then, to reset the screen, the information would be "played That's an interesting idea; where exactly is "somewhere?" If the kernel's going to be in charge of things, you've just turned a lot of memory non-pageable. If not, you might as well go with a simpler scheme based on V86 mode and the C000:0003 initialization vector. >back." Of course, the best solution is still emulating each >individual SVGA card.... Why emulate each one? If you know that much about each card, write a bunch of drivers for those cards. Emulation is only useful to supply a generic card type. For example, if you provide a VGA emulation in front of your card, programs under dosemu can only play around with standard VGA registers (and states). Therefore, restoring from any inflicted modes is a simple matter of fiddling the registers back to the way you want them; since you know which ones changed, and what their meanings are, and what registers you want there for text mode, it's cake. Everything's a known quantity. >If we could only save/restore the COMPLETE svga state, any program >could do anything it wanted to the video card. If wishes were horses, beggars would ride. SVGA manufacturers really dropped the ball on this; VESA was too lazy to pick the damn thing up. [umpteen lines of .sig deleted] > Tell Clinton to stop the genocide: president@whitehouse.gov Perhaps I should invest in an inappropriate political .sig for technical newsgroups. Bandwidth grows on trees, doesn't it? -- Robert Sanders Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b Internet: gt8134b@prism.gatech.edu ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Let's have a prog to restore screen state! Date: Fri, 17 Sep 1993 11:47:33 GMT In article <112507@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes: >I think it's just too costly to go with this scheme. On my localbus >ET4000 (on a 486/33), X is tolerably fast. I wouldn't want it any Actually, SCO has an ioctl that takes an *array* of I/O ports and values. There's even a (slight, knowing SCO...) chance that it's standard in the SysV/386 world. But it still doesn't help dosemu. ++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: mchapman@argos.eis (Michael Chapman K8/EIS1. Tel. 1662) Subject: Re: Anybody ever try crashme on Linux? Date: 17 Sep 93 11:56:00 GMT Reply-To: mchapman@argos.eis In article 3vv@usenet.rpi.edu, rogerj@marcus.its.rpi.edu (Diversion (Jeff Rogers)) writes: >s9329053@sandcastle.cosc.brocku.ca (Darcy Boese) writes: > >>You want to crash Linux? Simple as pie... > >>Try deleting a file on a DOS disk using mtools when the disk is >>write-protected... > >Or try mounting a 1.72 meg floppy (the device is there, but the driver >apparantly isn't) > No problem on my system! (You have to modify the kernel to allocate more space to the buffer track so it doesn't write the last 3 sectors on the track over something vital!!! This is done in one of the assembler files). -- ============================================================================== Mike Chapman e-mail: mchapman@eis.k8.rt.bosch.de fax: (+49) 7121/35-1746 tel: (+49) 7121/35-1662 ------------------------------ From: grosen@argv.cs.ndsu.nodak.edu (Johannes Grosen) Subject: Re: [Q] biff and comsat? Date: Fri, 17 Sep 1993 12:35:34 GMT 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 >messages about new mail?). If so - under which name can they be >found? 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' environment variables. Bash can monitor several mailboxes with the MAILPATH environment variable. >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 -- Johannes Grosen grosen@argv.cs.ndsu.nodak.edu System Administrator Intelligent Systems Cluster, Room 244 IACC Building North Dakota State University, Fargo, ND USA 51805 (701) 237-8282 ------------------------------ From: kubla@wilbur.zdv.uni-mainz.de (Dominik Kubla) Subject: Re: To all device driver writers; boot-time messages. Date: 17 Sep 1993 11:02:17 GMT I agree with you about the boot-time messages, but i think we should leave an option to include drivers for non-detected hardware: Imagine a Linux maintainer who has to build several tailored kernels for his network on his one and only development machine ... So if you introduce such a configuration scheme it should not substitute the kernel sources. It should instead report the detected hardware and setup a template for configuration, allowing the user to override (what about building a kernel for a recovery disk? you would not like to have the sound-driver included by default!). But i am thinking of another configuration scheme, which seems better suited for networks and development: All drivers build their own objects which are copied to a special directory let's call it /kernel. Then you run a special makefile which just links the desired modules to the core (consisting of swapper, scheduler, i/o-monitor, and what else is independent from the driver selection.) This way you can easily upgrade drivers, create special kernels with/without certain drivers and commercial software/hardware developers can provide binary only drivers. (Well i won't like that to happen, but it would make it easier to get exotic, undocumented or non-disclosure-documented hardware to work with Linux.) BTW: Donald, there is some problem with the 3COM EtherLink II driver: Our EL2 is configured to IRQ9, but the auto-detection code always detects IRQ5. I guess the problem is a spurious interrupt from the 2nd parallel port. For now i just hardcode the IRQ into the sources (we are using alpha13 with arp-patches by Alan Cox and us( that is in fact Stefan Graefen ...)) Regards Dominik (aka 'Mr. Linux') +-----------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.uni-mainz.de | | sMail: Dominik Kubla, Steinsberg 34, 56355 Nast"atten, F. R. Germany | +-----------------------------------------------------------------------------+ | | | "Linux: The choice of a GNU generation" --S. Frampton | | | +-----------------------------------------------------------------------------+ ------------------------------ From: kubla@wilbur.zdv.uni-mainz.de (Dominik Kubla) Subject: Re: Parallel Port sound drivers - how compatiable? Date: 17 Sep 1993 11:11:23 GMT Well i can not answer this question, but i have related good news for all the owners of COVOX-comp. soundcards: Just substitute the i/o-port of one of the lp-ports with the i/o-port of your covox-card and compile the kernel. Then configure /dec/pcsp to be DACm on the port you subsituted and away you go! And it takes less cpu-power than the speaker driver :) I had vplay playing the enterprise theme in a endless loop while compiling the kernel in the back- ground. BTW this was a 386DX-20 with 4 MB of RAM !!!!! Currently i am working on a proper implementation of this, so that you can use a CVXm do swith to the covox device. I would also like to add auto-detection of covox-hardware, but i have no idea on how to do this ... Regards, Dominik +-----------------------------------------------------------------------------+ | eMail: kubla@goofy.zdv.Uni-Mainz.DE | | sMail: Dominik Kubla, Steinsberg 34, 56355 Nast"atten, F. R. Germany | +-----------------------------------------------------------------------------+ | | | "Linux: The choice of a GNU generation" --S. Frampton | | | +-----------------------------------------------------------------------------+ DISCLAIMAER: Everything written above are the expressed thoughts of the author and in no way connected to 'Johannes Gutenberg Universit"at', Mainz (Germany). This way, they do not have to care about what I say ... ------------------------------ ** 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 ******************************