[kde-solaris] KDE 3.3.2, patches for 3.3.1 and some news :-)

[Mats Rojestal]

Hi,

The patch submitted by Christopher is correct and discarding it as buggy 
is totally wrong. There is also a incorrect assumption from Stefan that
you can add more than 2GB swap on a single slice to the system for 
example adding a 8GB slice as a swap is wasting 6GB of disk space due to 
the fact that Solaris so far can't make use of a single swap partition 
larger than 2GB. How ever you can make two or more 2GB swap partitions.
Solaris swap is still 32 bit even on a 64 bit machine.


--Mats R


> 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
>