xserver: Cleaning up memory allocation functions and macros
eich at suse.de
Mon Apr 30 03:27:07 PDT 2007
Daniel Stone writes:
> > Are you suggesting to call the system provided malloc() from the code
> > directly?
> Is there a reason not to? It's portable and generally highly optimised.
> > X.Org has always also been the sample implementation of the X Window
> > System. Therefore the goal has been to make it portable enough that
> > it can be ported to whatever OS there is (*).
> > Have we abandoned this goal? - To ensure the maximum portability
> > either macros or wrappers seem to be advisable.
> malloc() is portable. Attempting to write our own is suicide. What
> you're proposing is that we write our own C library, because some C
> libraries out there somewhere aren't very good. Even leaving aside the
> fact that we don't even have enough developer resources currently to
> just deal with the server, libraries, and clients, we are never going to
> match glibc or Sun's libc.
Where have I suggested that *we* write/maintain our own
malloc? I've just suggested to leave a door open for those
who want to port X to environments with different
needs and requirementes and make it possible to do so.
I don't even care to see that code - I just want to make
> When we tried with the loader ('not all platforms have libdl, so let's
> write our own'), we ended up exacerbating the problem. To help LynxOS
> or Amoeba or something, meant that we were unable to function on
> Linux/IA64, Linux/HPPA, Linux/SH, and a great many other ports, because,
> surprisingly, no-one wanted to write an entire ELF loader for their
> particular platform, inside the X server.
Daniel, you keep flaming me for suggesting that *we*
develop/support/maintain such kludges.
Nowhere have I suggested this. - Do you think we can we
agree here? :)
What I have suggested was to keep lightweight 'interfaces'
to accomodate those, who need to provide such kludges for
And we may want to stronly encourage them to *not* dump them
into our code but to keep them nicely separated in a library
which they will maintain for their platform and link against.
> The use of malloc() is _not_ a portability problem. If your platform
> has a slow malloc(), then that is exactly the problem: _your platform_
> has a slow malloc().
> If the X server exhibits particular pathological behaviours, then we can
> and should fix it. But if your platform has particular endemic
> problems, then I can tell you exactly where the fault and responsibility
> I don't think you'll find anyone here opposed to actual portability.
> We've always been quite careful to restrict the subset of the C language
> and particular functions we use, and generally ask to make sure that any
> new usage won't break various ports.
OK, portability is fine but it's different. I was suggesting to allow
for the possibility for other X Window System implementors to provide
such 'workarounds' for problems that are known to exist *without* ever
getting involved in supporting them ourselves.
What's so bad about using xalloc() and friends macros which have the
exact same semantics as malloc() and friends instead of calling malloc()
directly? It's light weight, they will not add any overhead to the
binary produced, the semantics will be the same etc.
'Fix your platform' is not an option everywhere. On many platforms
such errands get stonewalled by proprietray vendors. Sound technical
reasoning or waving the POSIX flag will not make vendors to move -
truckloads of money may.
There are plenty of examples in open source applications where cludges
have to be used to work around such issues to make them feasable on a
wide range of platforms.
I think we ought to destinguish if we wanted to make these cludges ourselves
or if made it possible for others to make such kludges.
Do we care about these platforms? Most of *us* here on this list probably
don't. Still in an X.Org context we may want to: After all the X.Org
code is the SI anyone can grab to implement the X Window System on
his pet environment.
Wrapper macros for the alloc functions seem to be a sufficiently lightweight
compromise to keep a bridge open to those who are in a different less
fortunate situation without making any commitment to ever get involved
in doing other people's homework - especially if the bridge is already
> > > - free() can take NULL as argument, so it's not needed to test for NULL
> > > before calling it.
> > Maybe not on all implementations? If we use a wrapper or macro this
> > can be handled there. The default wrapper doesn't need to address this.
> Check what POSIX/SuS says. If it can take it, then we're fine.
> > But they may be handy in situations where a failure is unlikely (so we
> > don't want to be bothered with special handling) but if it happens need
> > to be handled with a proper error message.
> > Driver initialization is a situation that comes to my mind here.
> Using xnf* _is_ special handling.
Right. But it's not done everywhere where these calls take place to
avoid having to add special treatment for the unlikely case in
situations where a failure with a meaningful error message will
More information about the xorg