From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 11:24:38 2009 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 CB4B11065670 for ; Sun, 5 Apr 2009 11:24:38 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 69CB28FC1E for ; Sun, 5 Apr 2009 11:24:38 +0000 (UTC) (envelope-from kmsujit@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so1900295tia.3 for ; Sun, 05 Apr 2009 04:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yjcEG+jv4nzFqwTCLkdP6B3LDEtsp4G9R2eK5HXR/p8=; b=pHD/K5aTK3WHf7ylYoK6VtktZcUDUZQwglZcGI5Cjrli9uX7hzwf/u/6gHP+niYV4r dXyeMINy0h3SxkAEV7oLATuNjZ2pmA9csdN7aTJJjUXJFJOOw+s4ZA7ouYgbwjbiY9Ay xs9vHODFhfdb1ot+VZCcQudCQRoNHQZswVDSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uTZ1uI3AuP46yAhhAwWVve6O2Ukb6Ykl2lDb/fxoSAJhy/MMdLodKr8B2gUnUGtcZk bypQYAOIxdpTswzkWiUMKepCbM9NUAzYMRh4t6QU6qcj8r8TJKFjLq9+QDrYC7mZPxgn doGm7P+hS4d3F0uvp6dj4TpZ31VU4F0Sw7+Ko= MIME-Version: 1.0 Received: by 10.110.33.15 with SMTP id g15mr4777971tig.1.1238929432691; Sun, 05 Apr 2009 04:03:52 -0700 (PDT) In-Reply-To: <821081.71230.qm@web7703.mail.in.yahoo.com> References: <821081.71230.qm@web7703.mail.in.yahoo.com> Date: Sun, 5 Apr 2009 16:33:52 +0530 Message-ID: <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> From: Sujit K M To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kamlesh Patel Subject: Re: GSoC 2009 Project proposal Review 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, 05 Apr 2009 11:24:39 -0000 > May 23-June 6:=A0=A0=A0=A0 Write FreeBSD driver skeleton for GEOM driver. Could you clarify why this is on the GEOM Driver. Why Not be dependent on the technology like USB/FireWire/Hot Plug. Can this be achieved by using GEOM Drivers /dev interface. > June 14-June 20:=A0 Implement ECC routines ECC? Why Develop ECC routines. Are you specifically develop drivers that are chipset dependent. > July 26-Aug 15:=A0=A0 Get ufs working on the flash device, tune performan= ce. Why UFS? What Performance? Are you going to have Application Interface for executable. Could you specify which institution or company you are representing. From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 11:37:40 2009 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 988C3106566B for ; Sun, 5 Apr 2009 11:37:40 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4767F8FC15 for ; Sun, 5 Apr 2009 11:37:40 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LqQfS-0002y8-KP for freebsd-arch@freebsd.org; Sun, 05 Apr 2009 11:37:38 +0000 Received: from 93-141-3-137.adsl.net.t-com.hr ([93.141.3.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2009 11:37:38 +0000 Received: from ivoras by 93-141-3-137.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Apr 2009 11:37:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sun, 05 Apr 2009 13:37:08 +0200 Lines: 33 Message-ID: References: <821081.71230.qm@web7703.mail.in.yahoo.com> <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6A513FC19EAF0A1B5B6E6E7" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-141-3-137.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <74fe56020904050403x595af1a9of03b82e6356efacd@mail.gmail.com> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: GSoC 2009 Project proposal Review 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, 05 Apr 2009 11:37:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6A513FC19EAF0A1B5B6E6E7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sujit K M wrote: >> May 23-June 6: Write FreeBSD driver skeleton for GEOM driver. > Could you clarify why this is on the GEOM Driver. Why Not be dependent= > on the technology like USB/FireWire/Hot Plug. Can this be achieved by u= sing > GEOM Drivers /dev interface. I believe this was unfortunate wording on his part - any storage driver is a GEOM driver because the GEOM device is the top-level end-point for i= t. --------------enigE6A513FC19EAF0A1B5B6E6E7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknYl+QACgkQldnAQVacBciGmgCgqIdGp83N0+pTTgz11PEMh/qD hXkAniDg741DdIgoGmDfPbEx+U9A/S1G =90d0 -----END PGP SIGNATURE----- --------------enigE6A513FC19EAF0A1B5B6E6E7-- From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 17:28:57 2009 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 49F1210656D6 for ; Sun, 5 Apr 2009 17:28:57 +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 246768FC1A for ; Sun, 5 Apr 2009 17:28:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CFE2B46B58; Sun, 5 Apr 2009 13:28:56 -0400 (EDT) Date: Sun, 5 Apr 2009 18:28:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rick Macklem 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: getting a callback ip address for nfsv4 client 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, 05 Apr 2009 17:28:58 -0000 On Mon, 30 Mar 2009, Rick Macklem wrote: > Well, since the last one turned out to be too easy, here's one I think is a > little tougher... > > The nfsv4 client needs to know an ip address for the machine, that can be > used by servers to do callbacks on the client. I currently use the > following, which I know isn't correct, but usually works ok: > > loopb = htonl(INADDR_LOOPBACK); > TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > if (IA_SIN(ia)->sin_addr.s_addr != loopb) > return (&(IA_SIN(ia)->sin_addr.s_addr)); > } > return (NULL); > > Now, I could just make it a constant set by an rc script (argument to the > callback daemon or a sysctl variable), but that's a bother for laptops using > dhcp and similar. I think allowing an argument to the callback daemon is a > good fallback, but it would be nice if it didn't normally have to be set for > things to work ok. > > Any ideas on how to do this? > > Thanks in advance for any help, rick ps: Part of the reason that the above > loop doesn't seem to be good > enough is that it requires "options VIMAGE_GLOBALS" to build. One possibility is to connect() a socket to the server address, then call getsockaddr() to query what address the network stack is using. If the connection completed, then the address could at least send packets to the server, even if it isn't reachable from the server. (Obviously, kernel versions of the above...) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 17:31:59 2009 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 BB6CB1065672 for ; Sun, 5 Apr 2009 17:31:59 +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 99AB68FC17 for ; Sun, 5 Apr 2009 17:31:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 3D9E546B0D; Sun, 5 Apr 2009 13:31:59 -0400 (EDT) Date: Sun, 5 Apr 2009 18:31:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <20080412021209.W43186@desktop> Message-ID: References: <20080412021209.W43186@desktop> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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, 05 Apr 2009 17:32:01 -0000 On Sat, 12 Apr 2008, Jeff Roberson wrote: > As far as I can tell this has never been used. Unless someone can show me > otherwise I'm going to go ahead and remove it. (A year, +/- one week, passes...) Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, and NQNFS is long-gone, I propose we revisit removing VOP_LEASE, which you proposed last year but presumably died as a result of a discussion of whether it might be useful again someday. While not a huge overhead, in practice it means a passage through the VOP vector for every I/O operation, and it certainly adds lines of code. Assuming no objections in the few days, I'll toast VOP_LEASE implementation and calls from the rest of the stack from 8.x so that it's gone before we ship 8.0. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 19:27:46 2009 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 D4D97106564A; Sun, 5 Apr 2009 19:27:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 39C0B8FC15; Sun, 5 Apr 2009 19:27:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n35JRi0s016713; Sun, 5 Apr 2009 15:27:45 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n35JXrw10954; Sun, 5 Apr 2009 15:33:53 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 5 Apr 2009 15:33:53 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client 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, 05 Apr 2009 19:27:47 -0000 On Sun, 5 Apr 2009, Robert Watson wrote: > > One possibility is to connect() a socket to the server address, then call > getsockaddr() to query what address the network stack is using. If the > connection completed, then the address could at least send packets to the > server, even if it isn't reachable from the server. > I used rtalloc1() and then rt_ifa->ifa_addr, which seems adequate, as recommended by a couple of helpful folks. (I didn't bother to try and filter through weird cases like the temporary ipv6 addresses, as one person mentioned.) I put in a sysctl variable, so that this can be overridden. (I think that's pretty much what the connect() would end up doing, although I'm a tcp/ip midget, so I could be wayy wronnggg:-) If it doesn't work, it's not a big tragedy, since a non-functioning callback path just implies "don't issue delegations to the client". rick From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 20:24:35 2009 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 E4895106567D for ; Sun, 5 Apr 2009 20:24:35 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id C4A0C8FC0A for ; Sun, 5 Apr 2009 20:24:35 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Apr 2009 13:12:35 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1LqYg4-0007hw-Kl; Sun, 05 Apr 2009 13:10:48 -0700 Date: Sun, 5 Apr 2009 13:10:48 -0700 From: zachary.loafman@isilon.com To: Robert Watson Message-ID: <20090405201048.GB6319@isilon.com> References: <20080412021209.W43186@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 05 Apr 2009 20:12:35.0136 (UTC) FILETIME=[DBEC7C00:01C9B62A] Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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, 05 Apr 2009 20:24:36 -0000 On Sun, Apr 05, 2009 at 06:31:59PM +0100, Robert Watson wrote: > > On Sat, 12 Apr 2008, Jeff Roberson wrote: > >> As far as I can tell this has never been used. Unless someone can show >> me otherwise I'm going to go ahead and remove it. > > (A year, +/- one week, passes...) > > Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, > and NQNFS is long-gone, I propose we revisit removing VOP_LEASE [...] I haven't had a chance to dig into the code, but can you explain how the v4 server is granting delegations without something like VOP_LEASE? This was actually a conversation I was going to prep for prior to BSDcan. We already have a cluster-coherent oplock mechanism for CIFS, and we were planning on trying to hook that in with v4 delegations, but our FS very much needs VOP calls to accomplish things like delegations. We can't use a local lease manager. Like I said, I need to look at code; it's very likely the existing VOP_LEASE isn't right for us, anyways. -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 22:45:02 2009 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 34350106566B for ; Sun, 5 Apr 2009 22:45:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from skerryvore.cs.uoguelph.ca (skerryvore.cs.uoguelph.ca [131.104.94.204]) by mx1.freebsd.org (Postfix) with ESMTP id CF4188FC17 for ; Sun, 5 Apr 2009 22:45:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by skerryvore.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n35MJd4M007699; Sun, 5 Apr 2009 18:19:39 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n35MPkJ07401; Sun, 5 Apr 2009 18:25:46 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 5 Apr 2009 18:25:46 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: zachary.loafman@isilon.com In-Reply-To: <20090405201048.GB6319@isilon.com> Message-ID: References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.204 Cc: arch@FreeBSD.org, Robert Watson Subject: Re: VOP_LEASE 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, 05 Apr 2009 22:45:02 -0000 On Sun, 5 Apr 2009, zachary.loafman@isilon.com wrote: > > I haven't had a chance to dig into the code, but can you explain how the > v4 server is granting delegations without something like VOP_LEASE? This > was actually a conversation I was going to prep for prior to BSDcan. We > already have a cluster-coherent oplock mechanism for CIFS, and we were > planning on trying to hook that in with v4 delegations, but our FS very > much needs VOP calls to accomplish things like delegations. We can't use > a local lease manager. > Good question. At the moment my code simply assumes that nothing else in FreeBSD is doing Open/Share locks and my server just tracks them itself and, if enabled, issues delegations to clients so they can do them locally. If other things, like a CIFS server, are going to be doing them as well, I think there would need to be some sort of "Windows-like lock manager" that both/all services share. I don't know if it should live below the VFS layer (it's not a file system, but a lock manager). It almost seems like it needs its own kernel API that the varous servers use. (I'll admit, since POSIX clients just always Open/Deny_none, which means essentially "no open lock", I haven't much worried about it. There is only one Windows nfsv4 client out there and I don't know if they ever do Open/Deny other than none.) Obviously, if anything else in FreeBSD is going to be handling Open Shares, that isn't sufficient. (For those not familiar with them, Open Shares are a Windowsism where Open write/Deny write opens a file for writing, but doesn't allow anyone else to open it for writing until it is closed. I'm not a Windoze guy, so I probably didn't get that quite right, but it gives you some idea of what is being talked about. A Delegation allows a client to do the Open Shares and byte range locking locally, without talking to the server. The delegation is recalled when a conflicting Open or byte range lock shows up from another client (or something else locally on the server).) The only thing my server code currently does is provide a function that can be called to recall a delegation. It currently only gets called before a local VOP_RENAME() in my code, but should also be called before local VOP_OPEN() and VOP_REMOVE(). However, this isn't sufficient if anything other than my server is issuing Open Share locks. It's an area that definitely needs some thought. (Then, there's mandatory byte range locking. Lets not even talk about that, for now:-) > Like I said, I need to look at code; it's very likely the existing > VOP_LEASE isn't right for us, anyways. > I don't think that VOP_LEASE() would be appropriate for this, since it all happens at the time of Open. (A call before VOP_RENAME() is necessary, since the nfsv4 Open uses a directory filehandle + component name and won't work after a file is renamed, since the client only knows the old name. A call before VOP_REMOVE() would be nice, so that a client doesn't allow an Open of a file already removed. However, it'll get an ESTALE shortly after opening it, anyhow.) Long winded, but hopefully not too confused, rick From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 04:25:42 2009 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 1A96D10656C6 for ; Mon, 6 Apr 2009 04:25:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id F10B38FC1E for ; Mon, 6 Apr 2009 04:25:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A8C3F961D1; Sun, 5 Apr 2009 21:25:41 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id DD59C2D60B6; Sun, 5 Apr 2009 21:25:37 -0700 (PDT) Message-ID: <49D98461.4000002@elischer.org> Date: Sun, 05 Apr 2009 21:26:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rick Macklem , freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client 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, 06 Apr 2009 04:25:42 -0000 Robert Watson wrote: > On Mon, 30 Mar 2009, Rick Macklem wrote: > >> Well, since the last one turned out to be too easy, here's one I think >> is a little tougher... >> >> The nfsv4 client needs to know an ip address for the machine, that can >> be used by servers to do callbacks on the client. I currently use the >> following, which I know isn't correct, but usually works ok: >> >> loopb = htonl(INADDR_LOOPBACK); >> TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { >> if (IA_SIN(ia)->sin_addr.s_addr != loopb) >> return (&(IA_SIN(ia)->sin_addr.s_addr)); >> } >> return (NULL); >> >> Now, I could just make it a constant set by an rc script (argument to >> the callback daemon or a sysctl variable), but that's a bother for >> laptops using dhcp and similar. I think allowing an argument to the >> callback daemon is a good fallback, but it would be nice if it didn't >> normally have to be set for things to work ok. >> >> Any ideas on how to do this? >> >> Thanks in advance for any help, rick ps: Part of the reason that the >> above loop doesn't seem to be good >> enough is that it requires "options VIMAGE_GLOBALS" to build. > > One possibility is to connect() a socket to the server address, then > call getsockaddr() to query what address the network stack is using. If > the connection completed, then the address could at least send packets > to the server, even if it isn't reachable from the server. > > (Obviously, kernel versions of the above...) we ended up with him doing "whatever the connect code would have done" since as he is in fact inside the kernel, he can just do the same.. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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" From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 10:48:30 2009 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 90E6D106567B for ; Mon, 6 Apr 2009 10:48:30 +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 69ADD8FC13 for ; Mon, 6 Apr 2009 10:48:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0568D46B8D; Mon, 6 Apr 2009 06:48:30 -0400 (EDT) Date: Mon, 6 Apr 2009 11:48:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <49D98461.4000002@elischer.org> Message-ID: References: <49D98461.4000002@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rick Macklem , freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client 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, 06 Apr 2009 10:48:31 -0000 On Sun, 5 Apr 2009, Julian Elischer wrote: >> One possibility is to connect() a socket to the server address, then call >> getsockaddr() to query what address the network stack is using. If the >> connection completed, then the address could at least send packets to the >> server, even if it isn't reachable from the server. >> >> (Obviously, kernel versions of the above...) > > we ended up with him doing "whatever the connect code would have done" since > as he is in fact inside the kernel, he can just do the same.. I figured that if the RPC layer was going to make a connection anyway, we could just query the RPC layer and ask it what address it had used. However, if the decision needs to be made earlier than that, then that doesn't make as much sense. This would mean NFS could avoid knowing about routes and interfaces, and just know about sockets and addresses. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 11:06:51 2009 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 3D9DE10656D8 for ; Mon, 6 Apr 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 111368FC30 for ; Mon, 6 Apr 2009 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n36B6okk061803 for ; Mon, 6 Apr 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n36B6osx061799 for freebsd-arch@FreeBSD.org; Mon, 6 Apr 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Apr 2009 11:06:50 GMT Message-Id: <200904061106.n36B6osx061799@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 06 Apr 2009 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 12:13:00 2009 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 DDF7B106572F for ; Mon, 6 Apr 2009 12:13:00 +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 B9ACE8FC0C for ; Mon, 6 Apr 2009 12:13:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 58FCB46B90; Mon, 6 Apr 2009 08:13:00 -0400 (EDT) Date: Mon, 6 Apr 2009 13:13:00 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: zachary.loafman@isilon.com In-Reply-To: <20090405201048.GB6319@isilon.com> Message-ID: References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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, 06 Apr 2009 12:13:01 -0000 On Sun, 5 Apr 2009, zachary.loafman@isilon.com wrote: > On Sun, Apr 05, 2009 at 06:31:59PM +0100, Robert Watson wrote: >> >> On Sat, 12 Apr 2008, Jeff Roberson wrote: >> >>> As far as I can tell this has never been used. Unless someone can show me >>> otherwise I'm going to go ahead and remove it. >> >> (A year, +/- one week, passes...) >> >> Since we now have an NFSv4 client/server and it doesn't use VOP_LEASE, and >> NQNFS is long-gone, I propose we revisit removing VOP_LEASE [...] > > I haven't had a chance to dig into the code, but can you explain how the v4 > server is granting delegations without something like VOP_LEASE? This was > actually a conversation I was going to prep for prior to BSDcan. We already > have a cluster-coherent oplock mechanism for CIFS, and we were planning on > trying to hook that in with v4 delegations, but our FS very much needs VOP > calls to accomplish things like delegations. We can't use a local lease > manager. > > Like I said, I need to look at code; it's very likely the existing VOP_LEASE > isn't right for us, anyways. Zach, Let me know if/when you're ready for the VOP_LEASE-axing to take place, and I'll move ahead with it. And we should perhaps add delegation/oplock/etc mechanisms to our agenda for the devsummit? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 15:50:18 2009 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 A876110656D9; Mon, 6 Apr 2009 15:50:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from gigi.cs.uoguelph.ca (gigi.cs.uoguelph.ca [131.104.94.210]) by mx1.freebsd.org (Postfix) with ESMTP id 63B908FC08; Mon, 6 Apr 2009 15:50:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n36FoDOK014419; Mon, 6 Apr 2009 11:50:13 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n36FuK024013; Mon, 6 Apr 2009 11:56:20 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 6 Apr 2009 11:56:20 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <49D98461.4000002@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.210 Cc: Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client 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, 06 Apr 2009 15:50:18 -0000 On Mon, 6 Apr 2009, Robert Watson wrote: > On Sun, 5 Apr 2009, Julian Elischer wrote: > >>> One possibility is to connect() a socket to the server address, then call >>> getsockaddr() to query what address the network stack is using. If the >>> connection completed, then the address could at least send packets to the >>> server, even if it isn't reachable from the server. >>> >>> (Obviously, kernel versions of the above...) >> >> we ended up with him doing "whatever the connect code would have done" >> since as he is in fact inside the kernel, he can just do the same.. > > I figured that if the RPC layer was going to make a connection anyway, we > could just query the RPC layer and ask it what address it had used. However, > if the decision needs to be made earlier than that, then that doesn't make as > much sense. This would mean NFS could avoid knowing about routes and > interfaces, and just know about sockets and addresses. > I just took a quick look at Doug's RPC code and the socket doesn't seem to be exposed to the client side by the rpc layer, so I think that rtalloc1() is probably easier? I'd also be worried about knowing when the socket pointer is valid and in a connected state. (The rtalloc1() code only uses the one path rt->rt_ifa->ifa_addr after sanity checking that the pointers aren't null, so I don't think it will be difficult to maintain. It does imply that the code knows the route locking rules, but that just means it uses RTFREE_LOCKED(rt), so as long as that macro keeps working, it should be ok, I think.) rick From owner-freebsd-arch@FreeBSD.ORG Mon Apr 6 20:03:32 2009 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 3761B10657BC for ; Mon, 6 Apr 2009 20:03:32 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: from ekman.netline.com (ekman.netline.com [209.133.56.28]) by mx1.freebsd.org (Postfix) with ESMTP id 29D0E8FC20 for ; Mon, 6 Apr 2009 20:03:32 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: by ekman.netline.com (Postfix, from userid 1000) id 8FB161184A0; Mon, 6 Apr 2009 12:19:22 -0700 (PDT) To: freebsd-arch@freebsd.org Message-ID: <1239045562.43838.qmail@Poste-italiane.it> From: "MondoBancoPosta" Date: Mon, 6 Apr 2009 12:19:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Premio vi aspetta! 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, 06 Apr 2009 20:03:34 -0000 Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From owner-freebsd-arch@FreeBSD.ORG Tue Apr 7 21:53:09 2009 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 297991065677; Tue, 7 Apr 2009 21:53:09 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0689A8FC12; Tue, 7 Apr 2009 21:53:08 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 14:53:08 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1LrJ9a-0000wm-Ok; Tue, 07 Apr 2009 14:48:22 -0700 Date: Tue, 7 Apr 2009 14:48:22 -0700 From: zachary.loafman@isilon.com To: Robert Watson Message-ID: <20090407214822.GA31767@isilon.com> References: <20080412021209.W43186@desktop> <20090405201048.GB6319@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 07 Apr 2009 21:53:08.0826 (UTC) FILETIME=[3D1C03A0:01C9B7CB] Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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: Tue, 07 Apr 2009 21:53:10 -0000 On Mon, Apr 06, 2009 at 01:13:00PM +0100, Robert Watson wrote: > > Zach, > > Let me know if/when you're ready for the VOP_LEASE-axing to take place, > and I'll move ahead with it. I've glanced at it. I see no reason to keep it in its current form, we'll likely need something different. It's interesting to know the places where VOP_LEASE is called, but revision control systems are great for keeping a historical record of such. :) > And we should perhaps add delegation/oplock/etc mechanisms to our agenda > for the devsummit? Sure. I'll throw it on the wiki when I get a chance. Which reminds me, I should probably get around to booking .. ...Zach -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Thu Apr 9 07:43:23 2009 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 5368C10656C7 for ; Thu, 9 Apr 2009 07:43:23 +0000 (UTC) (envelope-from bounces+305227.46043599.562566@icpbounce.com) Received: from smtp2.icpbounce.com (smtp2.icpbounce.com [216.27.93.124]) by mx1.freebsd.org (Postfix) with ESMTP id 125368FC2B for ; Thu, 9 Apr 2009 07:43:22 +0000 (UTC) (envelope-from bounces+305227.46043599.562566@icpbounce.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp2.icpbounce.com (Postfix) with ESMTP id C6862F8763 for ; Thu, 9 Apr 2009 03:22:34 -0400 (EDT) Date: Thu, 9 Apr 2009 03:22:34 -0400 To: freebsd-arch@freebsd.org From: Global Access Travel Message-ID: <22a404d870a4591852e8d4b2a1375a96@localhost.localdomain> X-Priority: 3 X-Mailer: PHPMailer [version 1.72] Errors-To: bounces+305227.46043599.562566@icpbounce.com X-List-Unsubscribe: X-Unsubscribe-Web: X-ICPINFO: X-Return-Path-Hint: bounces+305227.46043599.562566@icpbounce.com MIME-Version: 1.0 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Private Shore Excursions-Turkey 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, 09 Apr 2009 07:43:24 -0000 [http://www.turkeycalling.us] PRIVATE SHORE EXCURSIONS- TURKEY Your cruise clients will make the best of their time in Turkey on a private shore excursion! Istanbul Kusadasi & Ephesus [mailto:incoming@gaturkey.com?subject=Private Shore Excursions- Turkey] **************************************************************************** Yasal Uyarı; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ücüncü kisiler ile paylasilmasi mümkün olmayabilir.Mesaji alan kisi, mesajin gönderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa lütfen mesaji geri gönderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. **************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. *********************************************************************************************** Yasal Uyarı; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ücüncü kisiler ile paylasilmasi mümkün olmayabilir.Mesaji alan kisi, mesajin gönderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa lütfen mesaji geri gönderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. ********************************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. This message was sent by: Global Access Incoming, Nuzhetiye cad, istanbul, besiktas 34357, Turkey Powered by iContact: http://freetrial.icontact.com To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=46043599&l=82228&s=5SJB&m=562566&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=562566&s=46043599&c=5SJB&cid=305227 From owner-freebsd-arch@FreeBSD.ORG Thu Apr 9 10:54:19 2009 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 93F4E1065672 for ; Thu, 9 Apr 2009 10:54:19 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.ilius.net (mail.ilius.net [62.23.30.92]) by mx1.freebsd.org (Postfix) with ESMTP id E5CFA8FC14 for ; Thu, 9 Apr 2009 10:54:18 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from viking.ilius.fr [192.168.192.55] by mail.ilius.net with ESMTP (SMTPD-9.23) id AB4707D0; Thu, 09 Apr 2009 12:17:43 +0200 Message-ID: <49DDCB1D.6080302@FreeBSD.org> Date: Thu, 09 Apr 2009 12:17:01 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Build shared profiled library? 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, 09 Apr 2009 10:54:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Currently, only static profiled library are built during buildworld. Why not shared library too? I ask this because Erlang uses dlsym(RTLD_NEXT, ...): when building a profiled Erlang VM, the produced binary is static and this call fails. Thanks! - -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndyx0ACgkQa+xGJsFYOlMgcACfZFzo5xszDs8yuPRSp0PuFjZo iZcAoMEsQKbSCFgdOhAUxKWC7/sV+07P =EJ6Z -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Thu Apr 9 17:21:01 2009 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 362F410656F6 for ; Thu, 9 Apr 2009 17:21:01 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from seaxch10.isilon.com (seaxch10.isilon.com [74.85.160.26]) by mx1.freebsd.org (Postfix) with ESMTP id 15F338FC0A for ; Thu, 9 Apr 2009 17:21:01 +0000 (UTC) (envelope-from zachary.loafman@isilon.com) Received: from famine.isilon.com ([10.54.190.95]) by seaxch10.isilon.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 10:21:01 -0700 Received: from zloafman by famine.isilon.com with local (Exim 4.69) (envelope-from ) id 1LrxrJ-0003cJ-RX for freebsd-arch@freebsd.org; Thu, 09 Apr 2009 10:16:13 -0700 Date: Thu, 9 Apr 2009 10:16:13 -0700 From: Zachary Loafman To: freebsd-arch@freebsd.org Message-ID: <20090409171613.GC9442@isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 09 Apr 2009 17:21:01.0255 (UTC) FILETIME=[8DF1E570:01C9B937] Subject: splice() in FreeBSD 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, 09 Apr 2009 17:21:01 -0000 Arch - Isilon has internally been using the FreeBSD sendfile() (with modifications) and our own recvfile() in order to accomplish zero-copy read/write for the userland portions of our stack (CIFS, NDMP). However, these interfaces are limited. In particular, sendfile/recvfile prevent any other thread from dealing with the same socket until the call is complete. That's somewhat silly - it would be nicer to split the read-from-file/write-to-file portion from the read-from-socket/write-to-socket portion. That also eases some of the decisions that only the layer above can really make - for example, in the sendfile() case, you don't really know if it's appropriate to send a partial read or whether the caller really needs all the data. What we'd like is something like splice(). The Linux splice interface is documented here: http://linux.die.net/man/2/splice and the internals are discussed here: http://kerneltrap.org/node/6505 . We don't need the sillier portions of it - Isilon could care less about vmsplice()/tee(). We need the ability to shuffle data from one source to one sink, and then to turn around later and use that sink as a source. At first, I found the splice() interface a bit of an abomination, but a pipe is a somewhat natural place to act as a data staging area. If we just implemented splice alone, this wouldn't require any real VM hackery - you can imagine just shuffling mbufs through the pipe to accomplish a limited form of this (or, say, a unix domain socket). As part of this, and in order to get something upstreamable, it seems like we would need a few things: *) Agreement on syscall APIs - My initial proposal is to adopt splice verbatim. Initially the interface may not be truly zero-copy for many cases, but it's a start. It also increases portability for any Linux apps that are trying to make use of it. *) Unification of uio and mbufs somehow? Isilon currently has private patches that add *_MBUF variants for I/O VOPs (e.g. we have a VOP_READ_MBUF in addition to the standard VOP_READ). Isilon is in a somewhat unique place here - I'm not sure a general file system can handle this as easily. At the top-half, our system in many ways acts a lot like a router, so we can handle things like VOP_READ_MBUF by taking file data off our back-end (which comes in as mbufs off IB), header splitting, then just slinging the mbufs out the front-end. However, I think our *_MBUF VOP variants are actually a little gross. I would rather figure out a way to unify the uio and mbuf APIs - they're both scatter/gather lists in their own special way, then call into a single VOP. Isilon can get a limited, non-upstreamable thing working fairly quickly - we can use a unix domain socket as the intermediate buffer and use our existing *_MBUF VOPs. But it would be nice if we had some consensus going forward, then we can internally march towards something we can upstream. ...Zach -- Zach Loafman | Staff Engineer | Isilon Systems From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 12:06:37 2009 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 A4616106571B; Fri, 10 Apr 2009 12:06:37 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 322DF8FC20; Fri, 10 Apr 2009 12:06:36 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n3ABagQB078603; Fri, 10 Apr 2009 13:36:42 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n3ABagsH078602; Fri, 10 Apr 2009 13:36:42 +0200 (CEST) (envelope-from marius) Date: Fri, 10 Apr 2009 13:36:42 +0200 From: Marius Strobl To: Alan Cox Message-ID: <20090410113642.GA78551@alchemy.franken.de> References: <49D252EF.7060102@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D252EF.7060102@cs.rice.edu> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, Robert Watson Subject: Re: memory protection and sbrk() 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, 10 Apr 2009 12:06:40 -0000 On Tue, Mar 31, 2009 at 12:29:19PM -0500, Alan Cox wrote: > For as long as I can remember, FreeBSD's sbrk() has provided memory with > execute permission enabled. Before we branch for FreeBSD 8.0, I'd like > to try removing execute permission on this memory. > > On (non-PAE) i386 and a few of the embedded processors, this change will > have little tangible effect because there is no distinction in the > processor's MMU between read and execute permissions. > > On amd64, the only potential problems are likely with a very few > applications, like the JVM, that have their own internal implementation > of "malloc()" and generate code on the fly (i.e., JIT compilation). > However, I have verified that at least the Sun JVM works ok. I have > also checked that cvsup, which is based on Modula-3 and does not use the > standard malloc(), works ok. > > It's also worth noting that our standard malloc() has flip-flopped over > the last year or so in terms of whether it uses sbrk() or mmap() by > default to acquire memory. When it uses mmap(), it does not request > execute permission on the allocated memory. So, depending on whether > malloc() used mmap() or sbrk(), malloc() was returning memory with > different permissions. Consequently, I think that any application > problems due to the lack of execute permission on memory returned by > malloc() would have long since been detected. > > As a final sanity check, I would appreciate it if three kinds of users > would test the attached patch: (1) some IA64, PowerPC, and Sparc64 > users, (2) amd64-based users of "exotic" languages, like common lisp, > haskell, etc. and (3) amd64-based users of other JVMs, like kaffe. > > My plan is to commit the attached patch to HEAD on the 7th of April > unless I hear of problems. > The patch doesn't seem to cause ill effects on sparc64. Marius From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 15:46:25 2009 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 44E5310656BD for ; Fri, 10 Apr 2009 15:46:25 +0000 (UTC) (envelope-from wwwrun@ipx11080.ipxserver.de) Received: from ipx11080.ipxserver.de (ipx11080.ipxserver.de [212.112.227.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7738FC1B for ; Fri, 10 Apr 2009 15:46:24 +0000 (UTC) (envelope-from wwwrun@ipx11080.ipxserver.de) Received: by ipx11080.ipxserver.de (Postfix, from userid 30) id 9F2CE24208D; Fri, 10 Apr 2009 19:05:09 +0200 (CEST) To: freebsd-arch@freebsd.org From: Mrs.Catharina Sies MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20090410170509.9F2CE24208D@ipx11080.ipxserver.de> Date: Fri, 10 Apr 2009 19:05:09 +0200 (CEST) Subject: Contact Barr. Foxy:- Mrs. Catharina Sies X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: princessdianafundgrantaward@gmail.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 15:46:25 -0000 Hello Dear, My name is Mrs. Catharina Sies; I am a dying woman who has decided to donate what I have to you for humanity services. I am 61 years old and I was diagnosed for cancer for about 2 years ago immediately after the death of my husband who has left me everything he worked for and because the doctors told me I will not live longer than some weeks because of my health I decided to WILL/donate the sum of USD 3, 500, 000:00 Three million five hundred thousand dollars to you for the good work of humanity and also to help the motherless and less privilege and also for the assistance of the widows. I wish you all the best and may the good Lord bless you abundantly and please use the funds well and always extend the good work to others. Here is the Contact information of my Attorney below: ABRAHAM WILLIAMS & ASSOCIATES Mr. John Foxy Esq Phone: +44-703-183-7885 Fax: +44-871-264-1453 Email: abrawillassojfoxy@gmail.com Tell him that I have WILLED USD 3,500 000.00 to you and I have also notified him. I know I don't know you but I have been directed to do this. NB: I will appreciate your utmost confidentiality in this matter until the task is accomplished as i don't want anything that will jeopardize my wishes. Sincerely, Mrs.Catharina Sies From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 17:20:19 2009 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 2533C1065675; Fri, 10 Apr 2009 17:20:19 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id E464E8FC19; Fri, 10 Apr 2009 17:20:18 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 5D8962C2ADC; Fri, 10 Apr 2009 12:20:18 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XcmY+7bCsqQR; Fri, 10 Apr 2009 12:20:09 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 675B72C2ACE; Fri, 10 Apr 2009 12:20:09 -0500 (CDT) Message-ID: <49DF7FC8.1000508@cs.rice.edu> Date: Fri, 10 Apr 2009 12:20:08 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Marius Strobl References: <49D252EF.7060102@cs.rice.edu> <20090410113642.GA78551@alchemy.franken.de> In-Reply-To: <20090410113642.GA78551@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Robert Watson Subject: Re: memory protection and sbrk() 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, 10 Apr 2009 17:20:21 -0000 Marius Strobl wrote: > On Tue, Mar 31, 2009 at 12:29:19PM -0500, Alan Cox wrote: > >> For as long as I can remember, FreeBSD's sbrk() has provided memory with >> execute permission enabled. Before we branch for FreeBSD 8.0, I'd like >> to try removing execute permission on this memory. >> >> On (non-PAE) i386 and a few of the embedded processors, this change will >> have little tangible effect because there is no distinction in the >> processor's MMU between read and execute permissions. >> >> On amd64, the only potential problems are likely with a very few >> applications, like the JVM, that have their own internal implementation >> of "malloc()" and generate code on the fly (i.e., JIT compilation). >> However, I have verified that at least the Sun JVM works ok. I have >> also checked that cvsup, which is based on Modula-3 and does not use the >> standard malloc(), works ok. >> >> It's also worth noting that our standard malloc() has flip-flopped over >> the last year or so in terms of whether it uses sbrk() or mmap() by >> default to acquire memory. When it uses mmap(), it does not request >> execute permission on the allocated memory. So, depending on whether >> malloc() used mmap() or sbrk(), malloc() was returning memory with >> different permissions. Consequently, I think that any application >> problems due to the lack of execute permission on memory returned by >> malloc() would have long since been detected. >> >> As a final sanity check, I would appreciate it if three kinds of users >> would test the attached patch: (1) some IA64, PowerPC, and Sparc64 >> users, (2) amd64-based users of "exotic" languages, like common lisp, >> haskell, etc. and (3) amd64-based users of other JVMs, like kaffe. >> >> My plan is to commit the attached patch to HEAD on the 7th of April >> unless I hear of problems. >> >> > > The patch doesn't seem to cause ill effects on sparc64. > Thanks for the feedback. I haven't committed the patch yet because yours is the first response that I've received. At this point, I'm going to wait another 24 hours and commit the patch. Alan From owner-freebsd-arch@FreeBSD.ORG Fri Apr 10 19:25:51 2009 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 683CD1065675; Fri, 10 Apr 2009 19:25:51 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0088FC0C; Fri, 10 Apr 2009 19:25:50 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C8E9F6D449; Fri, 10 Apr 2009 19:10:37 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AB056844C6; Fri, 10 Apr 2009 21:10:37 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= References: <49DDCB1D.6080302@FreeBSD.org> Date: Fri, 10 Apr 2009 21:10:37 +0200 In-Reply-To: <49DDCB1D.6080302@FreeBSD.org> (=?utf-8?Q?=22Jean-S=C3=A9bast?= =?utf-8?Q?ien_P=C3=A9dron=22's?= message of "Thu, 09 Apr 2009 12:17:01 +0200") Message-ID: <86vdpcuxxu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Build shared profiled library? 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, 10 Apr 2009 19:25:52 -0000 Jean-S=C3=A9bastien P=C3=A9dron writes: > Currently, only static profiled library are built during buildworld. Why > not shared library too? Because - if I understand correctly how gprof works - you wouldn't be able to profile code inside the libraries, unless gprof knew enough about rtld to figure out which libraries were loaded, in which order, at which addresses, and duplicate the relocations. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sat Apr 11 16:11:56 2009 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 2C8411065670 for ; Sat, 11 Apr 2009 16:11:56 +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 E08978FC0A for ; Sat, 11 Apr 2009 16:11:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 79FDF46B06 for ; Sat, 11 Apr 2009 12:11:55 -0400 (EDT) Date: Sat, 11 Apr 2009 17:11:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org 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: Simple #define for cache line size 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, 11 Apr 2009 16:11:56 -0000 Dear all: We have a number of __aligned() qualifiers scattered around the kernel intended to space objects to improve alignment with respect to cache lines. This is important for a number of reasons, not least avoiding cache line thrashing when using arrays of foo[MAXCPU]. What I'd like to do is provide a single compile-time constant, CACHE_LINE_SIZE, defined in machine-dependent param.h, to use for spacing such objects, rather than hard-coding various values around. Here are some examples of existing spacing attempts: i386/include/pcpu.h, line 67 66 #define PCPU_MD_FIELDS \ > 67 char pc_monitorbuf[128] __aligned(128); /* cache line */ \ 68 struct pcpu *pc_prvspace; /* Self-reference */ \ kern/sched_ule.c, line 230 229 #endif > 230 } __aligned(64); 231 vm/uma_core.c, line 115 114 /* The boot-time adjusted value for cache line alignment. */ > 115 static int uma_align_cache = 64 - 1; 116 We could then deploy __aligned(CACHE_LINE_SIZE) in various places, such as on the description of per-CPU caches for UMA, to ensure that, for example, per-CPU stats for one CPU weren't in the same cache line as stats for other CPUs. NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, but I'm going with an MD definition as I suspect people will want to do different things on different architectures (and there is variation). I've defaulted all architectures to 64 bytes, but I suspect a number would prefer to use 32. Patch below. There's undoubtably an argument for doing something more optimal than what I'm proposing here, but right now I'm just looking for something that works, and would be happy to see it replaced with something more mature once it's available. Robert N M Watson Computer Laboratory University of Cambridge Index: arm/include/param.h =================================================================== --- arm/include/param.h (revision 190941) +++ arm/include/param.h (working copy) @@ -81,6 +81,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT 12 #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ #define PAGE_MASK (PAGE_SIZE - 1) Index: powerpc/include/param.h =================================================================== --- powerpc/include/param.h (revision 190941) +++ powerpc/include/param.h (working copy) @@ -79,6 +79,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT 12 #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ #define PAGE_MASK (PAGE_SIZE - 1) Index: sparc64/include/param.h =================================================================== --- sparc64/include/param.h (revision 190941) +++ sparc64/include/param.h (working copy) @@ -71,6 +71,10 @@ #define ALIGNBYTES _ALIGNBYTES #define ALIGN(p) _ALIGN(p) +#ifndef CACHE_LINE_SIZE +#define CACHE_LINE_SIZE 64 +#endif + #define PAGE_SHIFT_8K 13 #define PAGE_SIZE_8K (1L< 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 04544106564A for ; Sat, 11 Apr 2009 16:55:53 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id DC8338FC0A for ; Sat, 11 Apr 2009 16:55:52 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTPA id 2913050819; Sat, 11 Apr 2009 09:39:48 -0700 (PDT) Message-ID: <49E0C7D3.1010005@FreeBSD.org> Date: Sat, 11 Apr 2009 09:39:47 -0700 From: Jason Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Simple #define for cache line size 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, 11 Apr 2009 16:55:53 -0000 Robert Watson wrote: > Index: arm/include/param.h > =================================================================== > --- arm/include/param.h (revision 190941) > +++ arm/include/param.h (working copy) > @@ -81,6 +81,10 @@ > #define ALIGNBYTES _ALIGNBYTES > #define ALIGN(p) _ALIGN(p) > > +#ifndef CACHE_LINE_SIZE > +#define CACHE_LINE_SIZE 64 > +#endif > + > #define PAGE_SHIFT 12 > #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ > #define PAGE_MASK (PAGE_SIZE - 1) > Index: powerpc/include/param.h It would be helpful to instead do: #ifndef CACHE_LINE_SHIFT #define CACHE_LINE_SHIFT 6 #endif #define CACHE_LINE_SIZE (1 << CACHE_LINE_SHIFT) In particular, src/lib/libc/stdlib/malloc.c would benefit. Thanks, Jason From owner-freebsd-arch@FreeBSD.ORG Sat Apr 11 18:29:14 2009 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 5506F1065670; Sat, 11 Apr 2009 18:29:14 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 286ED8FC1D; Sat, 11 Apr 2009 18:29:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) id <0KHY007005W9GS00@smtpauth3.wiscmail.wisc.edu>; Sat, 11 Apr 2009 12:28:57 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.201.152.222]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) with ESMTPSA id <0KHY002ZY5W37Q50@smtpauth3.wiscmail.wisc.edu>; Sat, 11 Apr 2009 12:28:56 -0500 (CDT) Date: Sat, 11 Apr 2009 12:28:51 -0500 From: Nathan Whitehorn In-reply-to: To: Robert Watson Message-id: <49E0D353.7090308@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.152.222 X-Spam-PmxInfo: Server=avs-10, Version=5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.4.11.171624, SenderIP=76.201.152.222 References: User-Agent: Thunderbird 2.0.0.21 (X11/20090405) Cc: arch@FreeBSD.org Subject: Re: Simple #define for cache line size 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, 11 Apr 2009 18:29:14 -0000 Robert Watson wrote: > > > NetBSD, FYI, defines CACHE_LINE_SIZE as a global constant in param.h, > but I'm going with an MD definition as I suspect people will want to > do different things on different architectures (and there is > variation). I've defaulted all architectures to 64 bytes, but I > suspect a number would prefer to use 32. For what it's worth, this is per-CPU variable on PowerPC and detected at runtime. Most of the CPUs we support have 32 byte cache lines, but some (e.g. the G5) use 128 bytes. I'm not sure there is a general solution in this case, but that's the situation on PPC. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sat Apr 11 21:10:05 2009 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 5FBA8106566C; Sat, 11 Apr 2009 21:10:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id D4F0B8FC18; Sat, 11 Apr 2009 21:10:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n3BIPtZF029573; Sun, 12 Apr 2009 04:25:55 +1000 Received: from besplex.bde.org (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n3BIPqeo012749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Apr 2009 04:25:53 +1000 Date: Sun, 12 Apr 2009 04:25:52 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jason Evans In-Reply-To: <49E0C7D3.1010005@FreeBSD.org> Message-ID: <20090412041840.F4999@besplex.bde.org> References: <49E0C7D3.1010005@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, Robert Watson Subject: Re: Simple #define for cache line size 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, 11 Apr 2009 21:10:05 -0000 On Sat, 11 Apr 2009, Jason Evans wrote: > Robert Watson wrote: >> Index: arm/include/param.h >> =================================================================== >> --- arm/include/param.h (revision 190941) >> +++ arm/include/param.h (working copy) >> @@ -81,6 +81,10 @@ >> #define ALIGNBYTES _ALIGNBYTES >> #define ALIGN(p) _ALIGN(p) >> >> +#ifndef CACHE_LINE_SIZE >> +#define CACHE_LINE_SIZE 64 >> +#endif >> + >> #define PAGE_SHIFT 12 >> #define PAGE_SIZE (1 << PAGE_SHIFT) /* Page size */ >> #define PAGE_MASK (PAGE_SIZE - 1) >> Index: powerpc/include/param.h > > It would be helpful to instead do: > > #ifndef CACHE_LINE_SHIFT > #define CACHE_LINE_SHIFT 6 > #endif > #define CACHE_LINE_SIZE (1 << CACHE_LINE_SHIFT) > > In particular, src/lib/libc/stdlib/malloc.c would benefit. It shouldn't be ifdefed, since it isn't an option and any override of the definition would tend to give binary incompatibilities, especially if it is used in userland (userland can't match kernel options or know if they are matched). FreeBSD already has too many non-options like this. CACHE_LINE_* is mainly advisory but would still cause binary incompatibilities when it is used for array sizes. Bruce