[PATCH 00/18] Xfbdev Atari and Amiga support

[Geert Uytterhoeven]

Hi Alan,

On Thu, Apr 25, 2013 at 7:42 AM, Alan Coopersmith
<alan.coopersmith at oracle.com> wrote:
> On 04/24/13 10:28 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
>> <alan.coopersmith at oracle.com> wrote:
>>> On 04/24/13 10:00 PM, Keith Packard wrote:
>>>> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
>>>>> On 04/24/13 06:58 PM, Keith Packard wrote:
>>>>>> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
>>>>>>> This broke my build:
>>>>>>>
>>>>>>> Undefined                       first referenced
>>>>>>>     symbol                             in file
>>>>>>> c2p_unsupported
>>>>>>> ../../../miext/shadow/.libs/libshadow.a(shafb4.o)
>>>>>>
>>>>>> Builds fine with GCC; perhaps that figures out that this function can
>>>>>> never be called?
>>>>>
>>>>> If I build with gcc 4.7.2 with -O2 it indeed optimizes it out.
>>>>> If I build with gcc 4.7.2 with -g and no -O flags, it fails the same
>>>>> way.
>>
>> Sorry, I forgot that unlike Linux kernel people, xorg people sometimes
>> do compile
>> without optimization.
>
> Or in the case I first hit this, with optimization using compilers that
> aren't gcc.  (Xorg is built on several non-Linux platforms, with compilers
> such as clang or Solaris Studio.)

Right.

>>>> That makes sense at least. We could either make c2p_unsupported call
>>>> FatalError or just be a no-op. Any preference?
>>>
>>> I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why
>>> stuff isn't working, though FatalError() also works for something that
>>> should be impossible to hit.
>>
>>
>> Or assert(), or <insert xorg favorite runtime check method here>.
>>
>> This should be indeed impossible to hit, as all calls to the c2p functions
>> use hardcoded parameters.
>>
>> I'm just a bit afraid that adding real error handling will slow down the
>> code.
>> Can it be dependent on DEBUG or so?
>
> Does it matter if the compiler optimizes out the call to c2p_unsupported?
> The performance should be the same for you.

Indeed, I forgot about that (just grabbing my morning coffee).

> Or does this code even need to be built for non-68k platforms at all?

No. I don't think Xfbdev already limits some options to certain platforms?

> (I'm still confused why we just took a big chunk of code for a platform
>  with no active maintainer, but if Keith's willing to maintain it himself,
>  that's his call.   I do hope we can fix the license before release to be
>  a standard license, not yet another one-off we all have to add to our
>  packages to comply with the terms of.)

I'm open for license changes. What's the recommended one?
But e.g. shiplan2p8.c was based on shpacked.c, so I mimicked its license
on shpacked.c, and refered to that file.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds