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

[Emil Velikov]

On 26/02/15 01:55, Jonathan Gray wrote:
> On Wed, Feb 25, 2015 at 10:43:39PM +0000, Emil Velikov wrote:
>> 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.
> 
> 10.4.4 made no difference, I doubt 10.4.5 would either.
> As it's hard for me to build Mesa it's going to be hard to bisect.
> 
> I would be interested to hear if newer Mesa releases work on
> ~ Linux 3.8.
> 
Keeping my fingers crossed.

Just please don't be shy on reporting bugs in bugzilla. Although it's
not the most looked after, it's a great way to get your (non linux folk)
feedback.

>>
>>>  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 ?
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89328
> 
I will try to clear those up, but bth, it won't get fixed overnight.
src/mapi is quite a dense material :-\


> It seems gnu make is a hard requirement as well, is that intentional?
> 
Yes it is. One of the reasons is that we're using/require --std=gnu99.

-Emil