Linux-Development-Sys Digest #765, Volume #8 Fri, 1 Jun 01 09:13:11 EDT
Contents:
Re: fast disk writes (Federico David Sacerdoti)
ARM dynamically linked executables ("Kevin Hirst")
Re: BSD signal (Juergen Heinzl)
Re: Getting CURRENT load average (Juha Laiho)
Re: how to force a core file dump ? ("J.O. Williams")
Re: fast disk writes (Alexander Viro)
Re: Problems with sources from MS Visual C++ ("D. Stimits")
Re: Device Driver Interrupts on SMP using kernel 2.4 (Charles Wilkins)
Patching the original RH (7.1) kernel (?) (Josef Molnar)
Re: how to force a core file dump ? (Villy Kruse)
kernel panic problem. help me ("Park Jung Kyu")
Re: thundering-herd vs wake-one (Gregory Bond)
Re: Patching the original RH (7.1) kernel (?) ("Nils O. Selåsdal")
Re: environment variable confusion ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Federico David Sacerdoti <[EMAIL PROTECTED]>
Subject: Re: fast disk writes
Date: Thu, 31 May 2001 13:40:33 -0700
The paper on FFS is
M. K. McKusick, Bill Joy, et al.
"A Fast File System for UNIX"
ACM Transactions on Computer Systems Vol 2 # 3
August 1984, pp 181-197
It's a good paper, very informative. It might be available online.
Dave
Alexander Viro wrote:
> In article <[EMAIL PROTECTED]>,
> cLIeNUX user <r@cLIeNUX.> wrote:
> >>Minix filesystem is a toy version of v7 fs with block bitmap added in the
> >>beginning of the disk. Ext2 consists of cylinder groups, each with its own
> >
> >A block bitmap. That's a rather striking family trait, don't you think?
>
> Not really. It's an obvious (and in case of minixfs - half-assed) fix for
> nightmarish block allocation stuff in v7.
>
> >"the main improvement introduced by FFS" being cylinder groups, yes?
>
> Cylinder groups, spreading the fs metadata over said groups, algorithms
> that maintain decent localty of references. That fixed the worst problems
> of v7 fs. Other fun stuff was support of long names (> 14 characters)
> and symlinks.
>
> v7 fs didn't scale and it had very bad fragmentation problems. When fs
> on your box is unable to use more than 2% of disk bandwidth - something
> is seriously rotten. The thing was OK for small disks. In 80s it became too
> bad for serious use.
>
> Minixfs was limited to 64Mb, BTW. _And_ it had all lovely problems with
> excessive disk seeks, too short names, etc. When size-related limits
> were raised the scalability problems had hit full-force. And since the
> solution was well-known (for ~10 years) and well-documented... <shrug>
> Why bother trying to modify minixfs/ext when you can implement a known
> good solution?
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Kevin Hirst" <[EMAIL PROTECTED]>
Subject: ARM dynamically linked executables
Date: Thu, 31 May 2001 16:45:03 -0400
To reply, my email is krh2n @ virginia.edu - remove the nospam.
Can anyone inform me as to how to produce dynamically linked executables for
ARM linux? I used what I considered to be the normal method for producing
such executables, i.e.
arm-linux-gcc filename -o executable -Xlinker -Bdynamic -L. -ldl -llib
and it produces no dynamic segment in the ELF binary. I have also tried
with and without the -ldl tag. I think it could be that when I cross
compiled gcc for ARM, it may be hard coded to produce static binaries. I
would appreciate tutelage in the matter, or simply any dynamically linked
executable for ARM linux.
Kevin
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: BSD signal
Date: Thu, 31 May 2001 22:03:12 GMT
In article <[EMAIL PROTECTED]>, Derek Viljoen wrote:
>Okay let's play:
>
>$ man signal
>...
>NOTES
> Signal handlers cannot be set for SIGKILL or SIGSTOP.
>
> Unlike on BSD systems, signals under Linux are reset to their
>default behavior when raised. However, if you
> include <bsd/signal.h> instead of <signal.h> then signal is
>redefined as __bsd_signal and signal has the BSD
> semantics. Both versions of signal are library routines built
>on top of sigaction(2).
>...
[-]
ls: /usr/include/bsd/signal.h: No such file or directory
glibc-2.2.3 -- compiled using the unpatched and official sources
from sourceware.cygnus.com.
You may update your manual pages, too since mine does not come
with this note. IIRC the latest version is man-pages-1.36 but
the info documentation is the final reference. Really really
really see the info documentation if in doubt. Since writing
man pages is not what I'd consider big fun you must not expect
others to do so and at times they're just not up to date.
Note: I'm using pinfo, much nicer than info ;)
[-]
Cheers,
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Juha Laiho <[EMAIL PROTECTED]>
Subject: Re: Getting CURRENT load average
Date: 31 May 2001 16:59:23 GMT
"Cameron Kerr" <[EMAIL PROTECTED]> said:
>I need to make a program to retrieve the current laod average of the
>system (This is for cluster computing, I want to find the least busiest
>machine). The best I can find is the look at the stats in /proc/loadavg.
>
>However, the information there is rather undesirable, since its a
>sliding/decaying average over at least 1 minute. I would like it so that
>after the load had gone, the information I am able to give is more
>accurate, rather than having to wait for the load average to dacay.
Well, some kind of decaying average is needed, as at any single point
of time a CPU either is doing something or is not (ok, not pedantically
correct, and simplifies a lot of things, but should give the correct
idea). And if you were to query the CPU "are you doing something _now_",
the answer would always be "yes", because at that poit it'd be executing
your query.
>Looking at the kernel source, I'm thinking about the best I could do
>would be to write a module or supplement the kernel so that it calculates
>the average over a smaller timeslice, say 5 seconds.
>
>Is this the best way to proceed, or is there something better?
Hmm.. I'd consider 5-second decay for load average calculation to be
hellishly (pardon) spiky, but depending on your load, that might be
exactly what suits your needs. If it's installed on your system(s),
or you can get it installed, you might like the output of 'sar':
$ sar 2 1
Linux 2.4.2-0.1.49 (dyn129.ichaos-int) 05/31/2001
07:53:54 PM CPU %user %nice %system %idle
07:53:56 PM all 0.00 0.00 0.50 99.50
Average: all 0.00 0.00 0.50 99.50
So, output is load average over two seconds. Change the first number
to change the interval, the second to change the number of samples
you want. I'd somewhat expect you to run this in a loop with large
number of samples.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ UH++++ UL++++$ P++@ L+++ E(-) W+$@ N++ !K w !O
!M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h--- r+++ y+++
"...cancel my subscription to the resurrection!" (Jim Morrison)
------------------------------
From: "J.O. Williams" <[EMAIL PROTECTED]>
Subject: Re: how to force a core file dump ?
Date: Thu, 31 May 2001 16:36:27 -0600
Christophe Dore wrote:
>
> Hi,
>
> I'd like to write handlers error signal (such as SIGSEV, SIGFPE, ...),
> but I would like to keep core dump.
>
> How can I force a program to dump a core? (especially in signal
> handlers ?)
>
> Thanks,
>
> C.Dore
kill -QUIT <pid> will cause a core dump but the program dies too.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: fast disk writes
Date: 31 May 2001 18:30:28 -0400
In article <[EMAIL PROTECTED]>,
Federico David Sacerdoti <[EMAIL PROTECTED]> wrote:
>
>The paper on FFS is
>
>M. K. McKusick, Bill Joy, et al.
>"A Fast File System for UNIX"
>ACM Transactions on Computer Systems Vol 2 # 3
>August 1984, pp 181-197
>
>It's a good paper, very informative. It might be available online.
Yes. On every FreeBSD box, for one thing (in /usr/share/doc/smm/05.fastfs/*).
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Date: Thu, 31 May 2001 18:08:41 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Problems with sources from MS Visual C++
Christian Jetter wrote:
>
> Hi there!
> I have to convert a DLL based on a source code which was originally
> developed for Windows NT/9x for a Linux application. Fortunately all big
> problems like semaphores or os specific system calls have been solved and
> the DLL is loaded without any problems into the application. The source code
> is compiled by gcc without any errors, the linking works fine and the
> resulting .so-file is of a sensible size.
> Anyhow there remain mysterious problems with the encryption and decryption
> functions using the OpenSSL package linked into the library.
> Since I am not very experienced on Linux it is a really hard job for me to
> find the bug.
> Is there something like a list of typical problems that occur when taking
> original Windows-C++ source code for development under Linux. Maybe it is
> just a simple problem like different size()-values for the same datatypes or
> variables, or string termination problems or something like that. If anyone
> can help me I would be very thankful for an e-mail. I have already busted
> all deadlines for the project and it would be a pity if all these
> Windows-oriented guys would have an another argument against portations for
> Linux.
>
> Greetings
> Chris
It sounds like it is a C++ app, rather than C. For that, you should be
using g++ instead of gcc. The typical problem I see in this sort of
conversion is the failure to wrap purely C functions:
extern "C" {
#include <someCfunc.h>
}
What would really help though is knowing what kind of error you get, and
when.
One of the more annoying things I found doing even simple conversions
was that VC++ does not always treat casting behavior the same as g++
does.
D. Stimits, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Charles Wilkins)
Subject: Re: Device Driver Interrupts on SMP using kernel 2.4
Date: Fri, 01 Jun 2001 01:19:02 GMT
Reply-To: [EMAIL PROTECTED]
why do you want to do that ?
just get a bus mastering nic card
On Sun, 27 May 2001 13:07:46 +0100, Hilik Stein <[EMAIL PROTECTED]>
wrote:
>Hi all
>I am trying to write/modify a NIC device driver for a high-speed lan
>card. the device generates a huge a number of H.W. interrupts.
>i wanted to switch to SMP machine and force the kernel to run the
>hardware interrupts on one CPU only. is this possible ? how can it be
>done ?
>10x
>Hilik
------------------------------
From: Josef Molnar <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc
Subject: Patching the original RH (7.1) kernel (?)
Date: Fri, 01 Jun 2001 08:42:41 +0200
Hi there,
My question is: is it possible to patch the RedHat kernel source with
patches downloaded from ftp.kernel.org?
If not, is it possible to use the latest kernel from for RH without any
modifications?
If not, what modifications are necessery?
Are there patches (to newer kernels) for the original RH kernel source
tree?
Thank you and
Best regards
Josef Molnar
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: how to force a core file dump ?
Date: 01 Jun 2001 06:38:30 GMT
On Thu, 31 May 2001 16:36:27 -0600, J.O. Williams <[EMAIL PROTECTED]> wrote:
>Christophe Dore wrote:
>>
>> Hi,
>>
>> I'd like to write handlers error signal (such as SIGSEV, SIGFPE, ...),
>> but I would like to keep core dump.
>>
>> How can I force a program to dump a core? (especially in signal
>> handlers ?)
>>
>> Thanks,
>>
>> C.Dore
>
>kill -QUIT <pid> will cause a core dump but the program dies too.
A core dump is produced in connection with the process being terminated.
So the only way to make a coredump is to send the process one of the signals
that would produce a core dump if not caught or ignored. SIGQUIT is one
of them as is SIGABRT aka. SIGIOT which is raised by the abort() function.
man 7 signal will give a list of signals that would cause a core dump.
Signal Value Action Comment
---------------------------------------------------------------------
SIGHUP 1 A Hangup detected on controlling terminal
or death of controlling process
SIGINT 2 A Interrupt from keyboard
SIGQUIT 3 A Quit from keyboard
SIGILL 4 A Illegal Instruction
SIGABRT 6 C Abort signal from abort(3)
SIGFPE 8 C Floating point exception
.....
Seems, though, that this list needs fixing; SIGQUIT for example should
have a 'C'. Who is the maintainer?
Villy
------------------------------
From: "Park Jung Kyu" <[EMAIL PROTECTED]>
Subject: kernel panic problem. help me
Date: Fri, 1 Jun 2001 16:13:59 +0900
Hi~
I have modified bread() in buffer.c at Linux kernel 2.2.17.
Only modified bread() in buffer.c.
Modified bread is similar to original bread().
Differece in bread() is that modified bread() prefetch one block.
Origianl bread : fetch request block
Modified bread : fetch request block + prefetch one block
Source complie is no error but when kernel is booting,
show kernel panic message.
(kernel panic: VFS: Unable to mount root fs on 03:07)
what's wrong my source.
please tell me answer.
thanks for your help.
/* source */
struct buffer_head * bread(kdev_t dev, int block, int size)
{
struct buffer_head * bh;
struct buffer_head * ph;
struct buffer_head * result;
int prefetch = 0;
int bhMiss = 1;
if (block < 0)
return NULL;
bh = getblk(dev, block, size);
if ( buffer_uptodate(bh) ) {
bhMiss = 0;
result = bh;
}
else ll_rw_block(READ, 1, &bh);
ph = getblk(dev, block + 1, size);
if ( buffer_uptodate(ph) ) {
prefetch = 0;
}
else {
prefetch = 1;
ll_rw_block(READ, 1, &ph);
}
if ( bhMiss = 1 ) {
wait_on_buffer(bh);
if ( buffer_uptodate(bh) ) {
result = bh;
}
else {
brelse(bh);
result = (struct buffer_head *)NULL;
}
}
/* OutofRange value 0 : block + 1 > total blocks in file system
*/
/* OutofRange value 1 : block + 1 <= total blocks in file
system */
if ( prefetch == 1 && OutofRange == 0) {
wait_on_buffer(ph);
}
brelse(ph);
return result;
}
------------------------------
From: Gregory Bond <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: thundering-herd vs wake-one
Date: 01 Jun 2001 17:04:53 +1000
[EMAIL PROTECTED] writes:
> What better solutions do you have or suggest?
Look at kqueue(2) and kevent(2) in 4.x or later FreeBSD. Basically,
only pass around the descriptor array/s once, rather than once per
select() call.
------------------------------
From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Crossposted-To: linux.redhat.misc
Subject: Re: Patching the original RH (7.1) kernel (?)
Date: Fri, 1 Jun 2001 09:39:08 +0200
"Josef Molnar" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi there,
>
> My question is: is it possible to patch the RedHat kernel source with
> patches downloaded from ftp.kernel.org?
Probably not, since redhat might have added something where the patch would
apply. So.. try it?
> If not, is it possible to use the latest kernel from for RH without any
> modifications?
Latest kernel from www.kernel.org works fine (if they havnt put another
malicious bug in it )
> If not, what modifications are necessery?
None.
> Are there patches (to newer kernels) for the original RH kernel source
> tree?
No.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: environment variable confusion
Date: 1 Jun 2001 02:22:46 -0700
In article <[EMAIL PROTECTED]>,
Eric Taylor <[EMAIL PROTECTED]> wrote:
[ ... ]
>The change is done in the shell before running the
>program. The program runs, notices a particular command
>line argument which tells it to restore itself from a prior
>saved checkpoint. This technique has been used on
>a solaris system and is being ported to linux
>w/o much change. It does "mostly" work.
I had assumed that you had a separate program that reloaded and restarted
your application. Obviously much of what I wrote was not relevant.
>[when the program starts up, it reads a file written earlier
>(prior run) to determine what memory to restore. Next 1 or
>more sbrk's are done, low address dynamic memory is restored from
>the file (just above the code). In
>this dynamic area is a saved copy of the stack ( only a few k bytes) at
>the time
>the checkpoint is written, so the last part is to copy this
>over top of the current stack - there is a longjmp done after this
>which has been setup in such a way to get everything back
>to where it was at the moment of the save, but with a jump
>to the code that runs after the restore is complete. Lastly,
>all i/o is reconnected. It's not a general purpose save/restore, so
>we only worry about things that our program needs - I didn't write
>this so I'm not 100% certain of my facts here]
>
>
>So, I am guessing that bash calls setenv to create or modify
>the environment inside itself, and later when you run a program,
>the environment is copied out of the bash process and into the
>new process that bash forked/exec'd
I believe this is correct.
>After looking at the code in the kernel, I see that there is a
>special copy that assembles the various strings (which might
>be anywhere in bash's address space) but sort of packs them
>all in one place so that the program that is forked/execd ends
>up with them in one contiguous spot at the top of the stack
>(do I have this right?)
Yes. The general layout in ascending order is:
argv array
envv array
elf parameters for program startup
argv strings
envv strings
[top of stack]
>What I do to recreate the problem is create a variable
>like this:
>
>export XXX=aaabbb
>export export XXX=abcdef_$XXX
>
>(this last one I repeat some number of times)
>
>So, I keep growing XXX a little bigger, and then run the
>program which tries to restore itself. For a while it works,
>so I make XXX bigger and try again. Eventually I get a
>segment fault inside getenv (called indirectly by some timezone
>library routine)
>
>
>This all may seem a little fragile, but I am trying to
>figure out what is going on, so I can make a policy
>that will allow this to work - like don't change any
>environment variables prior to a restore - but that
>may not be feasible, so I need more understanding.
If you restore all of the stack, it shouldn't matter what was in it
before, except that you must be sure you don't write over the part
you are using during restoration.
>I do not believe that this program ever references
>"environ" itself, so as a poster mentioned, the libc
>.so must have some way to set this up (i guess this
>is part of what the dynamic loader does although I
>don't yet understand how it figures out what the
>value for "environ" should be)
If your program references "environ", it is placed in the .bss area of
the program (where uninitialized data sits).
If your program doesn't reference it, it appears to be in the .bss area
of libc.
Assuming that the latter is the case, changing the size of the env-string
area will likely result in environ pointing at things that aren't pointers.
If the stack grew slightly, only the first few env entries would vanish.
The conclusion seems to be that either the environment must not change,
or environ must be restored, by forcing it into the program .bss area.
>I was thinking I might need to have some pad space
>somewhere. Maybe if I never get larger, only smaller,
>it would work... I could try starting out with a large
>variable and make it smaller which could give me room
>to grow or add some others.
Actually, there seems to be a small amount of unpredictable padding.
The kernel code seems to force some kind of alignment when it adds the
elf-parameters. Since this area is above the env-pointer array, small
changes in the environment _might_ not have an effect.
>Where this all comes into play, is that it pretty much works
>if I save and restore on the same system (and don't mess
>with environment variables). But, for a real
>robust situation, I actually need to be able to restart on
>another system (as close to a clone as possible). This way
>we can be running the same program at various stages
>on a few processors. So, part of the problem is that
>the environment of the process can be different on
>the other system (host name and ip address would
>be different for ex)
>
>BTW, The program is a simulation that
>can run for weeks and may use nearly 3 gigs of memory. Most of
>the code resides in a .so file so we can make changes
>to the program, if necessary, and then do a restart in the middle. But,
>that is all working, it's only with the environment/stack
>that I seem to be having trouble with now..
I guess I would suggest adding a reference to environ to the program
and see whether that fixes this problem.
The other thing I would suggest is to do a fairly large alloca() in the
restore case, before calling the main restore logic, to ensure that the
working part of the stack is below the area that will be in use after
the restoration.
--
B. D. Elliott [EMAIL PROTECTED]
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
