From owner-freebsd-arch@FreeBSD.ORG Sun Oct 3 23:21:51 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 175C51065673 for ; Sun, 3 Oct 2010 23:21:51 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id C01998FC15 for ; Sun, 3 Oct 2010 23:21:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P2Xdo-0006uk-3Z for freebsd-arch@freebsd.org; Mon, 04 Oct 2010 01:06:48 +0200 Received: from 93-141-115-47.adsl.net.t-com.hr ([93.141.115.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Oct 2010 01:06:48 +0200 Received: from ivoras by 93-141-115-47.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Oct 2010 01:06:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Mon, 04 Oct 2010 01:06:39 +0200 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-115-47.adsl.net.t-com.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100620 Thunderbird/3.0.4 In-Reply-To: Subject: Re: Porting effort towards TILERA massive multicore CPUs...? 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: Sun, 03 Oct 2010 23:21:51 -0000 On 09/30/10 12:05, Robert Watson wrote: > > On Sun, 26 Sep 2010, Paketix wrote: > >> there is a rather new processor from TILERA (100 core chip) which is >> most certainly already known here at FreeBSD mailing list. > > Theory has it I'll be getting access to Intel SCC 48/96-core hardware > here at Cambridge in the moderately near future, and I've been pondering > what would be involved. Their model involves 48+ x86 cores without > cache coherency, so you need separate OS instances for each. However, > the cores are linked by fifo-like memory that we'll need to figure out > what to do with. Sounds pretty much made for a variation on the microkernel design, or virtualization. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 7 16:05:52 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 36912106566B for ; Thu, 7 Oct 2010 16:05:52 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7A318FC25 for ; Thu, 7 Oct 2010 16:05:51 +0000 (UTC) Received: by gxk8 with SMTP id 8so4824gxk.13 for ; Thu, 07 Oct 2010 09:05:51 -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:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=RKk85lpFkIqeHIqm6sXquHEQL29SasW30Tm8rZEwm40=; b=V+xuCXuVv+b+mhf0Lgwn0OS4nKk+iZCpOj+eqB3VxP1iqRnFYAYmvQol9Kv7yCDrLS 4GpNNfPzFF3RgScOJ0lKYMm4LyG/w8oQZWD6InHbKIVxKYgTy5nZQK6dyHnr8FbhyMSz QhPXV9XnxZ6pqDbCiGcnZqwGB3NF87RAQr1i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=VayxxdBeHiPJxxSLLdkBSZUHSze39DtIkFxM57d1fpzM2HIC5+96ZzwsOkxu4k2FE0 2v4mFbMKbe4+vV0LzATHtmPc/YQp1eJ0L02uqqjIeM8nkkfs0mvybFuMAV0D1znHgYJG hIiQiY4Q+EuZVHbNCsRjJlBCOkgajUL3MA9dU= MIME-Version: 1.0 Received: by 10.231.170.21 with SMTP id b21mr1055132ibz.122.1286467549725; Thu, 07 Oct 2010 09:05:49 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.142.76 with HTTP; Thu, 7 Oct 2010 09:05:49 -0700 (PDT) Date: Thu, 7 Oct 2010 09:05:49 -0700 X-Google-Sender-Auth: W0cxDvvSpn2AVW3eIs3ipvqMqls Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Subject: freebsd32_ioctl.c 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, 07 Oct 2010 16:05:52 -0000 I added some more ioctls to those translated by freebsd32_ioctl in my local tree, and then I started thinking. If we support all the various drivers as loadable modules, but the ioctl translation is in the base kernel, that's a lot of code to have for COMPAT_IA32 that may never get run. It would be nice to keep the ioctl argument munging in the driver, but while it's not hard to check in the driver's ioctl function if p_sysent is freebsd32_sysent, the code isn't as clean as a passthrough function like freebsd32_ioctl(). So I was wondering if that would be considered an issue. Should we just be adding ioctl argument munging as we go along and not worry about the size? Or is there simple way to keep the munging inside the driver? Perhaps my making the driver's ioctl look something like: #ifdef COMPAT_IA32 static int xxx_ioctl32(struct cdev *dev, u_long com32, caddr_t arg, int flag, struct thread *td) { struct xxx_32 *cmd32 = (void *)arg; struct xxx cmd; u_long com; int error; CP(*cmd32, cmd, field1); /* ... */ error = xxx_ioctl(dev, com, &cmd, flag, td); if (error == 0 && (com & IOC_OUT) != 0) { CP(cmd, *cmd32, field1); /* ... */ } return (error); } #endif /* COMPAT_IA32 */ static int xxx_ioctl_devsw(struct cdev *dev, u_long com, caddr_t arg, int flag, struct thread *td) { #ifdef COMPAT_IA32 if (td->td_proc->p_sysent == &ia32_freebsd_sysvec) return (xxx_ioctl32(dev, com, arg, flag, td)); #endif return (xxx_ioctl(dev, com, arg, flag, td); } ... and the check for p_sysent == &ia32_freebsd_sysvec should probably be a more-correct macro. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Oct 7 16:13:44 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 EAC1A1065673; Thu, 7 Oct 2010 16:13:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6293B8FC20; Thu, 7 Oct 2010 16:13:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o97GDcjI057941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2010 19:13:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o97GDcEj089508; Thu, 7 Oct 2010 19:13:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o97GDc00089507; Thu, 7 Oct 2010 19:13:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Oct 2010 19:13:38 +0300 From: Kostik Belousov To: mdf@freebsd.org Message-ID: <20101007161338.GK2392@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZccQPJAL46kky/Sq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Arch Subject: Re: freebsd32_ioctl.c 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, 07 Oct 2010 16:13:44 -0000 --ZccQPJAL46kky/Sq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 07, 2010 at 09:05:49AM -0700, mdf@freebsd.org wrote: > I added some more ioctls to those translated by freebsd32_ioctl in my > local tree, and then I started thinking. If we support all the > various drivers as loadable modules, but the ioctl translation is in > the base kernel, that's a lot of code to have for COMPAT_IA32 that may > never get run. It would be nice to keep the ioctl argument munging in > the driver, but while it's not hard to check in the driver's ioctl > function if p_sysent is freebsd32_sysent, the code isn't as clean as a > passthrough function like freebsd32_ioctl(). >=20 > So I was wondering if that would be considered an issue. Should we > just be adding ioctl argument munging as we go along and not worry > about the size? Or is there simple way to keep the munging inside the > driver? Perhaps my making the driver's ioctl look something like: I think that in-driver variant is the best. >=20 > #ifdef COMPAT_IA32 > static int > xxx_ioctl32(struct cdev *dev, u_long com32, caddr_t arg, int flag, > struct thread *td) > { > struct xxx_32 *cmd32 =3D (void *)arg; > struct xxx cmd; > u_long com; > int error; >=20 > CP(*cmd32, cmd, field1); > /* ... */ > error =3D xxx_ioctl(dev, com, &cmd, flag, td); > if (error =3D=3D 0 && (com & IOC_OUT) !=3D 0) { > CP(cmd, *cmd32, field1); > /* ... */ > } > return (error); > } > #endif /* COMPAT_IA32 */ >=20 > static int > xxx_ioctl_devsw(struct cdev *dev, u_long com, caddr_t arg, int flag, > struct thread *td) > { > #ifdef COMPAT_IA32 > if (td->td_proc->p_sysent =3D=3D &ia32_freebsd_sysvec) > return (xxx_ioctl32(dev, com, arg, flag, td)); > #endif > return (xxx_ioctl(dev, com, arg, flag, td); > } >=20 > ... and the check for p_sysent =3D=3D &ia32_freebsd_sysvec should probably > be a more-correct macro. if (SV_CURPROC_FLAG(SV_ILP32)) --ZccQPJAL46kky/Sq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyt8bEACgkQC3+MBN1Mb4gU0ACeOIZs5hjj+7kK5TwHQrYNAaG/ GMoAoJ7qeI2y9KGHOClUMBopyo93ImrC =mL3O -----END PGP SIGNATURE----- --ZccQPJAL46kky/Sq-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 7 17:02:43 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 A7FDE1065672 for ; Thu, 7 Oct 2010 17:02:43 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFE98FC0A for ; Thu, 7 Oct 2010 17:02:43 +0000 (UTC) Received: by iwn8 with SMTP id 8so81806iwn.13 for ; Thu, 07 Oct 2010 10:02:42 -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=QZAIM9lt4/EcxoeStAz63PJuQ4zztgLeqhqb47xUK3g=; b=XowexRzzQ8csGvth5VAQj4G+Bgq4AVNSzkzrW0MvbB1pkaPxk976i1vncrxb3nbGsH eIXti+Z6F5xZieoe2oPEQlY60OVL4kAtNUbQtezGBd1G5CAyVXFE8pc203lEzXWjWFFl Es04RzChJyQDAa4JgzSjydkuYfzCu45r6O3ak= 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=QPHEtVmu+r2wol7URIwOe91nbt4chbK9A5u1rm/aaAebz+cczMCzuuVRg46f+YxIeJ QnbBUEtdJnF6w83PYWXpiKOl9OrI3s9ttk0xHH4FI7z5edoAIxIu2eTcrPQnmZv5U6/3 IkTnpVuaD/0qPj6of4fesebjbxJFXifCoMy8o= MIME-Version: 1.0 Received: by 10.231.10.141 with SMTP id p13mr1118446ibp.183.1286470962548; Thu, 07 Oct 2010 10:02:42 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.231.142.76 with HTTP; Thu, 7 Oct 2010 10:02:42 -0700 (PDT) In-Reply-To: <20101007161338.GK2392@deviant.kiev.zoral.com.ua> References: <20101007161338.GK2392@deviant.kiev.zoral.com.ua> Date: Thu, 7 Oct 2010 10:02:42 -0700 X-Google-Sender-Auth: dxHQoiJ4o6V7DAWzpHYHInQr4-c Message-ID: From: mdf@FreeBSD.org To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: freebsd32_ioctl.c 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, 07 Oct 2010 17:02:43 -0000 >>=A0Should we >> just be adding ioctl argument munging as we go along and not worry >> about the size? =A0Or is there simple way to keep the munging inside the >> driver? =A0Perhaps my making the driver's ioctl look something like: > I think that in-driver variant is the best. Okay, I am trying this approach. > =A0 =A0 =A0 =A0if (SV_CURPROC_FLAG(SV_ILP32)) That's what I get for doing development on stable/7. I miss out on the existence of such handy things. Thanks! matthew From owner-freebsd-arch@FreeBSD.ORG Thu Oct 7 17:52:36 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 7591A1065696; Thu, 7 Oct 2010 17:52:36 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 4950E8FC14; Thu, 7 Oct 2010 17:52:36 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 9AEA6582EC; Thu, 7 Oct 2010 12:34:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id fsABixJKwugS; Thu, 7 Oct 2010 12:34:22 -0500 (CDT) Received: from comporellon.tachypleus.net (adsl-75-50-91-12.dsl.mdsnwi.sbcglobal.net [75.50.91.12]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 3F296582E9; Thu, 7 Oct 2010 12:34:22 -0500 (CDT) Message-ID: <4CAE049D.2090603@freebsd.org> Date: Thu, 07 Oct 2010 12:34:21 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.12) Gecko/20100925 Thunderbird/3.0.8 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <20101007161338.GK2392@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , FreeBSD Arch Subject: Re: freebsd32_ioctl.c 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, 07 Oct 2010 17:52:36 -0000 On 10/07/10 12:02, mdf@FreeBSD.org wrote: >>> Should we >>> just be adding ioctl argument munging as we go along and not worry >>> about the size? Or is there simple way to keep the munging inside the >>> driver? Perhaps my making the driver's ioctl look something like: >>> >> I think that in-driver variant is the best. >> > Okay, I am trying this approach. > > >> if (SV_CURPROC_FLAG(SV_ILP32)) >> > That's what I get for doing development on stable/7. I miss out on > the existence of such handy things. > Also bear in mind that freebsd32 is also used on powerpc64 to run 32-bit ppc binaries, so testing for IA32 probably isn't what you want, anyway. -Nathan From owner-freebsd-arch@FreeBSD.ORG Fri Oct 8 10:39:16 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 59BFD106566B; Fri, 8 Oct 2010 10:39:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 301658FC0C; Fri, 8 Oct 2010 10:39:16 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9EF9146B52; Fri, 8 Oct 2010 06:39:15 -0400 (EDT) Date: Fri, 8 Oct 2010 11:39:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Porting effort towards TILERA massive multicore CPUs...? 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, 08 Oct 2010 10:39:16 -0000 On Mon, 4 Oct 2010, Ivan Voras wrote: >>> there is a rather new processor from TILERA (100 core chip) which is most >>> certainly already known here at FreeBSD mailing list. >> >> Theory has it I'll be getting access to Intel SCC 48/96-core hardware here >> at Cambridge in the moderately near future, and I've been pondering what >> would be involved. Their model involves 48+ x86 cores without cache >> coherency, so you need separate OS instances for each. However, the cores >> are linked by fifo-like memory that we'll need to figure out what to do >> with. > > Sounds pretty much made for a variation on the microkernel design, or > virtualization. With repsect to the former: more the distributed microkernel model, or the recently more trendy "multikernel" which appears to be functionally quite similar :-). For the latter: yes, hence the name Single-Chip Cloud Computer. If the TILERA is offering stronger cache coherence properties with similar scalability, that makes it a more appealing target, however. Robert