Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA18351; Sat, 16 Mar 96 04:17:11 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA00213; Sat, 16 Mar 96 04:16:23 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.13/2.3JIK) id EAA06382 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Sat, 16 Mar 1996 04:14:26 -0500 Message-Id: <199603160914.EAA06382@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Delivered-To: Linux-Development-System@senator-bedfellow.mit.edu Precedence: bulk Date: Sat, 16 Mar 96 04:14:20 EST Subject: Linux-Development-System Digest #511 Linux-Development-System Digest #511, Volume #2 Sat, 16 Mar 96 04:14:20 EST Contents: Re: need info about outb_p() (Paul Gortmaker) Threads, POSIX, and libc-5.2.18 (Bryon G. Rigg) Question about locale.. libc.. (Byun DongHo (kornet)) Re: Ricochet Drivers (Stuart David Cheshire) Explain: /usr/src/linux/mm/swap.c (Kent Ritchie) Re: Assembly subroutines !? (Jorge F. Delgado Mendoza) Re: "ld: invalid BFD target `'" compiling a kernel with ELF (John Dunne) Re: "ld: invalid BFD target `'" compiling a kernel with ELF (John Dunne) unknown NR_MEM_LISTS in kernel-interface.c (Chun-Yu Lee) Re: Kernel Change Summary 1.3.74 (Alain Knaff) Floating Exception with code produced by f2c (Lloyd Anthony Bozzi) Re: SMC EtherPower and Tulip driver - *More Info* (Dwayne Jacques Fontenot) Re: Kernel Change Summary 1.3.74 (Doug Ledford) Re: Ideal filesystem (Markus Kaufmann) Re: Assembly subroutines !? (Mike Schmit) Re: need secure OS to entrust millions to (Steve Dunham) Re: Threads, POSIX, and libc-5.2.18 (Bill Gribble) ---------------------------------------------------------------------------- From: gpg109@leonard.anu.edu.au (Paul Gortmaker) Subject: Re: need info about outb_p() Date: 16 Mar 1996 14:55:27 +1100 rjs@spider.compart.fi (Riku Saikkonen) writes: [...] >See ftp://sunsite.unc.edu/pub/Linux/doc/HOWTO/mini/IO-Port-Programming or >http://isil.lloke.dna.fi/rjs/tech-writing/ioportprog.html for details... Also, if you have installed a recent set of man pages, you will find that there are man pages for these as well. Paul. ------------------------------ From: bgrigg@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Bryon G. Rigg) Subject: Threads, POSIX, and libc-5.2.18 Date: 16 Mar 1996 04:08:14 GMT Is it me or what? I have been playing around with the threads stuff that came with libc-5.2.18. In /usr/include/pthread/mit/sys/timers.h, the following is defined: struct timespec { time_t ts_sec; long ts_nsec; }; I saw someone do this to the kernel recently and perhaps it was because they followed the above example. The problem is that timespec is specified in the POSIX standard, and the above does not match POSIX. The following is from /usr/include/linux/time.h: struct timespec { long tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; This is consistent with POSIX. As I see it, we have two problems: 1. Multiple definitions of struct timespec. 2. struct timespec as defined in the MIT threads package is incorrect. Who can be contacted to resolve this problem for linux? Thanks in advance, Bryon ------------------------------ From: cpascal@soback.kornet.nm.kr (Byun DongHo (kornet)) Crossposted-To: comp.os.linux.development.apps Subject: Question about locale.. libc.. Date: 16 Mar 1996 04:35:54 GMT Hello? Now I have met locale on my Linux. I edited libc error-list and saved. But if I want to see that in applications, I should put "setenv NLS_PATH `pwd`/libc.cat". How can I make as default without setting enviroment NLS_PATH? I want to set only one enviroment "LANG". Can I use this in /usr/lib/locale/{LANG}/.... ? Thank you very much for your reading.. ------------------------------ From: cheshire@Xenon.Stanford.EDU (Stuart David Cheshire) Subject: Re: Ricochet Drivers Date: 16 Mar 1996 04:48:12 GMT In article <4i9p53$mda@news.orst.edu>, Mark Madison wrote: >Does anyone know if there are any Ricochet drivers out there for Linux? Funny you should ask :-) Check out http://mosquitonet.stanford.edu/strip.html Stuart Cheshire * World Wide Web Page * Stanford Operating Systems and Networking Group Research Assistant * Stanford Residential Computing Associate * Macintosh Programmer ------------------------------ From: kritchie@bear.blake.pvt.k12.mn.us (Kent Ritchie) Subject: Explain: /usr/src/linux/mm/swap.c Date: Fri, 15 Mar 1996 22:55:19 -0600 Reply-To: kritchie@bear.blake.pvt.k12.mn.us I am trying to use Netatalk and Samba with a little bit more performance. The page cache seems to be hogging available ram. I want all unused ram to go to the fs buffer, not the page cache. I believe I can control this by editing /usr/src/linux/mm/swap.c and/or by specifying arguments to the kernel. Will someone please explain exactly what these numbers do and how they should be set for maximum fileserver performance? [from swap.c] /* * Constants for the page aging mechanism: the maximum age (actually, * the maximum "youthfulness"); the quanta by which pages rejuvinate * and age; and the initial age for new pages. */ swap_control_t swap_control = { 20, 3, 1, 3, /* Page aging */ 10, 2, 2, 4, /* Buffer aging */ I kinda get the aging settings from the definition above. 32, 4, /* Aging cluster */ ? 8192, 8192, /* Pageout and bufferout weights */ more is better here? -200, /* Buffer grace */ ? 1, 1, /* Buffs/pages to free */ more is better here? RCL_ROUND_ROBIN /* Balancing policy */ ? [snip] I assume I can pass these to the kernel like swap=20,3,1,3,32,4,8192,8192 and buff=10,2,2,4,8192,-200 Of course I will want to use different values as the ones above are default. /* General swap control */ /* Parse the kernel command line "swap=" option at load time: */ void swap_setup(char *str, int *ints) { int * swap_vars[8] = { &MAX_PAGE_AGE, &PAGE_ADVANCE, &PAGE_DECLINE, &PAGE_INITIAL_AGE, &AGE_CLUSTER_FRACT, &AGE_CLUSTER_MIN, &PAGEOUT_WEIGHT, &BUFFEROUT_WEIGHT [snip] /* Parse the kernel command line "buff=" option at load time: */ void buff_setup(char *str, int *ints) { int * buff_vars[6] = { &MAX_BUFF_AGE, &BUFF_ADVANCE, &BUFF_DECLINE, &BUFF_INITIAL_AGE, &BUFFEROUT_WEIGHT, &BUFFERMEM_GRACE [snip] TIA -- _____________________________________________________________________ Kent Ritchie Network Manager The Blake School kritchie@bear.blake.pvt.k12.mn.us or kent_ritchie@blake.pvt.k12.mn.us http://www.blake.pvt.k12.mn.us/~kritchie Pager: 612.539.4977 ------------------------------ From: ernar@isabel.dit.upm.es (Jorge F. Delgado Mendoza) Crossposted-To: comp.os.linux.development.apps,comp.windows.x.i386unix,comp.lang.asm.x86 Subject: Re: Assembly subroutines !? Date: 11 Mar 1996 17:43:35 GMT Daniele Paccaloni (ddt@bbs.infosquare.it) wrote: : Hello, : I am wondering how to include assembly subroutines to speedup C : programs compiled with gcc under Linux. : Is there a way to insert inline assembly into the C source (like on : MSDOS Borland-C) ? : Any info (and examples) will be appreciated. Yups, there is.... just grab the source for SVGALIB, and check the examples on the 'demo' directory.... speedtest.c has a nice example... the syntax is not obvious, but manageable. -- ============================================================================= | ernar@dit.upm.es | A much discussed alternative to homogeneous big | | Jorge Fernando Delgado | bang nucleosynthesis has been he first-order | | Madrid Telecom | quark-hadron phase-transition-inspired | | SPAIN | inhomogeneous model. | |---------------------------------------------------------------------------| | *********** http://www.dit.upm.es:80/~ernar/index.html ***************** | ============================================================================= ------------------------------ From: John Dunne Subject: Re: "ld: invalid BFD target `'" compiling a kernel with ELF Date: 15 Mar 1996 23:27:50 GMT John: There is an excellent web page on the migration to/towards ELF. It is: http://www.sjc.ox.ac.uk/users/barlow/elf-howto-2.html From what I have learned, it is not a great idea to try and make an ELF kernel out of v1.2.13, although it can be done if you apply all the required ELF patches. That is what you are trying to do, as indicated by the way that you are invoking gcc. If you wish to make an ELF kernel at this time, using the v1.3.72 source is the recommended route. To make an a.out kernel with gcc2.7x, you need to do 'gcc -b i486linuxaout' (besides any flags passed in the Makefile) and 'ld -m i386linux' for the loader. This will build an a.out kernel, if you have properly moved all the libs to their correct new locations. ------------------------------ From: John Dunne Subject: Re: "ld: invalid BFD target `'" compiling a kernel with ELF Date: 15 Mar 1996 23:27:56 GMT John: There is an excellent web page on the migration to/towards ELF. It is: http://www.sjc.ox.ac.uk/users/barlow/elf-howto-2.html From what I have learned, it is not a great idea to try and make an ELF kernel out of v1.2.13, although it can be done if you apply all the required ELF patches. That is what you are trying to do, as indicated by the way that you are invoking gcc. If you wish to make an ELF kernel at this time, using the v1.3.72 source is the recommended route. To make an a.out kernel with gcc2.7x, you need to do 'gcc -b i486linuxaout' (besides any flags passed in the Makefile) and 'ld -m i386linux' for the loader. This will build an a.out kernel, if you have properly moved all the libs to their correct new locations. ------------------------------ From: d791013@ce.ntu.edu.tw (Chun-Yu Lee) Subject: unknown NR_MEM_LISTS in kernel-interface.c Date: 16 Mar 1996 04:26:53 GMT As title, when compile modules for kernel 1.3.74. Chun-Yu Lee d791013@ce.ntu.edu.tw ------------------------------ From: knaff@hal.imag.fr (Alain Knaff) Subject: Re: Kernel Change Summary 1.3.74 Date: 16 Mar 1996 06:31:05 GMT Reply-To: Alain.Knaff@imag.fr In , Steve Farrell wrote: :In article <4ibivm$nmm@treflan.shout.net>, :Michael Elizabeth Chastain wrote: :>Kernel Change Summary :>Linux 1.3.74 (5080 lines) :>Thu 14 Mar 1996 :> :> :>My KCS archive: ftp://ftp.shout.net/pub/users/mec/kcs :> :>Documentation/Configure.help: add CONFIG_SCSI_PPA [Axel Boldt]. :>arch/i386/mm/init.c: disallow dma on memory over 16 megabytes. : :what's this? does this mean you can't have DMA w/>16megs? On an ISA bus, yes. : does :this mean dma is broken in older kernels? no, it just means that the test was done at (a) different place(s). The comparison with 16 megs used to be done at the place where DMA was actually allocated/used/etc. Now it is done in init, to set a flag which will later be tested when DMA will be allocated/used/etc. Supposedly, this allows to keep the machine-dependant "is this page DMA-able?" criteria in one place instead of spreading it all over the place. : or at least that it doesn't :accomodate for hardware where this is a problem? Alain ------------------------------ From: bozzi@students.uiuc.edu (Lloyd Anthony Bozzi) Crossposted-To: comp.os.linux.misc Subject: Floating Exception with code produced by f2c Date: 13 Mar 1996 22:34:34 GMT I've been trying to figure out why I occasionally get Floating Exception errors when executing code compiled by the f77 script. The Fortran code works fine on many other computers (RS6000, SPARC, IRIS ...). I am currently running kernel 1.2.13elf, gcc 2.7.0, and have the version of f2c that comes with slackware 3.0. Can anybody shed some light on this problem? Thanks, Lloyd bozzi@students.uiuc.edu ------------------------------ From: fontenot@weaver.argiope.com (Dwayne Jacques Fontenot) Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.networking Subject: Re: SMC EtherPower and Tulip driver - *More Info* Date: 12 Mar 1996 17:31:47 GMT In article <4i280j$9nu@geraldo.cc.utexas.edu>, Dwayne Jacques Fontenot wrote: >hello, > >AMD486DX120 PCI SiS 496/497 chipset. > >type of card: SMC >chip on card: 21041 >kernel version: 1.2.13 >driver: tulip.c w/ Manabe's patches >card mode: 10baseT >------------------------------------------------ >result: success! very fast! 950KB/sec ftp on large files! >------------------------------------------------ > > >type of card: SMC >chip on card: 21041 >kernel version: 1.3.67, 1.3.71, 1.3.72 >driver: tulip.c w/ Manabe's patches >card mode: 10baseT >------------------------------------------------ >result: pings work, machine HANGS on first significant transfer! > even a telnet will hang the machine. >------------------------------------------------ >Please help! I will try 1.3.72 tonight to see if it works. >I really want to use a 1.3.x kernel. Ok, I tried the latest Manabe tulip driver (0.68) and kernel 1.3.72 last night and had the same problem. I thought that maybe since 72 had changes to the timer interrupt code it might solve the problem, but it did not. Once again, my system is AMD486DX120 PCI SiS 496/497 chipset. I have PCI edge triggers set. I then tried the new de4x5 driver in 1.3.72 and so far have had success. The de4x5 driver is as fast as the tulip driver. I transferred a 6MB file at about 980K/sec. No problems so far. I would like to see whatever magic the de4x5 driver uses folded into the tulip driver, since the de4x5 author cannot support cards other than DEC. If anyone has any ways of finding out why the tulip driver hangs my system, let me know. I would like to help, but am not a driver hacker. Also, those disk checks on reboot after a hang are tiresome :-( thanks, Dwayne Fontenot ------------------------------ From: dledford@dialnet.net (Doug Ledford) Subject: Re: Kernel Change Summary 1.3.74 Date: 16 Mar 1996 05:17:48 GMT Steve Farrell (spfarrel@midway.uchicago.edu) wrote: : Michael Elizabeth Chastain wrote: : >Documentation/Configure.help: add CONFIG_SCSI_PPA [Axel Boldt]. : >arch/i386/mm/init.c: disallow dma on memory over 16 megabytes. : : what's this? does this mean you can't have DMA w/>16megs? does : this mean dma is broken in older kernels? or at least that it doesn't : accomodate for hardware where this is a problem? It means that DMA transfers to memory above 16MB used to be possible, but you have to use double buffering to support it. AKA, you would have to DMA a portion to memory below 16MB, then copy it to memory above 16MB, then DMA the next portion into your buffer below 16MB, etc. etc. Now, the kernel requires that all ISA bus DMA transfers (and possibly EISA and PCI as well, I haven't looked at the code) are limited to allocating memory below the 16MB boundary. This saves the double buffering overhead. This is a limitation of the ISA bus, not EISA or PCI, so it may not effect the latter two bus types. Of course, I haven't looked at the code, so I could be wrong, but that's what is suggested to me by understanding of PC architectures as well as what was mentioned in the kernel change summary, although I could be wrong here as well :) -- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * ***************************************************************************** ------------------------------ From: kaufmann@mh.zebra.fh-weingarten.de (Markus Kaufmann) Crossposted-To: comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Date: 16 Mar 1996 02:32:54 GMT Reply-To: kaufmann@zebra.fh-weingarten.de Mats Andtbacka (mandtbac@news.abo.fi) wrote: : - a *really, really fast* filesystem for people running big news : spools. OS/2 has a nice system-call, which allows to get more than one directory-entry at one time. This speeds up directory-scanning a lot. -- Tschau /\/\arkus There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen ------------------------------ From: mschmit@ix.netcom.com(Mike Schmit ) Crossposted-To: comp.os.linux.development.apps,comp.windows.x.i386unix,comp.lang.asm.x86 Subject: Re: Assembly subroutines !? Date: 16 Mar 1996 08:24:40 GMT In <4icune$phc@yantra.anyware-fast.com> stacey@yantra.anyware-fast.com (Stacey Campbell) writes: >You may be making a valid point in a world without project deadlines, >bug lists, code that must be reused for the next slightly different >rev of a graphics chip, etc. but in the real world where code must ship, >and it must be fast, and it must be bug free, and it must be easily >modified for reuse, the above attitude will get you in a world of trouble. > >That aside, do you seriously think that a `good' assembly language >programmer can keep a P5 or P6 pipeline busy in a useful way for any >substantial amount of code (e.g. the many large chunks of critical code >in an X DDX) better than the compiler writers at Intel who sat >cheek-by-jowl with the people that actually designed the chip? Yes, depending on your definition of 'good.' The typical output of, for example, MS VC++ 2.x and 4.0, as analyzed by Intel's Vtune product and my company's PentOpt product, will show you how bad it is. I'm not going to get into a big debate over this, but unless you have actually looked at the compiler output, then you are just assuming that it must be good. Compilers, sometimes generate very good code and sometimes they don't. And it is not based on how much performance is needed, it is based on the complexity of the specific source code (among other things). Last year I spent 2 weeks working on an MPEG decoder. The company that makes it spent several hours profiling the C code. They gave me these results and I just rewrote the few routines that consumed most of the CPU time. The pipeline pairing went from about 50% to 95% in these routines and I removed a number of stalls, such as AGI's. The code went from 20 frames per second to 28 fps (on a P-90). Mike Schmit =================================================================== mschmit@ix.netcom.com author: 408-244-6826 Pentium Processor Programming Tools 800-765-8086 ISBN: 0-12-627230-1 =================================================================== ------------------------------ From: dunham@gdl.msu.edu (Steve Dunham) Crossposted-To: comp.os.linux.misc,comp.os.linux.networking,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc Subject: Re: need secure OS to entrust millions to Date: 12 Mar 1996 15:57:49 -0500 In article richard@cogsci.ed.ac.uk (Richard Tobin) writes: > In article <4hsv73$d3h@park.uvsc.edu> Terry Lambert writes: > >So you are arguing that the product of two prime numbers > >renders the prime numbers themselves "secret". > > > >I claim that since the search space is known, they are "obscure". > So do you consider anything except a one-time pad to not be > security through obscurity? This would clearly not be the > usual meaning of the term. What do you mean, a one-time pad is in a known search space...(So, by his definition, it is security through obscurity. ------------------------------ From: Bill Gribble Subject: Re: Threads, POSIX, and libc-5.2.18 Date: 15 Mar 1996 23:16:53 -0600 Bryon G Rigg writes: > Is it me or what? I have been playing around with the threads stuff > that came with libc-5.2.18. The problem is that HJ started the project of adding thread support to libc but hasn't followed up. He put an old, buggy version of MIT pthreads in libc and didn't incorporate fixes. Some of the pthread headers were written for older versions of the kernel and the kernel header changes since then aren't reflected in the pthread files. Your best bet is to completely ignore the libc thread support. The MIT pthreads distribution (start looking at http://www.mit.edu:8001/people/proven/pthreads.html) has a thread-safe stdio and networking code of its own, which works fine for my rather large threaded c++ project. You will still have to fool with the headers a bit, but at least you can see what you're doing. Bill Gribble ------------------------------ ** 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-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@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-System Digest ******************************