All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: netdev@vger.kernel.org, Pavel Emelyanov <xemul@virtuozzo.com>
Subject: Re: uapi: MAX_ADDR_LEN vs. numeric 32
Date: Sat, 5 Aug 2017 01:25:19 +0300	[thread overview]
Message-ID: <20170804222519.GA11085@altlinux.org> (raw)
In-Reply-To: <20170804213325.GC28459@lakka.kapsi.fi>

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

Hi,

On Sat, Aug 05, 2017 at 12:33:25AM +0300, Mikko Rapeli wrote:
> First, thanks Dmitry for fixing several uapi compilation problems in
> user space. I got a bit demotivated

That's quite understandable.

> about the slow review progress, e.g.
> no feedback what so ever, on some of the patches, but lets try again...
> 
> I rebased my tree now and saw
> 
> commit 745cb7f8a5de0805cade3de3991b7a95317c7c73
> Author: Dmitry V. Levin <ldv@altlinux.org>
> Date:   Tue Mar 7 23:50:50 2017 +0300
> 
>     uapi: fix linux/packet_diag.h userspace compilation error
> 
> which does:
> 
> --- a/include/uapi/linux/packet_diag.h
> +++ b/include/uapi/linux/packet_diag.h
> @@ -64,7 +64,7 @@ struct packet_diag_mclist {
>         __u32   pdmc_count;
>         __u16   pdmc_type;
>         __u16   pdmc_alen;
> -       __u8    pdmc_addr[MAX_ADDR_LEN];
> +       __u8    pdmc_addr[32]; /* MAX_ADDR_LEN */
>  };
>  
>  struct packet_diag_ring {
> 
> In my tree I had fixed that case with:
> 
> --- a/include/uapi/linux/packet_diag.h
> +++ b/include/uapi/linux/packet_diag.h
> @@ -2,6 +2,7 @@
>  #define __PACKET_DIAG_H__
>  
>  #include <linux/types.h>
> +#include <linux/netdevice.h>
>  
>  struct packet_diag_req {
>         __u8    sdiag_family;
> 
> since netdevice.h has the definition also in user space
> 
> #define MAX_ADDR_LEN    32              /* Largest hardware address length */
> 
> I find using MAX_ADDR_LEN better than numeric 32, though I doubt this will
> change any time soon. Would you mind if I change packet_diag.h and
> if_link.h to use that instead and fix the userspace compilation
> problems by including netdevice.h?

The alternative fix, that is, to include <linux/netdevice.h>
which pulls in other headers and a lot of definitions with them,
has been mentioned in the discussion, too.
We decided that the fix that was applied would be the least of all evils.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2017-08-04 22:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 21:33 uapi: MAX_ADDR_LEN vs. numeric 32 Mikko Rapeli
2017-08-04 22:25 ` Dmitry V. Levin [this message]
2017-08-04 22:34   ` Mikko Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170804222519.GA11085@altlinux.org \
    --to=ldv@altlinux.org \
    --cc=mikko.rapeli@iki.fi \
    --cc=netdev@vger.kernel.org \
    --cc=xemul@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.