[Mesa-stable] [PATCH] auxilary/os: correct sysctl use in os_get_total_physical_memory()

[Emil Velikov]

On 25 February 2015 at 22:19, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Wed, Feb 25, 2015 at 08:49:52PM +0000, Emil Velikov wrote:
>> On 24/02/15 22:48, Jonathan Gray wrote:
>> > On Tue, Feb 24, 2015 at 04:53:03PM +0000, Emil Velikov wrote:
>> >> On 22 February 2015 at 08:19, Jonathan Gray <jsg at jsg.id.au> wrote:
>> >>> The length argument passed to sysctl was the size of the pointer
>> >>> not the type.  The result of this is sysctl calls would fail on
>> >>> 32 bit BSD/Mac OS X.
>> >>>
>> >>> Additionally the wrong pointer was passed as an argument to store
>> >>> the result of the sysctl call.
>> >>>
>> >>> Cc: "10.4, 10.5" <mesa-stable at lists.freedesktop.org>
>> >>> Signed-off-by: Jonathan Gray <jsg at jsg.id.au>
>> >> Seems like my attempt was enough but not quite there yet.
>> >> Thanks for fixing my goof-up.
>> >>
>> >> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
>> >>
>> >> I'll push this in a couple of days unless there are any objections.
>> >>
>> >> Cheers
>> >> Emil
>> >
>> > It should be possible to use the sysconf path in more places
>> > as well.  Classic swrast for example doesn't use sysctl at all.
>> >
>> > OpenBSD/FreeBSD have _SC_PHYS_PAGES/_SC_PAGE_SIZE
>> > NetBSD/Mac OS X don't document _SC_PAGE_SIZE but do document
>> > _SC_PAGESIZE, though I wouldn't be surprised if they
>> > had _SC_PAGE_SIZE in their headers.
>> >
>> If you feel like unifying some code that would be appreciated.
>>
>> Although, I have a greater request from you - can you look at removing
>> the symlinks in src/mesa/drivers/dri/r{adeon,200} ?  Pretty please :-)
>>
>> Restructuring the common bits into one place (radeon_common perhaps ?)
>> will allow one to drop the links, and this will also cut down a fair
>> hunk of the classic dri module binary.
>>
>> Btw did you have the chance to try 10.5 with a simple wrapper, similar
>> to xorg-server ? I believe that most concerns should be sorted out now -
>> no python, lex, etc... dependency.
>
> I have not tracked down the reason but Mesa 10.4.3 (and 10.3.7) caused
> problems with gpu compositing on chrome resulting in a black window
> on older Intel (ie 945gm) and discrete radeons (ie evergreen) but
> not newer Intel hardware like ivy bridge.
>
> As we're busy finishing off a release at the moment I've reverted
> everything to 10.2.9.
Perhaps one could have tried 10.4.4/10.4.5 but I guess I'm pushing it :-)
What kind of bug tracking system do you guys use ? Please don't forget
to give us a shout as you find the culprit for the issue.

>  So it will be a while before I have some
> time to look at importing 10.5.
>
> Grabbing 10.5.0 rc2 it seems python is still required?
>
> python  ./mapi_abi.py --mode lib --printer shared-glapi glapi/gen/gl_and_es_API.xml > shared-glapi/glapi_mapi_tmp.h
> python  ./main/get_hash_generator.py            \
> python  ./main/format_info.py        \
> python  ./gen_xmlpool.py ./t_options.h . ca de es nl fr sv > options.h
>
Hmm those should not be executed if you have the distribution tarball.
Can you open a bug or two if my assumption is incorrect ?

> I also see
> ./util/u_math.h: In function 'u_bit_scan64':
> ./util/u_math.h:591: warning: implicit declaration of function 'ffsll'
>
> which I thought was fixed...
Don't think your fix ever got in - there were a couple of
comments/suggestions, one from Brian and another one from Matt. Cannot
quite see if you've followed up on that one.

Cheers,
Emil