Linux-Development-Sys Digest #938, Volume #6 Wed, 7 Jul 99 16:14:19 EDT
Contents:
Re: Callbacks (Emile van bergen)
Re: Determining drive usage from C (Karl Heyes)
Re: Why not C++ (Craig Graham)
Re: egcs idiocy (John McKown)
Re: Memory handling with really large processes (> 6-700MB) (Wolfram Gloger)
Memory handling with really large processes (> 6-700MB) (Ole Jacob Taraldset)
large executables on Red Hat 6.0 ([EMAIL PROTECTED])
Re: Determining drive usage from C (John McKown)
Re: getting slackware linux (Mark Tranchant)
Re: Max threads, processes, file descriptors, etc ... (Matthew Carl Schumaker)
Linux 2.2 threads and GLIBC errors ([EMAIL PROTECTED])
Having problem in porting a software to Linux ([EMAIL PROTECTED])
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Patrick Letovsky)
Re: getting slackware linux ("John E. Garrott")
Re: gdb & pthreads in Alpha linux 2.0.36 (Stan Shebs)
Re: Module: Export Symbols?!? ("B. James Phillippe")
Re: getting slackware linux (Lew Pitcher)
Re: Why not C++ (Kaz Kylheku)
Re: diskless linux (Peter Pointner)
Re: Why not C++ (Horst von Brand)
----------------------------------------------------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Callbacks
Date: Wed, 7 Jul 1999 13:35:52 +0200
On Wed, 7 Jul 1999, overflow wrote:
>The problem is that I have to use the BIOS because I'm writting the
>framebuffer driver for generic VESA devices. There are some functions that
>can be done through a protected mode entry point, but others do not.
>Jaime Medrano
I see... I guess the only thing VESA provides for those entry points is
the bankswitching routines, isn't it... Then I guess there are two
options, as completely dropping out to real mode isn't an option:
1. Handle the initial setup to the flat framebuffer mode in the
vgasetup-parts of the kernel that run in real mode (have a look at
the console options that can be specified at the kernel command line),
so that you can use real mode sw int 10 to set it up. But once you have
a running kernel, there's no way to get to the original int10 entry
point, so the mode setup is only done _once_. Don't know if that'd
satisfy you, however.
2. Have a look at DosEmu! This program utilises some syscalls to run a
piece of code (including int 10 functions, btw) in virtual-8086 mode. I
guess with a bit of tweaking, you could cut out the code that handles
the video setup in VM86 mode and use it from userspace. But I guess
doing it from within the kernel would be kind of problematic (and
unnecessary).
Hope this is of some help, though.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Determining drive usage from C
Date: Wed, 07 Jul 1999 12:42:49 +0100
Adam the Amazing wrote:
> Is there some C function I can call to determine how much free space is
> on a particular hard disk partition?
>
statfs
karl
------------------------------
From: Craig Graham <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Wed, 7 Jul 1999 15:22:46 +0000
o r c @ p e l l . p o r t l a n d . o r . u s (david parsons) wrote:
> >Java, even compiled to machine code, will be slower than C or C++.
>=20
> I presume you have experimental evidence that supports this claim.
> Care to share it?
Compiled Java would have extra overheads relative to C++,
due mostly to the absense of a delete operator. You have to either:
1) Generate extra code for each object access to support reference counti=
ng
and then delete unreferenced objects on context exit.
or
2) Mark & sweep or some other global garbage collect operation, which tak=
es
a relatively large time to execute, and has to be scheduled into the
execution path at pretty regular intervals.
Method 1 causes a uniform slowdown in speed, due to the extra code
each reference variable requires when written to, and also leaves objects
in the top level hanging around, whereas method 2 causes those annoying
pauses that JVM's used to be prone to whilst the global garbage collect i=
s
performed.
> >Java requires a run time system (ala Objective-C), making it both more
> >dynamic, and slower.
>=20
> Care to enumerate exactly how this make it slower?
> Inquiring minds, doncha know.
See above....
> david parsons \bi/ I can think of one runtime (garbage collection)=
feature
Strangly hidden in your sig, your last comment is right - to an extent, b=
ut
the garbage collectors are still going to hammer performance no matter
how clever they are, it's just a matter of how they do it....
I spent several months writing a JVM for TwoWayTV/Cable&Wireless
(embedded system application), so I've spent a shit load of time looking
at the garbage collector issue.
Craig.
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Subject: Re: egcs idiocy
Date: 7 Jul 1999 00:17:40 GMT
On Tue, 6 Jul 1999 13:22:27 -0400, SV <[EMAIL PROTECTED]> wrote:
>
>I feel like the whole linux is becoming just a heap
>of bugfixes piled up by a bunch of non-professional
>bafoons
>
>Cordially,
>SV
Just remember. Those who can, do. Those who can't, teach. Those who can
do neither, critize.
It is a simple, but unfortunate, fact of life that
as software systems age, they expand (much like my waist line <grin>).
Some of this is due to the "patch upon patch" caused by some miscoding
in the past, with insufficient time and resources to totally rewrite.
That's assuming that it is even possible to rewrite. Complex software
often has side effects that were unplanned but are now critical to
something else working. Usually because the something else has bugs.
But to fix program#1, you must first fix program#2. But fixing program#2
may break program#3, and so forth.
Linux and every other OS that I'm even faintly familiar with shows this
problem. We run an S/390 mainframe at work. The OS for that is cleverly
called OS/390 (well one of the anyway - VMer's and VSE'ers don't yell).
IBM says to expect a 2 to 6 percent increase in system overhead for
each version. And IBM expects to release new versions around every
6 months.
Part is due to patching patches. But a lot is due to the demand for
more functionality. We want the computer to do more "housekeeping"
for us.
Well, I'm running off a the mouth again. Better shut up for now.
John
------------------------------
From: Wolfram Gloger <[EMAIL PROTECTED]>
Subject: Re: Memory handling with really large processes (> 6-700MB)
Date: 07 Jul 1999 17:10:12 +0200
Ole Jacob Taraldset <[EMAIL PROTECTED]> writes:
> When the process becomes so large that it hits the roof it aborts with
> an out of memory message on HP, SGI and Sun, but on Linux it brings the
> whole system to its knees.
You need to look at `ulimit' and put appropriate settings into
/etc/initscript, for example.
Regards,
Wolfram.
------------------------------
From: Ole Jacob Taraldset <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Memory handling with really large processes (> 6-700MB)
Date: Wed, 07 Jul 1999 16:12:20 +0200
My company has developed a CAD tool to accompany our CFD tool FLACS. It
is written in c/c++ and runs under HP, SGI, Sun and is also ported to
Linux. If you load a large geometry into the CAD tool the process can
become very large (close to 1GB, OK we have some major memory leaks...).
When the process becomes so large that it hits the roof it aborts with
an out of memory message on HP, SGI and Sun, but on Linux it brings the
whole system to its knees. I loose complete control of the machine for
5-10 minutes and then the CAD process dies and I regain control of the
machine. The problem is that it takes with it a random number of other
processes. Sometimes just the wm, other times X and a lot of services.
The CAD tool is of course run as a normal user. This should not happen,
right? I thought Linux, as any UN*X, protects processes from each other.
Since the machine doesn't die completely I guess the kernel it self is
protected in a way.
If you reply please also reply to my email address, as I'm not a regular
reader.
Ole Jacob Taraldset
GexCon AS
--
GexCon AS, Bergen, Norway <http://www.gexcon.com>
Tel : +47 55574334 (office) +47 55558650 (home)
Mob.tel. : +47 95080525 Fax : +47 55574331
PGP key : <http://home.c2i.net/ojt/pgp.txt>
------------------------------
From: [EMAIL PROTECTED]
Subject: large executables on Red Hat 6.0
Date: Wed, 07 Jul 1999 16:01:05 GMT
I have a scientific model written in g77 that uses large arrays. I have
Red Hat 6.0 with 512 Meg memory and 8 120 meg swap partitions to give
me about 1.5 gig memory space. When I set constants so that my program
takes
up 800 meg it works fine but if I make constants so that it takes up
970 meg it hangs a while and then segmantation faults at the prompt
without getting to the first line which was a print.
Any suggestions why this happens? [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John McKown)
Subject: Re: Determining drive usage from C
Date: 7 Jul 1999 00:17:39 GMT
On Tue, 06 Jul 1999 11:23:03 -0500, Adam the Amazing
<[EMAIL PROTECTED]> wrote:
>Is there some C function I can call to determine how much free space is
>on a particular hard disk partition?
>
>thanks,
>--adam
I don't know of one that exactly does that. However, the "df" command does.
"df" is a part of fileutils. What'd I'd do is install the fileutils source
and see how "df" does it. I did take a fast look and it appears that the
heart of "df" is the statfs() call. I'd look at the man page for that.
It appears, again looking at it quickly, that you should be able to get
what you want from it.
I absolutely LOVE the fact that the GNU & Linux believe in letting you look
at their code.
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: getting slackware linux
Date: Wed, 07 Jul 1999 15:49:36 +0100
Reply-To: [EMAIL PROTECTED]
Sigh. Try www.slackware.com, as if that wasn't obvious.
If you're not on a fast link (and I don't mean 56k modem here!) buy a CD
from Cheapbytes (www.cheapbytes.com). It'll be faster and more
satisfying. Plus, if anything goes horribly wrong, you still have the
files.
Mark.
Mahesh wrote:
>
> Hi,
>
> I want to buy or download slackware linux for a laptop. Can you give me
> an idea where I can buy or download it.
>
> Thanks for your help.
>
> -Mahesh
------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Subject: Re: Max threads, processes, file descriptors, etc ...
Date: Wed, 7 Jul 1999 14:32:00 -0400
If you want to change the number of proccesses/threads you have to got
tasks.h in the same directory
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
On Wed, 7 Jul 1999, Alexander Kuznetsov wrote:
> Gerald Gutierrez wrote:
>
> > I remember some time back there was a discussion regarding how to
> > change the maximum user & system wide number of threads, processes and
> > file descriptors, amongst other things.
> >
> > Does anyone know where I might be able to find such information?
>
> Go stright to /usr/src/linux/include/linux/limits.h
>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.programming.threads
Subject: Linux 2.2 threads and GLIBC errors
Date: Wed, 07 Jul 1999 13:31:11 -0500
We've recently upgraded to the standard RedHat 6.0 with linux
kernel 2.2 and libc-2.1.1 and, evidently, linuxthreads-0.8.
When we recompile our threaded applications --- which
work fine under RedHat 5.2 --- we introduce an intermittent
(about 50% of the time) error. The error message that
happens during exectution is always similar to this:
test_cpp: error in loading shared libraries: /lib/libpthread.so.0: symbol
__libc_waitpid,
version GLIBC_2.0 not defined in file libc.so.6 with link time reference
The actual symbol, in this case __libc_waitpid, sometimes changes
but the error message stays the same. Does anyone have any
comments or suggestions on where to find the source of this
error?
Thanks,
John
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Having problem in porting a software to Linux
Date: Wed, 07 Jul 1999 17:51:47 GMT
I am trying to Port a software on Linux. There is a system function
gettxt() which is used in the program to retrieve a text string from a
message database. And there is no gettxt function in Linux. I was
trying to find an equivalent function and I found catgets() function
which get message from a message catalog. But in this function I did
not understand the argument "set_number" which is passed to the
function. And second doubt I have is that on Linux the default path to
find a message catalog is /usr/lib/locale/LC_MESSAGE, but I could not
find such directory. I was wondering whether this is the right function
that is equivalent to gettxt().
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Patrick Letovsky <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Date: Wed, 07 Jul 1999 14:08:58 -0700
Reply-To: [EMAIL PROTECTED]
Thanks Christopher,
I understand the 3 parts involved into the process, so I guess I'll
need to move to a 64 bits OS. I'm gonna use an irix box to do this job.
Thanks again for the explanation.
Patrick
"Christopher B. Browne" wrote:
>
> On Wed, 30 Jun 1999 18:50:05 -0700, Patrick Letovsky
> <[EMAIL PROTECTED]> posted:
> >Christopher Browne wrote:
> >>
> >> ext2 is quite capable of handling *filesystem* sizes considerably larger
> >> than 2GB. (2TB rings a bell.)
> >
> >I read your page about the 32 bits architecture limitation, actually
> >your page is very well documented for all kernel features.
> >In my case, it is just for being able to create a tar file > 2gb, so if
> >the only thing to do is to recompile tar under the 2.2.x with the latest
> >GNU C compiler, that is not that big of a deal.
> >But I still miss information about this patch itself, it can be in beta
> >or alpha, I want to give it a try. I mount a RAID5 disk array on
> >/dev/sda3, there, I only have backup files from other systems, and one
> >of this file needs to be > 2Gb. I hope the patch doesn't involved to
> >re-mkfs the partition.
> >
> >Any information on this unobtainable patch will be very appreciate.
>
> The *killer* part isn't a kernel patch; it's the (probably nonexistent
> at this point) GLIBC patch that is needed to support big files.
>
> SAS Institute did a summit on this, and some of the "big name" UNIX
> vendors do have API extensions to allow 64 bit file accessors on 32
> bit platforms.
>
> Note that this is anything but transparent; you really have to pick for
> LIBC to either be 32-bit-oriented, or 64-bit-oriented, and *NOT BOTH
> AT ONCE.*
>
> The result of *that* is that if you want to have tar/cat/dd/...
> support 64 bit access, you need to modify them as well as LIBC to use
> the 64 bit API.
>
> LIBC5 *definitely* doesn't support "big files," and I don't *think*
> that GLIBC2 provides both APIs (e.g. - small&large file accessors) yet.
>
> Net result:
> Patches must be to *ALL* of:
> a) Kernel,
> b) LIBC,
> c) Applications.
>
> I'm certain that c) hasn't been done, which puts you Out Of Luck.
>
> See: <http://www.sas.com/standards/large.file/x_open.20Mar96.html>
> for more details on the API changes.
>
> I do not know where the patch is.
> --
> Those who do not understand Unix are condemned to reinvent it, poorly.
> -- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
> [EMAIL PROTECTED] - "What have you contributed to free software today?..."
--
=======================The Web Zone, Inc.=======================
Your Internet & Networking Solutions Company
8100 Boone Blvd., suite 110 Tel: (703) 744-8811
Vienna, VA 22182 Fax: (408) 235-8881
http://www.webzoneinc.com [EMAIL PROTECTED]
================================================================
------------------------------
From: "John E. Garrott" <[EMAIL PROTECTED]>
Subject: Re: getting slackware linux
Date: Wed, 07 Jul 1999 08:03:51 -0700
Mahesh wrote:
>
> Hi,
>
> I want to buy or download slackware linux for a laptop. Can you give me
> an idea where I can buy or download it.
>
> Thanks for your help.
>
> -Mahesh
http://www.cdrom.com/
You can buy the cds or download from their ftp repository.
Good luck,
John
------------------------------
From: Stan Shebs <[EMAIL PROTECTED]>
Subject: Re: gdb & pthreads in Alpha linux 2.0.36
Date: 07 Jul 1999 10:47:15 -0700
Larry Williamson <[EMAIL PROTECTED]> writes:
> Someone here is working on an application that runs on an Alpha Linux
> 2.0.36 machine. The code is written in C++ (egcs-1.1.1).
>
> It appears gdb v4.18 does not support debugging pthread'd apps.
That's true. There are patches for x86 Linux, but I don't know if
they'll work on Alpha.
> Does anyone know of any effort to add pthread support to the Alpha
> port of gdb ?
Yes, Cygnus is working on this, as part of our deal with API; see
http://www.cygnus.com/news/alpha.html for more bits. The press
release doesn't mention thread support explicitly, but it's on the
work agenda nevertheless.
Stan Shebs
Cygnus Solutions
[EMAIL PROTECTED]
------------------------------
From: "B. James Phillippe" <[EMAIL PROTECTED]>
Subject: Re: Module: Export Symbols?!?
Date: 7 Jul 1999 18:34:10 GMT
On Wed, 7 Jul 1999, Michael Knigge wrote:
> Hi all,
>=20
> I=B4ve problems using a Kernel Module. I added the line
> "EXPORT_SYMBOL(my_function);" to the source (Module A)
>=20
> When I load another Module (Module B), that requires the
> function of "Module A" (using insmod), I get the Message
>=20
> unresolved symbol my_function
Is it perhaps because your kernel is being compiled with CONFIG_MODVERSIONS
and your module is not? Try these two suggestions (in order)..
1.) compile your modules with -DMODVERSIONS -include
/path/to/kernel/include/linux/modversions.h
2.) if that doesn't work, change the EXPORT_SYMBOL to EXPORT_SYMBOL_NOVERS.
This is a dirty hack but might work around the problem until you get it
figured out.
-bp
--
# bryan at terran dot org
# http://www.terran.org/~bryan
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: getting slackware linux
Reply-To: [EMAIL PROTECTED]
Date: Wed, 07 Jul 1999 15:47:20 GMT
On Wed, 07 Jul 1999 08:03:51 -0700, "John E. Garrott" <[EMAIL PROTECTED]> wrote:
>Mahesh wrote:
>>
>> Hi,
>>
>> I want to buy or download slackware linux for a laptop. Can you give me
>> an idea where I can buy or download it.
>>
>> Thanks for your help.
>>
>> -Mahesh
>
>http://www.cdrom.com/
>
or
http://www.slackware.com/
which claims to be the "Official home of the Slackware Linux project"
Lew Pitcher
System Consultant, Integration Solutions Architecture
Toronto Dominion Bank
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Wed, 07 Jul 1999 19:18:06 GMT
On 7 Jul 1999 18:15:36 GMT, Mike McDonald <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Craig Graham <[EMAIL PROTECTED]> writes:
>
>> I spent several months writing a JVM for TwoWayTV/Cable&Wireless
>> (embedded system application), so I've spent a shit load of time looking
>> at the garbage collector issue.
>> Craig.
>
> A whole "several months"? Wow! I suggest you check out
>cs.utexas.edu:/pub/garbage for real information on garbage collection of all
>kinds, including malloc/free and their relative performance.
The trick is that to implement true garbage collection in Java, you have to
gradually purge all of the program's text from memory. :)
------------------------------
Crossposted-To: comp.os.linux.setup,comp.os.linux.misc
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: diskless linux
Date: Wed, 7 Jul 1999 18:24:32 GMT
Piyush Agarwal <[EMAIL PROTECTED]> wrote:
> I need to boot diskless linux from flash. I saw etherboot and netboot
> but they require a server on the net. I have a standalone linux board
> with no NFS server. The kernel image has to be burnt in flash and if any
> directory structure is required then it has to be created in flash or
> RAMDISK. Please advise on how this can be achieved.
Sorry, I don't know about something ready. But if you don't get something
better, the following thoughts might be a start:
- You might use an initial ramdisk. Then you burn the compressed kernel
image and the compressed ramdisk image to flash. I assume you don't
need a full unix system, so the script "linuxrc" might never exit, and
your initial ramdisk is quite final.
- Something has to load kernel and ramdisk image. Maybe syslinux can be
hacked to read the few needed "files" from flash?
- Do you have ethernet? For a small system I used etherboot during
development to load a tagged image including an initial ramdisk. Later
I burnt this tagged image to flash and hacked etherboot to "load" from
flash instead of tftp.
Peter
(Followup trimmed)
------------------------------
From: Horst von Brand <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 07 Jul 1999 14:56:59 -0400
Justin Vallon <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Bruce Hoult) writes:
> > In article <7lbkp6$h72$[EMAIL PROTECTED]>, Cameron Hutchison
> > <[EMAIL PROTECTED]> wrote:
> > > Consider this:
> > >
> > > #define inc(x) (++(x))
> > > ...
> > > int x = 1;
> > > ...
> > > inc(x);
> > > In this case, x is being modified and you cannot tell from the
> > > context. It may be bad form to write a macro with lower case letters,
> > > but it can also be argued that it is bad form to use non-const
> > > references in C++.
It isn't "bad form", it is just that C only has pass-by-value, and
"functions" that modify their arguments are alien there. C++ is enough
alike C that this may become a problem.
Just a cultural bias.
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
------------------------------
** 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
******************************
