From owner-freebsd-arch@FreeBSD.ORG Fri Sep 3 17:07:38 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5319310656CD; Fri, 3 Sep 2010 17:07:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EC3F38FC0C; Fri, 3 Sep 2010 17:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o83GxMic032794; Fri, 3 Sep 2010 10:59:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 03 Sep 2010 10:59:27 -0600 (MDT) Message-Id: <20100903.105927.70320533242210716.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <201009031001.58036.jhb@freebsd.org> References: <4C80A728.6090002@freebsd.org> <201009031001.58036.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: avg@freebsd.org, freebsd-arch@freebsd.org Subject: Re: newbus: type (max value) for device order X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 17:07:38 -0000 In message: <201009031001.58036.jhb@freebsd.org> John Baldwin writes: : On Friday, September 03, 2010 3:43:36 am Andriy Gapon wrote: : > : > device_add_child_ordered() takes order as a parameter of int type. : > struct device stores it as u_char. : > : > This can be confusing, can't it? : > In fact, up to r203776 we used to use order value of 100000 in acpi.c (which : > effectively was 160 according to my calculations). : > : > Not sure what I want to suggest, perhaps defining DEVICE_MAX_ORDER or something. : > Or changing the type in struct device to int. : : Just fix device_t to store an int I think. Also, it should probably be a : u_int as negative values don't really make sense. One caution: u_short flags; /**< internal device flags */ #define DF_ENABLED 1 /* device should be probed/attached */ #define DF_FIXEDCLASS 2 /* devclass specified at create time */ #define DF_WILDCARD 4 /* unit was originally wildcard */ #define DF_DESCMALLOCED 8 /* description was malloced */ #define DF_QUIET 16 /* don't print verbose attach message */ #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ #define DF_REBID 128 /* Can rebid after attach */ #define DF_REMAPPED 256 /* all remapping completed */ u_char order; /**< order from device_add_child_ordered() */ u_char pad; I'd be inclined to change this to: u_int flags; /**< internal device flags */ #define DF_ENABLED 1 /* device should be probed/attached */ #define DF_FIXEDCLASS 2 /* devclass specified at create time */ #define DF_WILDCARD 4 /* unit was originally wildcard */ #define DF_DESCMALLOCED 8 /* description was malloced */ #define DF_QUIET 16 /* don't print verbose attach message */ #define DF_DONENOMATCH 32 /* don't execute DEVICE_NOMATCH again */ #define DF_EXTERNALSOFTC 64 /* softc not allocated by us */ #define DF_REBID 128 /* Can rebid after attach */ #define DF_REMAPPED 256 /* all remapping completed */ u_int order; /**< order from device_add_child_ordered() */ so that the padding and such remains consistent. I think this is even an MFCable change, since device_t's size isn't exposed outside of subr_bus.c... Warner