From owner-svn-src-head@freebsd.org Tue Aug 29 19:18:20 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50EACDE366E for ; Tue, 29 Aug 2017 19:18:20 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F37A66DD20 for ; Tue, 29 Aug 2017 19:18:19 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ua0-x22c.google.com with SMTP id 104so13114861uas.1 for ; Tue, 29 Aug 2017 12:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pCqWQH+xV1sdbc6piJeMx/ei5d1v/xSDZ2LnyUfBAN4=; b=AFSxDF1Rb+vTyIhYiVIOatVfUWUKudsmxVTIr5MceK0vTQ+NKsG00em4hR+KJsiBiR xsqRSDUZnRpWQzneFEg5La+Fcxu1YKq1j/bhShOohnCE/v4w6hgpuaHQsE/9LrZYv5aW ed79I/Px7ZB+/BmmGf4NYyP98PGtA+u6Ohv7Y7DRpMsGC5521GxXCVFpaiK6teH2jLOQ nRrB1Cvm4Hb9BJIlxfpvOgtBatCRZ4slD8SvmHIvSeA6/Z2HhitYMs7qClPMlTkPMQqn 7Fo7EhB5y6sDtYCnriJKBcD1fkx+Yyf2gP27OXpYpNO7r+yGWYSQrVvuHLeoprM5GJpu RF0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pCqWQH+xV1sdbc6piJeMx/ei5d1v/xSDZ2LnyUfBAN4=; b=SDQNpYodGUnEuFfgzF10CF+JcZlQt17Q6k5roHBC6jeUKnP5VTw2SiFpHDv4tX326E WDTOiUSHglpXdERxtuzgL8BhSCV75ORF/CHBLg3p1ZOoZk2EHeF70S28o1X468fvVzA5 MAdA9VCAxsbXfNJsHeaUPiLeLlFgd3CmCXMrf1SwCjBnjcYmuoFSnU8QbR98oyv7Pqn4 TQzmFpi3bG3QwdJ9VviGDkE3ze9hYNPUpEFAZsDcp2r8dMvcoZPE/sqK7P1p00rkVE+/ XfeSxSm7QdCX6Fw+ZBIklURq0OkMLe67UpKA9fvhSbcPKGu06zQsFDd7djicZOcUCAP4 Zy5Q== X-Gm-Message-State: AHYfb5hYOQp3PoeqNsV70af672tCiWkOHuwbCuDrNEhMixPd4g5DTud/ dv8wo4AafQWZLnIM3zV0SI/09NAo8bIE X-Google-Smtp-Source: ADKCNb634g6d7UI7PtPsjtBovznZ5TkxkLY9xFWJIHnW+fwK9sc15E8DAz1jtkiSWF2WHy2T9jfP1N0yfwas3rzPUNU= X-Received: by 10.176.24.75 with SMTP id j11mr981013uag.114.1504034298911; Tue, 29 Aug 2017 12:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.6.137 with HTTP; Tue, 29 Aug 2017 12:18:18 -0700 (PDT) In-Reply-To: <6350259.n2rmZ9RnEY@ralph.baldwin.cx> References: <201708281554.v7SFs8fr014268@repo.freebsd.org> <2937323.CvTEtZnL2T@ralph.baldwin.cx> <6350259.n2rmZ9RnEY@ralph.baldwin.cx> From: Maxim Sobolev Date: Tue, 29 Aug 2017 12:18:18 -0700 Message-ID: Subject: Re: svn commit: r322969 - in head: sbin/mdconfig sys/dev/md sys/sys To: John Baldwin Cc: Ryan Libby , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:18:20 -0000 John, OK, maybe you are right and the current status quo was just an accident. I am curious what do you and other people think about expressing expected structure size and padding more explicitly instead of trying to accommodate for sometimes intricate play between alignment and type size with something like char[N]? I.e. along the following lines: #if __WORDSIZE < 64 #define MD_IOCTL_LEN 436 #else #define MD_IOCTL_LEN 448 #endif struct md_ioctl { union { struct _md_ioctl_payload { unsigned version; /* Structure layout version */ unsigned unit; /* unit number */ enum md_types type ; /* type of disk */ char *file; /* pathname of file to mount */ off_t mediasize; /* size of disk in bytes */ unsigned sectorsize; /* sectorsize */ unsigned options; /* options */ u_int64_t base; /* base address */ int fwheads; /* firmware heads */ int fwsectors; /* firmware sectors */ char *label; /* label of the device */ } md; char raw[MD_IOCTL_LEN]; /* payload + padding for future ideas */ }; }; CTASSERT(sizeof(struct md_ioctl) == MD_IOCTL_LEN); I've tested that it DTRT on i386 and amd64, need to validate on ARM and MIPS. The code impact should be minimal and easy to apply, i.e. ptr->md_ywz becomes ptr->md.xyz. On Tue, Aug 29, 2017 at 7:30 AM, John Baldwin wrote: > On Monday, August 28, 2017 04:40:49 PM Maxim Sobolev wrote: > > John, well, this depends on how you look at it. The padding element size > is > > "int", which when you account for the alignment has the nice property on > > both 32 and 64-bit arches that no matter what kind of element you add > > (char, short, int or void *), you only need to bring down MDNPAD by 1 to > > keep the structure size the same. > > That's only true once. Add a second pointer and this trick won't work > again > on 64-bit platforms. It only worked this time by accident because there > was > unaccounted-for padding at the end of the structure, not on purpose. In > other places in the tree where ABI is more carefully maintained we use > explicit spare pointers or spare longs instead (e.g. padding in > kinfo_proc). > > -- > John Baldwin > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft