Re: [Qemu-devel] [PATCH 1/3] char: fix alias devices regression

[Markus Armbruster]

Marc-André Lureau <address@hidden> writes:

> Hi
>
> ----- Original Message -----
>> Marc-André Lureau <address@hidden> writes:
>> 
>> > Fix regression from commit 4d43a603c71, where the serial and parallel
>> > headers got removed from char.c, which broke the alias table.
>> >
>> > Signed-off-by: Marc-André Lureau <address@hidden>
>> > ---
>> >  chardev/char.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/chardev/char.c b/chardev/char.c
>> > index 7aa0210765..f38fac5c6b 100644
>> > --- a/chardev/char.c
>> > +++ b/chardev/char.c
>> > @@ -34,6 +34,8 @@
>> >  #include "qemu/help_option.h"
>> >  
>> >  #include "chardev/char-mux.h"
>> > +#include "chardev/char-parallel.h" /* for HAVE_CHARDEV_PARPORT */
>> > +#include "chardev/char-serial.h" /* for HAVE_CHARDEV_SERIAL */
>> >  
>> >  /***********************************************************/
>> >  /* character device */
>> 
>> Two drive-by observations:
>> 
>> * Putting HAVE_FOOs in random headers, then testing them with #ifdef is
>>   asking for trouble.  Anything you test with #ifdef should be there
>>   after #include "qemu/osdep.h" at the latest, or be defined in the same
>>   .c.
>> 
>
> I agree, is it fine to move those HAVE_FOO there?

Let's have a look at the definitions.

    #if defined(__linux__) || defined(__FreeBSD__) ||               \
        defined(__FreeBSD_kernel__) || defined(__DragonFly__)
    #define HAVE_CHARDEV_PARPORT 1
    #endif

Used in char-parallel.c and char.c.  If it was used in just one of them,
I'd ask you to move it there.

    #ifdef _WIN32
    #define HAVE_CHARDEV_SERIAL 1
    #elif defined(__linux__) || defined(__sun__) || defined(__FreeBSD__)    \
        || defined(__NetBSD__) || defined(__OpenBSD__) || 
defined(__DragonFly__) \
        || defined(__GLIBC__)
    #define HAVE_CHARDEV_SERIAL 1
    #endif

Used in char-serial.c and char.c.  Same story.

osdep.h seems like fair game to me.  Precedence: QEMU_VMALLOC_ALIGN.

>> * Such comments after #include rot quickly.  Strong dislike.
>
> Well, if that comment would have been there, there would have been less 
> chance to remove the header by mistake, even if it rotted.

Point taken.  So I dislike a quick-rotting work-around for a bad idea ;)