xserver: Cleaning up memory allocation functions and macros
Egbert Eich
eich at suse.de
Mon May 7 12:33:19 PDT 2007
Daniel Stone writes:
>
> What would we be deprecating? Some macros and wrappers? Usually we
> reserve deprecation notices for subsystems or large bodies of code;
> else, we'd be issuing deprecation notices and attempting to consult with
> a community that, in all likelihood, does not exist[0], every time ajax
> committed something.
>
> We have been explicit in aying many times since 6.7.0 that a system
> which at least pays lip service to POSIX, as well as a compiler that
> supports ANSI C (and, now, named initialisers and variadic macros) is
> essential.
>
>
> > Surely apart from the porting issues there may be plenty of other use
> > cases where someone might want to wrap these functions.
>
> Such as?
I've hooked in various memory debuggers as well as small and quickly
written wrappers that addressed exactly what I was looking for in
the particular situation.
It's easy, quick and it'll work everywhere - as it doesn't depend
on LD_PRELOAD and other dynamic linker features.
But I concede: On all systems I've got here (even the oldest ones)
are able to wrap or intercept malloc() and friends or any other
system library call and there are different ways to do it.
I don't know of all other OS we presently support can handle this
similarly. At least noone has complained here so I assume they
do.
In this case we can probably savely drop all these wrappers.
>
> [0]: I must admit to being at a loss over how to interact on matters
> such as these with people who aren't on xorg at .
Exactly.
I understand that for some who work off the SI the
traffic on xorg@ is to high wile most subjects are
irrelevant to them.
Once we had the architecture WG and mailing list to
discuss such things.
There didn't seem to be an overly large interest in
that - also not from those who consume X.
We know some vendors who make use of our SI as they
are sponsors of this organization. So they could be
asked how they prefer to interact.
Cheers,
Egbert.
More information about the xorg
mailing list