From owner-freebsd-arch Sun Oct 27 8:14:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1708137B401 for ; Sun, 27 Oct 2002 08:14:50 -0800 (PST) Received: from walton.kettenis.dyndns.org (a169250.upc-a.chello.nl [62.163.169.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43CE543E65 for ; Sun, 27 Oct 2002 08:14:47 -0800 (PST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g9RGEgdh000798; Sun, 27 Oct 2002 17:14:42 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id g9RGEgQ6005537; Sun, 27 Oct 2002 17:14:42 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id g9RGEbFD005532; Sun, 27 Oct 2002 17:14:37 +0100 (CET) Date: Sun, 27 Oct 2002 17:14:37 +0100 (CET) Message-Id: <200210271614.g9RGEbFD005532@elgar.kettenis.dyndns.org> From: Mark Kettenis To: thorpej@wasabisystems.com Cc: freebsd-arch@freebsd.org, bsd-api-discuss@wasabisystems.com In-reply-to: <20021026091608.L19682@dhcp7.wlan.shagadelic.org> (message from Jason R Thorpe on Sat, 26 Oct 2002 09:16:08 -0700) Subject: Re: ptrace(2) and vector registers References: <200210212039.g9LKdMjS001116@elgar.kettenis.dyndns.org> <20021026091608.L19682@dhcp7.wlan.shagadelic.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Date: Sat, 26 Oct 2002 09:16:08 -0700 From: Jason R Thorpe That "s" on the end is my fault -- guess I got a little carried away (it's certainly possible that my brain silently added the "s" without my knowledge every time I typed it :-) I've been known to do that myself from time to time too ;-). I suppose a "struct vreg" would be fine. I could certainly change NetBSD/i386 to use that name (keeping the "xmmregs" name around for backward compatibility). Right now GDB doesn't use `struct xmmregs', and never has. Instead it uses a 512-byte character array. I've no intention to change that. So feel free to punt backwards compatibility. The danger is, of course, that at some point in the future, the XMM stuff will be extended yet again, leaving us with a useless generic name. If only I had that crystal ball :-(. You never know what Intel is going to put in the remaining bytes of the "FXSAVE/FXRSTOR Memory Region". One could argue that XMMREGS is "useless" already, since the MMX registers are also included. Anyway, I'll try to get the PT_GETVREGS request integrated in FreeBSD -current. I'll drop you a note when/if I've succeeded. There's no point in changing NetBSD if we don't know if my patch is going to be accepted. In fact, NetBSD/arm already has this problem -- there are two distinct types of floating point register sets -- the FPA (old floating point accelerator available for e.g. ARM7) and VFP (the vector floating point defined by ARMv5). Don't let the "vector" in VFP fool you -- it is also used to plain old IEEE FP -- so in your world, would that be "fpreg" or "vreg"? Most likely fpreg. If an architecture has floating-point registers, they should be made available via the PT_GETFPREGS request (unless they're already included with the general-purpose registers in the PT_GETREGS request). And I don't think we should artificially create a seperate PT_GETVREGS request if the FPU also provides some sort of vector operations. However if Actually on the i386 `struct vreg' will also contain the plain old FP registers, fortunately for me they also get used for the MMX registers which do have the `vector' charcter :-). Mark To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 27 17:57:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DDA737B401; Sun, 27 Oct 2002 17:57:45 -0800 (PST) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30AF843E4A; Sun, 27 Oct 2002 17:57:44 -0800 (PST) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id BC0CA812F5; Mon, 28 Oct 2002 12:06:06 +1030 (CST) Date: Mon, 28 Oct 2002 12:06:06 +1030 From: Greg 'groggy' Lehey To: Robert Watson Cc: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021028013606.GW69631@wantadilla.lemis.com> References: <20021027021440.GB58312@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Saturday, 26 October 2002 at 22:59:02 -0400, Robert Watson wrote: > > On Sat, 26 Oct 2002, David O'Brien wrote: > >> On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote: >>> Given that lukemftpd is highly feature incomplete with regards to the >>> default ftpd, I'd like to propose at least the following: >> >> What "default" ftpd? We don't have one anymore. I consider it a HUGE >> feature that lukemftpd doesn't do PAM. Like the new "standards" >> headers, PAM has done nothing for me over what I had in pre-PAM'ized >> FreeBSD, but cause great pain. Yet another promiss of something the >> better and easier that has not turned out to be the case. > > You seem to have ignored the remainder of my questions, including whether > or not you plan to add support for login.conf to lukemftpd, which is > required to support: > > ... Has anybody thought of talking to lukem about this? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 27 21:33:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C22B637B401 for ; Sun, 27 Oct 2002 21:33:35 -0800 (PST) Received: from opiate.thirteenandtwo.org (CPE0030ab0ef2bb.cpe.net.cable.rogers.com [24.103.202.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45E5A43E75 for ; Sun, 27 Oct 2002 21:32:54 -0800 (PST) (envelope-from munish@opiate.thirteenandtwo.org) Received: from opiate.thirteenandtwo.org (munish@localhost.thirteenandtwo.org [127.0.0.1]) by opiate.thirteenandtwo.org (8.12.6/8.12.6) with ESMTP id g9S5WWG5027882 for ; Mon, 28 Oct 2002 00:32:48 -0500 (EST) (envelope-from munish@opiate.thirteenandtwo.org) Received: (from munish@localhost) by opiate.thirteenandtwo.org (8.12.6/8.12.6/Submit) id g9S5WRjN027877 for arch@FreeBSD.ORG; Mon, 28 Oct 2002 00:32:27 -0500 (EST) Date: Mon, 28 Oct 2002 00:32:27 -0500 From: Munish Chopra To: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) Message-ID: <20021028053227.GC32006@opiate.thirteenandtwo.org> Mail-Followup-To: arch@FreeBSD.ORG References: <20021027021440.GB58312@dragon.nuxi.com> <20021028013606.GW69631@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021028013606.GW69631@wantadilla.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-10-28 12:06 +0000, Greg 'groggy' Lehey wrote: > [snip lots of discussion] > > Has anybody thought of talking to lukem about this? > I was hoping someone with a more concrete idea and understanding of what needs to be done than myself would take this up. Which brings us full-round to 'who' again. -- Munish Chopra To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 27 21:58:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9760F37B401 for ; Sun, 27 Oct 2002 21:58:14 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E339443E3B for ; Sun, 27 Oct 2002 21:58:13 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9S5wDpk026507 for ; Sun, 27 Oct 2002 22:58:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 27 Oct 2002 22:57:15 -0700 (MST) Message-Id: <20021027.225715.90705158.imp@bsdimp.com> To: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? From: "M. Warner Losh" In-Reply-To: <20021028013606.GW69631@wantadilla.lemis.com> References: <20021027021440.GB58312@dragon.nuxi.com> <20021028013606.GW69631@wantadilla.lemis.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021028013606.GW69631@wantadilla.lemis.com> "Greg 'groggy' Lehey" writes: : On Saturday, 26 October 2002 at 22:59:02 -0400, Robert Watson wrote: : > : > On Sat, 26 Oct 2002, David O'Brien wrote: : > : >> On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote: : >>> Given that lukemftpd is highly feature incomplete with regards to the : >>> default ftpd, I'd like to propose at least the following: : >> : >> What "default" ftpd? We don't have one anymore. I consider it a HUGE : >> feature that lukemftpd doesn't do PAM. Like the new "standards" : >> headers, PAM has done nothing for me over what I had in pre-PAM'ized : >> FreeBSD, but cause great pain. Yet another promiss of something the : >> better and easier that has not turned out to be the case. : > : > You seem to have ignored the remainder of my questions, including whether : > or not you plan to add support for login.conf to lukemftpd, which is : > required to support: : > : > ... : : Has anybody thought of talking to lukem about this? I've talked to him abstractly about the idea in the past. He's indicated that he's willing to integrate FreeBSD stuff, but doesn't have the time to actively do it himself. Until someone steps up to the plate to do it, lukemftpd won't change, and we'll still be in this silly limbo. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 27 23:12:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E696237B401 for ; Sun, 27 Oct 2002 23:12:17 -0800 (PST) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85F2B43E3B for ; Sun, 27 Oct 2002 23:12:17 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0035.cvx40-bradley.dialup.earthlink.net ([216.244.42.35] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18644N-00055U-00; Sun, 27 Oct 2002 23:12:15 -0800 Message-ID: <3DBCE302.9C0E3CB7@mindspring.com> Date: Sun, 27 Oct 2002 23:10:58 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Munish Chopra Cc: arch@FreeBSD.ORG Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) References: <20021027021440.GB58312@dragon.nuxi.com> <20021028013606.GW69631@wantadilla.lemis.com> <20021028053227.GC32006@opiate.thirteenandtwo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Munish Chopra wrote: > I was hoping someone with a more concrete idea and understanding of what > needs to be done than myself would take this up. Which brings us > full-round to 'who' again. That's easy to answer: whoever wants to replace the BSD ftpd with lukemftpd. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 28 9:59:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32AD537B499; Mon, 28 Oct 2002 09:59:48 -0800 (PST) Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id E100243E77; Mon, 28 Oct 2002 09:59:47 -0800 (PST) (envelope-from d9999@optonline.net) Received: from optonline.net (ool-18bd986b.dyn.optonline.net [24.189.152.107]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with SMTP id <0H4P00DMHDXKSD@mta6.srv.hcvlny.cv.net>; Mon, 28 Oct 2002 12:58:57 -0500 (EST) Date: Mon, 28 Oct 2002 12:58:59 +0000 (PM) From: lana Subject: info<<< To: awal@tworld.com Message-id: <0H4P00DYLDY9SD@mta6.srv.hcvlny.cv.net> X-Mailer: L.C. Enterprises - Email Extractor 2002 Content-transfer-encoding: 7BIT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi ,,your home based business opportunity sounds interesting .. got few questions pleasecall me 614-837-8112 thank..you LANA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 28 23: 7:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CFEA37B401 for ; Mon, 28 Oct 2002 23:07:36 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AEE743E4A for ; Mon, 28 Oct 2002 23:07:36 -0800 (PST) (envelope-from kelly@alicia.nttmcl.com) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id g9T77bvm091993 for ; Mon, 28 Oct 2002 23:07:37 -0800 (PST) (envelope-from kelly@alicia.nttmcl.com) Received: from localhost (kelly@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) with ESMTP id g9T77bUe091990 for ; Mon, 28 Oct 2002 23:07:37 -0800 (PST) Date: Mon, 28 Oct 2002 23:07:37 -0800 (PST) From: Kelly Yancey To: freebsd-arch@freebsd.org Subject: RFC: Exporting number of bytes of protocol data to userland Message-ID: <20021028230434.U91753-200000@alicia.nttmcl.com> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-34758017-1035866312=:87083" Content-ID: <20021028230434.X91753@alicia.nttmcl.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-34758017-1035866312=:87083 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20021028230434.O91753@alicia.nttmcl.com> The attached patch is rather short so the impatient can probably skip right to the source. The background is that there are at least 3 interfaces which report the "number of bytes in the socket buffer" to userland: ioctl(s, FIONREAD, &len) stat(2) via the st_size member of struct stat kqueue(2) via data member of struct kevents returned for EVFILT_READ filters. The problem is that the number of bytes in a receive socket buffer is a trivial piece of information at best. Since there is no way for an application to determine how much of that data is non-protocol data (i.e. OOB, control, etc), it cannot use the number of anything: all of the kernel interfaces for reading from a socket buffer take the number of bytes of *protocol data* as their length parameter (actually, this is a slight exageration: TCP does well since OOB data is handled differently than OSI protocols). PR 30634 touches on this issue; UDP sockets are particularly visible examples since they always include 16 bytes of address information in addition to the datagram received. The attached patch adds an additional member to the sockbuf structure to track the amount of non-protocol data in the buffer so that interfaces can account for that before reporting to userland. The patch also updates stat(2) and kqueue(2) to report the number of bytes of protocol data rather than the total number of bytes of all data in the socket buffer. While ioctl(s, FIONREAD, &len) is also a candidate, I didn't dare touch it because it is an old, well-documented interface. But the point is that there needs to be at least one interface which reports a value to userland that it can actually use. As alluded to above, TCP sockets should be unaffected because they have no non-protocol data in the socket buffer so the majority of socket-using applications won't notice the change at all. However, UDP sockets and non-IP sockets will benefit from knowing how much readable data is available. A version of this patch has been floating around -net for over a week now with no comments but since it slightly changes API semantics I thought it best to give it another round of review on -arch before committing. Thanks, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} -- kelly@nttmcl.com --0-34758017-1035866312=:87083 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="sb_ctl.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20021028203832.K87083@alicia.nttmcl.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="sb_ctl.diff" SW5kZXg6IGxpYi9saWJjL3N5cy9rcXVldWUuMg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2xpYi9saWJjL3N5 cy9rcXVldWUuMix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjgNCmRpZmYg LXUgLXAgLXUgLXIxLjI4IGtxdWV1ZS4yDQotLS0gbGliL2xpYmMvc3lzL2tx dWV1ZS4yCTIgSnVsIDIwMDIgMjE6MDQ6MDAgLTAwMDAJMS4yOA0KKysrIGxp Yi9saWJjL3N5cy9rcXVldWUuMgkyOSBPY3QgMjAwMiAwMzo0MjowMyAtMDAw MA0KQEAgLTIyNiw3ICsyMjYsNyBAQCBhbmQgc3BlY2lmeWluZyB0aGUgbmV3 IGxvdyB3YXRlciBtYXJrIGluDQogLlZhIGRhdGEgLg0KIE9uIHJldHVybiwN CiAuVmEgZGF0YQ0KLWNvbnRhaW5zIHRoZSBudW1iZXIgb2YgYnl0ZXMgaW4g dGhlIHNvY2tldCBidWZmZXIuDQorY29udGFpbnMgdGhlIG51bWJlciBvZiBi eXRlcyBvZiBwcm90b2NvbCBkYXRhIGF2YWlsYWJsZSB0byByZWFkLg0KIC5Q cA0KIElmIHRoZSByZWFkIGRpcmVjdGlvbiBvZiB0aGUgc29ja2V0IGhhcyBz aHV0ZG93biwgdGhlbiB0aGUgZmlsdGVyDQogYWxzbyBzZXRzIEVWX0VPRiBp bg0KSW5kZXg6IHN5cy9rZXJuL3N5c19zb2NrZXQuYw0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9rZXJu L3N5c19zb2NrZXQuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDYNCmRp ZmYgLXUgLXAgLXUgLXIxLjQ2IHN5c19zb2NrZXQuYw0KLS0tIHN5cy9rZXJu L3N5c19zb2NrZXQuYwk2IE9jdCAyMDAyIDE0OjM5OjE0IC0wMDAwCTEuNDYN CisrKyBzeXMva2Vybi9zeXNfc29ja2V0LmMJMjkgT2N0IDIwMDIgMDM6NDM6 MzcgLTAwMDANCkBAIC0yMDYsNyArMjA2LDcgQEAgc29vX3N0YXQoZnAsIHVi LCBhY3RpdmVfY3JlZCwgdGQpDQogCQl1Yi0+c3RfbW9kZSB8PSBTX0lSVVNS IHwgU19JUkdSUCB8IFNfSVJPVEg7DQogCWlmICgoc28tPnNvX3N0YXRlICYg U1NfQ0FOVFNFTkRNT1JFKSA9PSAwKQ0KIAkJdWItPnN0X21vZGUgfD0gU19J V1VTUiB8IFNfSVdHUlAgfCBTX0lXT1RIOw0KLQl1Yi0+c3Rfc2l6ZSA9IHNv LT5zb19yY3Yuc2JfY2M7DQorCXViLT5zdF9zaXplID0gc28tPnNvX3Jjdi5z Yl9jYyAtIHNvLT5zb19yY3Yuc2JfY3RsOw0KIAl1Yi0+c3RfdWlkID0gc28t PnNvX2NyZWQtPmNyX3VpZDsNCiAJdWItPnN0X2dpZCA9IHNvLT5zb19jcmVk LT5jcl9naWQ7DQogCXJldHVybiAoKCpzby0+c29fcHJvdG8tPnByX3VzcnJl cXMtPnBydV9zZW5zZSkoc28sIHViKSk7DQpJbmRleDogc3lzL2tlcm4vdWlw Y19zb2NrZXQuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC9ob21lL25jdnMvc3JjL3N5cy9rZXJuL3VpcGNfc29ja2V0LmMsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjEzMg0KZGlmZiAtdSAtcCAtdSAtcjEuMTMy IHVpcGNfc29ja2V0LmMNCi0tLSBzeXMva2Vybi91aXBjX3NvY2tldC5jCTUg T2N0IDIwMDIgMjE6MjM6NDYgLTAwMDAJMS4xMzINCisrKyBzeXMva2Vybi91 aXBjX3NvY2tldC5jCTE2IE9jdCAyMDAyIDIxOjMyOjAxIC0wMDAwDQpAQCAt MTc4NSw2ICsxNzg1LDcgQEAgZmlsdF9zb3JlYWQoc3RydWN0IGtub3RlICpr biwgbG9uZyBoaW50KQ0KIAlzdHJ1Y3Qgc29ja2V0ICpzbyA9IChzdHJ1Y3Qg c29ja2V0ICopa24tPmtuX2ZwLT5mX2RhdGE7DQogDQogCWtuLT5rbl9kYXRh ID0gc28tPnNvX3Jjdi5zYl9jYzsNCisJa24tPmtuX2RhdGEgLT0gc28tPnNv X3Jjdi5zYl9jdGw7DQogCWlmIChzby0+c29fc3RhdGUgJiBTU19DQU5UUkNW TU9SRSkgew0KIAkJa24tPmtuX2ZsYWdzIHw9IEVWX0VPRjsNCiAJCWtuLT5r bl9mZmxhZ3MgPSBzby0+c29fZXJyb3I7DQpJbmRleDogc3lzL3N5cy9zb2Nr ZXR2YXIuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9o b21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0dmFyLmgsdg0KcmV0cmlldmlu ZyByZXZpc2lvbiAxLjk0DQpkaWZmIC11IC1wIC11IC1yMS45NCBzb2NrZXR2 YXIuaA0KLS0tIHN5cy9zeXMvc29ja2V0dmFyLmgJMTcgQXVnIDIwMDIgMDI6 MzY6MTYgLTAwMDAJMS45NA0KKysrIHN5cy9zeXMvc29ja2V0dmFyLmgJMTYg T2N0IDIwMDIgMjE6MzQ6MTMgLTAwMDANCkBAIC0xMDUsNiArMTA1LDcgQEAg c3RydWN0IHNvY2tldCB7DQogCQl1X2ludAlzYl9oaXdhdDsJLyogbWF4IGFj dHVhbCBjaGFyIGNvdW50ICovDQogCQl1X2ludAlzYl9tYmNudDsJLyogY2hh cnMgb2YgbWJ1ZnMgdXNlZCAqLw0KIAkJdV9pbnQJc2JfbWJtYXg7CS8qIG1h eCBjaGFycyBvZiBtYnVmcyB0byB1c2UgKi8NCisJCXVfaW50CXNiX2N0bDsJ CS8qIG5vbi1kYXRhIGNoYXJzIGluIGJ1ZmZlciAqLw0KIAkJaW50CXNiX2xv d2F0OwkvKiBsb3cgd2F0ZXIgbWFyayAqLw0KIAkJaW50CXNiX3RpbWVvOwkv KiB0aW1lb3V0IGZvciByZWFkL3dyaXRlICovDQogCQlzaG9ydAlzYl9mbGFn czsJLyogZmxhZ3MsIHNlZSBiZWxvdyAqLw0KQEAgLTIyNyw2ICsyMjgsOCBA QCBzdHJ1Y3QgeHNvY2tldCB7DQogLyogYWRqdXN0IGNvdW50ZXJzIGluIHNi IHJlZmxlY3RpbmcgYWxsb2NhdGlvbiBvZiBtICovDQogI2RlZmluZQlzYmFs bG9jKHNiLCBtKSB7IFwNCiAJKHNiKS0+c2JfY2MgKz0gKG0pLT5tX2xlbjsg XA0KKwlpZiAoKG0pLT5tX3R5cGUgIT0gTVRfREFUQSkgXA0KKwkJKHNiKS0+ c2JfY3RsICs9IChtKS0+bV9sZW47IFwNCiAJKHNiKS0+c2JfbWJjbnQgKz0g TVNJWkU7IFwNCiAJaWYgKChtKS0+bV9mbGFncyAmIE1fRVhUKSBcDQogCQko c2IpLT5zYl9tYmNudCArPSAobSktPm1fZXh0LmV4dF9zaXplOyBcDQpAQCAt MjM1LDYgKzIzOCw4IEBAIHN0cnVjdCB4c29ja2V0IHsNCiAvKiBhZGp1c3Qg Y291bnRlcnMgaW4gc2IgcmVmbGVjdGluZyBmcmVlaW5nIG9mIG0gKi8NCiAj ZGVmaW5lCXNiZnJlZShzYiwgbSkgeyBcDQogCShzYiktPnNiX2NjIC09ICht KS0+bV9sZW47IFwNCisJaWYgKChtKS0+bV90eXBlICE9IE1UX0RBVEEpIFwN CisJCShzYiktPnNiX2N0bCAtPSAobSktPm1fbGVuOyBcDQogCShzYiktPnNi X21iY250IC09IE1TSVpFOyBcDQogCWlmICgobSktPm1fZmxhZ3MgJiBNX0VY VCkgXA0KIAkJKHNiKS0+c2JfbWJjbnQgLT0gKG0pLT5tX2V4dC5leHRfc2l6 ZTsgXA0K --0-34758017-1035866312=:87083-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 0: 0:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 208BB37B401 for ; Tue, 29 Oct 2002 00:00:28 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F2D643E3B for ; Tue, 29 Oct 2002 00:00:27 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA27781; Mon, 28 Oct 2002 23:42:36 -0800 (PST) Date: Mon, 28 Oct 2002 23:42:35 -0800 (PST) From: Julian Elischer To: Kelly Yancey Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Exporting number of bytes of protocol data to userland In-Reply-To: <20021028230434.U91753-200000@alicia.nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems reasonable to me, but have you run a lot of apps? Also I'd like to know what the standards say about these interfaces. On Mon, 28 Oct 2002, Kelly Yancey wrote: > > The attached patch is rather short so the impatient can probably skip > right to the source. > > The background is that there are at least 3 interfaces which report the > "number of bytes in the socket buffer" to userland: > ioctl(s, FIONREAD, &len) > stat(2) via the st_size member of struct stat > kqueue(2) via data member of struct kevents returned for > EVFILT_READ filters. > [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 10:45:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B56E37B401 for ; Tue, 29 Oct 2002 10:45:27 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C87DD43E6E for ; Tue, 29 Oct 2002 10:45:21 -0800 (PST) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9TIjDX8537702; Tue, 29 Oct 2002 13:45:14 -0500 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9TIjCOQ035545; Tue, 29 Oct 2002 10:45:12 -0800 (PST) (envelope-from kbyanc@posi.net) Date: Tue, 29 Oct 2002 10:45:12 -0800 (PST) From: Kelly Yancey To: Julian Elischer Cc: Kelly Yancey , Subject: Re: RFC: Exporting number of bytes of protocol data to userland In-Reply-To: Message-ID: <20021029101832.X35506-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Oct 2002, Julian Elischer wrote: > It seems reasonable to me, but have you run a lot of apps? > Also I'd like to know what the standards say about these interfaces. > > On Mon, 28 Oct 2002, Kelly Yancey wrote: > > > > > The attached patch is rather short so the impatient can probably skip > > right to the source. > > > > The background is that there are at least 3 interfaces which report the > > "number of bytes in the socket buffer" to userland: > > ioctl(s, FIONREAD, &len) > > stat(2) via the st_size member of struct stat > > kqueue(2) via data member of struct kevents returned for > > EVFILT_READ filters. > > > [...] > Thanks for the feedback, I've had the kqueue portion of the patch running on my workstation for a couple of weeks now. Needless to say, not a lot of applications use kqueue yet so that doesn't really say much. :| However my UDP applicates which use kqueue are rather happy with the change. :) In any event, kqueue isn't covered by any standards so it is the safest to modify. The stat change I've been running for a few days with no ill effects so far which I more or less expected: I seriously doubt too many applications rely on fstat's behavior on sockets. Heck, according to the fstat(2) man page[*], practically the entire struct sb (including st_size) should be 0 which, despite not being the case on either -stable or -current, if anything relied on the old st_size value being anything other than 0 then they already knew they were dancing with the devil. All this is moot anyway because the change is a no-op for sockets without non-protocol data in the socket buffer (i.e. TCP) and for sockets that do put non-protocol data in the socket buffer the old value was practically useless anyway. Thanks again, Kelly [*] The fstat(2) man page's BUGS section is horribly out-of-touch with reality with regards to sockets. -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 13:16:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58B0837B404 for ; Tue, 29 Oct 2002 13:16:41 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D326E43E6E for ; Tue, 29 Oct 2002 13:16:40 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 88093 invoked by uid 1000); 29 Oct 2002 21:16:41 -0000 Date: Tue, 29 Oct 2002 13:16:41 -0800 (PST) From: Nate Lawson To: Kelly Yancey Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Exporting number of bytes of protocol data to userland In-Reply-To: <20021028230434.U91753-200000@alicia.nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In uipc-socket, you should probably just subtract on the previous line rather than using -= -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 17:45:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F91737B401 for ; Tue, 29 Oct 2002 17:45:26 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A77A43E4A for ; Tue, 29 Oct 2002 17:45:25 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g9U1ioOo036753 for ; Tue, 29 Oct 2002 20:44:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 29 Oct 2002 20:44:49 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Re: Status of lukemftpd? (was: cvs commit: src/etc inetd.conf (fwd)) In-Reply-To: <20021027021440.GB58312@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 Oct 2002, David O'Brien wrote: > On Thu, Oct 24, 2002 at 12:17:09PM -0400, Robert Watson wrote: > > Given that lukemftpd is highly feature incomplete with regards to the > > default ftpd, I'd like to propose at least the following: > > What "default" ftpd? We don't have one anymore. I consider it a HUGE > feature that lukemftpd doesn't do PAM. Like the new "standards" > headers, PAM has done nothing for me over what I had in pre-PAM'ized > FreeBSD, but cause great pain. Yet another promiss of something the > better and easier that has not turned out to be the case. > > Anyway, please do not do anything to lukemftpd until I return. David, Now that you're back from travel, do you have any plans to resolve the issues I've raised with lukemftpd? I've pointed at a number of problems (both large and small) and presumably we should try and make progress quickly so that the issues are resolved by 5.0-RELEASE. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 20:39:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9AC237B401 for ; Tue, 29 Oct 2002 20:39:44 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A3A43E75 for ; Tue, 29 Oct 2002 20:39:44 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 0FB60534E; Wed, 30 Oct 2002 05:39:42 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: "MB" instead of "K bytes" in memory probe? From: Dag-Erling Smorgrav Date: Wed, 30 Oct 2002 05:39:41 +0100 Message-ID: Lines: 18 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386--freebsd) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= The attached patch replaces the "K bytes" figure in the memory probe ("{real,avail} memory = XXX") with a MB figure. Before-and-after from /var/log/messages: Oct 21 22:44:21 dsa kernel: real memory = 266493952 (260248K bytes) Oct 21 22:44:21 dsa kernel: avail memory = 253214720 (247280K bytes) Oct 29 15:55:18 dsa kernel: real memory = 266493952 (254 MB) Oct 29 15:55:18 dsa kernel: avail memory = 251641856 (239 MB) Not a big thing, but I find the last two lines far easier to read than the first two. Any objections to committing this patch? DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=memory.diff Index: sys/alpha/alpha/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.187 diff -u -r1.187 machdep.c --- sys/alpha/alpha/machdep.c 25 Oct 2002 19:10:55 -0000 1.187 +++ sys/alpha/alpha/machdep.c 29 Oct 2002 14:10:34 -0000 @@ -266,7 +266,8 @@ #ifdef PERFMON perfmon_init(); #endif - printf("real memory = %ld (%ldK bytes)\n", alpha_ptob(Maxmem), alpha_ptob(Maxmem) / 1024); + printf("real memory = %ld (%ld MB)\n", alpha_ptob(Maxmem), + alpha_ptob(Maxmem) / 1048576); /* * Display any holes after the first chunk of extended memory. @@ -285,8 +286,8 @@ vm_ksubmap_init(&kmi); - printf("avail memory = %ld (%ldK bytes)\n", ptoa(cnt.v_free_count), - ptoa(cnt.v_free_count) / 1024); + printf("avail memory = %ld (%ld MB)\n", ptoa(cnt.v_free_count), + ptoa(cnt.v_free_count) / 1048576); /* * Set up buffers, so they can be used to read disk labels. Index: sys/i386/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v retrieving revision 1.545 diff -u -r1.545 machdep.c --- sys/i386/i386/machdep.c 25 Oct 2002 19:10:56 -0000 1.545 +++ sys/i386/i386/machdep.c 29 Oct 2002 14:11:05 -0000 @@ -236,8 +236,8 @@ #ifdef PERFMON perfmon_init(); #endif - printf("real memory = %u (%uK bytes)\n", ptoa(Maxmem), - ptoa(Maxmem) / 1024); + printf("real memory = %u (%u MB)\n", ptoa(Maxmem), + ptoa(Maxmem) / 1048576); /* * Display any holes after the first chunk of extended memory. */ @@ -257,8 +257,8 @@ vm_ksubmap_init(&kmi); - printf("avail memory = %u (%uK bytes)\n", ptoa(cnt.v_free_count), - ptoa(cnt.v_free_count) / 1024); + printf("avail memory = %u (%u MB)\n", ptoa(cnt.v_free_count), + ptoa(cnt.v_free_count) / 1048576); /* * Set up buffers, so they can be used to read disk labels. Index: sys/ia64/ia64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/ia64/ia64/machdep.c,v retrieving revision 1.117 diff -u -r1.117 machdep.c --- sys/ia64/ia64/machdep.c 25 Oct 2002 19:10:56 -0000 1.117 +++ sys/ia64/ia64/machdep.c 29 Oct 2002 14:12:10 -0000 @@ -196,7 +196,8 @@ #ifdef PERFMON perfmon_init(); #endif - printf("real memory = %ld (%ldK bytes)\n", ia64_ptob(Maxmem), ia64_ptob(Maxmem) / 1024); + printf("real memory = %ld (%ld MB)\n", ia64_ptob(Maxmem), + ia64_ptob(Maxmem) / 1048576); /* * Display any holes after the first chunk of extended memory. @@ -215,8 +216,8 @@ vm_ksubmap_init(&kmi); - printf("avail memory = %ld (%ldK bytes)\n", ptoa(cnt.v_free_count), - ptoa(cnt.v_free_count) / 1024); + printf("avail memory = %ld (%ld MB)\n", ptoa(cnt.v_free_count), + ptoa(cnt.v_free_count) / 1048576); if (fpswa_interface == NULL) printf("Warning: no FPSWA package supplied\n"); Index: sys/pc98/i386/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/pc98/i386/machdep.c,v retrieving revision 1.300 diff -u -r1.300 machdep.c --- sys/pc98/i386/machdep.c 26 Oct 2002 15:44:06 -0000 1.300 +++ sys/pc98/i386/machdep.c 29 Oct 2002 14:14:41 -0000 @@ -256,8 +256,8 @@ #ifdef PERFMON perfmon_init(); #endif - printf("real memory = %u (%uK bytes)\n", ptoa(Maxmem), - ptoa(Maxmem) / 1024); + printf("real memory = %u (%u MB)\n", ptoa(Maxmem), + ptoa(Maxmem) / 1048576); /* * Display any holes after the first chunk of extended memory. */ @@ -277,8 +277,8 @@ vm_ksubmap_init(&kmi); - printf("avail memory = %u (%uK bytes)\n", ptoa(cnt.v_free_count), - ptoa(cnt.v_free_count) / 1024); + printf("avail memory = %u (%u MB)\n", ptoa(cnt.v_free_count), + ptoa(cnt.v_free_count) / 1048576); /* * Set up buffers, so they can be used to read disk labels. Index: sys/powerpc/powerpc/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/powerpc/powerpc/machdep.c,v retrieving revision 1.40 diff -u -r1.40 machdep.c --- sys/powerpc/powerpc/machdep.c 25 Oct 2002 19:10:57 -0000 1.40 +++ sys/powerpc/powerpc/machdep.c 29 Oct 2002 14:15:05 -0000 @@ -199,8 +199,8 @@ #ifdef PERFMON perfmon_init(); #endif - printf("real memory = %ld (%ldK bytes)\n", ptoa(Maxmem), - ptoa(Maxmem) / 1024); + printf("real memory = %ld (%ld MB)\n", ptoa(Maxmem), + ptoa(Maxmem) / 1048576); /* * Display any holes after the first chunk of extended memory. @@ -220,8 +220,8 @@ vm_ksubmap_init(&kmi); - printf("avail memory = %ld (%ldK bytes)\n", ptoa(cnt.v_free_count), - ptoa(cnt.v_free_count) / 1024); + printf("avail memory = %ld (%ld MB)\n", ptoa(cnt.v_free_count), + ptoa(cnt.v_free_count) / 1048576); /* * Set up buffers, so they can be used to read disk labels. --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 20:46:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A7337B401 for ; Tue, 29 Oct 2002 20:46:31 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBC1A43E75 for ; Tue, 29 Oct 2002 20:46:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id g9U4kPFC013682; Tue, 29 Oct 2002 20:46:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id g9U4kPnF013681; Tue, 29 Oct 2002 20:46:25 -0800 (PST) (envelope-from dillon) Date: Tue, 29 Oct 2002 20:46:25 -0800 (PST) From: Matthew Dillon Message-Id: <200210300446.g9U4kPnF013681@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: "MB" instead of "K bytes" in memory probe? References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Great idea! -Matt :--=-=-= : :The attached patch replaces the "K bytes" figure in the memory probe :("{real,avail} memory = XXX") with a MB figure. Before-and-after from :/var/log/messages: : :Oct 21 22:44:21 dsa kernel: real memory = 266493952 (260248K bytes) :Oct 21 22:44:21 dsa kernel: avail memory = 253214720 (247280K bytes) :Oct 29 15:55:18 dsa kernel: real memory = 266493952 (254 MB) :Oct 29 15:55:18 dsa kernel: avail memory = 251641856 (239 MB) : :Not a big thing, but I find the last two lines far easier to read than :the first two. Any objections to committing this patch? : :DES :-- :Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 23:32: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF68537B401 for ; Tue, 29 Oct 2002 23:32:05 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7BB7843E42 for ; Tue, 29 Oct 2002 23:32:05 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 89336 invoked by uid 1000); 30 Oct 2002 07:32:07 -0000 Date: Tue, 29 Oct 2002 23:32:07 -0800 (PST) From: Nate Lawson To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: "MB" instead of "K bytes" in memory probe? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Considering FreeBSD has never run on a machine with less than 1 MB (I think 4 MB was the lowest) and that the values are only for the benefit of the user, sounds great. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 29 23:56:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3690C37B401 for ; Tue, 29 Oct 2002 23:56:34 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8B243E3B for ; Tue, 29 Oct 2002 23:56:33 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0273.cvx21-bradley.dialup.earthlink.net ([209.179.193.18] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 186niJ-00000D-00; Tue, 29 Oct 2002 23:56:31 -0800 Message-ID: <3DBF9061.D583C481@mindspring.com> Date: Tue, 29 Oct 2002 23:55:13 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: "MB" instead of "K bytes" in memory probe? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > The attached patch replaces the "K bytes" figure in the memory probe > ("{real,avail} memory = XXX") with a MB figure. Before-and-after from > /var/log/messages: > > Oct 21 22:44:21 dsa kernel: real memory = 266493952 (260248K bytes) > Oct 21 22:44:21 dsa kernel: avail memory = 253214720 (247280K bytes) > Oct 29 15:55:18 dsa kernel: real memory = 266493952 (254 MB) > Oct 29 15:55:18 dsa kernel: avail memory = 251641856 (239 MB) > > Not a big thing, but I find the last two lines far easier to read than > the first two. Any objections to committing this patch? It's kind of annoying that the KVA gets subtracted out up front; I'm pretty sure that you don't have 254MB of SIMMs... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 30 0: 0:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D331837B401 for ; Wed, 30 Oct 2002 00:00:23 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A3DC43E88 for ; Wed, 30 Oct 2002 00:00:23 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0273.cvx21-bradley.dialup.earthlink.net ([209.179.193.18] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 186nlz-0002d0-00; Wed, 30 Oct 2002 00:00:19 -0800 Message-ID: <3DBF9145.B0FAB8BD@mindspring.com> Date: Tue, 29 Oct 2002 23:59:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: Dag-Erling Smorgrav , arch@freebsd.org Subject: Re: "MB" instead of "K bytes" in memory probe? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Lawson wrote: > Considering FreeBSD has never run on a machine with less than 1 MB (I > think 4 MB was the lowest) and that the values are only for the benefit of > the user, sounds great. 2MB ACER, compiled without networking (FreeBSD 1.1.5.1). 8-). -- Terry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 30 0: 5: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACE137B404 for ; Wed, 30 Oct 2002 00:05:08 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 982EB43E42 for ; Wed, 30 Oct 2002 00:05:06 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9U855pk043605; Wed, 30 Oct 2002 01:05:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 30 Oct 2002 01:03:47 -0700 (MST) Message-Id: <20021030.010347.76766507.imp@bsdimp.com> To: nate@root.org Cc: des@ofug.org, arch@FreeBSD.ORG Subject: Re: "MB" instead of "K bytes" in memory probe? From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Nate Lawson writes: : Considering FreeBSD has never run on a machine with less than 1 MB (I : think 4 MB was the lowest) and that the values are only for the benefit of : the user, sounds great. Actually, ultra-stripped 1.0 kernels were being booted on 2MB and 3MB 386SX systems. It was possible to build 1.0 kernels that were 500k or so if you restricted devices and features severely. But you are right. We should use MB for anything under about 2G or so (but even 4G vs 4096M isn't that bad). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 30 0:20:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5DDD37B401 for ; Wed, 30 Oct 2002 00:20:10 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A1F43E77 for ; Wed, 30 Oct 2002 00:20:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id g9U8K3FC014619; Wed, 30 Oct 2002 00:20:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id g9U8K3wB014618; Wed, 30 Oct 2002 00:20:03 -0800 (PST) (envelope-from dillon) Date: Wed, 30 Oct 2002 00:20:03 -0800 (PST) From: Matthew Dillon Message-Id: <200210300820.g9U8K3wB014618@apollo.backplane.com> To: "M. Warner Losh" Cc: nate@root.org, des@ofug.org, arch@FreeBSD.ORG Subject: Re: "MB" instead of "K bytes" in memory probe? References: <20021030.010347.76766507.imp@bsdimp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Keep in mind that Des's change is still printing the total number of bytes, in bytes. The MB is in parenthesis. Oct 29 15:55:18 dsa kernel: real memory = 266493952 (254 MB) There is no need to do anything fancy inside the parenthesis. It should just be in megabytes (as DES presented). If the machine has so little memory that '1 MB' or '2 MB' meaningless, then the user can still read the actual number of bytes. I would certainly find the MB number useful no matter how little memory the computer has. -Matt :: think 4 MB was the lowest) and that the values are only for the benefit of :: the user, sounds great. : :Actually, ultra-stripped 1.0 kernels were being booted on 2MB and 3MB :386SX systems. It was possible to build 1.0 kernels that were 500k or :so if you restricted devices and features severely. : :But you are right. We should use MB for anything under about 2G or so :(but even 4G vs 4096M isn't that bad). : :Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 30 9:43:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 032BD37B401 for ; Wed, 30 Oct 2002 09:43:41 -0800 (PST) Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A70643E88 for ; Wed, 30 Oct 2002 09:43:40 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g9UHhWMF216294; Wed, 30 Oct 2002 12:43:32 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200210300820.g9U8K3wB014618@apollo.backplane.com> References: <20021030.010347.76766507.imp@bsdimp.com> <200210300820.g9U8K3wB014618@apollo.backplane.com> Date: Wed, 30 Oct 2002 12:43:31 -0500 To: Matthew Dillon , "M. Warner Losh" From: Garance A Drosihn Subject: Re: "MB" instead of "K bytes" in memory probe? Cc: nate@root.org, des@ofug.org, arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:20 AM -0800 10/30/02, Matthew Dillon wrote: >Warner Losh wrote: >:But you are right. We should use MB for anything under about 2G >:or so (but even 4G vs 4096M isn't that bad). > > Keep in mind that Des's change is still printing the total number > of bytes, in bytes. The MB is in parenthesis. > >=> Oct 29 15:55:18 dsa kernel: real memory = 266493952 (254 MB) > > There is no need to do anything fancy inside the parenthesis. > It should just be in megabytes (as DES presented). If the > machine has so little memory that '1 MB' or '2 MB' meaningless, > then the user can still read the actual number of bytes. I > would certainly find the MB number useful no matter how little > memory the computer has. I think you read Warner's request backwards. He was saying to use MB for anything *under* 2gig, and presumably switch to gigabytes at that point. He was talking about machines with lots and lots of memory, not "little memory". That is an idea I like too, but I'd do it somewhere closer to 8196 Meg. Actually I tend to do it at "10,000 somethings", switching to "10 (somethings*1K)". -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 30 11:43:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE6E237B404; Wed, 30 Oct 2002 11:43:35 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8715E43E88; Wed, 30 Oct 2002 11:43:31 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch02.lj.gnf.org [172.25.10.20]) by ns1.gnf.org (8.12.3/8.12.3) with ESMTP id g9UJhSMf071369; Wed, 30 Oct 2002 11:43:28 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Oct 2002 11:44:16 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.6/8.12.5) with ESMTP id g9UJhU7j082074; Wed, 30 Oct 2002 11:43:30 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.6/8.12.6/Submit) id g9UJhTcH082073; Wed, 30 Oct 2002 11:43:29 -0800 (PST) Date: Wed, 30 Oct 2002 11:43:29 -0800 From: Gordon Tetlow To: Robert Watson Cc: Dan Nelson , Julian Elischer , Mark Valentine , Poul-Henning Kamp , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <20021030194329.GZ30253@roark.gnf.org> References: <20021025193859.GA51818@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="plrZyjZcS71xjaqX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-OriginalArrivalTime: 30 Oct 2002 19:44:16.0881 (UTC) FILETIME=[BB589610:01C2804C] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --plrZyjZcS71xjaqX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 25, 2002 at 03:44:36PM -0400, Robert Watson wrote: > On Fri, 25 Oct 2002, Dan Nelson wrote: >=20 > > In the last episode (Oct 25), Julian Elischer said: > > > > > > In the future I feel that the default names may eventually be > > > over-ridden by semantically meaningfull names. e.g. You may partition= a > > > drive and give each partition a name which might be used instead of t= he > > > default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that = it > > > would rather be known "/dev/swap2" because the table entry has a field > > > "swap%d" in it, or disk2 may decide that it wants to be known as > > > "/dev/tunes". (A removable disk full of music) > >=20 > > Linux allows this, sort of. You can label disks with tune2fs, and mount > > can find disks based either the label or filesystem UUID. This lets you > > have an fstab that looks like >=20 > Gordon Tetlow and I have been discussing possibly reusing the superblock > "last mounted on" field for volume label and uuid storage. Right now the > "last mounted on" data is basically used for printfs, and often somewhat > confusingly (the kernel will print the last mount point when reporting a > mount error, which might not be where the user is trying to mount). It's > 512 bytes of superblock space, so would provide lots of room for volume > identifier information, if we decided to go that way. Anyone interested > in this sort of thing should spend a fair amount of time looking at prior > art, including at Apple's approach to volume name automounting. Also, > Poul-Henning's comments on security are important: in some case, you may > be less willing to trust the label on the media than others. Another > important consideration relates to issues like removable media, and media > from less trusted sources, as well as accidental collisions in the > namespace. If anyone wants to take on this project seriously, GEOM and > devfs provide a good starting point and many of the tools you need.=20 > Anyone giving it a try should go do a prior art search and document what > they find, however. :-)=20 Well, I put together the necessary struct fs patches along with the stuff that is needed by the various utilities (newfs, tunefs, dumpfs). All this does is put the volume label there. Nothing interesting is done with them. The next step is to write a GEOM module that would expose those volume labels (probably into /dev/volume). The patch is located at http://people.freebsd.org/~gordon/patches/volume.diff I welcome all feedback as to code quality, it's been about 3 years since I've done anything with C. -gordon --plrZyjZcS71xjaqX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9wDZhRu2t9DV9ZfsRAh2pAJwNz58iibYn1RofD/+UhFKwjWXSVwCfTQeL brh8qTMKLhEsmXHctckNtRE= =00wk -----END PGP SIGNATURE----- --plrZyjZcS71xjaqX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 31 17:55:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37E1637B401 for ; Thu, 31 Oct 2002 17:55:16 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CBA443E7B for ; Thu, 31 Oct 2002 17:55:15 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA11tE0N083457 for ; Thu, 31 Oct 2002 17:55:14 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA11tGbE001764 for ; Thu, 31 Oct 2002 17:55:16 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gA11tG1i001763 for arch@FreeBSD.org; Thu, 31 Oct 2002 17:55:16 -0800 (PST) (envelope-from marcel) Date: Thu, 31 Oct 2002 17:55:15 -0800 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: i386: Bug in prototype for rgs() Message-ID: <20021101015515.GA1707@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gang, The prototype for rgs() in sys/i386/include/cpufunc.h claims that the result of the function is 32-bits (ie returns an u_int). As such, when inlining the function the compiler happy generates the following code: 11ed7: 8c 6d 80 movl %gs,0xffffff80(%ebp) or 12175: 8c ad 14 fd ff ff movl %gs,0xfffffd14(%ebp) where in this case the memory operand is 32-bit. The source location that corresponds with this is sys/i386/linux/linux_sysvec.c:331 and sys/i386/linux/linux_sysvec.c:451 If you actually look at the frame being created in the debugger, you'll see: Breakpoint 4, linux_sendsig (catcher=0x28091468, sig=11, mask=0xc2827d78, code=30) at ../../../i386/linux/linux_sysvec.c:472 472 if (copyout(&frame, fp, sizeof(frame)) != 0) { Current language: auto; currently c (kgdb) p /x frame $21 = {sf_sig = 0xb, sf_sc = {sc_gs = 0xcdd3002f, sc_fs = 0xf, sc_es = 0x2f, sc_ds = 0x2f, sc_edi = 0x2809aca8, sc_esi = 0xbfbff0e0, [snip] In words: the upper 32-bit of sf_sc.sc_gs are garbage. Different CPU implementations behave differently WRT to the upper 16-bits when the destination is known to be a 32-bit operand (ie register). The point: should we not do (whitespace corrupted diff): Index: cpufunc.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v retrieving revision 1.130 diff -u -r1.130 cpufunc.h --- cpufunc.h 22 Sep 2002 04:45:21 -0000 1.130 +++ cpufunc.h 1 Nov 2002 01:08:45 -0000 @@ -449,10 +449,10 @@ return (sel); } -static __inline u_int +static __inline u_int16_t rgs(void) { - u_int sel; + u_int16_t sel; __asm __volatile("movl %%gs,%0" : "=rm" (sel)); return (sel); } So that the compiler generates: 5c2: 8c e8 mov %gs,%eax 5c4: 0f b7 c0 movzwl %ax,%eax 5c7: 89 45 80 mov %eax,0xffffff80(%ebp) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 31 21:47:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31B5137B401 for ; Thu, 31 Oct 2002 21:47:12 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A0DA43E4A for ; Thu, 31 Oct 2002 21:47:11 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA20904; Fri, 1 Nov 2002 16:46:59 +1100 Date: Fri, 1 Nov 2002 16:58:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: i386: Bug in prototype for rgs() In-Reply-To: <20021101015515.GA1707@dhcp01.pn.xcllnt.net> Message-ID: <20021101155451.G13913-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 31 Oct 2002, Marcel Moolenaar wrote: > The prototype for rgs() in sys/i386/include/cpufunc.h claims that > the result of the function is 32-bits (ie returns an u_int). As This partly is an (out of date) efficiency hack dating from when gas generated pessimal code for mov[w] between segment registers and r/m16. It may still work provided the r/m16 is actually r/m32 (since it just gives garbage in the upper bits but the upper bits are never really used. obrien fixed this hack in *.s. This is partially a non-out-of date efficiency hack for avoiding 16-bit load/stores of copies of segment registers in 16-bit general registers. It is more efficient to load/store the corresponding 32-bit registers unless this causes partial register stalls, and this is correct provided it doesn't leak kernel bits to userland. > such, when inlining the function the compiler happy generates > the following code: > > 11ed7: 8c 6d 80 movl %gs,0xffffff80(%ebp) > > or > > 12175: 8c ad 14 fd ff ff movl %gs,0xfffffd14(%ebp) > > where in this case the memory operand is 32-bit. The source location > that corresponds with this is sys/i386/linux/linux_sysvec.c:331 and > sys/i386/linux/linux_sysvec.c:451 Seems OK, except we really want a movw. gcc is smart to convert this to a direct memory access. gcc accidentally generates perfect code although not what the assignment says: it stores to 16 bits of memory and doesn't change the upper bits, although the assignment together with the hacks say that it should write garbage to the upper bits. If gcc weren't so smart, then it would generate "movw %gs,%ax; movl %eax.mem" and write the garbage in the upper bits of %eax. > If you actually look at the frame being created in the debugger, you'll > see: > > Breakpoint 4, linux_sendsig (catcher=0x28091468, sig=11, mask=0xc2827d78, > code=30) at ../../../i386/linux/linux_sysvec.c:472 > 472 if (copyout(&frame, fp, sizeof(frame)) != 0) { > Current language: auto; currently c > (kgdb) p /x frame > $21 = {sf_sig = 0xb, sf_sc = {sc_gs = 0xcdd3002f, sc_fs = 0xf, sc_es = 0x2f, > sc_ds = 0x2f, sc_edi = 0x2809aca8, sc_esi = 0xbfbff0e0, > [snip] > > In words: the upper 32-bit of sf_sc.sc_gs are garbage. Different CPU > implementations behave differently WRT to the upper 16-bits when the > destination is known to be a 32-bit operand (ie register). I think the upper bits are never accessed for moves to and from segment registers (certainly not unless there are bogus operand size prefixes). Here the upper bits are garbage simply because linux_sendsig() is missing a bzero() and gcc doesn't write to them. A bzero() is necessary in case there are any [other] holes in the struct. > The point: should we not do (whitespace corrupted diff): > > Index: cpufunc.h > =================================================================== > RCS file: /home/ncvs/src/sys/i386/include/cpufunc.h,v > retrieving revision 1.130 > diff -u -r1.130 cpufunc.h > --- cpufunc.h 22 Sep 2002 04:45:21 -0000 1.130 > +++ cpufunc.h 1 Nov 2002 01:08:45 -0000 > @@ -449,10 +449,10 @@ > return (sel); > } > > -static __inline u_int > +static __inline u_int16_t > rgs(void) > { > - u_int sel; > + u_int16_t sel; > __asm __volatile("movl %%gs,%0" : "=rm" (sel)); ^ should be 'w' or nothing (I prefer 'w', but obrien used nothing in *.s (due to residual bugs in gas?) > return (sel); > } > > > So that the compiler generates: > > 5c2: 8c e8 mov %gs,%eax ^ ^^^^ (low qual/wrong) > 5c4: 0f b7 c0 movzwl %ax,%eax > 5c7: 89 45 80 mov %eax,0xffffff80(%ebp) ^ ^^^^^^^^^^ (low qual) This is mostly a pessimization. Cases where a memory operand is wanted would work better (much the same as now, but for the right reasons) if they were 16 bits (sc_gs would hen be followed by 16 bits of explicit padding). Doing things correctly probably works better for load_gs(), etc. load_gs() currently forces an extension of the operand to 32 bits if it is initially 16 bits. Copies of segment registers in memory are currently always kept in 32-bit garbage-extended form so that this extension is free (pushing segment regsisters garbage-extends them in a different way). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 31 22: 0:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F09837B401 for ; Thu, 31 Oct 2002 22:00:32 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C02843E77 for ; Thu, 31 Oct 2002 22:00:31 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA160P0N083892; Thu, 31 Oct 2002 22:00:25 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA160RbE002422; Thu, 31 Oct 2002 22:00:27 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gA160R97002421; Thu, 31 Oct 2002 22:00:27 -0800 (PST) (envelope-from marcel) Date: Thu, 31 Oct 2002 22:00:26 -0800 From: Marcel Moolenaar To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: i386: Bug in prototype for rgs() Message-ID: <20021101060026.GA2372@dhcp01.pn.xcllnt.net> References: <20021101015515.GA1707@dhcp01.pn.xcllnt.net> <20021101155451.G13913-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021101155451.G13913-100000@gamplex.bde.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Nov 01, 2002 at 04:58:18PM +1100, Bruce Evans wrote: > > Here the upper bits are garbage simply because linux_sendsig() is missing > a bzero() and gcc doesn't write to them. A bzero() is necessary in case > there are any [other] holes in the struct. Yeah, I noticed that too and moved the bzero that covered the fpstate all the way up and have it cover the complete frame. Thanks for the explanation. I wasn't aware the behaviour was intentional, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 1 5:46: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33DEA37B401 for ; Fri, 1 Nov 2002 05:46:08 -0800 (PST) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 62AC843E3B for ; Fri, 1 Nov 2002 05:46:05 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 7395 invoked from network); 1 Nov 2002 13:38:52 -0000 Received: from upnet-dialinpool-87.upnet.gr (HELO gray.sea.gr) (root@150.140.128.167) by nic.upatras.gr with SMTP; 1 Nov 2002 13:38:52 -0000 Received: from gray.sea.gr (gray [127.0.0.1]) by gray.sea.gr (8.12.6/8.12.6) with ESMTP id gA1DkOY0027872; Fri, 1 Nov 2002 15:46:24 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by gray.sea.gr (8.12.6/8.12.6/Submit) id gA1DJYOf021245; Fri, 1 Nov 2002 15:19:34 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 1 Nov 2002 15:19:33 +0200 From: Giorgos Keramidas To: Mark Valentine Cc: Julian Elischer , freebsd-arch@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <20021101131933.GA14846@gray.sea.gr> References: <200210252215.g9PMFlBO083244@dotar.thuvia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210252215.g9PMFlBO083244@dotar.thuvia.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-10-25 23:15, Mark Valentine wrote: > Julian Elischer wrote: > > If you are going to repartition your disk, then fix the fstab > > before you reboot for goodness' sake! It's not so complicated! > > I'm not repartitioning in any way which should affect FreeBSD. > > It doesn't sound complicated in this scenario, but when you consider > the partition table index embedded in backups and in scripts, it's > another matter. Those scripts could be smarter: $ mount | grep 'on / ' | awk '{print $1}' /dev/ad0s1a Giorgos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message