From owner-freebsd-arch@FreeBSD.ORG Mon Aug 2 16:19:02 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 744B21065676 for ; Mon, 2 Aug 2010 16:19:02 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 286BC8FC23 for ; Mon, 2 Aug 2010 16:19:01 +0000 (UTC) Received: by qyk31 with SMTP id 31so6630318qyk.13 for ; Mon, 02 Aug 2010 09:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JYQnWJUCei/OKom1oJcoDrtl6R4JvVnbYwGbh4Mn+Ms=; b=Mvx4MbaFO+7n9U/gqt1vZgOVfPCeGJGZqQwvEqbesaFP+wpXJ/+qXDZVX/9blGcz2m LM2jFYTTugura/r7Q6jAkZgusWWSk/PU6PPVtRHyP4LceOEyCYGs7v0FmtxIuE8mpiAE J3mGNLfCpTuUP1BtvFehwG3228ugQaZ34h650= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=f1ygSwoshsBIZIdOwSh+6EdCkdBIDg1BkWs3CaUlR3Uam3JsEFB0IeVMHhBw3uKs3J OtAMShkzL+FkHeOs2aBwM9tX32e9ne5T3Rnck3Og7fS0W77RNJsGLGBcOAUEB7RLufOP yvcslGvaQ/8zPRKQyQYekLfsgOtsSKsAEOrMo= MIME-Version: 1.0 Received: by 10.224.19.200 with SMTP id c8mr1868936qab.70.1280765941107; Mon, 02 Aug 2010 09:19:01 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.6.85 with HTTP; Mon, 2 Aug 2010 09:19:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Aug 2010 09:19:00 -0700 X-Google-Sender-Auth: pv5NOqAPOWnqJfFyxEVAVwqBTpM Message-ID: From: mdf@FreeBSD.org To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: brueffer@freebsd.org Subject: Re: memguard(9) rewrite, part 2 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: Mon, 02 Aug 2010 16:19:02 -0000 On Thu, Jul 29, 2010 at 10:01 AM, wrote: > Back in March I asked about interest in a memguard(9) redo. =A0I've had > the time to get the code to a place I'm pretty happy with, and we've > successfully used it at work without running into some of the resource > limitations that the original memguard(9) gave. > > http://people.freebsd.org/~mdf/bsd-memguard.diff > > The gist of the new implementation is to reserve a lot of KVA for > memguard(9) to use, and then to avoid re-using KVA as long as > possible. =A0Rather than keep the physical pages around, though, on > free(9) the pages are returned to the system. =A0The KVA is allocated > using vm_map_findspace() from a current pointer into the memguard_map, > which is incremented until the end of the map is encountered, at which > time it wraps. =A0This is a "free" way to avoid re-use of KVA as long as > possible; any other scheme requires more than O(1) data to track what > has been used. I have a diff of my proposed man page update at http://people.freebsd.org/~mdf/bsd-memguard.9.diff ; my mdoc skills are in their infancy so any suggestions are welcome. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Mon Aug 2 18:12: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 86B2A1065765; Mon, 2 Aug 2010 18:12:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0213C8FC21; Mon, 2 Aug 2010 18:12:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 990A346B95; Mon, 2 Aug 2010 14:12:36 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 93C6F8A04F; Mon, 2 Aug 2010 14:12:35 -0400 (EDT) From: John Baldwin To: Alan Cox Date: Mon, 2 Aug 2010 09:42:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <4C4DB2B8.9080404@freebsd.org> <201007301614.40768.jhb@freebsd.org> <4C54981B.9080209@cs.rice.edu> In-Reply-To: <4C54981B.9080209@cs.rice.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008020942.29654.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 02 Aug 2010 14:12:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: alc@freebsd.org, freebsd-arch@freebsd.org Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? 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: Mon, 02 Aug 2010 18:12:38 -0000 On Saturday, July 31, 2010 5:39:39 pm Alan Cox wrote: > John Baldwin wrote: > > On Friday, July 30, 2010 2:49:59 pm Alan Cox wrote: > >> With that in mind, the following patch slows the growth of "virt" from > >> 2/5 of vm_kmem_size to 1/7. This has no effect on amd64. However, on > >> i386. it allows desiredvnodes to grow slowly for machines with 1.5GB to > >> about 2.5GB of RAM, ultimately exceeding the old desiredvnodes cap by > >> about 17%. Once we exceed the old cap, we increase desiredvnodes at a > >> marginal rate that is almost the same as your patch, about 1% of > >> physical memory. It's just computed differently. > >> > >> Using 1/8 instead of 1/7, amd64 machines with less than about 1.5GB lose > >> about 7% of their vnodes, but they catch up and pass the old limit by > >> 1.625GB. Perhaps, more importantly, i386 machines only exceed the old > >> cap by 3%. > >> > >> Thoughts? > > > > I think this is much better. My strawman was rather hackish in that it was > > layering a hack on top of the existing calculations. I prefer your approach. > > I do not think penalizing amd64 machines with less than 1.5GB is a big worry > > as most x86 machines with a small amount of memory are probably running as > > i386 anyway. Given that, I would probably lean towards 1/8 instead of 1/7, > > but I would be happy with either one. > > I've looked a bit at an i386/PAE system with 8GB. I don't think that a > default configuration, e.g., no changes to the mbuf limits, is at risk > with 1/7. Ok. > > How is this value computed? I would prefer something like: > > > > '512 * 1024 * 1024 * 1024 / (sizeof(struct vnode) + sizeof(struct vm_object) / N' > > > > if that is how it is computed. A brief note about the magic number of 393216 > > would also be nice to have (and if it could be a constant with a similar > > formula value that would be nice, too.). > > > > > > I've tried to explain this computation below. Thanks, it looks good to me now. > Index: kern/vfs_subr.c > =================================================================== > --- kern/vfs_subr.c (revision 210702) > +++ kern/vfs_subr.c (working copy) > @@ -282,23 +282,34 @@ SYSCTL_INT(_debug, OID_AUTO, vnlru_nowhere, CTLFLA > > /* > * Initialize the vnode management data structures. > + * > + * Reevaluate the following cap on the number of vnodes after the physical > + * memory size exceeds 512GB. In the limit, as the physical memory size > + * grows, the ratio of physical pages to vnodes approaches sixteen to one. > */ > #ifndef MAXVNODES_MAX > -#define MAXVNODES_MAX 100000 > +#define MAXVNODES_MAX (512 * (1024 * 1024 * 1024 / PAGE_SIZE / > 16)) > #endif > static void > vntblinit(void *dummy __unused) > { > + int physvnodes, virtvnodes; > > /* > - * Desiredvnodes is a function of the physical memory size and > - * the kernel's heap size. Specifically, desiredvnodes scales > - * in proportion to the physical memory size until two fifths > - * of the kernel's heap size is consumed by vnodes and vm > - * objects. > + * Desiredvnodes is a function of the physical memory size and the > + * kernel's heap size. Generally speaking, it scales with the > + * physical memory size. The ratio of desiredvnodes to physical > pages > + * is one to four until desiredvnodes exceeds 98,304. > Thereafter, the > + * marginal ratio of desiredvnodes to physical pages is one to > + * sixteen. However, desiredvnodes is limited by the kernel's heap > + * size. The memory required by desiredvnodes vnodes and vm objects > + * may not exceed one seventh of the kernel's heap size. > */ > - desiredvnodes = min(maxproc + cnt.v_page_count / 4, 2 * > vm_kmem_size / > - (5 * (sizeof(struct vm_object) + sizeof(struct vnode)))); > + physvnodes = maxproc + cnt.v_page_count / 16 + 3 * min(98304 * 4, > + cnt.v_page_count) / 16; > + virtvnodes = vm_kmem_size / (7 * (sizeof(struct vm_object) + > + sizeof(struct vnode))); > + desiredvnodes = min(physvnodes, virtvnodes); > if (desiredvnodes > MAXVNODES_MAX) { > if (bootverbose) > printf("Reducing kern.maxvnodes %d -> %d\n", > > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Aug 5 22:12:22 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AADF4106566C for ; Thu, 5 Aug 2010 22:12:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6CDAB8FC24 for ; Thu, 5 Aug 2010 22:12:22 +0000 (UTC) Received: by qyk11 with SMTP id 11so3817545qyk.13 for ; Thu, 05 Aug 2010 15:12:21 -0700 (PDT) Received: by 10.224.20.78 with SMTP id e14mr5337447qab.135.1281044725964; Thu, 05 Aug 2010 14:45:25 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id r38sm758747qcs.2.2010.08.05.14.45.23 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 14:45:24 -0700 (PDT) Date: Thu, 5 Aug 2010 11:46:07 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Change to sysctl to support linux kobj 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: Thu, 05 Aug 2010 22:12:22 -0000 Hi folks, I really need two pointer arguments to a sysctl function to support linux sysfs via sysctl. To facilitate this I propose changing the int arg2 to a uinptr_t. This keeps it as an integer type but makes it wide enough to accept a pointer. A small number of places in the kernel have to be fixed for the new type or because they don't use SYSCTL_HANDLER_ARGS. This will introduce an api/abi incompatibility although it is relatively minor. Comments? Alternatives? Thanks, Jeff Index: sysctl.h =================================================================== --- sysctl.h (revision 207767) +++ sysctl.h (working copy) @@ -114,8 +114,8 @@ #define CTL_AUTO_START 0x100 #ifdef _KERNEL -#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2, \ - struct sysctl_req *req +#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, \ + uintptr_t arg2, struct sysctl_req *req /* definitions for sysctl_req 'lock' member */ #define REQ_UNLOCKED 0 /* not locked and not wired */ @@ -158,7 +158,7 @@ int oid_number; u_int oid_kind; void *oid_arg1; - int oid_arg2; + uintptr_t oid_arg2; const char *oid_name; int (*oid_handler)(SYSCTL_HANDLER_ARGS); const char *oid_fmt; From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 15:58:31 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 3F4A51065673 for ; Fri, 6 Aug 2010 15:58:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDBB8FC0C for ; Fri, 6 Aug 2010 15:58:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A031F46C05; Fri, 6 Aug 2010 11:58:30 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 898778A03C; Fri, 6 Aug 2010 11:58:29 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 6 Aug 2010 10:30:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008061030.03214.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 06 Aug 2010 11:58:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Change to sysctl to support linux kobj 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, 06 Aug 2010 15:58:31 -0000 On Thursday, August 05, 2010 5:46:07 pm Jeff Roberson wrote: > Hi folks, > > I really need two pointer arguments to a sysctl function to support linux > sysfs via sysctl. To facilitate this I propose changing the int arg2 to a > uinptr_t. This keeps it as an integer type but makes it wide enough to > accept a pointer. A small number of places in the kernel have to be fixed > for the new type or because they don't use SYSCTL_HANDLER_ARGS. This will > introduce an api/abi incompatibility although it is relatively minor. > > Comments? Alternatives? Presumably it should be intptr_t to stay signed. One could always create a structure that holds the two pointers and pass that as arg1 also which is what other code does that needs to pass in more than a simple pointer to an int, etc. as well. > Thanks, > Jeff > > Index: sysctl.h > =================================================================== > --- sysctl.h (revision 207767) > +++ sysctl.h (working copy) > @@ -114,8 +114,8 @@ > #define CTL_AUTO_START 0x100 > > #ifdef _KERNEL > -#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg2, \ > - struct sysctl_req *req > +#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, \ > + uintptr_t arg2, struct sysctl_req *req > > /* definitions for sysctl_req 'lock' member */ > #define REQ_UNLOCKED 0 /* not locked and not wired */ > @@ -158,7 +158,7 @@ > int oid_number; > u_int oid_kind; > void *oid_arg1; > - int oid_arg2; > + uintptr_t oid_arg2; > const char *oid_name; > int (*oid_handler)(SYSCTL_HANDLER_ARGS); > const char *oid_fmt; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 22:41:31 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE38106566C for ; Fri, 6 Aug 2010 22:41:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3EB08FC14 for ; Fri, 6 Aug 2010 22:41:30 +0000 (UTC) Received: by qwg5 with SMTP id 5so4074829qwg.13 for ; Fri, 06 Aug 2010 15:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.69.17 with SMTP id x17mr6408316qai.283.1281133184956; Fri, 06 Aug 2010 15:19:44 -0700 (PDT) Received: by 10.229.189.15 with HTTP; Fri, 6 Aug 2010 15:19:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Aug 2010 15:19:44 -0700 Message-ID: From: Peter Wemm To: Jeff Roberson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Change to sysctl to support linux kobj 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, 06 Aug 2010 22:41:31 -0000 On Thu, Aug 5, 2010 at 2:46 PM, Jeff Roberson wro= te: > Hi folks, > > I really need two pointer arguments to a sysctl function to support linux > sysfs via sysctl. =A0To facilitate this I propose changing the int arg2 t= o a > uinptr_t. =A0This keeps it as an integer type but makes it wide enough to > accept a pointer. =A0A small number of places in the kernel have to be fi= xed > for the new type or because they don't use SYSCTL_HANDLER_ARGS. =A0This w= ill > introduce an api/abi incompatibility although it is relatively minor. > > Comments? =A0Alternatives? > > Thanks, > Jeff > > Index: sysctl.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sysctl.h =A0 =A0(revision 207767) > +++ sysctl.h =A0 =A0(working copy) > @@ -114,8 +114,8 @@ > =A0#define CTL_AUTO_START 0x100 > > =A0#ifdef _KERNEL > -#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int arg= 2, > \ > - =A0 =A0 =A0 struct sysctl_req *req > +#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, =A0 =A0= =A0 \ > + =A0 =A0 =A0 uintptr_t arg2, struct sysctl_req *req > > =A0/* definitions for sysctl_req 'lock' member */ > =A0#define REQ_UNLOCKED =A0 0 =A0 =A0 =A0 /* not locked and not wired */ > @@ -158,7 +158,7 @@ > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 oid_number; > =A0 =A0 =A0 =A0u_int =A0 =A0 =A0 =A0 =A0 oid_kind; > =A0 =A0 =A0 =A0void =A0 =A0 =A0 =A0 =A0 =A0*oid_arg1; > - =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 oid_arg2; > + =A0 =A0 =A0 uintptr_t =A0 =A0 =A0 oid_arg2; > =A0 =A0 =A0 =A0const char =A0 =A0 =A0*oid_name; > =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 (*oid_handler)(SYSCTL_HANDLER_= ARGS); > =A0 =A0 =A0 =A0const char =A0 =A0 =A0*oid_fmt; > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > My initial thoughts.. 32 bit systems should be unaffected. Impact on 64 bit systems may be low.. For the args passing on amd64, that should be covered by the already 64 bit register passing. The impact on sysctl_oid struct is varied. It won't change the size on 64 bit systems because of native alignment requirements adding invisible padding in the structure already. A 64 bit type, followed by 32 bit, followed by 64 bit, leaves space to expand the 32 bit to a 64 bit object. However, little vs big endian is affected to a different degree. Big endian ppc64 would be affected since the oid_arg2 fields won't be in the same bit positions. The impact on little endian systems depends on what goes into the padding area. If it is usually initialized to zeroes, we might get away with it. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 23:16:37 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0DB1106567B for ; Fri, 6 Aug 2010 23:16:37 +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 5E2728FC12 for ; Fri, 6 Aug 2010 23:16:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o76NEdge056679; Fri, 6 Aug 2010 17:14:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Aug 2010 17:15:10 -0600 (MDT) Message-Id: <20100806.171510.506212773199813899.imp@bsdimp.com> To: jroberson@jroberson.net From: "M. Warner Losh" In-Reply-To: References: 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: arch@freebsd.org Subject: Re: Change to sysctl to support linux kobj 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, 06 Aug 2010 23:16:37 -0000 In message: Jeff Roberson writes: : Hi folks, : : I really need two pointer arguments to a sysctl function to support : linux sysfs via sysctl. To facilitate this I propose changing the int : arg2 to a uinptr_t. This keeps it as an integer type but makes it : wide enough to accept a pointer. A small number of places in the : kernel have to be fixed for the new type or because they don't use : SYSCTL_HANDLER_ARGS. This will introduce an api/abi incompatibility : although it is relatively minor. : : Comments? Alternatives? : : Thanks, : Jeff : : Index: sysctl.h : =================================================================== : --- sysctl.h (revision 207767) : +++ sysctl.h (working copy) : @@ -114,8 +114,8 @@ : #define CTL_AUTO_START 0x100 : : #ifdef _KERNEL : -#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, int : -#arg2, \ : - struct sysctl_req *req : +#define SYSCTL_HANDLER_ARGS struct sysctl_oid *oidp, void *arg1, \ : + uintptr_t arg2, struct sysctl_req *req : : /* definitions for sysctl_req 'lock' member */ : #define REQ_UNLOCKED 0 /* not locked and not wired */ : @@ -158,7 +158,7 @@ : int oid_number; : u_int oid_kind; : void *oid_arg1; : - int oid_arg2; : + uintptr_t oid_arg2; : const char *oid_name; : int (*oid_handler)(SYSCTL_HANDLER_ARGS); : const char *oid_fmt; We've been making a lot of changes to the MIPS tree that involve using intptr_t when dealing with addresses to get the proper sign extension to happen. I'm unsure if this would be a good thing or not more generally, but at least two architectures use this convention (MIPS and the now-defunct alpha). Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 23:17:12 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 C8D90106566B for ; Fri, 6 Aug 2010 23:17:12 +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 624908FC31 for ; Fri, 6 Aug 2010 23:17:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o76N9UvR056603; Fri, 6 Aug 2010 17:09:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Aug 2010 17:09:53 -0600 (MDT) Message-Id: <20100806.170953.119882392252204233.imp@bsdimp.com> To: tijl@coosemans.org From: "M. Warner Losh" In-Reply-To: <201007291718.12687.tijl@coosemans.org> References: <201007291718.12687.tijl@coosemans.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: pluknet@gmail.com, freebsd-arch@freebsd.org Subject: Re: Support for cc -m32 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, 06 Aug 2010 23:17:12 -0000 In message: <201007291718.12687.tijl@coosemans.org> Tijl Coosemans writes: : Hi, : : I've put the initial version of some patches online to support cross : compilation of 32 bit binaries on amd64. It's modelled after how NetBSD : does this. : : With these patches something like "cc -m32 -o test test.c -pthread -lm" : generates a program that runs on FreeBSD/i386. : : http://people.freebsd.org/~tijl/cc-m32-1.diff : http://people.freebsd.org/~tijl/cc-m32-2.diff : http://people.freebsd.org/~tijl/cc-m32-3.diff : : *cc-m32-1.diff* : Let ld and cc find 32 bit libraries. : : *cc-m32-2.diff* : Install i386 headers on amd64. : : With this patch headers for a particular $arch are always installed : under /usr/include/$arch and /usr/include/machine becomes a symlink. This patch is wrong. /usr/include/machine is for sys/$MACHINE/include, not for sys/$MACHINE_ARCH/include. These can (and will) be different. Today in the pc98/i386 case, but in the future in the mipsel/mips, mipseb/mips and armeb/arm cases. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Aug 7 09:37:50 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 49CBB106564A for ; Sat, 7 Aug 2010 09:37:50 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id D7E7F8FC1B for ; Sat, 7 Aug 2010 09:37:49 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALLEXExbsZwY/2dsb2JhbACgS3LBPIU6BA Received: from 24.156-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.156.24]) by relay.skynet.be with ESMTP; 07 Aug 2010 11:37:46 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o779bk4Y001567; Sat, 7 Aug 2010 11:37:46 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: "M. Warner Losh" Date: Sat, 7 Aug 2010 11:37:38 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-PRERELEASE; KDE/4.4.5; i386; ; ) References: <201007291718.12687.tijl@coosemans.org> <20100806.170953.119882392252204233.imp@bsdimp.com> In-Reply-To: <20100806.170953.119882392252204233.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2715759.BhTqe3yHZp"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201008071137.45543.tijl@coosemans.org> Cc: pluknet@gmail.com, freebsd-arch@freebsd.org Subject: Re: Support for cc -m32 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: Sat, 07 Aug 2010 09:37:50 -0000 --nextPart2715759.BhTqe3yHZp Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday 07 August 2010 01:09:53 M. Warner Losh wrote: > In message: <201007291718.12687.tijl@coosemans.org> > Tijl Coosemans writes: > : I've put the initial version of some patches online to support cross > : compilation of 32 bit binaries on amd64. It's modelled after how NetBSD > : does this. > :=20 > : With these patches something like "cc -m32 -o test test.c -pthread -lm" > : generates a program that runs on FreeBSD/i386. > :=20 > : http://people.freebsd.org/~tijl/cc-m32-1.diff > : http://people.freebsd.org/~tijl/cc-m32-2.diff > : http://people.freebsd.org/~tijl/cc-m32-3.diff > :=20 > : *cc-m32-1.diff* : Let ld and cc find 32 bit libraries. > :=20 > : *cc-m32-2.diff* : Install i386 headers on amd64. > :=20 > : With this patch headers for a particular $arch are always installed > : under /usr/include/$arch and /usr/include/machine becomes a symlink. >=20 > This patch is wrong. /usr/include/machine is for > sys/$MACHINE/include, not for sys/$MACHINE_ARCH/include. These can > (and will) be different. Today in the pc98/i386 case, but in the > future in the mipsel/mips, mipseb/mips and armeb/arm cases. Could you clarify this somewhat? I think the patch already does that. It installs headers for ${MACHINE} under /usr/include/${MACHINE}, headers for ${MACHINE_ARCH} (when different from ${MACHINE}) under /usr/include/${MACHINE_ARCH} and symlinks /usr/include/machine to /usr/include/${MACHINE}. On amd64 it also installs i386 headers under /usr/include/i386. --nextPart2715759.BhTqe3yHZp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iF4EABEIAAYFAkxdKWkACgkQfoCS2CCgtitOrwD6AoEyu+6Eb1eWpqki1CHcM/xE lkhEOtRu7oBZjDt3SX4A/RnnGt6taO7wYFXZvjfheO7z+pIKi2dPGTnZEyYA+P7g =1NOz -----END PGP SIGNATURE----- --nextPart2715759.BhTqe3yHZp--