KDE 3.3.2, patches for 3.3.1 and some news :-)
Christopher Layne
clayne at anodized.com
Wed Feb 9 13:08:32 GMT 2005
On Thu, Feb 03, 2005 at 07:21:19AM -0500, Stefan Teleman wrote:
> The point is that the patch you submitted was flat out wrong. And i
> know for a fact that you were CC'ed on the emails i exchanged with
> kde-core-devel about this back in December 2004.
>
> Everybody is welcome to submit patches as long as these patches make
> things better, not worse.
>
> --Stefan
Really.. flat out wrong?
After slagging through kde-core-devel I found it. Gee, where's
the Cc: line where you apparently CC'd me on it? Yes - that's right
you didn't.
Your mail to core-devel:
From: Stefan Teleman <steleman at nyc.rr.com>
To: KDE Core Devel <kde-core-devel at kde.org>
Date: Sat, 4 Dec 2004 20:16:00 -0500
Subject: bad patch applied to kdebase/kcontrol/memory_solaris.cpp
>From kde-core-devel-bounces-+clayne=anodized.com at kde.org Sat Dec 4 17:27:27 2004
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.5K --]
Hi.
A patch was applied to kdebase/kcontrol/memory_solaris.cpp between
3.3.1 and 3.3.2.
This patch (diff between 3.3.1 and 3.3.2 attached) is wrong. The
values reported by memory_solaris with this new patch are orders of
magnitude off reality.
1. sysconf(_SC_PHYS_PAGES) does not report the total number of pages
available to memory, just the number of pages in physical memory
(i.e. core RAM).
2. swapctl (SC_AINFO, (void *) &struct anoninfo) reports wrong values.
A comment to this effect already exists in memory_solaris.cpp.
Values reported by the new patch :
total memory: 2097152 MB
total swap: 1546632 MB
free swap: 1131280 MB
used swap: 415852 MB
swap -s reports:
[steleman at obiwan][~/tmp][12/04/2004 20:22:21][3353]>> swap -s
total: 276296k bytes allocated + 138784k reserved = 415080k used,
9520168k available
This box has 2GB core RAM and 8GB swap. Total memory should be
reported as 2GB physical + 8GB swap. Total swap should be reported as
8192 MB.
The following #ifdef block is also wrong:
/* Stop <sys/swap.h> from crapping out on 32-bit architectures. */
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
# undef _FILE_OFFSET_BITS
# define _FILE_OFFSET_BITS 32
#endif
_FILE_OFFSET_BITS should *not* be redefined to 32. The error in
sys/procfs.h is fixed by making _FILE_OFFSET_BITS undefined in this
file only.
The values reported by memory_solaris.cpp before this patch were
correct.
--Stefan
--
Stefan Teleman 'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com -Monty Python
---
Now my comments:
"1. sysconf(_SC_PHYS_PAGES) does not report the total number of pages
available to memory, just the number of pages in physical memory
(i.e. core RAM)."
a. This is part of the real memory side of things which I never even changed.
This has *nothing* to do with the changes I made in the patch I submitted.
b. Either I'm stupid or not following you - but it's a standard asumption that
if you're providing both total MEMORY and total SWAP in the same statistical
area that it implies total MEMORY is REAL MEMORY.
"2. swapctl (SC_AINFO, (void *) &struct anoninfo) reports wrong values.
A comment to this effect already exists in memory_solaris.cpp."
Wrong wrong wrong.
At this moment, I'm looking at the Solaris 5.9 source code for swap.c and various
other VM related tools/libs and they're using the same structures and methods as
I did using anoninfo structs. Is Sun wrong too?
Perhaps the comment you're referring to is the one *I* added - which did
not say what you paraphrased. In addition there were no comments present
in the code previous to my patching that dictated what you said above. Go
ahead and check out revision 1.3 of kdebase/kcontrol/info/memory_solaris.cpp
if you don't believe me.
This was my comment added:
/*
* Retrieve overall swap information from anonymous memory structure -
* which is the same way "swap -s" retrieves it's statistics.
*
* swapctl(SC_LIST, void *arg) does not return what we are looking for.
*/
Anyways:
[clayne at build02-sol8-x86 ~]$ swap -s
total: 605024k bytes allocated + 532732k reserved = 1137756k used, 1748648k available
Of which kinfocenter reports:
TOTAL: 2955677696 = 2.75 GB
FREE: 1790738432 = 1.67 GB
USED: 1164939264 (using basic math)
Divide all by 1024, we derive:
USED: 1137636k
FREE: 1748768k
So if you're referring to a 120k difference (when we're dealing with gigs here) as
"orders of magnitude off reality" I really don't know what to tell you.
"The values reported by memory_solaris.cpp before this patch were
correct."
No they were not - which is why I wrote the patch in the first place.
It's quite possible that the code still has issues with machines utilizing greater
than 4GB of swap. In the machine you list as having 8GB as swap, is this a single
8 GB swap file, or multiple?
In regards to the _FILE_OFFSET_BITS issue:
1. Undefine, or set it to 32, it really doesn't matter in this case.
2. I do remember this disussion which you NEVER replied to:
From: steleman at nyc.rr.com
To: KDE Solaris <kde-solaris at mail.kde.org>
Cc: coolo at kde.org, kde-solaris at kde.org, deller at kde.org, waba at kde.org,
tk at Genetik.Uni-Bielefeld.DE
Date: Tue, 19 Oct 2004 23:09:20 -0400
Subject: Re: [kde-solaris] kdebase/kcontrol/info/memory_solaris.cpp patch
>From kde-solaris-bounces-+clayne=anodized.com at mail.kde.org Tue Oct 19 20:21:16 2004
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.8K --]
This is only true for Solaris x86 which currently has no 64-bit support.
It is not true for Solaris SPARC. The patches should be #ifdef'd for Solaris
x86.
--Stefan
-----
From: Christopher Layne <clayne at anodized.com>
To: steleman at nyc.rr.com,
"For people using KDE on Solaris,\
with questions about KDE or Solaris" <kde-solaris at mail.kde.org>
Cc:
Date: Wed, 20 Oct 2004 00:22:54 -0700
Subject: Re: [kde-solaris] kdebase/kcontrol/info/memory_solaris.cpp patch
>From kde-solaris-bounces-+clayne=anodized.com at mail.kde.org Wed Oct 20 00:23:40 2004
On Tue, Oct 19, 2004 at 11:09:20PM -0400, steleman at nyc.rr.com wrote:
> This is only true for Solaris x86 which currently has no 64-bit support.
> It is not true for Solaris SPARC. The patches should be #ifdef'd for Solaris
> x86.
>
> --Stefan
I do not believe the above to be accurate.
[clayne at build01-sol8-sparc ~]$ uname -a
SunOS build01-sol8-sparc.corp.tellme.com 5.8 Generic_108528-22 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
[clayne at build01-sol8-sparc ~]$ egrep 'OFFSET_BITS|large files' /usr/include/sys/swap.h
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error "Cannot use swapctl in the large files compilation environment"
[clayne at sparc-hatch01 ~]$ uname -a
SunOS sparc-hatch01.dev.villa.tellme.com 5.8 Generic_108528-17 sun4u sparc SUNW,UltraAX-i2
[clayne at sparc-hatch01 ~]$ egrep 'OFFSET_BITS|large files' /usr/include/sys/swap.h
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error "Cannot use swapctl in the large files compilation environment"
----
Whats cracks me up is that I start working on some obscure section of kdebase
in regards to Solaris specifics that has not been touched in months and
months and you all of a sudden you feel it necessary to jump on it and point
out how my patches are wrong and how I'm "doing it all wrong." and then begin
your own work on it - after which you've finished you send an email to kde-core-devel
smearing my patch as "bad patch" *without* even CCing me at all.
All I know is that I don't like people flat-out misrepresenting me, particularly
in cases where they want *their* version/changes/contribution/etc to be used
instead.
-cl
___________________________________________________
This message is from the kde-solaris mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde-core-devel
mailing list