From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 28 Oct 93 08:22:44 EDT Subject: Linux-Development Digest #195 Linux-Development Digest #195, Volume #1 Thu, 28 Oct 93 08:22:44 EDT Contents: Problem with Csound and no member in a structure error. (Dark Mage) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (York Lam - ACPS/F93) Re: Slowness in scsi disk access (Brandon S. Allbery) Re: Slowness in scsi disk access (Brandon S. Allbery) Re: Slowness in scsi disk access (Matthias Urlichs) Re: Slowness in scsi disk access (Michael O'Reilly) *PATCH* AMI BIOS Super VGA 132x43 132x25 video support (Daniel L. Marks) Re: LC port to LINUX available? (EurIng Chris Thoday) Re: UNIX trademark now X/Open (Steve Traugott) ---------------------------------------------------------------------------- From: spedge@csd4.csd.uwm.edu (Dark Mage) Crossposted-To: comp.os.linux.help Subject: Problem with Csound and no member in a structure error. Date: 28 Oct 93 02:52:06 GMT I am having a problem porting csound to linux. I get the error sndinfo.c:125: structure has no member named 'format' sndinfo.c:137: structure has no member named 'format' I looked at all the files involved, and see that the structure DOES include format as a member. What is the problem To kinda show the problem I have included the crutial parts of the files where the errors occure. <------------------------------------------------------------------------------------> These are the includes in the file sndinfo.c. This is the header file that the structure is in --------------------------------+ | #include | /* personal lib */ | #include /* all the Soundfile stuff */ | #include /* stft type files */ <--------------+ This is where the error occures.-------------------+ | PrintSNDFinfo(theSound, name) | SFSTRUCT *theSound; | char *name; | { | float durn; | int dsize,chans,infolen; | long frames; | char type[32]; | | switch(theSound->format) <----------------+ { case SFMT_CHAR: strcpy(type, "linear bytes"); dsize = 1; break; etc... This is the structure in the header file. typedef struct sfstruct { long magic; /* magic number to identify */ long headBsize; /* byte offset from start to data */ long dataBsize; /* number of bytes of data */ int format; /* format specifier */ <------------------+ int channels; /* mono/stereo etc */ | float samplingRate; /* .. of the data */ | char info[SFDFLTBYTS]; /* extendable byte area */ | } SFSTRUCT; | | Notice format is there! -----------------------------------------------+ So what is the problem here. I have tried changing the variable to _format, but them a bunch of other file bombed out. So that means that the variable format worked elsewhere. Anyone have any ideas? Spedge spedge@csd4.csd.uwm.edu ------------------------------ From: ylam@acs.ryerson.ca (York Lam - ACPS/F93) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 28 Oct 1993 04:13:04 GMT Rui Pedro Mendes Salgueiro (rps@matuc2.mat.uc.pt) wrote: [some stuff deleted] : For BSD/386 someone has made a "commitee solution" patch. : With this patch the behaviour is selectable when the kernel is configured. [some more stuff deleted] Selectability could break some packages out there which expect 'core'. On the other hand, named cores (ie .core. ) does indeed have it's advantages (hate having to rename cores just to keep them around). Maybe we could try having ONE alternate name for the cores, and make that switchable by root. Then we can dump, with the usual 'core' name when apps. require so, or use the alternate format. Personally, I like the .core. format (yeah, I know, names could get long...) Haven't read any complaints regaring .core either, so what's wrong which appending a timestamp to it? -- ========================================================================== | York Lam <-=-> ylam@acs.ryerson.ca | It's only fun until someone loses | ======================================| an eye... then it's fun for one | | ( free-space ) | less person. | ========================================================================== --- ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Slowness in scsi disk access Date: Thu, 28 Oct 1993 01:39:03 GMT In article jvs@netcom.com (Jonathan Stockley) writes: >In article eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: >> Someone else suggested a builtin task in the kernel that does >>this job. This would be relatively easy and doable, I suppose. I would >>be curious how other people feel about builtin tasks in the kernel, >>however. >> >I think this is what SVR3 called the "buffer dribbler" or bdflush. It is >tunable in that you can configure how often it runs and what percentage >of the buffer cache it scans for dirty buffers. If you set it to 30 seconds >and 100% you get .... sync()! I presume you mean you get /etc/update. Eric and I are working on this. At least I think he is still working on it... no mail since this morning but he may well be as busy as I am (aargh!), or be fixing some of the other things he recently found. ++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: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Slowness in scsi disk access Date: Thu, 28 Oct 1993 01:44:25 GMT In article pcg@aber.ac.uk (Piercarlo Grandi) writes: >WHAT? It has to *scan* the free list for a buffer? Cannot it just take >the first buffer and run scared? WHY? :-) :-) Because it might be a page from an executable, or an mmap()ed file. Neither of which is LRU-updated, since the cost is prohibitive (*every* time the page is touched it would have to be put on the end of the LRU-list). ++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: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: Slowness in scsi disk access Date: 27 Oct 1993 10:46:58 +0100 In comp.os.linux.development, article , eric@tantalus.nrl.navy.mil (Eric Youngdale) writes: > > Someone else suggested a builtin task in the kernel that does > this job. This would be relatively easy and doable, I suppose. I would > be curious how other people feel about builtin tasks in the kernel, > however. > I don't have a problem with that. In fact, stuff like the Sprite log file system, as implemented in Sprite, more or less requires a kernel task. (I looked into porting it to Linux, a few months ago, but realized that I don't have enough time right now.) Besides, just try a simple test -- copy a lot of files between two different disks. Most of the time, only one disk actually does something because the written blocks linger in the buffer cache and are flushed out all at once when the copy process needs more buffers. With an update process that flushes buffers out to disk in the background, this can be avoided and both disks would run at the same time, cutting copy time in half. This is an extreme example, but I think that the general case would also profit from such an update mechanism. A global sync() is OK for safety but ugly for performance. > >3) curiosity: How well does the hashing work in searching for buffers? > >Got any stats on hit/miss ratios ?? search lengths? > > I am not sure, but I think that this works well. The hash table > contains close to 1000 entries, so this means that each hash chain is > only something like 15 entries deep with a 15Mb buffer cache. Long ago > I experimented with the alogorithm to verify that the hash function did > in fact store the entries more or less evenly across the hash table, and > this was in fact the case. > Has anybody done benchmarks with bigger hash tables? Since the buffer cache can grab almost all of memory, 15-entry chains look like there's space for improvement here. -- To him nothing is impossible, who is always dreaming of his past possibilities. -- Carlyle -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 ------------------------------ From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: Slowness in scsi disk access Date: 28 Oct 1993 04:01:44 GMT Piercarlo Grandi (pcg@aber.ac.uk) wrote: : >>> On 27 Oct 1993 03:15:34 GMT, oreillym@tartarus.uwa.edu.au (Michael : >>> O'Reilly) said: : Later on you have statistics that state that only in 15% of cases a : request for a buffer is satisfied by looking at the first one in the : inaptly named 'free list'. : WHAT? It has to *scan* the free list for a buffer? Cannot it just take : the first buffer and run scared? WHY? :-) :-) Ok. Point taken. :) : Searching the free list? Just Say No. : Michael> A much-vaunted 'free list' doesn't help if it's empty. : But at least one does not have to scan 15,000 entries (which costs 50ms) : on the 'free list' just to discover it is empty. Well, the scan only runs once. The basic algorithm is to search for a buffer with a lower 'badness' than the one we have, dropping out right away if we get one with a zero badness. But yes, in the case where all buffers are dirty, or locked, you have problems, and must rescan.. : BTW, even with the current design, a suitable heuristic might be: if a : suitable buffer is not say within the first N (N perhaps between 50 and : 100) withing the free list, just allocate new space. But perhaps this is : an expensive operation. Well, I belive the current one is, if we can allocate more space to the buffer, do so, and if we can't, THEN search for a reusable buffer. I must say, I do like the idea of having a bdflush process cleaning buffers. --- Some more stats, X = search length. i.e. number of buffers checked before aborting search (due to sucess or otherwise). for X not 0, 1 (i.e. when block is already in buffer, or first buffer is free), X is approx. poisson distributed with mean approx 34. Thats on an 8 meg machine, with an average number of buffers about 1600 I'll let it collect stats for a while longer, but that's basically it. Raw data available on request. ------------------------------ From: dlm40629@uxa.cso.uiuc.edu (Daniel L. Marks) Subject: *PATCH* AMI BIOS Super VGA 132x43 132x25 video support Date: 28 Oct 1993 05:09:55 GMT This is a patch that is for video cards with an AMI BIOS to do 132x43 and 132x25 resolutions. I personally have a localbus S3, though it really does not matter because the BIOS sets up all of the VGA registers. If you have problems, or a different BIOS signature, let me know. Patch the file /usr/src/linux/boot/setup.S This diff is for 99pl13 but it should work with earlier patchlevels. Use at your own risk, no flames please, blah blah blah. Maybe it will make it into a kernel version someday! :) Daniel Marks dlm40629@uxa.cso.uiuc.edu *** setup.S Wed Oct 27 23:46:59 1993 --- setup.S.old Wed Oct 27 23:55:56 1993 *************** *** 390,410 **** int 0x10 ! turn on cursor (scan lines 11 to 12) pop ds mov ax,#0x501c ! return 80x28 ret /* svga modes */ ! svga: cld ! Check for S3 AMI BIOS card ! lea si,idAMIBIOS ! at C000:0008, 21 byte long ! mov di,#0x008 ! signature ! mov cx,#21 ! repe ! cmpsb ! jne namibi ! (dlm40629@uxa.cso.uiuc.edu) ! isami: lea si,dscamibios ! lea di,moamibios ! br selmod ! namibi: cld lea si,idf1280 ! Check for Orchid F1280 (dingbat@diku.dk) mov di,#0x10a ! id string is at c000:010a mov cx,#0x21 ! length repe cmpsb --- 390,400 ---- int 0x10 ! turn on cursor (scan lines 11 to 12) pop ds mov ax,#0x501c ! return 80x28 ret /* svga modes */ ! svga: cld lea si,idf1280 ! Check for Orchid F1280 (dingbat@diku.dk) mov di,#0x10a ! id string is at c000:010a mov cx,#0x21 ! length repe cmpsb *************** *** 815,825 **** idgenoa: .byte 0x77, 0x00, 0x99, 0x66 idparadise: .ascii "VGA=" idoakvga: .ascii "OAK VGA " idf1280: .ascii "Orchid Technology Fahrenheit 1280" idVRAM: .ascii "Stealth VRAM" - idAMIBIOS: .ascii "AMI-VGA-BIOS, (C) AMI" ! Manufacturer: Numofmodes+2: Mode: ! Number of modes is the number of chip-specific svga modes plus the extended ! modes available on any vga (currently 2) --- 805,814 ---- *************** *** 833,843 **** motrident: .byte 0x09, 0x50, 0x51, 0x52, 0x57, 0x58, 0x59, 0x5a motseng: .byte 0x07, 0x26, 0x2a, 0x23, 0x24, 0x22 movideo7: .byte 0x08, 0x40, 0x43, 0x44, 0x41, 0x42, 0x45 mooakvga: .byte 0x07, 0x00, 0x07, 0x4f, 0x50, 0x51 mof1280: .byte 0x04, 0x54, 0x55 - moamibios: .byte 0x04, 0x54, 0x55 mounknown: .byte 0x02 ! msb = Cols lsb = Rows: ! The first two modes are standard vga modes available on any vga. ! mode 0 is 80x50 and mode 1 is 80x28 --- 822,831 ---- *************** *** 852,862 **** dsctrident: .word 0x5032, 0x501c, 0x501e, 0x502b, 0x503c, 0x8419, 0x841e, 0x842b, 0x843c dsctseng: .word 0x5032, 0x501c, 0x503c, 0x6428, 0x8419, 0x841c, 0x842c dscvideo7: .word 0x5032, 0x501c, 0x502b, 0x503c, 0x643c, 0x8419, 0x842c, 0x841c dscoakvga: .word 0x5032, 0x501c, 0x2819, 0x5019, 0x843c, 0x8419, 0x842C dscf1280: .word 0x5032, 0x501c, 0x842b, 0x8419 - dscamibios: .word 0x5032, 0x501c, 0x842b, 0x8419 dsunknown: .word 0x5032, 0x501c modesave: .word SVGA_MODE .text --- 840,849 ---- ------------------------------ From: chris@thoday.demon.co.uk (EurIng Chris Thoday) Subject: Re: LC port to LINUX available? Reply-To: Chris@thoday.demon.co.uk Date: Wed, 27 Oct 1993 22:17:27 +0000 I have my own version of LC which was originally similar to the LC supplied with the MKS Toolkit which is a set of Unix type tools running under MS-DOS. The version I now use has various additional features: o The output is displayed by a pager (defined by an environment variable). o There is a recursive option. o The output can be piped to a printer (and is suitably formatted). o The full path name of the directory is given in the heading. o Executable files are shown with '*'. o Hard links to files (but not directories) are shown eg as [x2]. o Soft links are shown with '!' if the target does not exist. o The total size and revision date of the files in the directory is shown. There is a separate date if the directory was updated after the most recent file. o If used on a file instead of a directory then it gives you full details about the file. I am not sure how best to send you the source. Please mail me if interested. There is about 18kb of source code. I only use LS when I need the -lg listing. Example of lc / / Links: etc -> var/etc/ tmp -> var/tmp/ vmunix -> vmlinux Directories: A B C D bin dev home lib mcd mnt proc root1 usr usr1 var Files: .Xauthority .Xdefaults .Xmodmap .Xsession* .bash_history .bashrc* .emacs .kermrc .openwin-menu .profile .twmrc .vtwmrc .xerrors .xfmrc .xinitrc .xinitrc.bak .xinitrc.old .xinitrc.olvmn .xinitrc~ .xsession* .xsession-errors capture.log cproot* exclude vmlinux Files updated: 27 Oct 1993 18:17 Total: 272 kb Mode: mixed Owner: root =============================================================================== Example of lc . /home/cjt/lc Files: Makefile display.c display.o files.c files.o getnames.c getnames.o lc* main.c main.o output.c output.o tree.c tree.o tstamp.c tstamp.o Files updated: 27 Oct 1993 21:29 Total: 98 kb Mode: 0644 Owner: cjt =============================================================================== EurIng Chris Thoday, Software Engineer and 8 Victoria Street, RUGBY, a Director of the European X User Group Ltd Warwickshire, CV21 2HN Phone: (0788) 565 842 (home), UK (0788) 542 121 x 3741 (work) Email: chris@thoday.demon.co.uk =============================================================================== ------------------------------ From: stevegt@TerraLuna.Org (Steve Traugott) Subject: Re: UNIX trademark now X/Open Date: Thu, 28 Oct 93 00:53:40 EDT quinlan@ebony.cs.bucknell.edu (Daniel Quinlan) writes: > > That does not mean that we can't claim to meet the spec (if we already > do or will eventually), just that we probably won't be calling it > "Unix". I don't think it is something that we should worry about too > much, especially if it will impair Linux development (real > development, i.e. the kernel). (Note: Disclaimer - I am currently on a short-term contract for USL, am not an employee and do not in any way speak for the company or for Novell, and to my knowledge am disclosing no proprietary information. The following words represent my own personal views and philosophies formed over years of contracting in the Un*x industry for many companies and on many flavors of Un*x.) What Dan's saying is right - but as someone who's working on USL's UNIX right now, let me urge you all to *please* pay attention to those X/Open et al standards, and keep them in mind when adding or changing features - one of the big problems we have in what I do involves finding non-standard applications and non-standard Unii which break something basic. On the flip side, we tend to push these non-standard apps and OS's further down the priority list when it comes to designing for future compatibility - we have to; that's what standards are for. Linux shows a lot of promise - it would be a shame for it to fall short by drifting away on tangents. Meet those specs, and claim them! It would be a huge boost for the OS. Linux is already positioned in the right direction with POSIX. Novell just announced $99 versions of UnixWare for educational institutions, and is also offering UnixWare source code licenses to same. The entire industry is trying pretty hard to beat back that spectre of NT - I've messed with NT and I still think it's a ghost with little usable real-world substance, but the effect it's having on potential single-user UNIX customers is real. Bill Gates and company may actually succeed by sheer shock effect and even capture some of the multi-user MIS market by claiming that the UNIX world is loose and lacking rigorous standards. If they succeed, then we will have Yet Another Proprietary Operating System dominating the planet's silicon for another 10 years or more. All of these standards and the huge Un*x development community and porting base are part of our ammo. I think so far we haven't done too bad, and NT's debut is sort of fizzling, but there's always 2.0... DOS didn't do so well until the second major release either. Steve --- . . ` * Steve Traugott ` . * + stevegt@TerraLuna.Org ...Organizational Evolution + ` . . stevegt@well.sf.ca.us Unix/Internet Systems Engineer . UUs-L@UBVM.BITNET List Manager Currently contracting in Summit, NJ . stevegt@usl.com ------------------------------ ** 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 ******************************