From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 13 Nov 93 18:13:13 EST Subject: Linux-Development Digest #225 Linux-Development Digest #225, Volume #1 Sat, 13 Nov 93 18:13:13 EST Contents: Re: Debugger wants libc source?! (Bruce Thompson 295-5967(w or 229-3370(h))) Re: Motif - Pay? BAH! (Timothy J. Bogart) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Berkeley Fast Filesystem (J. Dean Brock) Re: Motif - Pay? BAH! (Matthew J. Ryan) Re: Is dosemu still being developed? (dan@oea.hobby.nl) Q: mmap() - used to work, now doesn't (David Schenfeld) Present status of WINE & dosemu? (Shun-Chang Tsai) Re: Is dosemu still being developed? (James B. MacLean) Re: 16550A handling in serial.c (Bill Roman) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux.admin From: thompson@indigo.cuug.ab.ca (Bruce Thompson 295-5967(w) or 229-3370(h)) Subject: Re: Debugger wants libc source?! Date: Sat, 13 Nov 1993 05:50:42 GMT In article <2be9at$p5m@fbi-news.informatik.uni-dortmund.de> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes: Guten Tag! Unfortunately, while debugging various pieces of code, I really that my debuggers -- gdb and ups -- demand the sources of libc when libc calls, like printf or whatever, are reached. I can pass it by using "next" instead of "step"ping into the call. However, it's not very comfortable. Moreover, I always get a disturbing little "beep" for each call with a missing source. My libs are from image-4.4.1.tar.gz (or so) from the GCC directory on sunsite. So: what I am doing wrong? Thank you in advance! Any information will be appreciated! Holger Muenx (muenx@heike.informatik.uni-dortmund.de) What are you doing wrong? Nothing. The behavior you're describing is correct, assuming that the libraries you are referring to were compiled with debugging enabled. The debugger is assuming that since you stepped into the library routines, you want to debug them. That is, after all, what the step command is for. The debugger `should' step completely over any routine that is not compiled for debugging unless you specify to step to the next machine instruction. If you have the sources for libc, I'd recommend that you recompile them without debugging, not to mention turning optimization on. If you don't have the sources, I'd suggest looking into finding a libc that is nott compiled with debugging on. In the mean time, here are a couple of things you can do once you've stepped into a routine you don't have source for: 1) Try the `continue -return' command (I think that's it). Check the gdb manual for more info, but I believe there's an option to continue that means continue until this routine is exited. 2) Move up one stack frame and set a one time breakpoint on the next line after the call you're currently in. Hope this helps some. I'd check my own system, but I don't yet have it. Cheers, Bruce. -- Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, Software Development Engineer,|Renegade Legion nor NAPRA, just myself. ACTC Technologies Inc. |"So this is it, we're going to die!" Renegade Legion, NAPRA #473 | -- Dent Arthur Dent -- Bruce Thompson, |I do not speak for CUUG, ACTC Technologies, Software Development Engineer,|Renegade Legion nor NAPRA, just myself. ACTC Technologies Inc. |"So this is it, we're going to die!" Renegade Legion, NAPRA #473 | -- Dent Arthur Dent ------------------------------ From: tjb@NeoSoft.com (Timothy J. Bogart) Subject: Re: Motif - Pay? BAH! Date: Sat, 13 Nov 1993 00:43:18 GMT In article <2c0i88$plo@ground.cs.columbia.edu> ringel@news.cs.columbia.edu (Matthew F. Ringel) writes: >In article <2c0diq$9ro@pdq.coe.montana.edu>, >Jaye Mathisen wrote: >> >>I am not a Mosaic user, but WTF does the choice of window manager have >>to do with the libraries required to build a program? >>-- >> Jaye Mathisen > >Absolutely nothing. mwm is merely a window manager that is built >with the motif libraries. Therefore you get the Motif look-and-feel >without having to own the libraries. The confusion between having the >libraries and having the window manager comes up every now and then in >the comp.os.unix.* groups. > > ......Matthew > >-- >|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| >Matthew F. Ringel ringel@ground.cs.columbia.edu >"I am not a number! I'm three numbers, a hyphen, two numbers, another hyphen, > and another four numbers after that! Hah!" -mfr Well, that doesn't explain the apps that you get that request Motif libraries when you try and compile them. Care to clear this up for us? If an app is looking for Motif libraries, what can we substitute? ------------------------------ Crossposted-To: comp.os.linux.admin From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Berkeley Fast Filesystem Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Sat, 13 Nov 1993 14:07:07 GMT >>> On 12 Nov 1993 05:49:26 GMT, nate@bsd.coe.montana.edu (Nate >>> Williams) said: [ ... on the issue of BSD FFS vs. The World ... ] Nate> Right. When you read in block-at-a-time mode, you can only read Nate> the blocksize value at a time. True in the BSD FFS; in general this is rather inaccurate. You can read ahead/write behind as many blocks as you want (transfer clustering). If such blocks are laid out contiguously on the disk (allocation clustering) and memory (if you controller supports scatter/gather there is no need for contiguousness in memory), then you need only issue one IO operation to transfer them all. If your controller cannot transfer multiple blocks in one operation, then large fixed block sizes are pointless too, because most disks are sectored to 512B (more rarely 1KB), and thus transferring a single block would still require multiple IO operations. Nate> The larger the blocksize, the more data you read at one time. Yeah, and this can be a big problem too. A large blocksize implies a _fixed & synchronous_ large readahead and writehind factor. If you are not doing sequential accesses this is a big loss, and it is a big loss also if you do sequential transfers at low speed because the application is CPU bound. A large fixed blocksize is also a big loss if you can only allocate full sized blocks in memory, as then you will waste a lot of it. >> If you read too much data, then you may well be wasting space on I/O >> buffers that could better be used for programs or data. Nate> ??? This is irrelavant to the file-system, and is a problem with Nate> your buffer code being overly agressive. If the filesystem code specifies a large fixed blocksize, then that is an effective minimum level on the aggressivity of the buffer code. The classic BSD FFS will only transfer blocks in their entirety, and cannot do partial block transfers for any reason. Nate> ??? 8K isn't large enough to get really good throughput. Let's Nate> see some numbers to back that up. I get VERY good performance Nate> using an 8K/2K BSD-FFS with the 486/33. (1.5MB/sec reading and Nate> 1MB/sec writing w/out any hardware cache on a 486/33 ISA box. On Nate> EISA boxes I've seen numbers in the upper 2's and 3's) The issue of clustering has been discussed in this newsgroup only last week (last month there was a discussion in comp.arch.storage). Eric Youngdale was under the same mistaken impressions as other people in this newsgroup... I kindly rectified them :-), both in this newsgroup and in an email conversation, and as a consequence he has done some nice dynamic clustering mods to the Linux IO subsystem, which don't change the block size away from 1KB. He reports that such mods give the performance you report above, with an unmodified ext2 fs. Amazing facts! I have found he has put them up for BETA testing on funet and its mirrors under ".../BETA/scsi/cluster-04.tar.gz". Try them out... ------------------------------ Crossposted-To: comp.os.linux.admin From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Berkeley Fast Filesystem Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Sat, 13 Nov 1993 14:29:04 GMT >>> On Fri, 12 Nov 1993 14:45:51 GMT, wayne@backbone.uucp (Wayne >>> Schlitt) said: >> Huh? I think the end result is that if you read one block at a time, >> you read one block at a time. This has very little bearing on disk >> tracks. Wayne> If the overhead of reading one block at a time is large enough, Wayne> you won't be able to read consecutive sectors. Nitpicking: yes, but many modern interfaces can; in particular because the disk drive itself normally reads ahead a full track. So the issue is less important. Besides, the loss of performance need not be total; interleaving (which is what the BSD FFS amounts to, BTW) is better than waiting the next revolution for the next block. >>> If you read too much data, then you may well be wasting space >>> on I/O buffers that could better be used for programs or data. >> >> ??? This is irrelavant to the file-system, and is a problem with >> your buffer code being overly agressive. Wayne> how much data should be read at one time depends on how much free Wayne> memory you currently have. If you have 1MB of free memory, go ahead Wayne> and read 128k. If memory is tight, only read 8k... This is something Wayne> that can't be accurately guessed at when you are building the file Wayne> system. You should check it at run time. This is an hypothesis that I made in the comp.arch.storage discussion, but I must for honesty report that there are also reasons to think that is is as big a win. The main reason is given in Knuth, Vol. 1; if the bandwidth consumed by the program is systematically less than or greater than the bandwidth offered by the peripheral, a lot of buffering does not buy you a lot, simply because one of the two will end up waiting for the other more often than not. If the two are bandwidth matched, two buffers will suffice. The size of each buffer though, that is the transaction size, will have an important impact though if it is _too small_: where too small means that the cost of setting up its transfer is a significant fraction of the cost of transferring or processing it. Then I think that the optimal transfer size is that transfer size for which the setup time is 10% of the smaller of the time needed to transfer it, or to process it. This does not necessarily depend on how much free memory you have got: doing a large cluster to get overheads from 10% to 5% might be a boon, but it is not vital, even if you have lots of free memory; and if you have too little memory, a cluster size that gives you an incidence of overheads greater than 10% is too small. Wayne> It was my understanding that framents were used only when the Wayne> entire file was 1k or less, but you may be right that it is used Wayne> for the tails of all files. He is right... Wayne> I am fairly sure that you can't uses multiple fragements though, Wayne> so a 42k file would not be able to use 2 fragements. Indeed: the fragment is only used the tail. However, if only for the tail, the existence of fragments means that one either has to implements two sizes of incore blocks, and this complicates memory allocation unless one can play tricks with VM, or just one incore block size (the larger...) and this wastes lots of memory. Wayne> Note, that I didn't say that 8k would get really bad throughput, Wayne> just that reading an entire track at a time can get better Wayne> performance than reading just 8k. No necessarily: only if you are reading sequentially, and (blah blah). Also, there is an impact on latency even when sequential access is involved: reading a track at a time means that you cannot start processing the 1st block of a track until the last has arrived (several milliseconds). Dynamic clustering avoid this entirely: perhaps all blocks in a track get transferred, but individually, so (at least in principle) as soon as the first has been transferred it can be processed. Wayne> Basically, my point was that fragments get you nothing that just Wayne> clustering reads and writes can't also get you. Clustering is Wayne> simpler to implement, wastes less disk space and can get even Wayne> better performance. This was all discussed recently in Wayne> comp.arch.storage... Yeah, and on these screens to. See my comments on Nate's own article. ------------------------------ From: brock@cs.unca.edu (J. Dean Brock) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 13 Nov 1993 15:19:42 GMT In article wayne@backbone.uucp (Wayne Schlitt) writes: >It was my understanding that framents were used only when the entire >file was 1k or less, but you may be right that it is used for the >tails of all files. I am fairly sure that you can't uses multiple >fragements though, so a 42k file would not be able to use 2 >fragements. OK, OK. Everybody. Pull out your copy of The Design and Implementation of 4.3BSD Unix Operating Systems and read how fragments are really allocated before posting any more messages on this topic. Files CAN use multiple fragments. A 42k file WILL consist of 8 full blocks followed by 2 fragments. ------------------------------ From: ryanm4@hall103.its.rpi.edu (Matthew J. Ryan) Subject: Re: Motif - Pay? BAH! Date: 13 Nov 1993 17:35:42 GMT In article , Timothy J. Bogart wrote: >In article <2c0i88$plo@ground.cs.columbia.edu> ringel@news.cs.columbia.edu (Matthew F. Ringel) writes: >>In article <2c0diq$9ro@pdq.coe.montana.edu>, >>Jaye Mathisen wrote: >>> >>>I am not a Mosaic user, but WTF does the choice of window manager have >>>to do with the libraries required to build a program? >>>-- >>> Jaye Mathisen >> >>Absolutely nothing. mwm is merely a window manager that is built >>with the motif libraries. Therefore you get the Motif look-and-feel >>without having to own the libraries. The confusion between having the >>libraries and having the window manager comes up every now and then in >>the comp.os.unix.* groups. >> >> ......Matthew >> >>-- >>|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\| >>Matthew F. Ringel ringel@ground.cs.columbia.edu >>"I am not a number! I'm three numbers, a hyphen, two numbers, another hyphen, >> and another four numbers after that! Hah!" -mfr > >Well, that doesn't explain the apps that you get that request Motif >libraries when you try and compile them. Care to clear this up for >us? If an app is looking for Motif libraries, what can we >substitute? > A window manager does just that: it manages your application's windows for it, so it can peacefully co-exist with other apps. Other than that, it really has nothing to with the execution of your program, and has nothing to do with compiling your program. Libraries, on the other hand, are collections of pre-compiled functions for use by apps. The Motif package has such a library, and it is that library that Motif applications require when you compile and run them. Hence, you don't need mwm to run Motif applications at all. But you do need the libraries, and I do not believe their is currently anything you can substitute for those libraries (Someone please correct me if I'm wrong). A Motif application can, however, be compiled by someone with Motif, in such a way that the executable contains the Motif library functions that it needs. That way, if you get this executable, you do not need Motif. Xmosaic is an example of this - there are precompiled versions for several systems available. Hope this cleared you up. - Matt -- "Still looking for a funky quote..." Matthew Ryan ryanm4@rpi.edu ------------------------------ From: dan@oea.hobby.nl Subject: Re: Is dosemu still being developed? Date: Sat, 13 Nov 1993 12:19:27 GMT Thaddeus H. Wood (pustule@cats.ucsc.edu) wrote: : Greetings, all. I was just wondering if dosemu is still : under development. Seeing that there has not been a new : release in quite some time. Anyone have any info?? Is : anyone in touch with Howlin' Bob? Haven't seen any posts from Howlin' Bob lately, but I seem to remember reading something about adding DPMI support to DOSEMU. -- |< Dan Naas dan@oea.hobby.nl >| +---------------------------------+ ------------------------------ From: m-ds0054@cs.nyu.edu (David Schenfeld) Subject: Q: mmap() - used to work, now doesn't Date: 13 Nov 1993 14:37:49 -0500 Hello, I'm having a problem with mmap() on Linux 0.99.13. A friend of mine just upgraded from an older version, and the code fragment used to work, but now I get: Creating file /tmp/vm_839.dd Writing out 60 bytes Associating file with VM mmap: Invalid argument Can anyone tell me what I'm doing wrong? Code fragment is at end of message. Thanks in advance. -David m-ds0054@cs.nyu.edu ---- #define DEBUG #define LINUX extern struct user_defaults *userdef; /* Initialize shared memory segement */ void init_memory () { int s_userdef = sizeof (struct user_defaults); int memfd; char fn[MAXPATHLEN]; /* Hopefully a unique VM name */ sprintf (fn, "/tmp/vm_%d.dd", (int) getpid ()); #ifdef DEBUG fprintf (stderr, "Creating file %s\n", fn); #endif memfd = open (fn, O_RDWR | O_CREAT, 0600); #ifdef DEBUG fprintf (stderr, "Writing out %d bytes\n", s_userdef); #endif /* Write out a file to hold user_defaults */ write (memfd, fn, s_userdef); #ifdef DEBUG fprintf (stderr, "Associating file with VM\n"); #endif #ifdef LINUX userdef = (struct user_defaults *) mmap (0, (unsigned int)s_userdef, PROT_READ | PROT_WRITE , MAP_SHARED, memfd,0); #else /* CONVEX - works on Convex, not on Linux*/ userdef = (struct user_defaults *) mmap (0, &s_userdef, PROT_READ | PROT_WRITE, MAP_FILE | MAP_SHARED | MAP_DEBUG, memfd, 0); #endif if ((int) userdef == -1) { perror ("mmap"); close(memfd); unlink (fn); exit (1); } ------------------------------ Subject: Present status of WINE & dosemu? From: stsai@scws1.harvard.edu (Shun-Chang Tsai) Date: 13 Nov 93 20:18:47 GMT I remember hearing that WINE will be beta by the beginning of next year. Does anyone know what happened to it? Also, are there any words on dosemu? Thanks. ------------------------------ From: jmaclean@fox.nstn.ns.ca (James B. MacLean) Subject: Re: Is dosemu still being developed? Date: 13 Nov 1993 18:09:26 -0400 In article dan@oea.hobby.nl writes: >From: dan@oea.hobby.nl >Subject: Re: Is dosemu still being developed? >Date: Sat, 13 Nov 1993 12:19:27 GMT >Thaddeus H. Wood (pustule@cats.ucsc.edu) wrote: >: Greetings, all. I was just wondering if dosemu is still >: under development. Seeing that there has not been a new >: release in quite some time. Anyone have any info?? Is >: anyone in touch with Howlin' Bob? > Haven't seen any posts from Howlin' Bob lately, but I seem to >remember reading something about adding DPMI support to DOSEMU. >-- >|< Dan Naas dan@oea.hobby.nl >| >+---------------------------------+ Unfortunately Bob has not been well lately :-(, and we all wish him a speedy recovery :-). On the up side, we are almost ready to release an intrim release to let Bob have a rest. Look for it within the next week. Mostly bug fixes. It will handle keyboard controlling programs better, as well as the emufs.sys has had a few patches. The big ticket item is thanks to Tim Bird(Tim_R_Bird@Novell.COM) who has added the ability to redirect the drives mounted by emufs.sys giving us back our C: drive as drive C: . Later, JES --- ------------------------------ From: roman@eskimo.com (Bill Roman) Subject: Re: 16550A handling in serial.c Date: Wed, 10 Nov 1993 14:10:19 GMT In article <1993Nov4.180544.3642@infodev.cam.ac.uk> tjrc1@mbfs.bio.cam.ac.uk (Tim Cutts (Zoology)) writes: >I'm afraid I'm not much of an expert in these things, but I bought a 16550A >serial card in the hope that it would improve term connections via an X25 >gateway to my SunOS host. The old 8250 chip copes fine at 19200 baud on this >serial connection, but drops characters at any higher speed, but ONLY on >outgoing data (the CPU is a 486/33 and presumably copes with the interrupts). >^^^^^^^^ >However, my 16550A is no better! :-( I am still limited to 19200 baud. I The FIFO helps with dropping characters on INCOMING data. If you're dropping characters at high speed on OUTGOING data, it's very likely because of improper flow control. Your fast machine is quite capable of overrunning the PAD. Enable hardware flow control on the PAD and serial port, and it should solve this problem. Note that the FIFOs are of benefit both directions because they decrease the number of interrupts the CPU must service. Time spent entering/leaving the ISR is not insignificant on a [34]86. This time is better spent in user code. -- Bill Roman (roman@songdog.uucp / songdog!roman@eskimo.com) running linux Recently at PC Expo, Bill Gates said that Windows NT is "a form of Unix.... In a short time, it will be the most popular form of Unix ever.... Windows NT will outsell those other incompatible versions of Unix." -- Infoworld ------------------------------ ** 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 ******************************