Around 18 o'clock on Jul 17, Jon Smirl wrote:
> The use of the XFree routines are guarded like this:
>
> #if defined(XFree86LOADER) && defined(IN_MODULE)
>xf86free(ptr);
> #else
>free(ptr);
> #endif
Ah. The XFree86 loader "wraps" libc to attempt to make calls
libc-independent (it isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 17 July 2004 22:34, Jon Smirl wrote:
> What mesa code uses the lines protected by these defines? Building
> linux-dri does not use this code. In fact linux-dri doesn't even need
> the X11 headers to build.
>
> XFree86LOADER
> XFree86Server
What mesa code uses the lines protected by these defines? Building
linux-dri does not use this code. In fact linux-dri doesn't even need
the X11 headers to build.
XFree86LOADER
XFree86Server
IN_MODULE
If these are indeed protecting dead code some significant cleanup can
be done. Looking in mesa/m
The use of the XFree routines are guarded like this:
#if defined(XFree86LOADER) && defined(IN_MODULE)
xf86free(ptr);
#else
free(ptr);
#endif
Does XFree86LOADER and IN_MODULE impact DRI objects or is it ok to use
libc ones?
Now that DRI is building in the mesa tree it should be possible to
Around 10 o'clock on Jul 17, Jon Smirl wrote:
> Can we switch DRI/mesa to use the standard malloc/free and forget about
> the one in the X server? If not we will need some kind of run-time fix up.
Seems like DRI/mesa should just use malloc/free for objects which aren't
related to the X server i
Why does __driCreateNewScreen() need the framebuffer parameter? For
example in the radeon driver case there is common code that drmMap()'s
the framebuffer and builds the framebuffer structure. This structure is
then passed to the radeon implementation of __driCreateNewScreen()
which never uses it.
What are we going to do about DRM_USE_MALLOC? When the DRI binaries are
built for X they use the malloc/free in X. These aren't there in the
solo builds.
Can we switch DRI/mesa to use the standard malloc/free and forget about
the one in the X server? If not we will need some kind of run-time fix
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
http://freedesktop.org/bugzilla/show_bug.cgi?id=733
--- Additional Comments From [EMAIL PROTECTED] 2004-07-17 09:33 ---
(In reply to comment
Context creation in DRM is marked as needing root access. Is this to
prevent a process from doing a DOS attack by creating too many
contexts? Couldn't I do the same DOS attack simply by creating lots of
processes each with their own context?
Is there a hardware limit on contexts? It looks to me li
