678 lines
26 KiB
Plaintext
678 lines
26 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Thu, 13 Oct 94 11:13:18 EDT
|
|
Subject: Linux-Development Digest #301
|
|
|
|
Linux-Development Digest #301, Volume #2 Thu, 13 Oct 94 11:13:18 EDT
|
|
|
|
Contents:
|
|
Re: Linux For Mac (Hillel Y. Sims)
|
|
Re: FTP slowdown under 1.1.52 with hdparm on (Mark Lord)
|
|
Re: FTP slowdown under 1.1.52 with hdparm on (Mark Lord)
|
|
Re: A badly missed feature in gcc (Jeff Kesselman)
|
|
Re: Kernel 1.1.53 - no BOOM (David Kastrup)
|
|
Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Rob Janssen)
|
|
Re: Xircom PCMCIA ethernet support? (Vir Lagua)
|
|
Re: A badly missed feature in gcc (Bruce Thompson)
|
|
Re: Improving SLIP latency under Linux (Andrew R. Tefft)
|
|
Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Bart Kindt)
|
|
Re: Serious Bug In The Networking Code (Bart Kindt)
|
|
Need more than 32 mount's (Holger Kausch US/ESC 60/3/135 #3630)
|
|
Re: insmod drv_hello.o gives "___moddi3 undefined" (Michael Krause)
|
|
Re: A badly missed feature in gcc (Jeff Kesselman)
|
|
Re: Unable to find XF86-3.1-lib.tar.gz with correct sum. (Pierre Belanger)
|
|
Re: A badly missed feature in gcc (Jeff Kesselman)
|
|
Re: A badly missed feature in gcc (Jeff Kesselman)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: simsh@rembrandt.its.rpi.edu (Hillel Y. Sims)
|
|
Subject: Re: Linux For Mac
|
|
Date: 13 Oct 1994 05:34:35 GMT
|
|
|
|
Well, just to throw my two cents into this thread...
|
|
I just purchased a PowerMac 7100/66 for my brother this last weekend, and boy
|
|
was that thing fast, and _that_ was while running at least 3/4 of its software
|
|
emulated from 68k code
|
|
|
|
I would LOVE to have an asskicking os like linux running on this thing, rather
|
|
than system 7, especially now that i have to pay for updates to the os (i love
|
|
macs look-and-feel of software, but i've grown to loathe the actual os itself
|
|
over the last year or so, since my exposure to linux :-)
|
|
|
|
so here's hoping the guys working on the port can get as much info as needed
|
|
and that apple opens up and gives them what they need to know!
|
|
--
|
|
Hillel Sims ----- simsh@rpi.edu ----- Rensselaer Polytechnic Institute
|
|
Howard Stern for Pope!
|
|
"Is rot13 rotated 13 forward or backward?"
|
|
--Anonymous
|
|
|
|
------------------------------
|
|
|
|
From: mlord@bnr.ca (Mark Lord)
|
|
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
|
|
Date: 13 Oct 1994 03:30:50 GMT
|
|
|
|
In article <37fcvm$9pb@clam.rutgers.edu> gnielsen@clam.rutgers.edu writes:
|
|
<Hello,
|
|
<
|
|
< Not that I am complaining or anything. I just wanted to state that
|
|
<I had a drop in transfer rate on my FTP transfers while using hdparm.
|
|
<I am using 1.1.52 and running a SLIP line on a 14.4 modem. Normally I
|
|
<get about 1.4 K/sec. But while running it with hdparm -m 32 the
|
|
<ftp transfer stopped for a few seconds after each disk write. After
|
|
<I set the hdparm -m0 then the ftp ran fine again. Any explainations?
|
|
|
|
Sure. Your serial port probably does not have a 16550A uart, right?
|
|
|
|
By default, the linux hard disk driver performs much of it's I/O with
|
|
all other interrupts masked. When you use -m32, it is performing up to
|
|
32 times as much I/O per interrupt, with interrupts masked correspondingly
|
|
longer. Odds are good that during this I/O, your serial port is dropping
|
|
characters, causing FTP to timeout and retry.
|
|
|
|
To negate this effect, the -u1 (hdparm) option can be used, though on
|
|
some systems this causes trouble. Backup first!
|
|
--
|
|
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
|
|
|
|
------------------------------
|
|
|
|
From: mlord@bnr.ca (Mark Lord)
|
|
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
|
|
Date: 13 Oct 1994 03:35:04 GMT
|
|
|
|
In article <37fkq6$nfa@vixen.cso.uiuc.edu> roth@ux4.cso.uiuc.edu writes:
|
|
<
|
|
<I am not sure that hdparm is as good as it claims to be.
|
|
|
|
Hmmm. I don't believe it claims to be good in all cases at all.
|
|
Better re-read the man page, paying particular attention to the paragraphs
|
|
for the -m setting, which state (among other things):
|
|
|
|
On many systems, it also provides increased data
|
|
throughput of anywhere from 5% to 50%. Some
|
|
drives, however (most noteably the WD Caviar
|
|
series), seem to run slower with multiple mode
|
|
enabled. Your mileage may vary.
|
|
|
|
<I was fooling around with it, and my results were not encouraging.
|
|
|
|
See last line above.
|
|
|
|
<I tried setting my multcount to 16, which is the max value for my disk
|
|
<according the the kernel at bootup. I also tried 2, 4, and 8. My
|
|
<benchmark was the suggested "dd if=/dev/hda of=/dev/null count=32768
|
|
<bs=1024". When the multcount was set to anything but 0, system and
|
|
<user time went down, but wall-clock time went up. This was under
|
|
<kernels 1.1.51 and 1.1.52.
|
|
|
|
Use the built-in -t option for more consistent timings.
|
|
As noted in the man page, some drives are slower with multiple-mode
|
|
enabled, and many are faster. Looks like yours are slower.
|
|
--
|
|
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: Thu, 13 Oct 1994 04:55:54 GMT
|
|
|
|
In article <hpa.4aca0000.Swedes.have.more.fun@ahab.eecs.nwu.edu>,
|
|
H. Peter Anvin <hpa@nwu.edu> wrote:
|
|
>Followup to: <CxKAz1.JIC@news.cern.ch>
|
|
>By author: danpop@cernapo.cern.ch (Dan Pop)
|
|
>In newsgroup: comp.os.linux.development
|
|
>>
|
|
>> The C compilers on AIX, Solaris, SunOS, IRIX, HPUX and Domain/OS don't
|
|
>> support it. If they would, they wouldn't be C compilers anymore.
|
|
>>
|
|
>
|
|
>Most can be coaxed into doing so (IRIX: -acpp -Wp,-B). However, I
|
|
>notice all the ones above are UNIX... I think this is more common on
|
|
>non-UNIX platforms.
|
|
>
|
|
>>
|
|
>> They're valid C code, nevertheless. A C compiler which fails to translate
|
|
>> correctly valid C code is broken by definition.
|
|
>>
|
|
>
|
|
>True, but there is no law against extensions (which may conflict with
|
|
>obscure standard constructs) if you can turn them off.
|
|
>
|
|
|
|
Sure. There's no law against a c compielr compiling Modula2 with the
|
|
right flags, as long as it DOESN'T claim its an ANSI c compierl in that mode.
|
|
I think (correct me if I'm wrong) that this thread of conversation spun
|
|
off someone claiming that // was being considered for inclusion in an
|
|
ANSI revision-- and my responding such was highly unlikely since it woudl
|
|
break previously legal syntax.
|
|
|
|
As a flagged option, sure, go ahead and put it in your compiler. But
|
|
don't expect ANSI portability if you use it. Myself, when I want to
|
|
write code like that I use c++, where its already legal.
|
|
|
|
Jeff Kesselman
|
|
|
|
------------------------------
|
|
|
|
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
|
|
Subject: Re: Kernel 1.1.53 - no BOOM
|
|
Date: 13 Oct 1994 08:00:35 GMT
|
|
|
|
luyer@tartarus.uwa.edu.au (David Luyer) writes:
|
|
|
|
>Steven M. Doyle (wcreator@kaiwan.com) wrote:
|
|
>: In <1994Oct11.171749.2385@ka4ybr.com> mah@ka4ybr.com (Mark A. Horton KA4YBR)
|
|
>: writes:
|
|
>: >Console: colour EGA+ 132x44, 24 virtual consoles
|
|
>: >Serial driver version 4.00 with no serial options enabled
|
|
>: >tty00 at 0x03f8 (irq = 4) is a 16550A
|
|
>: >tty01 at 0x02f8 (irq = 3) is a 16550A
|
|
>: >tty02 at 0x03e8 (irq = 4) is a 16550A
|
|
>: >tty03 at 0x02e8 (irq = 3) is a 16550A
|
|
...
|
|
>The easiest (believe me, it is the simplest modification I've ever done
|
|
>to hardware) thing to do is re-wire the serial boards - usually this
|
|
>requires the addition of one wire and the removal of one jumper
|
|
>connector, sometimes you also have to cut a track.
|
|
|
|
>After doing this, you have to modify the kernel to use AUTO_IRQ,
|
|
>CONFIG_AUTO_IRQ or change the flags on the first four com ports,
|
|
>depending on kernel version.
|
|
|
|
Or, if your kernel is not pre-antique (considerably older than 1.0),
|
|
just use the setserial program to set the interrupts.
|
|
--
|
|
David Kastrup dak@pool.informatik.rwth-aachen.de
|
|
Tel: +49-241-72419 Fax: +49-241-79502
|
|
Goethestr. 20, D-52064 Aachen
|
|
--
|
|
David Kastrup dak@pool.informatik.rwth-aachen.de
|
|
Tel: +49-241-72419 Fax: +49-241-79502
|
|
Goethestr. 20, D-52064 Aachen
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Tue, 11 Oct 1994 09:03:50 GMT
|
|
|
|
In <37c8hk$ekl@ncar.ucar.edu> kuehn@citadel.scd.ucar.edu (Jeff Kuehn) writes:
|
|
|
|
>In his last kernel patch announcement, Linus requested information on
|
|
>performance of the recent kernels. I took it upon myself to gather a few
|
|
>hard numbers in as much as this is possible. (Lies, Damned Lies, and
|
|
>Benchmarks!) While I consider myself far too skeptical to call Byte
|
|
>Magazine's UNIX Benchmark a "good" benchmark, it seemed like a reasonable
|
|
>place to start for several reasons.
|
|
|
|
I have noticed ever since 0.98pl4 that I started with, that performance
|
|
has been dropping. The only exception is the disk performance, which
|
|
increased because of the clustering.
|
|
|
|
In the early days, starting something in X windows was snappy. Now I
|
|
get a noticable delay. I still have a copy of Byte-3.1 results of
|
|
0.98pl4 and indeed it shows a decrease since then. At that time, my
|
|
system yielded 3.0 and on 1.1.33 it had 2.3
|
|
(not as much decrease as it seems to be. however, I should also note
|
|
that my fist reaction when running Linux was "boy this is fast", as my
|
|
only frame of reference at that time was SCO XENIX and SCO UNIX running
|
|
on comparable hardware. over time, one gets used to the speed and wonders
|
|
how it could ever be experienced as "fast" :-)
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: vir@45acp.slip.com (Vir Lagua)
|
|
Subject: Re: Xircom PCMCIA ethernet support?
|
|
Date: 11 Oct 1994 16:17:15 GMT
|
|
|
|
Russell Nelson (nelson@crynwr.crynwr.com) wrote:
|
|
: In article <36nuon$74f@senator-bedfellow.MIT.EDU> dthumim@ATHENA.MIT.EDU (Daniel J Thumim) writes:
|
|
|
|
: Is there any chance of getting support for a Xircom CE10 PCMCIA
|
|
: ethernet adapter? I heard of problems with the parallel port
|
|
: adapters, they don't give out the programming info. Is this true
|
|
: of the PCMCIA adapter too?
|
|
|
|
STUFF DELETED
|
|
|
|
: Why bother? They've been unhelpful for years. I've spoken to the
|
|
: President of the company, and he has a specific philosophical problem
|
|
: with free software. That's his right, but it's our right to ignore
|
|
: his company's products.
|
|
|
|
|
|
How about support for the 3COM-3c589 PCMCIA Card?
|
|
|
|
|
|
--
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||||||CUL, vir |||| vir@slip.com |||| vir@world.std.com ||||||||||||||
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
Network and InterNetwork Solutions + There is only one Amendment
|
|
yet another computer consultant (yacc) + that ensures all 10. The 2nd.
|
|
|
|
------------------------------
|
|
|
|
From: bruce@mdavcr.mda.ca (Bruce Thompson)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: 12 Oct 94 09:54:46 GMT
|
|
|
|
H. Peter Anvin (hpa@ahab.eecs.nwu.edu) wrote:
|
|
: Followup to: <jeffpkCxJ93y.Ku1@netcom.com>
|
|
: By author: jeffpk@netcom.com (Jeff Kesselman)
|
|
: In newsgroup: comp.os.linux.development
|
|
: >
|
|
: > This is doubtful. The problem is that making this a 'feature' of ANSI c
|
|
: > will all of a sudden make previously syntacticly correct code now fail to
|
|
: > compile or, worse, compile with a different symantic meaning. This woudl
|
|
: > be DISASTEROUS to the attempt to standardize C.
|
|
: >
|
|
|
|
: It is *already* put into quite a number of compilers (making it a
|
|
: portability issue already), and anyone writing code that uses that
|
|
: type of constructs should be shot anyway. It is true there are such
|
|
: cases, but they are throuroughly and completely artificial.
|
|
|
|
Sorry, but simply because other compiler vendors want to break the
|
|
ANSI standard is not a sufficient reason IMHO.
|
|
|
|
The example cited most often,
|
|
|
|
i = 4 //* comment */ 2;
|
|
|
|
is of dubious merit from a _style_ point of view. HOWEVER, it _is_
|
|
legal according to the ANSI standard. I would argue then that what
|
|
we're discussing is a change to the standard, not a simply a change to
|
|
a particular compiler. As such, it's my opinion that the change should
|
|
be evaluated in that light.
|
|
|
|
IMHO it still strikes me as a needless modification to the C standard
|
|
since in most cases C++ will look and feel enough like ANSI C that
|
|
simply using C++ should suffice.
|
|
|
|
As a postscript, I find the notion of supporting multiple comment
|
|
syntaxes as unusual in the extreme. I know of no other language than
|
|
C++ which has multiple comment syntaxes. I have yet to encounter a
|
|
compelling reason for it besides backward-compatability which isn't
|
|
_that_ compelling for me.
|
|
|
|
Cheers,
|
|
Bruce.
|
|
--
|
|
Bruce Thompson, B.Sc. | "A great many people think they are
|
|
Software Engineer | thinking when they are merely
|
|
MacDonald Dettwiler, | rearranging their prejudices."
|
|
13800 Commerce Parkway, | -- William James
|
|
Richmond, BC |
|
|
(604) 278-3411 | Usual disclaimers apply
|
|
NAPRA #473 |
|
|
|
|
------------------------------
|
|
|
|
From: teffta@erie.ge.com (Andrew R. Tefft)
|
|
Subject: Re: Improving SLIP latency under Linux
|
|
Reply-To: teffta@erie.ge.com
|
|
Date: Tue, 11 Oct 1994 12:42:12 GMT
|
|
|
|
In article <377ijq$96@ulowell.uml.edu>, jrichard@cs.uml.edu (John Richardson) writes:
|
|
>If your slip server has a queue of ftp packets to send you, it should
|
|
>be thowing your interactive packet at the front of the queue.
|
|
>Or if you are sending and you have a full buffer of interactive
|
|
>packets, your interactive packet should go to the front of your
|
|
>queue.
|
|
|
|
I just wanted to mention that Morningstar PPP has had a queueing
|
|
priority scheme for some time, and from what the documentation says,
|
|
it treats ftp as *interactive*, same as a login session. So people
|
|
have some different ideas on this.
|
|
|
|
--
|
|
|
|
Andy Tefft - new, expanded .sig - teffta@erie.ge.com
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: bart@dunedin.es.co.nz (Bart Kindt)
|
|
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
|
|
Date: Fri, 14 Oct 1994 05:27:54 GMT
|
|
|
|
In article <3776lk$lb7@ns.oar.net> root@jaguar.tigerden.com (System Administrator) writes:
|
|
|
|
>Steve Kneizys (STEVO@acad.ursinus.edu) wrote:
|
|
>: Yuri Trifanov (yuri@shimari.cmf.nrl.navy.mil) wrote:
|
|
|
|
>: : > We are using SLIP! And the problems we see are not *after* a connection
|
|
>: : > is successfully opened, it is one of the system *refusing* connections
|
|
>: : > (apparently). Nearly all functions handled by inetd seem affected:
|
|
>: : > telnet logins, rlogins, ftp attempts, smail connections, attemps to do
|
|
>: : > zone transfers from named by our provider's router, you name it. Things
|
|
>: : > work fine *most* of the time, but the login problems are the most
|
|
>: : > persistant and visible. In those cases, the system log *usually* shows
|
|
>: : > 'connect from...' but the user never gets a prompt, or never gets a
|
|
>: : > password prompt after entering username. Netd entries in the log are
|
|
>: : > 'connection refused' mostly.
|
|
|
|
>: : you could be having problems with the resolver and tcpd, which comes
|
|
>: : turned on by default in at least some distributions. if it can't
|
|
>: : resolve the inaddr of the connecting host it will refuse the
|
|
>: : connection.
|
|
|
|
>We've done extensive work with the nameserver setup. I don't think this
|
|
>is the cause.. more a symptom.
|
|
|
|
>: I see the freeze and I only use Etherlink III 3c579 cards on the same
|
|
>: wire as 3 VAXes, including our domain's name resolver. Telnets from
|
|
>: the domain resolver VAX to the Linux freeze, as does FTP, finger,
|
|
>: smtp, rlogin.
|
|
|
|
>I've seen it when accessing the main machine from both the local ethernet
|
|
>connecting about 8 machines, and when accessing by telnet/ftp/etc through
|
|
>the SLIP link from our service provider. This tends to rule out the SLIP
|
|
>link or external network problems. Everything *seems* to be pointing to
|
|
>the low level daemons and/or kernel.
|
|
|
|
>--- George
|
|
|
|
In line with all this; Where can I read what is actually done with any new
|
|
Kernel version? I just upgraded to 1.1.52, but I don't know what has been done
|
|
to this kernel; was there any TCP / SLIP / PPP development which may solve the
|
|
TCP problems we are having?
|
|
|
|
|
|
====================================================================================
|
|
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
|
|
====================================================================================
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
|
|
From: bart@dunedin.es.co.nz (Bart Kindt)
|
|
Subject: Re: Serious Bug In The Networking Code
|
|
Date: Fri, 14 Oct 1994 05:39:23 GMT
|
|
|
|
In article <dtran.395.2E997F32@emelnitz.ucla.edu> dtran@emelnitz.ucla.edu (Daniel Tran) writes:
|
|
>Xref: otago.ac.nz comp.os.linux.development:12491 comp.os.linux.admin:11970 comp.os.linux.help:43483
|
|
>Path: otago.ac.nz!canterbury.ac.nz!waikato!ames!ncar!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!news.mic.ucla.edu!emelnitz.ucla.edu!dtran
|
|
>From: dtran@emelnitz.ucla.edu (Daniel Tran)
|
|
>Newsgroups: comp.os.linux.development,comp.os.linux.admin,comp.os.linux.help
|
|
>Subject: Re: Serious Bug In The Networking Code
|
|
>Date: Mon, 10 Oct 1994 17:51:46 GMT
|
|
>Organization: UCLA Arts - Theater/Film & TV Network Support
|
|
>Lines: 17
|
|
>Message-ID: <dtran.395.2E997F32@emelnitz.ucla.edu>
|
|
>References: <KETIL.94Oct9183323@lomvi.ii.uib.no> <37a37b$a2d@Venus.mcs.com>
|
|
>NNTP-Posting-Host: 128.97.175.99
|
|
>X-Newsreader: Trumpet for Windows [Version 1.0 Rev A]
|
|
|
|
|
|
>In article <37a37b$a2d@Venus.mcs.com> munster@MCS.COM (Jerry Ablan) writes:
|
|
>>: There appears to be a serious bug in some of the networking code
|
|
>>: supplied with linux/slackware, that causes the computer to get
|
|
>>: 'network unreachable' after approximately 3 minutes of perfect
|
|
>>: functioning. I have no idea what the problem might be, and if
|
|
>>: somebody tell me where to look, I can try to figure out what versions
|
|
>>: my drivers etc. are. Here are the configurations I ve gotten this
|
|
>>: problem with:
|
|
|
|
>>I've noticed that this occurs when you run routed. Do not run routed and see
|
|
>>if it still happens.
|
|
|
|
>>-- Jerry
|
|
|
|
>Would running running routed with -q parameter help.
|
|
|
|
>Daniel Tran - dtran@emelnitz.ucla.edu
|
|
|
|
Routed overwrites the Kernel 1.0.xx memory tables. Eventually it will crash
|
|
the system, depending how big the routing table becomes. I my case, within a
|
|
few minutes. Routed does not work properly anyway (the Linux version). The
|
|
only way out is Gated, which I now use all the time... BUT it cannot be used
|
|
with the 1.0.xx kernels!
|
|
So, if you MUST use a routed (gated) program, you also *must* use the new
|
|
kernels. I am now using 1.1.52, which works fine as a multi-line SLIP dial-in
|
|
server.
|
|
|
|
|
|
====================================================================================
|
|
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
|
|
====================================================================================
|
|
|
|
------------------------------
|
|
|
|
From: kausch@slsv59t.lts.alcatel.sel.de (Holger Kausch US/ESC 60/3/135 #3630)
|
|
Subject: Need more than 32 mount's
|
|
Date: 13 Oct 1994 09:40:01 GMT
|
|
|
|
Hello,
|
|
|
|
I am running LINUX (kernel release 1.0) in a 'big' SUN network, using
|
|
the automounter 'amd' and YP.
|
|
|
|
The configuration works very stable, and the integration into the network
|
|
you can call 'perfect', except:
|
|
|
|
In some cases the limitation of maximal 32 mounts inside
|
|
LINUX is a blocking problem. Because of the use of 'amd'
|
|
the problem is temporary, but shell's hang, if you want
|
|
to move to a directory, which can not be mounted if the
|
|
limitation is reached.
|
|
|
|
I was searching inside the sources, but was'nt able to redefine the
|
|
limit to an higher value (like 128).
|
|
|
|
I hope, someone out there can help me.
|
|
|
|
Thank you!
|
|
|
|
Holger
|
|
====================================================================
|
|
kausch@lts.sel.alcatel.de
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: mkrause@TechFak.Uni-Bielefeld.DE (Michael Krause)
|
|
Subject: Re: insmod drv_hello.o gives "___moddi3 undefined"
|
|
Date: Thu, 13 Oct 1994 08:35:22 GMT
|
|
|
|
Erik E. Rantapaa (rantapaa@s6.math.umn.edu) wrote:
|
|
: I am trying to use the module utilities with the following set up:
|
|
|
|
: kernel version: 1.1.51
|
|
: cc version: 2.5.8
|
|
: modules.tar.gz: dated June 27, 1994
|
|
|
|
: When attempting to load the sample module dvr_hello.o, however,
|
|
: I get the following error:
|
|
|
|
: ___moddi3 undefined
|
|
|
|
: Is there something special I need to do when compiling module
|
|
: object files?
|
|
|
|
One of the datatypes involved in the modulo operation (%) is of type
|
|
long long of you look at the includes. As you only want to test the modules,
|
|
you can cast each of the operands to int. Then __moddi3 is no longer needed.
|
|
|
|
Ciao,
|
|
Michael
|
|
|
|
--
|
|
- Michael Krause
|
|
- E-Mail: mkrause@techfak.uni-bielefeld.de
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: Wed, 12 Oct 1994 17:43:31 GMT
|
|
|
|
In article <hpa.3e7e0000.Swedes.have.more.fun@ahab.eecs.nwu.edu>,
|
|
H. Peter Anvin <hpa@nwu.edu> wrote:
|
|
>Followup to: <jeffpkCxJ93y.Ku1@netcom.com>
|
|
>By author: jeffpk@netcom.com (Jeff Kesselman)
|
|
>In newsgroup: comp.os.linux.development
|
|
>>
|
|
>> This is doubtful. The problem is that making this a 'feature' of ANSI c
|
|
>> will all of a sudden make previously syntacticly correct code now fail to
|
|
>> compile or, worse, compile with a different symantic meaning. This woudl
|
|
>> be DISASTEROUS to the attempt to standardize C.
|
|
>>
|
|
>
|
|
>It is *already* put into quite a number of compilers (making it a
|
|
>portability issue already), and anyone writing code that uses that
|
|
>type of constructs should be shot anyway. It is true there are such
|
|
>cases, but they are throuroughly and completely artificial.
|
|
>
|
|
|
|
Thsi is a half-truth, it is true but incomplete. It IS in many compilers
|
|
BUT goes away if you set s 'strict-ANSI' flag. Thsi is as it shoudl be
|
|
for the reasons I already specified. Making it a part of ANSI C would
|
|
invalidate previosuly legal syntax-- a very very bad idea.
|
|
|
|
JK
|
|
|
|
------------------------------
|
|
|
|
From: belanger@info.polymtl.ca (Pierre Belanger)
|
|
Subject: Re: Unable to find XF86-3.1-lib.tar.gz with correct sum.
|
|
Date: 9 Oct 1994 21:43:15 GMT
|
|
|
|
Kevin Ruland (kevin@rodin.wustl.edu) wrote:
|
|
|
|
: I've searched the world over to find the X11R6 libs and can't find one
|
|
: with the correct checksum. gunzip even pukes on it. It seems okay
|
|
: up to ./lib/libX11.so.6
|
|
|
|
: I've tried the following sites:
|
|
|
|
: xfree86.cdrom.com
|
|
Either you don't ftp with "bin" option 'enable' or you must do something
|
|
wrong. I HAD NO PROBLEM AT ALL.
|
|
|
|
: Were's the good one.
|
|
They must be all god...
|
|
|
|
Pierre B,
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: Wed, 12 Oct 1994 17:47:41 GMT
|
|
|
|
In article <hpa.45d30000.Heja.Sverige@ahab.eecs.nwu.edu>,
|
|
H. Peter Anvin <hpa@nwu.edu> wrote:
|
|
>Followup to: <6453@sparky.mdavcr.mda.ca>
|
|
>By author: bruce@mdavcr.mda.ca (Bruce Thompson)
|
|
>In newsgroup: comp.os.linux.development
|
|
>>
|
|
>> is of dubious merit from a _style_ point of view. HOWEVER, it _is_
|
|
>> legal according to the ANSI standard. I would argue then that what
|
|
>> we're discussing is a change to the standard, not a simply a change to
|
|
>> a particular compiler. As such, it's my opinion that the change should
|
|
>> be evaluated in that light.
|
|
>>
|
|
>> IMHO it still strikes me as a needless modification to the C standard
|
|
>> since in most cases C++ will look and feel enough like ANSI C that
|
|
>> simply using C++ should suffice.
|
|
>>
|
|
>> As a postscript, I find the notion of supporting multiple comment
|
|
>> syntaxes as unusual in the extreme. I know of no other language than
|
|
>> C++ which has multiple comment syntaxes. I have yet to encounter a
|
|
>> compelling reason for it besides backward-compatability which isn't
|
|
>> _that_ compelling for me.
|
|
>>
|
|
>
|
|
>C++ added another comment convention for the reason that comments
|
|
>terminated in newline tend to be a *lot* more convenient to use than
|
|
>C-style block comments. (You may disagree, but I am fairly certain
|
|
>you are in minority). /* ... */ is supported as backward
|
|
>compatibility, but you will be hard-pressed to find a C++ programmer
|
|
>who uses them more than once in a blue moon.
|
|
>
|
|
|
|
Guys,
|
|
Pardon my intrusion but I think you are both sayign the same thing:)
|
|
And as a c++ programmer I agreee with you. /* */ causes alot of
|
|
problems (primary in this is its non-nesting nature. Yucko!). I ALWAYS
|
|
use // in new c++ programs. I do find the c++ compiler accepting /* */
|
|
handy in lazy sort of way, though, when i am porting straight ansi c
|
|
code. (Yes, I could change the comments myself, or write a little
|
|
processor to do it, but as I said, I'm lazy :) )
|
|
|
|
JK
|
|
|
|
------------------------------
|
|
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: A badly missed feature in gcc
|
|
Date: Wed, 12 Oct 1994 17:49:54 GMT
|
|
|
|
In article <ARMB.94Oct11113003@shiva.setanta.demon.co.uk>,
|
|
Alan Braggins <armb@setanta.demon.co.uk> wrote:
|
|
>In article <jeffpkCxEDKF.LA9@netcom.com> jeffpk@netcom.com (Jeff Kesselman) writes:
|
|
> >This would break perfectly correct C code, like
|
|
> >
|
|
> > a = b//* Comment here */ c;
|
|
> >--
|
|
>
|
|
> And this is the cannonical case of why c++ is NOT a true super-set of
|
|
> ANSI c. (Thanks, I'm going to save the exampel for the next time I have
|
|
> THAT argument.)
|
|
>
|
|
>That "int function();" declares a function with no arguments in C++
|
|
>and an unknown number of arguments in C is far more common.
|
|
>So are variables called "class" or other new reserved words.
|
|
>--
|
|
>Alan Braggins armb@setanta.demon.co.uk abraggins@cix.compulink.co.uk
|
|
>"Any technology distinguishable from magic is insufficiently advanced"
|
|
>
|
|
|
|
Very true, he said, quickly jotting notes for the next inevitble
|
|
super-set argument.
|
|
|
|
You'ld be suprised, though, how many people DON'T realize that c++ is not
|
|
just extended ANSI C....
|
|
|
|
JK
|
|
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|