Linux-Development-Sys Digest #685, Volume #6 Thu, 6 May 99 14:14:33 EDT
Contents:
Re: crash with 2.2.x SMP under heavy disk activity (bryan)
Re: Understanding Linux development (Christopher Browne)
Re: help on compiling glibc 2.1 (and texinfo and termcap and ugh..) (Paul Kimoto)
Re: physical Memory (Robert Kaiser)
Re: Glibc rant (David T. Blake)
Re: Get client machine's IP-address (AKK)
Re: Linux disk defragmenter (Anthony Ord)
----------------------------------------------------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: crash with 2.2.x SMP under heavy disk activity
Date: Thu, 06 May 1999 15:18:20 GMT
same here. I built 2.2.7 SMP (celerons) and I just burned a redhat
6.0 cdr. that's at least 600meg ;-) no crashes, etc.
Sascha Bohnenkamp <[EMAIL PROTECTED]> wrote:
: >I wonder if anyone encounters the same problems we have : crashes under
: >2.2.x (seems not to matter to much) under heavy scsi disk activity.
: >The dual PII 450 MHz, which used to be rock solid under 2.0.x SMP,
: >crashes after "big" files (like 10-50 Mb) are written (not 100% sure) to
: >its disks.
: mmmh, my system with 2.2.7 and smp does not crash after writing some gigs
: even under heavy load (>20 on two cpus)
--
Bryan
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Understanding Linux development
Reply-To: [EMAIL PROTECTED]
Date: Thu, 06 May 1999 12:16:01 GMT
On Wed, 05 May 1999 16:19:40 -0400, Jim Bailey <[EMAIL PROTECTED]>
wrote:
>A word of warning - I am a Linux newbie.
>
>I'm not however, new to development. I've been programming 20 years but
>never on Unix/Linux systems (VMS, much Windows, other various). I'm
>trying to move to the Linux world but hitting some obstacles. The main
>one seems to be in understanding the various C compilers and reqd libs
>with which to do development. I installed Caldera 2.2 and set up the
>common stuff (PPP, mail, news etc.). I immediately opened up an editor
>typed in the old "Hello world", and built it with gcc in an Xterm, and
>it worked. Wow - maybe this won't be so bad after all.
>
>Then I decide to try my hand at KDE devlopment - download the samples
>from KDE, type them in, and per the sample, try G++ and my system knows
>of no such thing. So for the last week I've tried to find the answers
>to things like:
>
>1. What is egcs ? Is g++ hidden in there somewhere ? Must not be because
>the Kpackage tool says that's already installed. There's another
>package called egcs-c++ that won't install because it has a dependency
>on '==2.9' - yes thats the error.
EGCS is an experimental (hence the "E") development effort which has
been working on substantial improvements to the GCC "family" of
compilers. (e.g. - GCC, along with various front ends for different
languages such as C++, Objective C, Chill, FORTRAN...).
Up until version 2.8, the C++ support in GCC was "pretty poor." The
reasons are many; assessing reasons and blame could be fun but largely
pointless. At the time of 2.8, EGCS also came out. In addition,
efforts came to the forefront on both GLIBC 2.0, the "new generation" C
libraries, as well as corresponding C++ libraries.
The compiler, C libraries, *and* C++ libraries all integrate together a
bit more tightly than people are entirely comfortable with, and it seems
pretty critical to keep versions straight, otherwise programs may not
link or run quite as you expect.
Upshot is that that all of this has been in a fair bit of flux over the
last year, which has been particularly hurtful to the stability of
peoples' C++ environments.
Things are in the process of consolidating; EGCS will soon become GCC,
and I expect that this will result in a new version number for both GCC
as well as for C++ libraries.
>2. The Kde sample references some includes that I can't find anywhere
>on my system - where (what RPM) are the Kde includes ?
Look for kdelibs-devel, maybehaps?
>3. I really can't tell if I have all the Qt stuff I need either.
There should be two relevant packages; one that's the libraries for
deployment, and one for development.
>I've tried the Troll site, KDE, the Linux programming books I've bought,
>other newgroups etc. but can't figure out what compilers need what
>librarys for what window manager/desktop environments. Those sites
>weren't really meant for the 'new' developer. Antoher person suggested I
>look at Kdevelop - I will check it out but I'd feel much better if I
>understood some of this.
There are two approaches that are reasonable at this time:
a) Go with a G++ version that's a bit old, but fairly stable, and then
sync up libraries against that, or
b) Bleeding edge, EGCS.
I haven't had call for much C++, so I can't name the precise packages
that will correspond to one another. One place where you can find all
the RPMs is <http://rpmfind.net>; you can do dependancy searches there,
which should prove helpful.
--
"If you want to travel around the world and be invited to speak at a
lot of different places, just write a Unix operating system." (By Linus
Torvalds)
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: help on compiling glibc 2.1 (and texinfo and termcap and ugh..)
Date: 6 May 1999 11:51:14 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Vladimir G. Stanishev wrote:
> The INSTALL file for glibc 2.1 lists a bunch of programs that are needed
> to compile (or configure) glibc 2.1 successfully.
> I am using debian 2.0 with a 2.2.4kernel. I've installed everything
> unitl now using dpkg adn packages from teh debian site (except for the
> kernel and X).
The Debian "unstable" track has a glibc-2.1(.1-preX?). Why not use that?
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: physical Memory
Date: 6 May 1999 11:48:18 GMT
In article <[EMAIL PROTECTED]>,
Wolfram Gloger <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Robert Kaiser) writes:
>
> OK, this driver requires the bigphysarea patch, which is about 80
> lines of code. This should be in the standard kernel, to that I agree
> 100% ! (For example, it already _is_ in all Debian kernels.)
>
Well, my patch is about 200 lines of code (comments included). I
suppose "kernel bloat" is neither an argument against bigphysarea
nor against my UDMA patch. Furthermore, I don't think they would
interfere, so one could even include both bigphysarea and my patch.
[This might actually make sense as they have different strong and
weak points, so depending on what you do, one or the other is more
suitable.]
>> > What user space part ? You mean the integer constants passed via
>> > ioctl() ?
>>
>> They are not constants, otherwise it would be pointless to pass them
>> via ioctl().
>
> Huh ? Every ioctl() gets a constant request id, some (of course)
> additional parameters, like with every interface. What is bothering
> you about ioctl() ?
>
I was referring to things like the DMA buffer size that has to be passed
along with an ioctl() call to allocate a DMA buffer. This parameter is
determined by the application, so, at least from the driver's point of
view, it is not a constant.
>> But, OTOH, consider something like a tape device: Nothing is more
>> natural than doing a read() call to such a device's driver.
>
> But nothing is stopping you from doing an mmap() either.
>
Are you seriously suggesting we should re-write e.g. tar(1) and cpio(1)
for a tape that can do DMA ?
>> That
>> read() call moves data from the device into a user space buffer.
>> If the device supports scatter/gather DMA (which many do), it would
>> physically be able to store it's data to the user buffer right away,
>> without the CPU getting involved in the process. But, currently,
>> if I want to write such a driver for Linux, I have no choice but to:
>>
>> - waste memory to allocate a kernel space buffer,
>
> No, this is the exact same memory that you want to have in userspace.
> So it's definitely not wasted.
>
>> - DMA to that buffer,
>
> Yes. Like in the case for DMAing into userspace.
>
>> - waste CPU time to copy the data from one place in memory
>> (the kernel buffer) to another place in memory (the user
>> process's buffer).
>
> No ! mmap() does this transparently, without copying.
I was describing what I have to do with an unpatched kernel (i.e. no
bigphysarea patch installed). What you are referring to requires
bigphysarea.
Basically, what bigphysarea does is to pre-allocate a kernel space
buffer at boot time, so the allocation has in fact been done earlier.
(and the de-allocation is never done). Thus mmap()/munmap() is the
only thing remaining to be done in this case.
>> Of course, I _could_ do this with mmap(). Instead of a simple read(),
>> I would have to:
>>
>> 1) tell the driver the amount of data I want to read (presumably
>> with a nonstandard ioctl()) so it can allocate an appropriately
>> sized kernel buffer for me.
>
> Same as with read(). Your point is that read() provides a `standard'
> version of an ioctl() call with one pointer and one size_t argument ?
> Fair enough.
> But you won't tell me that that is sufficient for things
> like a framegrabber, right ? How do I specify that I want continuous
> capture into a ring buffer, for example ?
The read() call is certainly not sufficient for that. Nevertheless
user-space DMA can be very useful: With bigphysarea, if the buffer is
for a typical framegrabber, it will usually be easy to tell how much
buffer space will be needed (it's defined by the video format). Note
that, again, in this case the buffer logically belongs to the device,
even though it is physically represented by the host CPU's memory
However, I have had to deal with situations where the buffer size was
defined at run-time by the application. With bigphysarea, I would have
had to allocate for the worst case (i.e. highest expected requirement),
resulting in a huge DMA buffer which remains unused most of the time.
[Also note that in some cases it is not even possible to define
a "highest expected" buffer requirement.]
>
>> 2) mmap() that buffer into user space (after the driver has given
>> me the information I need for that (physical address)
>
> No, the physical address is of no interest whatsoever to the
> application. Processes only deal with virtual addresses. The
> application can map the DMA buffer at any address it sees fit.
>
Sorry for calling it a physical address. "handle" would have been
a better word. My point is that I can't mmap() the buffer before it
has been allocated.
>> 3) when I'm finished processing the data, tell the driver to
>> de-allocate the buffer -- yet another nonstandard ioctl().
>
> No, that is just a standard munmap() call.
>
munmap() does not de-allocate, it just unmaps. You are again
assuming that bigphysarea is being used (with all of its pros
and cons).
>> * What if my process gets killed before it has a chance do that
>> last deallocation ioctl() ? (well, the driver's close() function
>> could deal with that, but that means the driver has to keep track
>> of the buffer(s) it has allocated)
>
> Yes, of course it has to keep track, because it has allocated the
> buffers. (I'm repeating myself.)
It shouldn't have to allocate buffers, that's the application's job.
(I'm also repeating myself).
>> * What if multiple processes use the same device ? The driver
>> has to allocate multiple buffers simultaneously (how many ?
>> where is the limit) and it must keep track of which buffer
>> belongs to which process.
>
> No, for the framegrabber and even for the tape, there clearly needs to
> be only one buffer per device.
No, for the tape, either the device must be non-sharable, or there
must be one buffer per process.
>
>> Now, _that's_ what I call a kludgy interface!
>
> Your choice. All vendors of Unix systems seem to think it's clean
> enough.
_That_ is definitely not true! Of all Unix systems I have dealt with
(Linux, AIX, LynxOS, ...), Linux is the _only_ one that does not have
the functionality that my UDMA patch adds to it. Even NT can do it.
>> > Well, what if I want to share the DMA buffer between different
>> > processes ? This is trivially possible with mmap() but impossible
>> > with read().
>> Why would that be impossible ? I would just create a shared memory
>> segment and read() data into that segment.
>
> Aha ! Have you looked at what attaching to a shared memory segment
> involves ? Right, exactly the same interface, and a closely related
> implementation, as mmap().
Shure. I never said mmap() is evil.
> But anyway, what if two processes invoke
> read() at the same time ? Who gets the frame ?
The same thing happens as when two processes uncoordinatedly write to a
shared memory segment. This is part of the semantics of shared memory.
It has nothing to do with user-space DMA.
> Don't get me wrong, I actually like your kernel patch! For certain
> devices, something like that will probably be very nice to have in the
> kernel. But it is not _necessary_ to obtain zero-copy performance
> with DMA devices.
> ..
> True. But as Linus said, zero-copy is possible even without DMA to
> userspace.
I know it's possible. I described how to do it, and how that leads
to what I call a kludgy interface.
IMHO, the distinction of wether mmap() or user-space DMA is a better
approach depends on the device: If the device has or needs dedicated
memory to DMA to, then mmap() is appropriate. The bigphysarea patch
is just a method of obtaining dedicated memory for a device that
doesn't have memory of it's own. However, if it is the application that
defines the buffer requirements, then using mmap() tends to make things
clumsy (though admittedly not impossible).
IMHO, the mere fact that I can not implement a zero-copy read() with
the unpatched Linux kernel should be reason enough to implement something
like my UDMA patch in the kernel by default.
Cheers
Rob
================================================================
Robert Kaiser email: [EMAIL PROTECTED]
SYSGO RTS GmbH
Carl-Zeiss-Str. 41 phone: (49) 6131 9138-80
D-55129 Mainz / Germany fax: (49) 6131 9138-10
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Glibc rant
Date: 06 May 1999 09:15:28 -0700
[EMAIL PROTECTED] (Lou Grinzo) writes:
>My point is that when you're talking about a system library,
>a change should NEVER be the proximal cause of apps breaking.
>It's not a matter of whose fault it is, or who did what with
>the library that they weren't supposed to, etc.
>
>Does this cause cruft build up? Absolutely, and I'm as
>militantly anti-cruft as programmers get. But it's still
>better than breaking apps, because cruft costs less in
>the short and long run than alienating users and programmers
>with this sort of compatibility problem.
This is really not a serious consideration in an open
source system. Everything can be recompiled. A distribution
upgrade was all that I required to be fully functional
again. If I didn't want newer versions of everything, I
could keep what I had. Anything that didn't work, I could
recompile.
>The Linux community should be VERY relieved that this happened now,
>and not a year from now, when there would be many more mainstream
>Linux users screaming from the rooftops about how upgrading to RH 8.0
>or SuSE 8.0 broke their apps.
>
>I sincerely hope that everyone involved learned a lesson and won't
>let this happen again. This is exactly the kind of nonsense that
>drives Windows users crazy (they call it "DLL Hell"), and is one of
>the reasons Linux is so appealing to them--it's more stable and far
>less prone to going haywire when you upgrade the system or apps.
No, dll hell is different. If you get a third party app for
Unix, the third party will substitute libraries for the
system's libraries by throwing them somewhere on the disk,
and having a shell script set LD_PRELOAD or LD_LIBRARY_PATH
before calling the real binary executable. StarOffice does this,
as does Matlab. It is the 'right' way to issue a third party
closed source binary. Matlab will never break with a system upgrade,
since it uses ONLY its own libraries.
dll hell occurs because in the infinite wisdom of M$, link libraries
are only found in one place. A third party will regularly, as part
of their install, write over your existing dlls with their own, which
may or may not be compatible. Then you are hosed.
> In my personal usage, Linux has been a rock compared to Windows
>98's house of cards. But I'm sticking with RH 5.2 for my real work
>until this problem is ironed out to the point that all I have to do
>is install a glib 2.2 (2.1A, or whatever) to make all the parts of my
>system peacefully coexist.
You will be waiting a long long time. Because there is not even
a hint from the glibc people that they will ever make a version
that is totally backwards compatible.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: AKK <[EMAIL PROTECTED]>
Crossposted-To:
it.comp.linux.development,comp.os.linux.networking,comp.os.linux.development.apps,comp.programming,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.unix.programmer,comp.unix.sco.programmer
Subject: Re: Get client machine's IP-address
Date: Thu, 06 May 1999 17:10:05 GMT
AKK wrote:
> Iond Research Srl wrote:
>
> > Hi, world
> >
> > Does anybody know how can I get in a stand-alone C/C++ program, running
> > on a server machine
> > but started during a telnet/rlogin session, the IP-address of the client
> > machine that launched the
> > telnet session ?
> >
> > Obviously the program doesn't anything know about the client machine.
> >
>
> In unix all logins are recorded in the /etc/utmp file. You could find out
> the
> format (man utmp) of the file and read the IP address of the client which
> started current session(using current pty as the key) from it or use
> "system" system call to run a script which returns the IP address to an ENV
> variable and read it into the C code
>
> $who -R am i | awk { print $6 } /who with some option depending on the
> / implemetation should
> return the IP of
> /client that started the
> current session
>
> There should be a better way of doing it..any suggestions......
There is a more elegant way of doing it using "popen" in unix.
sid = popen("who am i | awk { print $6 }", "r"};
you can read the o/p from the stream sid - which will get you the IP add
of the client which launched the current session.
------------------------------
From: [EMAIL PROTECTED] (Anthony Ord)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Linux disk defragmenter
Date: Thu, 06 May 1999 17:13:59 GMT
On 5 May 1999 01:22:17 GMT, [EMAIL PROTECTED]
(Andrew Rothstein) wrote:
>Anthony Ord ([EMAIL PROTECTED]) wrote:
>: On 3 May 1999 05:01:13 -0500, [EMAIL PROTECTED]
>: Yes, but has anyone actually *tried* it?
>
>The glory of the GPL ==>
>Go for it ;->
The GPL doesn't prevent me from being too crap to do it...
>Drew
Regards
Anthony
--
=========================================
| And when our worlds |
| They fall apart |
| When the walls come tumbling in |
| Though we may deserve it |
| It will be worth it - Depeche Mode |
=========================================
------------------------------
** 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
******************************
