Linux-Development-Sys Digest #298, Volume #8 Fri, 24 Nov 00 19:13:15 EST
Contents:
Re: extend the blocksize (Nick Maclaren)
Re: Block number numbering scheme (Josef Moellers)
Re: Triton problem with 2.2.X... (was Re: slow connection?)
Re: C Autoresponder For Linux (Kaz Kylheku)
Re: via kt133 chipset and agpgart ("Tomasz Jerzykowski")
question on rt_sigreturn (yk)
Re: Software RAID ("Peter T. Breuer")
Re: Linux on mainframe ([EMAIL PROTECTED])
rdtsc() timestamps synchronized between SMP CPU's? (Kaelin Colclasure)
Re: Linux on mainframe ("William Alexander Segraves")
Re: Triton problem with 2.2.X... (was Re: slow connection?) ("JB")
Re: No swap activity. (Nix)
linux software-interupt open file? (Daniel Schroeter)
XFree 4 crashes kernel 2.4.0-test5 (Otto Wyss)
Modconf doesn't find any modules (kernel 2.4.0-test10) (Otto Wyss)
Re: Stack access speed (Nix)
Re: Patch for g++ and glibc-2.2 anyone? (Nix)
Re: Message queues: real world applications (Nix)
Re: Patch for g++ and glibc-2.2 anyone? (An additional query) (Nix)
Re: linux API (Nix)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: extend the blocksize
Date: 24 Nov 2000 14:15:12 GMT
In article <[EMAIL PROTECTED]>, root <[EMAIL PROTECTED]> writes:
|> Most current file systems use only about 4096 bytes blocksize. However,
|> as I am implementing a video server, I have to extend the blocksize up
|> to around 512KB. Are there any ways to achieve that ???
You don't do it that way. You do it the same way that we did it on
1960s and 1970s mainframes. The APPLICATION interface may ask for
512 KB, but that gets broken down at a lower level. If you made a
Unix filing system with 512 KB blocks, you would create havoc in
all sorts of ways.
You start off multiple reads, check one (i.e. wait until the data
has come in and check that it has), start off the next read into
that buffer, and then process the data. Under MVT, I got 90% of
hardware capacity from unmodified Fortran using double buffered
BSAM with chained scheduling. It was possible to do even better.
However, how much of this can be done effectively under Linux
depends on the detailed design of the disk interface. I don't
know that. What I do know is that there is no point in increasing
the block size above the track size of the disk, and often little
point in increasing it to even that.
Josef Moellers is also correct about the need to avoid head
movement but, for optimal performance, you also need to tune the
block size to the rotational timings to avoid missing a block as
it spins by. I could once have told you how to do that on an
IBM 3330, but that doesn't help with modern disks ....
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Re: Block number numbering scheme
Date: Fri, 24 Nov 2000 15:37:45 +0100
Sean wrote:
> =
> What is the numbering scheme of the block number of a SCSI hard disk?
> i.e. what is the relationship between the block number and the track,
> zone of the hard disk ??
Absolutely irrelevant.
With modern SCSI disks, you cannot correlate SCSI block numbers with CHS
values any more. You can store more data at the outer tracks than you
can at the inner tracks. Modern disks do that and you have little to no
chance of infering cylinder number from logical block address.
There is a bit (PMI) in the READ CAPACITY command which "indicates that
the returned logical block address and block length in bytes are that of
the logical block address after which a substantial delay in data
transfer will be encountered." I once used that to build a map of a
disk. It failed on some other disk model.
Due to automatic spare assignment the relation that a difference in
block numbers infers some relative location on the disk may not even be
true.
Since some vintage software still might want to talk about CHS values,
some mapping has been invented which constructs CHS values from LBA
values, but due to the technical advances, these mappings usually assume
the maximum number of sectors per track possible (63) and the maximum
number of heads possible (255), in order to be able to access as much of
the disk as possible given the limitations in the number of cylinders
(1024).
HTH,
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware
Subject: Re: Triton problem with 2.2.X... (was Re: slow connection?)
Date: 24 Nov 2000 15:00:13 GMT
In article <Pine.GSO.4.21.0011221739390.25237-100000@acms23>,
"Guennadi V. Liakhovetski" <[EMAIL PROTECTED]> writes:
>
> PIIX: IDE controller on PCI bus 00 dev 38
> PIIX: not 100% native mode: will probe irqs later
> PIIX: neither IDE port enabled (BIOS)
>
I would like the explaination too. However it is at least somewhat
bogus in that I get this message when the bios clearly thinks the ide
ports are enabled. Common consumer os will boot too.
--
Recreational Calculus - Just For Fun!
P.S. "From" header is bogus, use below email address.
--
Chris Wagner
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: C Autoresponder For Linux
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Nov 2000 15:30:20 GMT
On Fri, 24 Nov 2000 20:25:24 +1100, Adrian <[EMAIL PROTECTED]> wrote:
>Hi All,
>
>Im looking for some code to get started on making a custom e-mail auto
>responder. Realy need some help or something to start me off.
Take a look at procmail.
> If anyone
>has some code, links or could give me a sample that would allow me to
>manipulate the mail in the mail server etc that would be cool.
Uh, what mail server?
------------------------------
From: "Tomasz Jerzykowski" <[EMAIL PROTECTED]>
Subject: Re: via kt133 chipset and agpgart
Date: Fri, 24 Nov 2000 17:15:56 +0100
"Stefan Boresch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> I am attempting to get the agpgart module to load on a machine with
> the via kt133 chipset and an Athlon Thunderbird processor. The kernel
> is RH's 2.2.16 (with the ext3 patch); unfortunately, I am not having
> very much luck. (The point of the exercise is to use the utah-glx mga
> module efficiently; I guess the same would apply if I were to try
> XFree 4.x?)
>
> This is the output from /sbin/modprobe agpgart on a RH 6.2 machine
>
> /lib/modules/2.2.16-3.ext3/misc/agpgart.o: init_module: Device or resource
busy
> Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters
> /lib/modules/2.2.16-3.ext3/misc/agpgart.o: insmod
/lib/modules/2.2.16-3.ext3/misc/agpgart.o failed
> /lib/modules/2.2.16-3.ext3/misc/agpgart.o: insmod agpgart failed
>
> and here the corresponding lines from the syslog:
>
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 203M
> agpgart: Unsupported Via chipset, you might want to try
agp_try_unsupported=1.
> agpgart: no supported devices found.
>
> I don't quite understand what the agp_try_unsupported=1 line is
> supposed to mean. I guess the problem is that the chipset isn't
> supported. Does anyone know whether there are improvements in 2.2.17/18
> or in the 2.4.0-test series? I have been rather unsuccessful trying
> to find detailed info on agpgart as far as what is supported etc.
>
> Anyways, maybe someone has had more luck or some ideas -- tia,
>
> Stefan
Lemme describe my experiences. I installed RH7.0 and then tried to install
Nvidia drivers.
The kernel module couldn't load, though, showing similar messages. Then I
compiled
kernel 2.4pre10, recompiled the NVdriver module and now everything works
fine (I mean QIII works).
Maybe you should the same...
Tomek
------------------------------
From: yk <[EMAIL PROTECTED]>
Subject: question on rt_sigreturn
Date: 24 Nov 2000 16:22:26 GMT
Hi,
For some reasons, I need to have a program call the system call rt_sigre
turn, an
d measure the time spent in the call thanks to "strace -c".
The problem is I don't know how to have this particular call invoked. As
the cal
l is intended to be used from inside the kernel, I need to call anoter s
ystem ca
ll with the proper arguments, which could then invoke rt_sigreturn.
I use kernel 2.2.7.
Any hint would be much appreciated.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Article poste via Voila News - http://www.news.voila.fr
Le : Fri Nov 24 17:22:26 2000 depuis l'IP : lobster.antd.nist.gov [VIP 9401287]
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Software RAID
Date: Fri, 24 Nov 2000 17:20:14 +0100
In comp.os.linux.misc [EMAIL PROTECTED] wrote:
> and I would never inflict Software RAID on another machine as long as I
> live. Hardware RAID can hide a lot of things from the user, and be just
> about as 'fast' as an individual disk. Software RAID is going to slow
> your disk writes, well REALLY BAD.
Tut tut. No, it doesn't slow it appreciably, provided the disk writes
are on two separate controllers (ide). Yes, two commands will be
issued, instead of one, but the bandwidth taken by two disks going full
out is nothing like saturation.
> My advice would be spend the bucks for the Hardware, or DONT DO IT.
Soft raid has always worked fine for me. It used to be recommended for
swap, but the kernel long since learned to write in stripes on its own!
I use soft raid prinicipally in linear and raid 0 modes.
Peter
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Linux on mainframe
Date: Fri, 24 Nov 2000 11:46:19 -0500
Nilesh Patel wrote:
> It was able to open /proc/interrupts and other proc entries but was not
> able to read the file.
> What is the problem ?
As Phil already said, the ESA/390 architecture does not define IRQs so
we have some room for invention what we want to implement for
/proc/interrupts.
More info on
http://oss.software.ibm.com/developerworks/opensource/linux390/index.html
and on the mailing list http://www.marist.edu/linuxvm
Ciao, Boas.
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: rdtsc() timestamps synchronized between SMP CPU's?
Date: 24 Nov 2000 09:46:30 -0800
Are the 64-bit timestamps (well, clock cycle counts) that are accessed
via rdtsc() synchronized between CPU's on an SMP Linux system? That
is, supposing it were somehow possible to execute a rdtsc instruction
on each CPU in the system at the exact same instant, would they all
have the same value?
If not, would they be close enough to allow reasonably meaningful
comparisons between values from two different CPU's?
-- Kaelin
------------------------------
From: "William Alexander Segraves" <[EMAIL PROTECTED]>
Subject: Re: Linux on mainframe
Date: Fri, 24 Nov 2000 12:13:30 -0600
Reply-To: "William Alexander Segraves" <[EMAIL PROTECTED]>
Try a Google search, www.google.com, with "Linux IBM System 390".
Bill Segraves
Auburn, AL
"Nilesh Patel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> We have a Linux running on a Mainframe. It is 2.2.16.
> When I try to do cat /proc/interrupts it returns with bad file
> descriptor error.
> I also tried
> strace lsdev .
> It was able to open /proc/interrupts and other proc entries but was not
> able to read the file.
> What is the problem ?
> Is the code for proc entry for interrupts is buggy and others reporting
> the same problem buggy ?
> cat /proc/meminfo and some other entries show meaningful values.
>
> Nilesh
>
------------------------------
From: "JB" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware
Subject: Re: Triton problem with 2.2.X... (was Re: slow connection?)
Date: Fri, 24 Nov 2000 19:39:44 +0200
Reply-To: "JB" <[EMAIL PROTECTED]>
Check if your disk supports PIO4 with
Check your bios and switch off UDMA detection (Award 4.51 is broken - it
damages UDMA/66-100 disks, so linux wont detect them correctly)
ZB
<[EMAIL PROTECTED]> wrote in message news:8vlvpt$cno$[EMAIL PROTECTED]...
> In article <Pine.GSO.4.21.0011221739390.25237-100000@acms23>,
> "Guennadi V. Liakhovetski" <[EMAIL PROTECTED]> writes:
> >
> > PIIX: IDE controller on PCI bus 00 dev 38
> > PIIX: not 100% native mode: will probe irqs later
> > PIIX: neither IDE port enabled (BIOS)
> >
>
> I would like the explaination too. However it is at least somewhat
> bogus in that I get this message when the bios clearly thinks the ide
> ports are enabled. Common consumer os will boot too.
>
> --
> Recreational Calculus - Just For Fun!
> P.S. "From" header is bogus, use below email address.
> --
> Chris Wagner
> [EMAIL PROTECTED]
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: No swap activity.
Date: 24 Nov 2000 18:28:55 +0000
"Patrick \"The King of Finchland\" Finch" <[EMAIL PROTECTED]> writes:
> Each server started by apache takes up about 7 megs of memory, right now it
> starts 10 servers, and keeps 10 servers around (MinSpareServers) just in
> case, in the last day it hasn't hit the MaxClients setting of 120... Each
And some of those pages of memory are probably copy-on-writable from fork(),
and so are not actually taking up any physical resources until they are
modified.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Daniel Schroeter <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86
Subject: linux software-interupt open file?
Date: Fri, 24 Nov 2000 19:26:00 -0000
hi,
does anybody know a software interupt where i can open a file under
LINUX. is there somewhere a (sorted) list with interupts?
THNX
daniel
------------------------------
From: [EMAIL PROTECTED] (Otto Wyss)
Crossposted-To: linux.debian.devel
Subject: XFree 4 crashes kernel 2.4.0-test5
Date: Fri, 24 Nov 2000 22:57:39 +0100
I have upgraded to XFree86 version 4.0.1e on my computer (i386) running
kernel 2.4.0-test5 with framebuffer support. While XFree86 version 3.3.6
works smoothly, version 4 kills the whole system completly. Not even
with telnet from another computer could I get a connection.
Since the machine crashed that bad I had to use the reset button
(luckally my computer has still on). It wasn't very much fun to wait
until my 30GB disk was repaired, desparatly watching if nothing got
lost. Side note: Linux should be less prone to this kind of situation
since I haven't done much work before. Anyway I have no idea what went
wrong and where I have to look for any crash information. Is the any
utility which gathers any information at the next boot so I can send
them to the developers? I guess there are still some bugs in the kernel
framebuffer support. I tried both the FBdev and the ATI (Mach64) driver
with the same results.
Besides dexter is a really nice tool to setup XFree86 but couldn't it
read the previous config file? Hopefully it might read the old version
as well.
O. Wyss
------------------------------
From: [EMAIL PROTECTED] (Otto Wyss)
Crossposted-To: comp.os.linux.misc
Subject: Modconf doesn't find any modules (kernel 2.4.0-test10)
Date: Fri, 24 Nov 2000 22:57:42 +0100
I just installed kernel 2.4.0-test10 to see if my crashes of X v4 goes
away but modconf doesn't find any modules, even if I have modutils
2.3.19. Of course any of the others in Changes mentioned versions were
okay.
O. Wyss
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Stack access speed
Date: 24 Nov 2000 22:36:33 +0000
[EMAIL PROTECTED] writes:
> My name is Alan and I have a question that I need some help from all
> great minds in this forum.
... but this is a GCC question; you should probably query on
[EMAIL PROTECTED] or [EMAIL PROTECTED]
> Platform 2 = Pentium 600, Suse Linux 6.4 , GCC compiler 2.95.2 with
> optimize flag '-O2' set.
Good, that includes -fdefer-pops, which would speed up this sort of
thing a lot.
> void STATIC_RAM_TEST()
> {
> unsigned long bigArray1[500];
> unsigned long bigArray2[500];
> unsigned long bigArray3[500];
> unsigned long bigArray4[500];
> unsigned long bigArray5[500];
> unsigned long bigArray6[500];
> unsigned long bigArray7[500];
> unsigned long bigArray8[500];
> unsigned long i;
>
> for (i=0;i<500;i++) {
> bigArray2[i] = bigArray1[i] + i;
> bigArray3[i] = bigArray2[i] + bigArray1[i];
> bigArray4[i] = bigArray3[i] + bigArray2[i];
> bigArray5[i] = bigArray4[i] + bigArray3[i];
> bigArray6[i] = bigArray5[i] + bigArray4[i];
> bigArray7[i] = bigArray6[i] + bigArray5[i];
> bigArray8[i] = bigArray7[i] + bigArray6[i];
(This loop is adding things to uninitialized variables. Is this what you
intended? If they were made `static' the variables would be initialized
to zero...)
> }
> }
OK.
> The results is as follow:
> MS Visual C++ = ~900ms
> Linux with GCC = ~2000ms
Rather pathological. I get timings so low that they fall off the
resolution of time(1) (also with GCC-2.95.2, but on a busy P233).
Running it a thousand times gives me a userspace timing of 320ms. With
static arrays instead, the timings are three times what they were, at
820ms.
Not knowing *exactly* what your test is, I can't comment
reliably. Please send the preprocessed source (the output of `gcc -E')
and if possible the generated assembler (the output of `gcc -s
-fverbose-asm') for better information.
In any case, the generated assembler for the non-static case is
.text
.align 4
.globl STATIC_RAM_TEST
.type STATIC_RAM_TEST,@function
STATIC_RAM_TEST:
pushl %ebp
movl %esp,%ebp
subl $16044,%esp
leal -4000(%ebp),%eax
leal -12000(%ebp),%ecx
xorl %edx,%edx
pushl %edi
pushl %esi
pushl %ebx
movl $0,-16004(%ebp)
movl %eax,-16008(%ebp)
leal -2000(%ebp),%edi
movl %edi,-16012(%ebp)
leal -6000(%ebp),%eax
movl %eax,-16024(%ebp)
leal -8000(%ebp),%esi
leal -10000(%ebp),%ebx
leal -14000(%ebp),%edi
movl %edi,-16016(%ebp)
leal -16000(%ebp),%eax
movl %eax,-16020(%ebp)
.p2align 4,,7
.L6:
movl -16012(%ebp),%edi
movl -16004(%ebp),%eax
addl (%edi,%edx),%eax
movl -16008(%ebp),%edi
movl %eax,(%edi,%edx)
movl -16012(%ebp),%edi
addl (%edi,%edx),%eax
movl -16024(%ebp),%edi
movl %eax,(%edi,%edx)
movl -16008(%ebp),%edi
addl (%edi,%edx),%eax
movl %eax,(%esi,%edx)
movl -16024(%ebp),%edi
addl (%edi,%edx),%eax
movl %eax,(%ebx,%edx)
addl (%esi,%edx),%eax
movl %eax,(%ecx,%edx)
movl -16016(%ebp),%edi
addl (%ebx,%edx),%eax
movl %eax,(%edi,%edx)
movl -16020(%ebp),%edi
addl (%ecx,%edx),%eax
movl %eax,(%edi,%edx)
addl $4,%edx
incl -16004(%ebp)
cmpl $499,-16004(%ebp)
jbe .L6
popl %ebx
popl %esi
popl %edi
movl %ebp,%esp
popl %ebp
ret
which is only mildly suboptimal, with a good few too many movs; but it's
as good as 2.95.2 could be expected to produce. The assembler for the
static variant (where all the automatic local variables were declared
static, and no other changes were made) consists of a load of
common-block declarations for the arrays, then
.globl STATIC_RAM_TEST
.type STATIC_RAM_TEST,@function
STATIC_RAM_TEST:
pushl %ebp
movl %esp,%ebp
pushl %edi
pushl %esi
pushl %ebx
movl $0,i.11
movl $bigArray7.9,%edi
movl $bigArray8.10,%esi
.p2align 4,,7
.L6:
movl i.11,%ebx
leal 0(,%ebx,4),%ecx
movl bigArray1.3(%ecx),%eax
leal (%ebx,%eax),%edx
movl %edx,bigArray2.4(%ecx)
addl %edx,%eax
movl %eax,bigArray3.5(%ecx)
addl %eax,%edx
movl %edx,bigArray4.6(%ecx)
addl %edx,%eax
movl %eax,bigArray5.7(%ecx)
addl %eax,%edx
movl %edx,bigArray6.8(%ecx)
addl %edx,%eax
movl %eax,(%ecx,%edi)
addl %edx,%eax
movl %eax,(%ecx,%esi)
leal 1(%ebx),%eax
movl %eax,i.11
movl %eax,%ebx
cmpl $499,%ebx
jbe .L6
popl %ebx
popl %esi
popl %edi
movl %ebp,%esp
popl %ebp
ret
So the assembler *is* more efficient, but not damned much... ... and
the generated output is still slower, probably because of the heavy use
of BSS.
> MS Visual C++ = ~900ms
> Linux with GCC = ~950ms
Bizarre.
> We have isolated the problem to be "access speed to locally defined
> automatic arrays" i.e. stack access speed. Our arrays are typically 1
Which makes my very different results mildly interesting.
> ran some timing tests for simple manipulation of arrays cells and found
> that arrays defined as "automatic" ran significantly slower than arrays
> defined as "static". This has caused our program to crawl in certain
The opposite is the case here.
> instances when arrays are constantly being pushed and popped from the
> stack. Is there a way to configure Linux to be more efficient in this
> regard, or possibly we have missed something in GCC?
Nope; the option that would really help (-fdefer-pops) is already turned
on at -O2.
> Any help would be much appreciated here. Thank you for your time.
This is the sort of question that the gcc-help people could be much more
helpful than I at.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Patch for g++ and glibc-2.2 anyone?
Date: 24 Nov 2000 22:39:38 +0000
[EMAIL PROTECTED] (Mike Dowling) writes:
> Just installed glibc-2.2, and everything is fine except g++. The FAQ
> says there is a patch
> http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
>
> however, this site appears to be dead. Is there an alternative site?
The site is not dead. If you haven't got the patch yet, get it now;
otherwise, a piece of code was missed out from it, breaking libio's
stdio replacement code, so you should probably get it and reapply
anyway.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Message queues: real world applications
Date: 24 Nov 2000 22:47:37 +0000
[EMAIL PROTECTED] writes:
[message queues]
> They're not very widely used.
>
> I think the likely problem is that they are not "network-aware;" while
> named pipes lend themselves to extending on to sockets that can talk
> across networks as easily as on the local host, there is no MQ
> equivalent.
>
> A secondary issue may be that if they're not available across many
> Unixes, then people will be discouraged from using them in apps that
> they intend to be portable. Note that the BSDs don't offer SysV
> Message Queueing...
A tertiary problem is that they are thoroughly non-Unixlike; they have
their own namespace, and their own descriptors, which you *cannot
damned well select() on*. So if you've got a select loop in your app
then you essentially cannot use message queues in the same place.
Plus the horrible things are persistent, unlike every other fs object
in Unix; ipcs(8) and ipcrm(8) should never have been necessary.
This makes message queues almost totally useless. Like the other parts
of sysvipc, their APIs are so broken that they might as well never have
been implemented, IMNSHO.
(Thank goodness for the new mq_*() functions. Much more reasonable...
although, to be frank, a pipe is just as useful in most cases.)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Patch for g++ and glibc-2.2 anyone? (An additional query)
Date: 24 Nov 2000 22:40:37 +0000
[EMAIL PROTECTED] (Mike Dowling) writes:
> The two files that need patching we streambuf.h and parsestream.h in
> /usr/include/g++. That did not suffice, however. There are also files
> with the same names in the directory /usr/include/g++-3, and only once
> these were also patched did g++ work.
>
> Is there an explaination for this?
/usr/include/g++ is used by egcs-1.1.2 and older;
/usr/include/g++-3 is used by GCC-2.95.x.
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: linux API
Date: 24 Nov 2000 22:58:49 +0000
[EMAIL PROTECTED] (Alexander Viro) writes:
> BTW, since when does gcc include "stack protection", whatever it means?
Maybe this is a reference to Greg McGary's bounds checking code
(-fbounds-checking).
They're in current CVS GCC and will be in GCC-3.0. They've already found
a bunch of errors (in the fileutils, for instance).
The only downside of this bounds checking code is that they need *all*
libraries you link with to be recompiled, including the libc, as they
use fat pointers. (glibc-2.2 lets you build such a library already,
assuming you build it with a new enough GCC.)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
