From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 17 Oct 94 13:13:18 EDT Subject: Linux-Development Digest #324 Linux-Development Digest #324, Volume #2 Mon, 17 Oct 94 13:13:18 EDT Contents: Re: LINUX Logical volumes (Marcus Daniels) Re: How do I dump core? (Rob Janssen) Re: A badly missed feature in gcc (Rob Janssen) Bad code generated by gcc for strlen() call? (Dan Swartzendruber) Re: A badly missed feature in gcc (Craig Burley) Re: Looking for X graphics/ Plotting libraries (A. Rohde) Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... (Rob Newberry) Re: Kernel 1.1.54: Error compiling ("Stephen Davies") Re: Problems compiling 1.1.54 (Huw Davies) Re: We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr) Re: 3c505 driver ? ("Neil S. Russell") Re: We a FAQ: Linux vs. *BSD!!! (Hans Petter Fasteng) getty_PS with UUCP out (Hans Petter Fasteng) Re: question about the kernel (Nick Williams) ---------------------------------------------------------------------------- From: marcus@ee.pdx.edu (Marcus Daniels) Subject: Re: LINUX Logical volumes Date: 13 Oct 1994 03:30:51 GMT Reply-To: marcus@ee.pdx.edu In-reply-to: adc@bach.coe.neu.edu's message of 12 Oct 1994 15:34:56 GMT Logical volumes should be easy to implement with userfs. What about `ifs'? ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: How do I dump core? Reply-To: pe1chl@rabo.nl Date: Mon, 17 Oct 1994 08:54:30 GMT In <37ro10$bbc@sun0.urz.uni-heidelberg.de> andreas@orion.mgen.uni-heidelberg.de (Andreas Helke) writes: >Jeff Kesselman (jeffpk@netcom.com) wrote: >: Thanks for the response, but either i wasn't clear enough with my >: problem, or I'm not understanding your answer. The program ALREADY >: segment faults. I can't do anything about that. What I want is for it >: to dump core WHEN it segments faults, so I can gdb the core and find out >: WHERE it segment faulted. Every other UNIX I've ever worked with does >: this automaticly, but Linux isn't doing it for me... >Somewhere between 0.99 and 1.1 a definition in the kernel sources changed >and now the default is not to produce a corefile. You have to reset this >definition and recompile your kernel. No, you just set the ulimit from your shell. E.g.: ulimit -c 1024 (when using bash) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: A badly missed feature in gcc Reply-To: pe1chl@rabo.nl Date: Mon, 17 Oct 1994 08:57:50 GMT In jeffpk@netcom.com (Jeff Kesselman) writes: >In article , Rob Janssen wrote: >>In jeffpk@netcom.com (Jeff Kesselman) writes: >> >>>>Well, (URP!) VMS Pascal supports both (* *) and { } .....for what >>>>*that* piece of silly trivia is worth... >> >>>Not much more then the fact that Borland C supports //,I'm afraid. Its >>>still a compiler specific extension to the accepte standard. >> >>No. The "Pascal user manual and report" by Jensen & Wirth defines these >>two notations of comments in Pascal. >>When that is not the accepted standard, then what is? >> >>The (* *) notation is said to be used on systems where { } are not available. >> >>Rob >>-- >Okay. I stand corrected. Must be the fact that the last time i used >pascal was better then 10 years ago. Thanks, Bob. Same for me, but I still have that book (second issue, 1978) on the shelf here :-) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: dswartz@deathstar.riva.com (Dan Swartzendruber) Subject: Bad code generated by gcc for strlen() call? Date: 17 Oct 1994 09:58:15 -0400 With the input passed to blah(), the loop should never iterate even once, since 0 is not less than -10. And in fact, if I change the call of strlen() to xstrlen(), which causes it to call the wrapper function, it works correctly. Examining the disassembled code seems to indicate that gcc is generating incorrect code for the strlen() code generated in the for loop. I'm running gcc 2.5.8 on Linux. Failing code section (and generated asm code follows): ================================== CUT HERE =================================== void blah(char *, int); void main(void) { blah("", 10); } void blah(char * string, int n) { int i; for (i = 0; i < strlen(string)-n; ++i) { printf("loop...\n"); } } int xstrlen(char * string) { return(strlen(string)); } ================================== CUT HERE =================================== .file "x.c" gcc2_compiled.: ___gnu_compiled_c: .text LC0: .ascii "\0" .align 4 .globl _main _main: pushl %ebp movl %esp,%ebp call ___main pushl $10 pushl $LC0 call _blah movl %ebp,%esp popl %ebp ret LC1: .ascii "loop...\12\0" .align 4 .globl _blah _blah: pushl %ebp movl %esp,%ebp subl $4,%esp pushl %edi pushl %esi pushl %ebx movl 12(%ebp),%esi xorb %dl,%dl movl 8(%ebp),%edi movb %dl,%al cld movl $-1,%ecx repne scasb notl %ecx movl %ecx,%eax subl $1,%eax xorl %ebx,%ebx cmpl %esi,%eax je L4 .align 2,0x90 L6: pushl $LC1 call _printf addl $4,%esp incl %ebx movl 8(%ebp),%edi xorb %al,%al cld movl $-1,%ecx repne scasb notl %ecx movl %ecx,%eax subl $1,%eax subl %esi,%eax cmpl %eax,%ebx jb L6 L4: leal -16(%ebp),%esp popl %ebx popl %esi popl %edi movl %ebp,%esp popl %ebp ret .align 4 .globl _xstrlen _xstrlen: pushl %ebp movl %esp,%ebp pushl %edi xorb %al,%al movl 8(%ebp),%edi cld movl $-1,%ecx repne scasb movl %ecx,%eax notl %eax subl $1,%eax movl -4(%ebp),%edi movl %ebp,%esp popl %ebp ret ------------------------------ From: burley@gnu.ai.mit.edu (Craig Burley) Subject: Re: A badly missed feature in gcc Date: 17 Oct 94 11:45:45 GMT In article wpp@marie.physik.tu-berlin.de (Kai Petzke) writes: The answer to this is found in the GCC info files. It has to do with the fact, that a number of people think, that GCC should become the world's standard compiler: A feature to report any failure to conform to ANSI C might be useful in some instances, but would require considerable additional work and would be quite different from `-pedantic'. We recommend, rather, that users take advantage of the extensions of GNU C and disregard the limitations of other compilers. Aside from certain supercomputers and obsolete small machines, there is less and less reason ever to use any other C compiler other than for bootstrapping GNU CC. Please note the words "limitations", "certain" and "obsolete". I personally like GCC very much, but I do not like some of the attitude behind it. The statement above tells me, that I might run into trouble, if I use GCC on one machine but not the other. This is exactly, what Microcruft and many others do, and this is exactly the behaviour, which is condemned in the GNU Manifesto. No, it is almost completely the _opposite_ behavior of what is condemned in the GNU Manifesto. Or, has my comparative lack of paying attention to the commercial-software world resulted in my not noticing that what you call "Microcruft" has done the following? - Distributed their software products for free - Distributed the source code to their software products for free - Invited people to help them improve their source code I suggest that you reexamine the situation. If you consider it intelligently, you'll notice that while the statement you quote indeed indicates a certain "attitude" among the "official" GCC developer, the FSF, that attitude does _not_ extend to leveraging significant assets to lock customers into a product line that they cannot easily wriggle out of. That would be a very hard thing to do with a product that is freely copyable like GCC. The only depressing "attitude" on display here is the one you have -- that because the FSF hasn't already devoted even more of its funds to make GCC "all things to all people", or chose to do that rather than, say, to port it to more machines and make it generate better code more reliably, it has somehow let you down. Fortunately, the answer to your "attitude" is the same, simple answer to most complaints about the FSF and its products: If you don't like it, change it, or persuade someone else to change it. How's that for attitude? -- James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu ------------------------------ From: exp109@modcomp.physik.uni-kiel.de (A. Rohde) Crossposted-To: gnu.gcc.help Subject: Re: Looking for X graphics/ Plotting libraries Date: 17 Oct 1994 14:17:25 GMT In article , c_farer@news.gate.net (Wade Scholine) writes: |> CookieMonster writes: |> |> |> >I am working on a small project, and need some library routines to do |> >some simple X windows graphics: Pop open a window, take some disk data, |> >and graph the data in the window with auto-scaling, axis, etc. SInce I |> >want to spend more time on the data producing side of the program, I need |> >a package that can do the plotting for me. |> |> There is a program called x11-graph which does the trick for me. |> It's kinda old (at least the version I have is) but with minor |> tweaks it works pretty well. You'd have to archie to find it, |> since I don't remember where I got mine (or I suppose I could |> mail it to you...) |> -- |> Wade L. Scholine | Once upon a time, four AMPHIBIOUS HOG |> c_farer associates, inc. | CALLERS attacked a family of DEFENSELESS, |> Delray Beach, FL. | SENSITIVE COIN COLLECTORS and brought DOWN |> | their PROPERTY VALUES!! Try GnuPlot, xvgr or GLE. They are available from sunsite.unc.edu and it's mirrors. Axel ------------------------------ From: rob@eats.com (Rob Newberry) Subject: Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... Date: Fri, 14 Oct 1994 23:00:01 >: Looking at the postings relating to this problem, it appears that the >: connecting piece of hardware is the NE2000 Ethernet Card. In fact we seem >: to have crudely fixed the problem by , by slowing down the reads/writes >: performed by the Network Card. >What do you mean by this? Did you define REALLY_SLOW_IO? Something else? >: If anyone else could suggest a better fix, please let me know. >FWIW, our system is closing in on 12 days of uptime since replacing the NE2000 >with a 3c509. I replaced mine with an SMC Ultra -- much nicer, and absolutely NO problems since. Rob ******************************************************************* Rob Newberry Education and Technology Solutions, Inc. Email: rob@eats.com 4303 Parkland Court Phone: 301 438 3915 Rockville, Maryland 20853 FAX: 301 438 3748 The secret to happiness is knowing how many weekdays you can afford a hangover. ******************************************************************* ------------------------------ From: "Stephen Davies" Subject: Re: Kernel 1.1.54: Error compiling Date: Mon, 17 Oct 94 22:00:35 PDT G'day Bart. I think that you have somehow screwed your source tree. Start again and try the following: 1. In /usr/src create a file called "dopatch" or somesuch that contains: zcat MYPATCHDIR/patch$1 | patch -p0 2>&1 | tee patchlog where MYPATCHDIR is where you keep your patch.gz files. chmod this file to 7xx as takes your fancy. 2. For each new patch, "cd /usr/src", "dopatch n" and "grep fail patchlog". (where "n" is the relevant patch number. eg 54) If the grep returns nothing you are half-way home. 3. "cd linux", "make mrproper", "make dep", "make zlilo"/"make zimage" For patch54, you will probably have to delete the second half (line 637 onwards +/-) of binfmt_elf.c to get a clean compile. Cheers, Stephen. >I have been trying to compile kernel 1.1.54. >I downloaded 1.1.52 complete, and compiled. No problem. > >I patched 1.1.53 and 1.1.54 from the / (root) with: >patch -p < patch53 (and 54) >I did not see any errors during the patch, but it is imposible to read anyway. > >Make config: enable all IP stuff, all else as default. >'Make dep' works ok, 'make clean' ok, > >'make' fails in the area: >tools/build.c , problems with N_MAGIC, ZMAGIC QMAGIC , implicit declar; >undeclared, incomplete type.... >Then stuff about: unused variable 'sb' and 'major_root' may be used >uninitialized.... >Error 1 >End of story. > >Is it me doing something wrong? I have been patching from 1.1.19 and never had >any problems until today. > >Any help appreciated. > >Thanks, >Bart. > > >----------------------------------------------------------------------------- ======= >Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand >----------------------------------------------------------------------------- ======= ======================================================================== Stephen Davies Consulting scldad@sdc.com.au Adelaide, South Australia. Voice: 61-8-2728863 Computing & Network solutions. Fax : 61-8-27410 ------------------------------ Crossposted-To: aus.computers.linux,latrobe.linux Subject: Re: Problems compiling 1.1.54 From: cchd@lucifer.latrobe.edu.au (Huw Davies) Date: Mon, 17 Oct 1994 12:51:17 GMT Huw Davies (cchd@lucifer.latrobe.edu.au) wrote: : I've just applied the 1.1.54 patches to a (working) copy of 1.1.53, ran : make config choosing the usual group of options (although I added ISO9660 : support which I must have accidentally turned off building 1.1.53) and : then ran make zImage. Sadly I get compile time errors (see below). I've : tried rebuilding the compiler with and without elf support but the errors : remain. It turns out that applying the 1.1.54 patch to a 1.1.53 system will lead to this problem. The simple solution is to edit binfmt_elf.c which, as the result of applying the patch, contains two copies of the file. I just simply went down to the start of the second copy and deleted to the end of file and then rebuilt the kernel. Thanks to all those who took the time to reply. If I'd bothered to think rather than just panic (something that's easy to do at 2 in the morning having worked all day on other computer problems) I'd have probably worked this out for myself.... ------------------------------ Crossposted-To: comp.os.386bsd.development,comp.unix.bsd From: jmonroy@netcom.com (Jesus Monroy Jr) Subject: Re: We a FAQ: Linux vs. *BSD!!! Date: Sat, 15 Oct 1994 20:37:12 GMT John Gotts (john@linux.reshall.umich.edu) wrote: : The 386BSD FAQ covers some of the differences. RTFM. : Yes, that's true, but the direct question is: Which is better Linux vs. *BSD? RTFQ (Question) And don't spout out on this.... I very serious on this issue. -- Jesus Monroy Jr jmonroy@netcom.com Zebra Research /386BSD/device-drivers /fd /qic /clock /documentation ___________________________________________________________________________ ------------------------------ From: neilr@nacro.demon.co.uk ("Neil S. Russell") Subject: Re: 3c505 driver ? Reply-To: neilr@nacro.demon.co.uk Date: Mon, 17 Oct 1994 13:30:12 +0000 > In article <1994Oct13.110404.20492@uxmail.ust.hk>, > Tall Sword wrote: > >Zheng Huang (huang@eagle.sangamon.edu) wrote: > >: Hi, > > > >: I tried to config my linux(slakware 2.0) to work with my 3c505 network card, > >: but I can't find the 3c505.c file in linux src directory under drivers. > >: For some reason, the 3c505 is been commented out from the config file. Could > >: someone tell me how I can make 3c505 work with linux. > > I tried to configure the kernel to include the 3c503 driver but it don't > recognize my card. I know the linux has support for all the 3com card except > for 505. I tried my 3c501 card, and it works. > > Any help for 3c505 driver? I Compiled kernel 1.1.51 to include 3c505 code included and it works fine with these cards. Try compiling a newer kernel. -- Neil S. Russell Nation Computer Systems Manager NACRO NCE Ltd ------------------------------ Crossposted-To: comp.os.386bsd.development,comp.sys.unix From: hansf@kfdata.no (Hans Petter Fasteng) Subject: Re: We a FAQ: Linux vs. *BSD!!! Date: Mon, 17 Oct 1994 11:56:15 GMT Jordan K. Hubbard (jkh@freefall.cdrom.com) wrote: : In article jmonroy@netcom.com (Jesus Monroy Jr) writes: : This is a weekly question. : More often than not, we get into a flame war : on this. Let's stop this silliness!!! : The only way we're going to stop this silliness is to simply start : ignoring the querants. If someone asks "Which is better? Which is : better?", jumping up and down all the while, and everybody just flat : out _ignores_ the question and goes about their business as if nothing : happened, folks will eventually get the point and stop asking. : Consider carefully: It's not the questions that start the bloody flame : wars, it's everyone's pathetic attempts to answer! "Well, xxx is : better because of yyy.." "No it's not!" "Yes it is, you moron! Just : look at blah blah blah!" "Well, you're a complete idiot who obviously : wouldn't know an operating system if it bit you - yyy is _obviously_ : better because bleh bleh bleh!". And so downhill it goes from there. : No FAQ will ever satisfy the two sides, and would rapidly become : obsolete even if it did. Dave Burgess's FAQ _tries_ to answer this : question about as well as any FAQ could, and people still aren't : remotely satisfied. One German magazine reviewer who compared FreeBSD : to Linux ended up making an unfavorable judgement of FreeBSD because : _it didn't have enough shells_ bundled in by default! He completely : ignored the other issues, he just wanted his bloody tcsh to be happy. : This almost perfectly exemplifys the average querant - they don't : really want to know which is better in general (as if "better in : general" meant anything anyway), they want to know which is better for : THEM, and how the hell are we supposed to know that? : The distraction is overwhelming and we need a solution. : The solution is obvious, and in right front of our faces. Don't even : bother with such questions. Ignore them. If you're dead-set on : answering questions, then there are PLENTY of more worthy questions : posed every single day that could use meaningful answers. Why waste : time with people who only want to know which brand gives you whiter : teeth, fresher breath, cures acne or gets out those nasty grass : stains? Such people are better off watching daytime television talk : shows or reading "USA Today" anyway ("Today on Sally Jesse Rafael, : we'll be asking the question "Which is better? Linux or FreeBSD?", : and we'll also be interviewing 3 truck drivers who like to do long : cross-country trips with live hamsters in their shorts.") : Sheesh! : Jordan It is always easy to know better then others. It is not easy to go into your self, therefore we go into others and tell them what to do better. THe people posting those questions is new on the net, and knows nothing about internet or linux,freebsd. I do not thing it is right to ignore questions or to tell people how silly thay are. Just telling them that it is a FAQ is enough. Nearlly every person askes questions that my sound stupide in other ears than thair own. (sorry spelling is not my best side) -hans ------------------------------ From: hansf@kfdata.no (Hans Petter Fasteng) Subject: getty_PS with UUCP out Date: Mon, 17 Oct 1994 12:19:11 GMT I have getty_ps 2.0.7e (uugetty) on my dialin line. I also uses that line for UUCP outgoing calls. But now it is not possible getty will not release the port to UUCP how do I instruct uugetty to let UUCP call out? -hans ------------------------------ From: nmw@ios.com (Nick Williams) Crossposted-To: comp.unix.internals,comp.os.linux.help Subject: Re: question about the kernel Date: 14 Oct 1994 23:02:21 -0400 In article <37m617$pht@gate.noris.de>, Matthias Urlichs wrote: >In comp.os.linux.development, article , > dyue@mega.cs.umn.edu (Dongxiao Yue) writes: >> Can someone tell me how and where the critical sections are protected? >If the critical sections are not accessed from interrupt code, there's no >need to lock access. Reason: Switching between processes happens when >somebody calls schedule(). Interrupts don't call schedule() and nobody >switches processes behind your back. QED. Critical sections are pieces of code that access data that could potentially be accessed by a different thread of execution or an interrupt handler. Thus accesses to a buffer that is to be filled by an interrupt handler must be protected in some way or another (by raising the priority on a single CPU machine, or raising the priority _and_ spinlocking on a shared memory multi-processor machine or some other scheme [?]). That said, I must make clear that I haven't had the priviledge of studying linux kernel sources; I am ignorant of how linux handles critical sections in the kernel. I do know how they are traditionally handled in other operating systems though. To the original poster I say "read the docs [if there are any]." >-- >Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.noris.de >Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email. >90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 > PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE > Click here. Nick ------------------------------ ** 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 ******************************