From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 00:15:16 2004 Return-Path: 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 38C8E16A524 for ; Sun, 7 Nov 2004 00:15:16 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB0AD43D31 for ; Sun, 7 Nov 2004 00:15:15 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id iA70FEaa015466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Sat, 6 Nov 2004 19:15:14 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id iA70FDxm015465; Sat, 6 Nov 2004 19:15:13 -0500 (EST) (envelope-from wollman) Date: Sat, 6 Nov 2004 19:15:13 -0500 (EST) From: Garrett Wollman Message-Id: <200411070015.iA70FDxm015465@khavrinen.lcs.mit.edu> To: phk@phk.freebsd.dk X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <10847.1099784360@critter.freebsd.dk> Organization: MIT Laboratory for Computer Science X-Spam-Score: -6.6 () IN_REP_TO,QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.37 cc: arch@FreeBSD.org Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 00:15:16 -0000 In article <10847.1099784360@critter.freebsd.dk> you write: >Assume a process with two threads on two CPUs, both >doing read(fd, buf, len) at the same time. > >Should we let both reads into the driver at the same time ? > >If so, which uio_offset do we hand them ? POSIX is quite clear on the matter: > All of the functions chmod (), close (), fchmod (), fcntl (), fstat > (), ftruncate (), lseek (), open (), read (), readlink (), stat (), > symlink ( ), and write ( ) shall be atomic with respect to each other > in the effects specified in IEEE Std 1003.1-2001 when they operate on > regular files. If two threads each call one of these functions, each > call shall either see all of the specified effects of the other call, > or none of them. (One of the "specified effects" is advancing the file offset.) -GAWollman -- Garrett A. Wollman | As the Constitution endures, persons in every wollman@lcs.mit.edu | generation can invoke its principles in their own Opinions not those of| search for greater freedom. MIT, LCS, CRS, or NSA| - A. Kennedy, Lawrence v. Texas, 539 U.S. ___ (2003) From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 00:15:36 2004 Return-Path: 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 B622016A526 for ; Sun, 7 Nov 2004 00:15:19 +0000 (GMT) Received: from beastie.mckusick.com (dsl081-247-227.sfo1.dsl.speakeasy.net [64.81.247.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C261B43D41 for ; Sun, 7 Nov 2004 00:15:18 +0000 (GMT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.9) with ESMTP id iA70FFCW074582; Sat, 6 Nov 2004 16:15:17 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200411070015.iA70FFCW074582@beastie.mckusick.com> To: Poul-Henning Kamp In-Reply-To: Your message of "Sun, 07 Nov 2004 00:39:20 +0100." Date: Sat, 06 Nov 2004 16:15:15 -0800 From: Kirk McKusick cc: arch@freebsd.org Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 00:15:37 -0000 > To: arch@freebsd.org > From: Poul-Henning Kamp > Date: Sun, 07 Nov 2004 00:39:20 +0100 > Subject: Multi-threading access to device drivers. > X-ASK-Info: Whitelist match > > Assume a device driver which is not Giant-handicapped. > > Assume an I/O path which does not need Giant to get from > read(2) to the device driver. > > Assume a SMP machine. > > Assume a process with two threads on two CPUs, both > doing read(fd, buf, len) at the same time. > > Should we let both reads into the driver at the same time ? > > If so, which uio_offset do we hand them ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. Historically, reads on a file descriptor are serialized. I believe that they still should. An an example, if two threads are trying to read a stream of commands, then they should not both get the same one as the above example would allow. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 00:38:47 2004 Return-Path: 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 A52F916A4CE for ; Sun, 7 Nov 2004 00:38:47 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3F443D2F for ; Sun, 7 Nov 2004 00:38:47 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 19326 invoked from network); 7 Nov 2004 00:38:47 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 7 Nov 2004 00:38:47 -0000 Received: from hydrogen.funkthat.com (lejqdo@localhost.funkthat.com [127.0.0.1])iA70chB6076933; Sat, 6 Nov 2004 16:38:46 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id iA70cgjw076932; Sat, 6 Nov 2004 16:38:42 -0800 (PST) Date: Sat, 6 Nov 2004 16:38:42 -0800 From: John-Mark Gurney To: Poul-Henning Kamp Message-ID: <20041107003842.GB73306@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , arch@freebsd.org References: <10847.1099784360@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10847.1099784360@critter.freebsd.dk> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: arch@freebsd.org Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 00:38:47 -0000 Poul-Henning Kamp wrote this message on Sun, Nov 07, 2004 at 00:39 +0100: > Assume a device driver which is not Giant-handicapped. > > Assume an I/O path which does not need Giant to get from > read(2) to the device driver. > > Assume a SMP machine. > > Assume a process with two threads on two CPUs, both > doing read(fd, buf, len) at the same time. > > Should we let both reads into the driver at the same time ? > > If so, which uio_offset do we hand them ? As was quoted POSIX, the update should be atomic.. so my reading of that is that you lock the fd, when you read the offset from the fd, you need to also update the offset with the number of bytes read, so that a racing read both doesn't drop any data, nor duplicate any data.. i.e. single file with fixed records, it should be perfectly safe to throw five threads looping doing a read processing of the records w/o fear of duplicate records, or dropped records... And if we handle it in this manner, then you can allow multiple reads into the driver... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 03:57:39 2004 Return-Path: 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 C350D16A4CF for ; Sun, 7 Nov 2004 03:57:39 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7649243D3F for ; Sun, 7 Nov 2004 03:57:39 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iA73vavA040766; Sat, 6 Nov 2004 19:57:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iA73vaqU040765; Sat, 6 Nov 2004 19:57:36 -0800 (PST) (envelope-from dillon) Date: Sat, 6 Nov 2004 19:57:36 -0800 (PST) From: Matthew Dillon Message-Id: <200411070357.iA73vaqU040765@apollo.backplane.com> To: John-Mark Gurney References: <10847.1099784360@critter.freebsd.dk> <20041107003842.GB73306@funkthat.com> cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 03:57:40 -0000 :As was quoted POSIX, the update should be atomic.. so my reading of :that is that you lock the fd, when you read the offset from the fd, :you need to also update the offset with the number of bytes read, so :that a racing read both doesn't drop any data, nor duplicate any data.. : :i.e. single file with fixed records, it should be perfectly safe to :throw five threads looping doing a read processing of the records w/o :fear of duplicate records, or dropped records... : :And if we handle it in this manner, then you can allow multiple reads :into the driver... : :-- : John-Mark Gurney Voice: +1 415 225 5579 If it's a regular file then the only requirements are for data atomicy against writes, and no duplication of the data space (no missing pieces, no overlapping pieces). This does not preclude the ability for N threads to all issue a read() on the same file descriptor simultaniously. A simple seek space range lock (internal to the kernel) is all that is required to guarentee atomicy. Serialization is not required. e.g. read(fd, buf, bytes) { off_t offset; serializing_lock(fd); /* temporarily protect fd->offset */ offset = fd->offset; fd->offset += bytes; (ignoring EOF issues for the moment) serializing_unlock(fd); range_lock_shared(fd, offset, bytes); [ ACTUAL READ INTO USER BUFFER ] range_unlock(fd, offset, bytes); } Or, alternatively, if you want I/O errors to also be atomic and the data fits in the cache, it would be something like: read(fd, buf, bytes) { off_t offset; int done = 0; while (!done) { offset = fd->offset; [ BRING DATA INTO THE CACHE ] (note: not locked at this point) serializing_lock(fd); /* temporarily protect fd->offset */ if (fd->offset == offset) { /* check for race */ fd->offset += bytes; done = 1; } serializing_unlock(fd); } range_lock_shared(fd, offset, bytes); [ ACTUAL READ INTO USER BUFFER ] range_unlock(fd, offset, bytes); } This pseudo code ignores overlapping atomicy issues if the user buffer happens to be mmap()'d from the same file, and ignores deadlock issues for same from a different file (A,B) <-> (B,A). Generally, however, that sort of deadlock detection is really easy to implement, and would not interfere with the basic algorithm. Dataspace range locking is something we will be doing in DFly though the purpose is primarily to allow one process to block on I/O while another successfully reads or writes data on the same file via the VM cache without both being stalled. It is not an SMP issue per-say, even though it can also be used to fix SMP based parallel access situations. It's really a concurrency issue between blocked I/O and cached I/O that is one of the biggest reasons why our FS performance sucks compared to linux when reading and writing a single file (e.g. database). -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 07:46:02 2004 Return-Path: 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 79BF616A4CE for ; Sun, 7 Nov 2004 07:46:02 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD0E543D41 for ; Sun, 7 Nov 2004 07:46:01 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA77jxVI018155; Sun, 7 Nov 2004 08:45:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Nov 2004 19:15:13 EST." <200411070015.iA70FDxm015465@khavrinen.lcs.mit.edu> Date: Sun, 07 Nov 2004 08:45:59 +0100 Message-ID: <18154.1099813559@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@FreeBSD.org Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 07:46:02 -0000 In message <200411070015.iA70FDxm015465@khavrinen.lcs.mit.edu>, Garrett Wollman writes: >In article <10847.1099784360@critter.freebsd.dk> you write: >>Assume a process with two threads on two CPUs, both >>doing read(fd, buf, len) at the same time. >> >>Should we let both reads into the driver at the same time ? >> >>If so, which uio_offset do we hand them ? > >POSIX is quite clear on the matter: > >> All of the functions chmod (), close (), fchmod (), fcntl (), fstat >> (), ftruncate (), lseek (), open (), read (), readlink (), stat (), >> symlink ( ), and write ( ) shall be atomic with respect to each other >> in the effects specified in IEEE Std 1003.1-2001 when they operate on >> regular files. If two threads each call one of these functions, each >> call shall either see all of the specified effects of the other call, >> or none of them. > >(One of the "specified effects" is advancing the file offset.) Yes, but notice the "... when they operate on regular files." bit. It doesn't say anything about devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 07:48:49 2004 Return-Path: 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 8A09816A4CE for ; Sun, 7 Nov 2004 07:48:49 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9C6943D2F for ; Sun, 7 Nov 2004 07:48:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA77mdbI018263; Sun, 7 Nov 2004 08:48:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Nov 2004 19:57:36 PST." <200411070357.iA73vaqU040765@apollo.backplane.com> Date: Sun, 07 Nov 2004 08:48:39 +0100 Message-ID: <18262.1099813719@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org cc: John-Mark Gurney Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 07:48:49 -0000 In message <200411070357.iA73vaqU040765@apollo.backplane.com>, Matthew Dillon writes: >:As was quoted POSIX, the update should be atomic.. so my reading of >:that is that you lock the fd, when you read the offset from the fd, >:you need to also update the offset with the number of bytes read, so >:that a racing read both doesn't drop any data, nor duplicate any data.. >: >:i.e. single file with fixed records, it should be perfectly safe to >:throw five threads looping doing a read processing of the records w/o >:fear of duplicate records, or dropped records... >: >:And if we handle it in this manner, then you can allow multiple reads >:into the driver... >: >:-- >: John-Mark Gurney Voice: +1 415 225 5579 > > If it's a regular file [...] BZZZT! Wrong, but thanks for playing. (We are talking devices here) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 07:55:59 2004 Return-Path: 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 C3FE616A4CE for ; Sun, 7 Nov 2004 07:55:59 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E23B43D3F for ; Sun, 7 Nov 2004 07:55:59 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA77tw8a018452; Sun, 7 Nov 2004 08:55:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John-Mark Gurney From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 06 Nov 2004 16:38:42 PST." <20041107003842.GB73306@funkthat.com> Date: Sun, 07 Nov 2004 08:55:58 +0100 Message-ID: <18451.1099814158@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 07:55:59 -0000 In message <20041107003842.GB73306@funkthat.com>, John-Mark Gurney writes: >Poul-Henning Kamp wrote this message on Sun, Nov 07, 2004 at 00:39 +0100: >> Assume a device driver which is not Giant-handicapped. >> >> Assume an I/O path which does not need Giant to get from >> read(2) to the device driver. >> >> Assume a SMP machine. >> >> Assume a process with two threads on two CPUs, both >> doing read(fd, buf, len) at the same time. >> >> Should we let both reads into the driver at the same time ? >> >> If so, which uio_offset do we hand them ? > >As was quoted POSIX, the update should be atomic.. so my reading of >that is that you lock the fd, when you read the offset from the fd, >you need to also update the offset with the number of bytes read, so >that a racing read both doesn't drop any data, nor duplicate any data.. See, this is where the fine print has to be read. If the device is not addressable, this is only a locking problem, something the driver should already be handling. If the device driver is addressable (ie: a disk), you would not read it from two threads without explicitly giving an offset (ie. using pread(2)). If you really want to read it sequentially using two (or more) threads, then I think it is fair to ask that you do the locking in userland. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 13:30:51 2004 Return-Path: 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 67E8A16A4CE for ; Sun, 7 Nov 2004 13:30:51 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1429F43D31 for ; Sun, 7 Nov 2004 13:30:51 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iA7DUn26000306; Sun, 7 Nov 2004 08:30:49 -0500 (EST) Date: Sun, 7 Nov 2004 08:30:49 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Poul-Henning Kamp In-Reply-To: <18451.1099814158@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: arch@freebsd.org cc: John-Mark Gurney Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 13:30:51 -0000 On Sun, 7 Nov 2004, Poul-Henning Kamp wrote: > In message <20041107003842.GB73306@funkthat.com>, John-Mark Gurney writes: > >Poul-Henning Kamp wrote this message on Sun, Nov 07, 2004 at 00:39 +0100: > >> Assume a device driver which is not Giant-handicapped. > >> > >> Assume an I/O path which does not need Giant to get from > >> read(2) to the device driver. > >> > >> Assume a SMP machine. > >> > >> Assume a process with two threads on two CPUs, both > >> doing read(fd, buf, len) at the same time. > >> > >> Should we let both reads into the driver at the same time ? > >> > >> If so, which uio_offset do we hand them ? > > > >As was quoted POSIX, the update should be atomic.. so my reading of > >that is that you lock the fd, when you read the offset from the fd, > >you need to also update the offset with the number of bytes read, so > >that a racing read both doesn't drop any data, nor duplicate any data.. > > See, this is where the fine print has to be read. > > If the device is not addressable, this is only a locking problem, > something the driver should already be handling. > > If the device driver is addressable (ie: a disk), you would not > read it from two threads without explicitly giving an offset (ie. > using pread(2)). > > If you really want to read it sequentially using two (or more) > threads, then I think it is fair to ask that you do the locking > in userland. I guess I'd agree with the last part. If there is no locking in userland, then even if there is locking in the kernel, there is no guarantee that the first thread in is the first thread out and the first thread to be run (or resumed). Regardless, the kernel shouldn't return duplicated data nor skip over any data. It is possible for the program to be reading records where sequence doesn't matter but loss, duplication, or otherwise corruption of data does. -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Sun Nov 7 20:07:47 2004 Return-Path: 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 8F4A816A4CE for ; Sun, 7 Nov 2004 20:07:47 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CEA543D4C for ; Sun, 7 Nov 2004 20:07:47 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iA7K7kvA044166; Sun, 7 Nov 2004 12:07:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iA7K7kgR044165; Sun, 7 Nov 2004 12:07:46 -0800 (PST) (envelope-from dillon) Date: Sun, 7 Nov 2004 12:07:46 -0800 (PST) From: Matthew Dillon Message-Id: <200411072007.iA7K7kgR044165@apollo.backplane.com> To: "Poul-Henning Kamp" References: <18262.1099813719@critter.freebsd.dk> cc: arch@freebsd.org cc: John-Mark Gurney Subject: Re: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2004 20:07:47 -0000 :> If it's a regular file [...] : :BZZZT! Wrong, but thanks for playing. (We are talking devices here) : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Well, most devices don't give a damn about the file offset supplied in the UIO from the file descriptor, so if it isn't a regular file why would you care? You should just parallel entry into the device and let the device take care of any required serialization. -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 18:58:12 2004 Return-Path: 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 47E2116A4CE for ; Mon, 8 Nov 2004 18:58:12 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0326543D39 for ; Mon, 8 Nov 2004 18:58:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8486 invoked from network); 8 Nov 2004 18:58:11 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 8 Nov 2004 18:58:11 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA8Iw71U019779; Mon, 8 Nov 2004 13:58:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Willem Jan Withagen Date: Mon, 8 Nov 2004 13:53:15 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> <418BE3D2.2030205@withagen.nl> In-Reply-To: <418BE3D2.2030205@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411081353.15394.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 18:58:12 -0000 On Friday 05 November 2004 03:34 pm, Willem Jan Withagen wrote: > John Baldwin wrote: > > [about the loader having flat addressspace....] > > >>But is it unsegmented? (perhaps I have a wrong idea of a flat address > >>space) > > > > Yes, it is unsegmented. You can translate physical addresses to virtual > > addresses using PTOV() and vice versa using VTOP(). > > I've run accross these calls, just need to figure out how to work them. > > >>What I mean with this is that I can iterate from 0xa000 to 0xffffffff > >> with a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming > >> this all has memory) > > > > Yes. > > Would be nice.... > > >>Next is then which ranges are valid to test, and then things really start > >>to get complicated and arch dependant. Which is why I ended up in > >> machdep.c right after the setting up of the memory ranges. > > > > Heh, the above memory mapping is also i386 specific. Alpha only has a > > small bit of memory mapped in the loader, same with sparc64, etc. > > Ehhhh, again more reasons to put this in the kernel, or something that > closely resembles a kernel. Well, part of the problem there is that the early kernel code is all MD anyway. I think your best bet really is to write your own mini-kernel that the loader can load to do this, but it will require MD stubs for early bootstrapping as well as some kind of API for mapping a page so you can test it and then unmap it, which is required for x86 machines with > 4GB of RAM for example. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 19:38:59 2004 Return-Path: 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 DB92B16A4CE for ; Mon, 8 Nov 2004 19:38:59 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7271143D39 for ; Mon, 8 Nov 2004 19:38:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iA8JclZC029887 for ; Mon, 8 Nov 2004 12:38:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Nov 2004 12:39:12 -0700 (MST) Message-Id: <20041108.123912.113102111.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Comments requested on adding ports modules to kernel build X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 19:39:00 -0000 I've been using the following for a while to automatically rebuild and install a kernel module on one of my machines. I think this is useful in general and would like to commit it. Comments? Warner diff --exclude CVS -I\$Revision -I\$Id -I\$Header -I \$FreeBSD -ur /shadow/imp/F reeBSD/src/sys/conf/kern.post.mk /shadow/imp/p4/src/sys/conf/kern.post.mk --- /shadow/imp/FreeBSD/src/sys/conf/kern.post.mk Thu Oct 7 23:46:20 2004 +++ /shadow/imp/p4/src/sys/conf/kern.post.mk Sat Nov 6 12:29:02 2004 @@ -26,6 +26,19 @@ ${target:S/^reinstall$/install/:S/^clobber$/cleandir/} .endif .endfor +# Handle out of tree ports +.if defined(PORTS_MODULES) +.if defined(SYSDIR) +PORTSMODULESENV=SYSDIR=${SYSDIR} +.endif +.for target in all install clean +${target}: ports-${target} +ports-${target}: +.for __i in ${PORTS_MODULES} + cd /usr/ports/${__i}; ${PORTSMODULESENV} ${MAKE} ${target} +.endfor +.endfor +.endif .ORDER: kernel-install modules-install From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:22:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2A81816A4CE; Mon, 8 Nov 2004 20:22:50 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id iA8KMnD5031840; Mon, 8 Nov 2004 15:22:49 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id iA8KMjqZ031839; Mon, 8 Nov 2004 15:22:45 -0500 (EST) (envelope-from green) Date: Mon, 8 Nov 2004 15:22:45 -0500 From: Brian Fundakowski Feldman To: "M. Warner Losh" Message-ID: <20041108202245.GE1069@green.homeunix.org> References: <20041108.123912.113102111.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041108.123912.113102111.imp@bsdimp.com> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org Subject: Re: Comments requested on adding ports modules to kernel build X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 20:22:50 -0000 On Mon, Nov 08, 2004 at 12:39:12PM -0700, M. Warner Losh wrote: > I've been using the following for a while to automatically rebuild and > install a kernel module on one of my machines. I think this is > useful in general and would like to commit it. > > Comments? Something like this is generally useful, but it should be easier and I would think more correct to instead have the target do portupgrade -f. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:27:05 2004 Return-Path: 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 402D616A4CE; Mon, 8 Nov 2004 20:27:05 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1686F43D48; Mon, 8 Nov 2004 20:27:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E0ACC7A440; Mon, 8 Nov 2004 12:27:04 -0800 (PST) Message-ID: <418FD698.7060108@elischer.org> Date: Mon, 08 Nov 2004 12:27:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> <418BE3D2.2030205@withagen.nl> <200411081353.15394.jhb@FreeBSD.org> In-Reply-To: <200411081353.15394.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Willem Jan Withagen cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 20:27:05 -0000 John Baldwin wrote: >On Friday 05 November 2004 03:34 pm, Willem Jan Withagen wrote: > > >>John Baldwin wrote: >> >>[about the loader having flat addressspace....] >> >> >> >>>>But is it unsegmented? (perhaps I have a wrong idea of a flat address >>>>space) >>>> >>>> >>>Yes, it is unsegmented. You can translate physical addresses to virtual >>>addresses using PTOV() and vice versa using VTOP(). >>> >>> >>I've run accross these calls, just need to figure out how to work them. >> >> >> >>>>What I mean with this is that I can iterate from 0xa000 to 0xffffffff >>>>with a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming >>>>this all has memory) >>>> >>>> >>>Yes. >>> >>> >>Would be nice.... >> >> >> >>>>Next is then which ranges are valid to test, and then things really start >>>>to get complicated and arch dependant. Which is why I ended up in >>>>machdep.c right after the setting up of the memory ranges. >>>> >>>> >>>Heh, the above memory mapping is also i386 specific. Alpha only has a >>>small bit of memory mapped in the loader, same with sparc64, etc. >>> >>> >>Ehhhh, again more reasons to put this in the kernel, or something that >>closely resembles a kernel. >> >> > >Well, part of the problem there is that the early kernel code is all MD >anyway. I think your best bet really is to write your own mini-kernel that >the loader can load to do this, but it will require MD stubs for early >bootstrapping as well as some kind of API for mapping a page so you can test >it and then unmap it, which is required for x86 machines with > 4GB of RAM >for example. > > to some extent you are describing reinventing memtest86 hense my original suggestion of adding loader support for loading binaries that are designed to be independently loadable (e.g. memtest86) From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:27:34 2004 Return-Path: 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 D000D16A4CE; Mon, 8 Nov 2004 20:27:34 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F8AE43D2F; Mon, 8 Nov 2004 20:27:33 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA8KRV5p056598; Mon, 8 Nov 2004 21:27:31 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418FD6B3.4040600@withagen.nl> Date: Mon, 08 Nov 2004 21:27:31 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> <418BE3D2.2030205@withagen.nl> <200411081353.15394.jhb@FreeBSD.org> In-Reply-To: <200411081353.15394.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 20:27:34 -0000 John Baldwin wrote: [All about getting a flat memoryspace] >>>>Next is then which ranges are valid to test, and then things really start >>>>to get complicated and arch dependant. Which is why I ended up in >>>>machdep.c right after the setting up of the memory ranges. >>> >>>Heh, the above memory mapping is also i386 specific. Alpha only has a >>>small bit of memory mapped in the loader, same with sparc64, etc. >> >>Ehhhh, again more reasons to put this in the kernel, or something that >>closely resembles a kernel. > > > Well, part of the problem there is that the early kernel code is all MD > anyway. I think your best bet really is to write your own mini-kernel that > the loader can load to do this, but it will require MD stubs for early > bootstrapping as well as some kind of API for mapping a page so you can test > it and then unmap it, which is required for x86 machines with > 4GB of RAM > for example. I would start simple, and forget about PAE, since I do not have a PAE machine... Simple 1386, and amd64-smp is all I got. Then I'd rather look at other architectures, then look at PAE. If ever I get this far. Can you give me some hints from the current modules/source-files on i386 I would at least need to get somewhere. Because that would be the way I'd go: See if I can rip enough from the regular kernel to be able to build the mini-kernel. And give the way mi_startup works that would be a very nice/simple way to keep loading modules until there is enough to get the work done. Did anybody write a routine that "dumps" the module list before mi_startup start to work on it??? Or would that be my first assignment :) I'll start by copying my own sys-tree so work does not get overwritten by daily cvsup. --WjW From owner-freebsd-arch@FreeBSD.ORG Mon Nov 8 20:51:03 2004 Return-Path: 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 8D3CB16A4CE; Mon, 8 Nov 2004 20:51:03 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1139543D2D; Mon, 8 Nov 2004 20:51:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iA8KovVJ031112; Mon, 8 Nov 2004 13:50:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 08 Nov 2004 13:51:23 -0700 (MST) Message-Id: <20041108.135123.61228519.imp@bsdimp.com> To: green@freebsd.org From: "M. Warner Losh" In-Reply-To: <20041108202245.GE1069@green.homeunix.org> References: <20041108.123912.113102111.imp@bsdimp.com> <20041108202245.GE1069@green.homeunix.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Comments requested on adding ports modules to kernel build X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2004 20:51:03 -0000 In message: <20041108202245.GE1069@green.homeunix.org> Brian Fundakowski Feldman writes: : On Mon, Nov 08, 2004 at 12:39:12PM -0700, M. Warner Losh wrote: : > I've been using the following for a while to automatically rebuild and : > install a kernel module on one of my machines. I think this is : > useful in general and would like to commit it. : > : > Comments? : : Something like this is generally useful, but it should be easier and : I would think more correct to instead have the target do portupgrade -f. Why do you think that's the case? Warner From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 03:52:05 2004 Return-Path: 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 88DE516A4CE; Tue, 9 Nov 2004 03:52:05 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 655F743D46; Tue, 9 Nov 2004 03:52:05 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iA93q4D3085455; Mon, 8 Nov 2004 19:52:04 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id 68B3F77AD0D; Mon, 8 Nov 2004 22:52:02 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9ED891FB5E2; Mon, 8 Nov 2004 22:52:03 -0500 (EST) To: Randall Stewart From: Mark Allman In-Reply-To: <417A5B28.9080308@stewart.chicago.il.us> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Back in Black MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 08 Nov 2004 22:52:03 -0500 Sender: mallman@icir.org Message-Id: <20041109035203.9ED891FB5E2@lawyers.icir.org> cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 03:52:05 -0000 --=-=-= Content-Type: text/plain (catching up ...) > I would rather have Andre work with me to get any other > rinkles out of SCTP that he deems are there... and get the > KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would > make more sense... Get something that is pretty well baked (IMO at > least) and work to get it "productionized" (even though I don't > feel it needs much work in this vein)... I do not prefer xor. I agree that it'd be nice if SCTP was rolled into freebsd. But, these things seem orthogonal to me. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBkD7jWyrrWs4yIs4RAo8UAJ9FV5ntNoD9L3PqIa1X5jj5gVpupACfUvC5 VFAjdGGFocvL54rph/JV5uI= =7iGy -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 09:19:20 2004 Return-Path: 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 4A10116A4CE for ; Tue, 9 Nov 2004 09:19:20 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2635343D2F for ; Tue, 9 Nov 2004 09:19:20 +0000 (GMT) (envelope-from rob@dproimpact.com) Received: from RVD56 (bgp981446bgs.stclar01.mi.comcast.net[68.42.250.8]) by comcast.net (rwcrmhc11) with SMTP id <2004110909191901300r0d79e>; Tue, 9 Nov 2004 09:19:19 +0000 From: "Rob VanDoorne" To: Date: Tue, 9 Nov 2004 04:16:32 -0500 Message-ID: <000c01c4c63c$ce69bcb0$0100a8c0@RVD56> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Which version of FreeBSD? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rob@dproimpact.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 09:19:20 -0000 Hello: I am considering using either my old Compaq (200mhz, Pent 2) or my old Gateway PC (200mhz, Pent 2) computer to use FreeBSD on. Which version is the correct and most stable one to install? Thanks, Rob From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 09:27:29 2004 Return-Path: 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 62E0016A4CF for ; Tue, 9 Nov 2004 09:27:29 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F19C43D58 for ; Tue, 9 Nov 2004 09:27:28 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35975 invoked from network); 9 Nov 2004 09:22:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2004 09:22:42 -0000 Message-ID: <41908D80.8EAEF656@freebsd.org> Date: Tue, 09 Nov 2004 10:27:28 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@icir.org References: <20041109035203.9ED891FB5E2@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Randall Stewart cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 09:27:29 -0000 Mark Allman wrote: > > (catching up ...) > > > I would rather have Andre work with me to get any other > > rinkles out of SCTP that he deems are there... and get the > > KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would > > make more sense... Get something that is pretty well baked (IMO at > > least) and work to get it "productionized" (even though I don't > > feel it needs much work in this vein)... > > I do not prefer xor. > > I agree that it'd be nice if SCTP was rolled into freebsd. But, these > things seem orthogonal to me. The author of the BSD SCTP code is working on a direct FreeBSD native port (no KAME detour to take). -- Andre From owner-freebsd-arch@FreeBSD.ORG Tue Nov 9 09:52:11 2004 Return-Path: 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 8D34416A4CE for ; Tue, 9 Nov 2004 09:52:11 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 4425E43D69 for ; Tue, 9 Nov 2004 09:52:09 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 35532 invoked by uid 0); 9 Nov 2004 09:46:39 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 9 Nov 2004 09:46:39 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 00B2D131E56; Tue, 9 Nov 2004 17:52:02 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02193-09; Tue, 9 Nov 2004 17:51:52 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id F40C4131E42; Tue, 9 Nov 2004 17:51:51 +0800 (CST) Date: Tue, 9 Nov 2004 17:51:51 +0800 From: Xin LI To: Rob VanDoorne Message-ID: <20041109095151.GA2895@frontfree.net> References: <000c01c4c63c$ce69bcb0$0100a8c0@RVD56> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <000c01c4c63c$ce69bcb0$0100a8c0@RVD56> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #11: Tue Oct 26 14:12:03 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-arch@FreeBSD.org Subject: Re: Which version of FreeBSD? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 09:52:11 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 09, 2004 at 04:16:32AM -0500, Rob VanDoorne wrote: > I am considering using either my old Compaq (200mhz, Pent 2) or my old > Gateway PC (200mhz, Pent 2) computer to use FreeBSD on. Which version is = the > correct and most stable one to install? I personally suggest that you stick with FreeBSD 4.x, maybe 4.10-RELEASE, because it would be a nightmare for you to compile the whole system, as 5-STABLE comes with many compiler improvements that needs more CPU time. However, if you want new networking features like pf, etc., then it is more suitable for you to use 5.3-RELEASE or 5-STABLE. I have three boxes with Pentium II-233 CPU, 64MB RAM running FreeBSD 5.x for more than 1 year. Be sure to use UFS1 when you set up the system, as you may not need UFS2 features and UFS1 may save you some disk space on relatively old systems. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBkJM3/cVsHxFZiIoRApHPAJ4hF7I9jDIzqx/dN7dIzKPIPsYUcACfWFR1 /eCcty0dCVpi3xXEhD1nC64= =5ET2 -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:00:44 2004 Return-Path: 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 BB16E16A4CE for ; Thu, 11 Nov 2004 03:00:44 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4C343D39 for ; Thu, 11 Nov 2004 03:00:44 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id iAB30Z6K071016 for ; Wed, 10 Nov 2004 22:00:35 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id iAB30Zda071015 for arch@FreeBSD.ORG; Wed, 10 Nov 2004 22:00:35 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 10 Nov 2004 22:00:35 -0500 From: David Schultz To: arch@FreeBSD.ORG Message-ID: <20041111030035.GA70923@VARK.MIT.EDU> Mail-Followup-To: arch@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:00:44 -0000 Over the years, the amount of data we have stored in each process' U area has eroded to the point where all we have left are the following: - A struct kinfo_proc that is only used for a.out core dumps. This can be reconstructed at the time of the core dump, so it doesn't need to be there. - The struct pstats for the process, which takes a mere 216 bytes on i386. In exchange for the ability to swap out this 216-byte structure, we keep around a 4096-byte page, a 132-byte vm_object, and a couple of pointers. Moreover, there is a small amount of runtime overhead associated with this, and developers need to remember to PHOLD() and PRELE() the process as appropriate.[1] I propose to remove the ability to swap the U area, allocating p_stats from malloced memory instead. Medium-term scheduling and swapping of kernel stacks would be retained. Here are the patches; !i386 testers wanted: http://www.freebsd.org/~das/patches/upages.diff [1] Most of the instances of PHOLD() and PRELE() right now never needed to be there or have been unnecessary ever since the PCB was moved out of the U area. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:16:07 2004 Return-Path: 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 3292016A4CE; Thu, 11 Nov 2004 03:16:07 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B812243D46; Thu, 11 Nov 2004 03:16:06 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAB3Idcd062345; Wed, 10 Nov 2004 20:18:40 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <4192D9AB.5060309@freebsd.org> Date: Wed, 10 Nov 2004 20:16:59 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <20041111030035.GA70923@VARK.MIT.EDU> In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:16:07 -0000 David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. > > - The struct pstats for the process, which takes a mere 216 bytes > on i386. > > In exchange for the ability to swap out this 216-byte structure, we > keep around a 4096-byte page, a 132-byte vm_object, and a couple of > pointers. Moreover, there is a small amount of runtime overhead > associated with this, and developers need to remember to PHOLD() and > PRELE() the process as appropriate.[1] > > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > > > [1] Most of the instances of PHOLD() and PRELE() right now never > needed to be there or have been unnecessary ever since the PCB > was moved out of the U area. Go for it! Just get some validation that amd64 and sparc64 work, and then do the deed. I'll try testing at least amd64 right now. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:16:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4187116A4CE for ; Thu, 11 Nov 2004 03:16:41 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id iAB3GeAG010347 for ; Wed, 10 Nov 2004 22:16:40 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id iAB3GeTN010346 for arch@FreeBSD.ORG; Wed, 10 Nov 2004 22:16:40 -0500 (EST) (envelope-from green) Date: Wed, 10 Nov 2004 22:16:39 -0500 From: Brian Fundakowski Feldman To: arch@FreeBSD.ORG Message-ID: <20041111031639.GC997@green.homeunix.org> References: <20041111030035.GA70923@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> User-Agent: Mutt/1.5.6i Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:16:41 -0000 On Wed, Nov 10, 2004 at 10:00:35PM -0500, David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. > > - The struct pstats for the process, which takes a mere 216 bytes > on i386. > > In exchange for the ability to swap out this 216-byte structure, we > keep around a 4096-byte page, a 132-byte vm_object, and a couple of > pointers. Moreover, there is a small amount of runtime overhead > associated with this, and developers need to remember to PHOLD() and > PRELE() the process as appropriate.[1] > > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > > > [1] Most of the instances of PHOLD() and PRELE() right now never > needed to be there or have been unnecessary ever since the PCB > was moved out of the U area. I am not going to get a chance to review this soon (which I'd like to) but I'm going to make sure I also voice support for removing this extra avenue for system instability due to media failure. I am happy to see you having the desire to take this step! -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:32:53 2004 Return-Path: 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 582BE16A4CE for ; Thu, 11 Nov 2004 03:32:53 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA6343D3F for ; Thu, 11 Nov 2004 03:32:52 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1BDA665213 for ; Thu, 11 Nov 2004 03:32:51 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32586-04-2 for ; Thu, 11 Nov 2004 03:32:50 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 064D465219 for ; Thu, 11 Nov 2004 03:32:50 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id D35646482; Wed, 10 Nov 2004 19:32:38 -0800 (PST) Date: Wed, 10 Nov 2004 19:32:38 -0800 From: Bruce M Simpson To: arch@FreeBSD.ORG Message-ID: <20041111033238.GA723@empiric.icir.org> References: <20041111030035.GA70923@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:32:53 -0000 Hey there, On Wed, Nov 10, 2004 at 10:00:35PM -0500, David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. Aren't we 100% ELF these days? Surely aout is no longer relevant? > - The struct pstats for the process, which takes a mere 216 bytes > on i386. That's pretty small. I don't see the rusage or timeval structs growing much for 64-bit platforms. > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. I think this is a good idea. > http://www.freebsd.org/~das/patches/upages.diff I've briefly looked over this and am happy to see it simplifies MD code somewhat. BMS From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:45:20 2004 Return-Path: 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 02C5B16A4CE for ; Thu, 11 Nov 2004 03:45:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9717E43D39 for ; Thu, 11 Nov 2004 03:45:19 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAB3lsE1062427; Wed, 10 Nov 2004 20:47:54 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <4192E086.8060005@freebsd.org> Date: Wed, 10 Nov 2004 20:46:14 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20041111030035.GA70923@VARK.MIT.EDU> <20041111033238.GA723@empiric.icir.org> In-Reply-To: <20041111033238.GA723@empiric.icir.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:45:20 -0000 Bruce M Simpson wrote: > Hey there, > > On Wed, Nov 10, 2004 at 10:00:35PM -0500, David Schultz wrote: > >>Over the years, the amount of data we have stored in each process' U >>area has eroded to the point where all we have left are the following: >> >> - A struct kinfo_proc that is only used for a.out core dumps. >> This can be reconstructed at the time of the core dump, so >> it doesn't need to be there. > > > Aren't we 100% ELF these days? Surely aout is no longer relevant? > We are 100% ELF toolchain. We can still (in theory) run AOUT binaries so long as you use the COMPAT_AOUT kernel option and have AOUT libraries. But this is offtopic =-) Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 03:56:52 2004 Return-Path: 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 7721916A4CE for ; Thu, 11 Nov 2004 03:56:52 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2933F43D2D for ; Thu, 11 Nov 2004 03:56:52 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id iAB3uh3s014809; Wed, 10 Nov 2004 22:56:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id iAB3uhRK014808; Wed, 10 Nov 2004 22:56:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 10 Nov 2004 22:56:43 -0500 From: David Schultz To: Bruce M Simpson Message-ID: <20041111035643.GA14702@VARK.MIT.EDU> Mail-Followup-To: Bruce M Simpson , arch@FreeBSD.ORG References: <20041111030035.GA70923@VARK.MIT.EDU> <20041111033238.GA723@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041111033238.GA723@empiric.icir.org> cc: arch@FreeBSD.ORG Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 03:56:52 -0000 On Wed, Nov 10, 2004, Bruce M Simpson wrote: > Hey there, > > On Wed, Nov 10, 2004 at 10:00:35PM -0500, David Schultz wrote: > > Over the years, the amount of data we have stored in each process' U > > area has eroded to the point where all we have left are the following: > > > > - A struct kinfo_proc that is only used for a.out core dumps. > > This can be reconstructed at the time of the core dump, so > > it doesn't need to be there. > > Aren't we 100% ELF these days? Surely aout is no longer relevant? Complete removal of a.out support is a separate topic. The aout.ko module works right now, and I've tried not to break it. Granted, I have yet to test whether a.out core dumps actually still work, but I intend to do so. > I've briefly looked over this and am happy to see it simplifies MD code > somewhat. FWIW, this is just phase one. There's even more that can be axed on another pass, such as most uses of PHOLD(). From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 06:00:13 2004 Return-Path: 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 B6EFB16A4D0; Thu, 11 Nov 2004 06:00:13 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD64143D4C; Thu, 11 Nov 2004 06:00:08 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])iAB606Q7046920; Thu, 11 Nov 2004 01:00:07 -0500 Message-ID: <4192FFE5.8060205@elischer.org> Date: Wed, 10 Nov 2004 22:00:05 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <20041111030035.GA70923@VARK.MIT.EDU> <4192D9AB.5060309@freebsd.org> In-Reply-To: <4192D9AB.5060309@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: David Schultz Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 06:00:13 -0000 Scott Long wrote: > David Schultz wrote: > >> Over the years, the amount of data we have stored in each process' U >> area has eroded to the point where all we have left are the following: >> >> - A struct kinfo_proc that is only used for a.out core dumps. >> This can be reconstructed at the time of the core dump, so >> it doesn't need to be there. >> >> - The struct pstats for the process, which takes a mere 216 bytes >> on i386. >> >> In exchange for the ability to swap out this 216-byte structure, we >> keep around a 4096-byte page, a 132-byte vm_object, and a couple of >> pointers. Moreover, there is a small amount of runtime overhead >> associated with this, and developers need to remember to PHOLD() and >> PRELE() the process as appropriate.[1] >> >> I propose to remove the ability to swap the U area, allocating p_stats >> from malloced memory instead. Medium-term scheduling and swapping of >> kernel stacks would be retained. Here are the patches; !i386 testers >> wanted: >> >> http://www.freebsd.org/~das/patches/upages.diff >> >> >> [1] Most of the instances of PHOLD() and PRELE() right now never >> needed to be there or have been unnecessary ever since the PCB >> was moved out of the U area. > We've been slowly working towards this.. when we moved the pcb out to the thread this became inevitable.. go for it! > > Go for it! Just get some validation that amd64 and sparc64 work, and > then do the deed. I'll try testing at least amd64 right now. > > Scott > _______________________________________________ > 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 Thu Nov 11 07:53:40 2004 Return-Path: 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 1509016A4CE; Thu, 11 Nov 2004 07:53:40 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7AF43D62; Thu, 11 Nov 2004 07:53:39 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id iAB7rdlH051337; Wed, 10 Nov 2004 23:53:39 -0800 (PST) (envelope-from marcel@xcllnt.net) In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> References: <20041111030035.GA70923@VARK.MIT.EDU> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 10 Nov 2004 23:53:38 -0800 To: David Schultz X-Mailer: Apple Mail (2.619) cc: arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 07:53:40 -0000 On Nov 10, 2004, at 7:00 PM, David Schultz wrote: > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > I got the following on ia64: : Mounting root from ufs:/dev/da0p2 init died (signal 6, exit 0) panic: Going nowhere without my init! KDB: enter: panic [thread 100003] Stopped at kdb_enter+0x81: [F1] nop.f 0x0 db> trace kdb_enter(0xe0000000045e7db8, 0xe00000000428c9d0, 0x896, 0xa000000019f031e8) at kdb_enter+0x81 panic(0xe0000000045e5570, 0x6, 0x0, 0xe00000000737ae50, 0xe000000004521bd0) at panic+0x1c0 exit1(0xe00000003e5fe780, 0x6, 0x4, 0xe0000000046ce100, 0xe0000000046ce100) at exit1+0xd0 kern_execve(0xe00000003e5fe780, 0x9ffffffffffffff2, 0x2, 0xe0000000046cd820, 0x4, 0x2, 0xc, 0xa000000019f032e0) at kern_execve+0x1d40 start_init(0x9fffffffffffffd8, 0x9ffffffffffffff2, 0xe00000000468f0a2, 0xe00000000468f098, 0x9ffffffffffffffd) at start_init+0x7a0 fork_exit(0xe00000000460c640, 0x0, 0xa000000019f03550) at fork_exit+0x120 enter_userland() at enter_userland db> I have to triage this, but that's not for today (in 7 minutes it will be tomorrow :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 16:13:32 2004 Return-Path: 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 9ED6616A4D7 for ; Thu, 11 Nov 2004 16:13:32 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1889443D1F for ; Thu, 11 Nov 2004 16:13:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20672 invoked from network); 11 Nov 2004 16:13:31 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Nov 2004 16:13:30 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iABGDLDb044012; Thu, 11 Nov 2004 11:13:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 10 Nov 2004 08:25:33 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> <200411081353.15394.jhb@FreeBSD.org> <418FD6B3.4040600@withagen.nl> In-Reply-To: <418FD6B3.4040600@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411100825.33982.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Willem Jan Withagen Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 16:13:32 -0000 On Monday 08 November 2004 03:27 pm, Willem Jan Withagen wrote: > John Baldwin wrote: > > [All about getting a flat memoryspace] > > >>>>Next is then which ranges are valid to test, and then things really > >>>> start to get complicated and arch dependant. Which is why I ended up > >>>> in machdep.c right after the setting up of the memory ranges. > >>> > >>>Heh, the above memory mapping is also i386 specific. Alpha only has a > >>>small bit of memory mapped in the loader, same with sparc64, etc. > >> > >>Ehhhh, again more reasons to put this in the kernel, or something that > >>closely resembles a kernel. > > > > Well, part of the problem there is that the early kernel code is all MD > > anyway. I think your best bet really is to write your own mini-kernel > > that the loader can load to do this, but it will require MD stubs for > > early bootstrapping as well as some kind of API for mapping a page so you > > can test it and then unmap it, which is required for x86 machines with > > > 4GB of RAM for example. > > I would start simple, and forget about PAE, since I do not have a PAE > machine... Simple 1386, and amd64-smp is all I got. Then I'd rather look at > other architectures, then look at PAE. If ever I get this far. Note that amd64 uses PAE, so if you want an amd64 version that can do more than 4 GB you will have to handle PAE. > Can you give me some hints from the current modules/source-files on i386 I > would at least need to get somewhere. Because that would be the way I'd go: > See if I can rip enough from the regular kernel to be able to build the > mini-kernel. It might be easier to start with a sys tree and start turning off stuff you don't need. If you want to use the FreeBSD kernel as the basis for your mini-kernel instead of writing it from scratch, you are basically going to need to sit down and read a lot of code and section 9 manpages to understand the APIs for mapping memory, etc. > Did anybody write a routine that "dumps" the module list before mi_startup > start to work on it??? Or would that be my first assignment :) > > I'll start by copying my own sys-tree so work does not get overwritten by > daily cvsup. I would strongly recommend using some type of source code control for this project such as p4 or svn with the stock FreeBSD sys sources in a vendor tree so that you can update to later FreeBSD versions and let the source code control software help manage the process of merging any relevant changes into your code. Also, having your own work under source code control will save you a lot of headaches. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 17:29:02 2004 Return-Path: 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 76AB316A4CE for ; Thu, 11 Nov 2004 17:29:02 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2719443D55 for ; Thu, 11 Nov 2004 17:29:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2224 invoked from network); 11 Nov 2004 17:29:01 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Nov 2004 17:29:01 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iABHSv7d044497; Thu, 11 Nov 2004 12:28:57 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 11 Nov 2004 12:28:18 -0500 User-Agent: KMail/1.6.2 References: <20041111030035.GA70923@VARK.MIT.EDU> In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411111228.19044.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: arch@FreeBSD.org cc: David Schultz Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 17:29:02 -0000 On Wednesday 10 November 2004 10:00 pm, David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. > > - The struct pstats for the process, which takes a mere 216 bytes > on i386. > > In exchange for the ability to swap out this 216-byte structure, we > keep around a 4096-byte page, a 132-byte vm_object, and a couple of > pointers. Moreover, there is a small amount of runtime overhead > associated with this, and developers need to remember to PHOLD() and > PRELE() the process as appropriate.[1] > > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > > > [1] Most of the instances of PHOLD() and PRELE() right now never > needed to be there or have been unnecessary ever since the PCB > was moved out of the U area. Yay! Two notes: +struct pstats * +pstats_alloc(void) +{ + + return (malloc(sizeof(struct plimit), M_SUBPROC, M_ZERO|M_WAITOK)); +} I think you mean s/plimit/pstats/ there. Secondly: /* - * Per process structure containing data that isn't needed in core - * when the process isn't running (esp. when swapped out). + * Formerly the per-process structure containing data that isn't needed + * in core when the process is swapped out, this structure remains only + * for the benefit of a.out core dumps. */ s/out, this/out. This/ It's a whole new sentence. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 17:29:02 2004 Return-Path: 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 819ED16A4D1 for ; Thu, 11 Nov 2004 17:29:02 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F81F43D39 for ; Thu, 11 Nov 2004 17:29:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2224 invoked from network); 11 Nov 2004 17:29:01 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Nov 2004 17:29:01 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iABHSv7d044497; Thu, 11 Nov 2004 12:28:57 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 11 Nov 2004 12:28:18 -0500 User-Agent: KMail/1.6.2 References: <20041111030035.GA70923@VARK.MIT.EDU> In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411111228.19044.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: arch@FreeBSD.org cc: David Schultz Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 17:29:02 -0000 On Wednesday 10 November 2004 10:00 pm, David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. > > - The struct pstats for the process, which takes a mere 216 bytes > on i386. > > In exchange for the ability to swap out this 216-byte structure, we > keep around a 4096-byte page, a 132-byte vm_object, and a couple of > pointers. Moreover, there is a small amount of runtime overhead > associated with this, and developers need to remember to PHOLD() and > PRELE() the process as appropriate.[1] > > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > > > [1] Most of the instances of PHOLD() and PRELE() right now never > needed to be there or have been unnecessary ever since the PCB > was moved out of the U area. Yay! Two notes: +struct pstats * +pstats_alloc(void) +{ + + return (malloc(sizeof(struct plimit), M_SUBPROC, M_ZERO|M_WAITOK)); +} I think you mean s/plimit/pstats/ there. Secondly: /* - * Per process structure containing data that isn't needed in core - * when the process isn't running (esp. when swapped out). + * Formerly the per-process structure containing data that isn't needed + * in core when the process is swapped out, this structure remains only + * for the benefit of a.out core dumps. */ s/out, this/out. This/ It's a whole new sentence. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 20:24:02 2004 Return-Path: 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 B936E16A4CE; Thu, 11 Nov 2004 20:24:02 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE4B43D48; Thu, 11 Nov 2004 20:24:02 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CSLU9-00018w-00; Thu, 11 Nov 2004 21:24:01 +0100 Received: from [84.128.130.223] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CSLU8-0007bw-00; Thu, 11 Nov 2004 21:24:01 +0100 From: Max Laier To: freebsd-arch@freebsd.org Date: Thu, 11 Nov 2004 21:24:05 +0100 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4509686.Ad4VYY4PBk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411112124.12616.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-net@freebsd.org Subject: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 20:24:02 -0000 --nextPart4509686.Ad4VYY4PBk Content-Type: multipart/mixed; boundary="Boundary-01=_np8kBd92qNtmEHy" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_np8kBd92qNtmEHy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, I know I have sent this a couple of times before, but never got anywhere. T= his=20 time I am set to commit! The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived f= rom=20 WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix=20 routes. Right now you can't have two legs into the same network. If you want to, yo= u=20 must give on of the interfaces a host address only (netmask /32). This way = it=20 is not possible to hand over the route if one of the interfaces is=20 "removed" (however this is done in the special case). The patch allows to add more than on IPv4 address with the same prefix. In = the=20 case that there is a route already, we leave it alone and add the new addre= ss=20 without the IFA_ROUTE flag. When we remove an address later on, that has a= =20 route associated, we try to find an alternative address to use for the rout= e=20 and hand it over. This is required for CARP, but should be helpful for other situations as we= ll. Any objections? I also plan to merge this back to RELENG_5 after some time. I don't see thi= s=20 breaking assumptions (it was an error case before) - please tell me if you= =20 see something. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_np8kBd92qNtmEHy Content-Type: text/x-diff; charset="us-ascii"; name="in.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="in.c.patch" =2D-- ../dist/sys/netinet/in.c Sat Nov 6 21:01:08 2004 +++ sys/netinet/in.c Mon Nov 8 02:05:17 2004 @@ -1,4 +1,32 @@ /* + * Copyright (C) 2001 WIDE Project. All rights reserved. + *=20 + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the project nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + *=20 + * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* * Copyright (c) 1982, 1986, 1991, 1993 * The Regents of the University of California. All rights reserved. * @@ -55,6 +83,8 @@ static int in_lifaddr_ioctl(struct socket *, u_long, caddr_t, struct ifnet *, struct thread *); =20 +static int in_addprefix(struct in_ifaddr *, int); +static int in_scrubprefix(struct in_ifaddr *); static void in_socktrim(struct sockaddr_in *); static int in_ifinit(struct ifnet *, struct in_ifaddr *, struct sockaddr_in *, int); @@ -654,14 +684,7 @@ register struct ifnet *ifp; register struct in_ifaddr *ia; { =2D =2D if ((ia->ia_flags & IFA_ROUTE) =3D=3D 0) =2D return; =2D if (ifp->if_flags & (IFF_LOOPBACK|IFF_POINTOPOINT)) =2D rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); =2D else =2D rtinit(&(ia->ia_ifa), (int)RTM_DELETE, 0); =2D ia->ia_flags &=3D ~IFA_ROUTE; + in_scrubprefix(ia); } =20 /* @@ -743,26 +766,7 @@ return (0); flags |=3D RTF_HOST; } =2D =2D /*- =2D * Don't add host routes for interface addresses of =2D * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it =2D * possible to assign several such address pairs with consistent =2D * results (no host route) and is required by BOOTP. =2D * =2D * XXX: This is ugly ! There should be a way for the caller to =2D * say that they don't want a host route. =2D */ =2D if (ia->ia_addr.sin_addr.s_addr !=3D INADDR_ANY || =2D ia->ia_netmask !=3D IN_CLASSA_NET || =2D ia->ia_dstaddr.sin_addr.s_addr !=3D htonl(IN_CLASSA_HOST)) { =2D if ((error =3D rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) !=3D 0) { =2D ia->ia_addr =3D oldaddr; =2D return (error); =2D } =2D ia->ia_flags |=3D IFA_ROUTE; =2D } =2D + error =3D in_addprefix(ia, flags); /* * If the interface supports multicast, join the "all hosts" * multicast group on that interface. @@ -776,6 +780,118 @@ return (error); } =20 +#define rtinitflags(x) \ + ((((x)->ia_ifp->if_flags & (IFF_LOOPBACK | IFF_POINTOPOINT)) !=3D 0) \ + ? RTF_HOST : 0) +/* + * add a route to prefix ("connected route" in cisco terminology). + * does nothing if there's some interface address with the same prefix alr= eady. + */ +static int +in_addprefix(target, flags) + struct in_ifaddr *target; + int flags; +{ + struct in_ifaddr *ia; + struct in_addr prefix, mask, p; + int error; + + if ((flags & RTF_HOST) !=3D 0) + prefix =3D target->ia_dstaddr.sin_addr; + else { + prefix =3D target->ia_addr.sin_addr; + mask =3D target->ia_sockmask.sin_addr; + prefix.s_addr &=3D mask.s_addr; + } + + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (rtinitflags(ia)) + p =3D ia->ia_dstaddr.sin_addr; + else { + p =3D ia->ia_addr.sin_addr; + p.s_addr &=3D ia->ia_sockmask.sin_addr.s_addr; + } + + if (prefix.s_addr !=3D p.s_addr) + continue; + + /* + * if we got a matching prefix route inserted by other + * interface adderss, we don't need to bother + */ + if (ia->ia_flags & IFA_ROUTE) + return 0; + } + + /* + * noone seem to have prefix route. insert it. + */ + error =3D rtinit(&target->ia_ifa, (int)RTM_ADD, flags); + if (!error) + target->ia_flags |=3D IFA_ROUTE; + return error; +} + +/* + * remove a route to prefix ("connected route" in cisco terminology). + * re-installs the route by using another interface address, if there's one + * with the same prefix (otherwise we lose the route mistakenly). + */ +static int +in_scrubprefix(target) + struct in_ifaddr *target; +{ + struct in_ifaddr *ia; + struct in_addr prefix, mask, p; + int error; + + if ((target->ia_flags & IFA_ROUTE) =3D=3D 0) + return 0; + + if (rtinitflags(target)) + prefix =3D target->ia_dstaddr.sin_addr; + else { + prefix =3D target->ia_addr.sin_addr; + mask =3D target->ia_sockmask.sin_addr; + prefix.s_addr &=3D mask.s_addr; + } + + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (rtinitflags(ia)) + p =3D ia->ia_dstaddr.sin_addr; + else { + p =3D ia->ia_addr.sin_addr; + p.s_addr &=3D ia->ia_sockmask.sin_addr.s_addr; + } + + if (prefix.s_addr !=3D p.s_addr) + continue; + + /* + * if we got a matching prefix route, move IFA_ROUTE to him + */ + if ((ia->ia_flags & IFA_ROUTE) =3D=3D 0) { + rtinit(&(target->ia_ifa), (int)RTM_DELETE, + rtinitflags(target)); + target->ia_flags &=3D ~IFA_ROUTE; + + error =3D rtinit(&ia->ia_ifa, (int)RTM_ADD, + rtinitflags(ia) | RTF_UP); + if (error =3D=3D 0) + ia->ia_flags |=3D IFA_ROUTE; + return error; + } + } + + /* + * noone seem to have prefix route. remove it. + */ + rtinit(&(target->ia_ifa), (int)RTM_DELETE, rtinitflags(target)); + target->ia_flags &=3D ~IFA_ROUTE; + return 0; +} + +#undef rtinitflags =20 /* * Return 1 if the address might be a local broadcast address. --Boundary-01=_np8kBd92qNtmEHy-- --nextPart4509686.Ad4VYY4PBk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBk8psXyyEoT62BG0RAmutAJ9z6WB3K1FYiXIDsa/gGY/QjISOYACggWA3 o3PCXKZ60jN3t6bk6VWdkXk= =DccO -----END PGP SIGNATURE----- --nextPart4509686.Ad4VYY4PBk-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 21:29:24 2004 Return-Path: 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 8FB1316A4CE; Thu, 11 Nov 2004 21:29:24 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8FE843D1D; Thu, 11 Nov 2004 21:29:23 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id A897ADD194; Thu, 11 Nov 2004 22:29:22 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 8F701909AF; Thu, 11 Nov 2004 22:29:22 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 3F4FD8EDAE; Thu, 11 Nov 2004 22:29:22 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id E3BCCD4563; Thu, 11 Nov 2004 22:29:21 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id iABLTLhp033370; Thu, 11 Nov 2004 22:29:21 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id iABLTLoM086628; Thu, 11 Nov 2004 22:29:21 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id iABLTKDU086571; Thu, 11 Nov 2004 22:29:20 +0100 (CET) (envelope-from q@uni.de) Date: Thu, 11 Nov 2004 22:29:20 +0100 From: Ulrich Spoerlein To: Max Laier Message-ID: <20041111212920.GA902@galgenberg.net> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 21:29:24 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 11.11.2004 at 21:24:05 +0100, Max Laier wrote: > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. Assume I have two computers hooked up via Ethernet and via Firewire (if_fwe). Will this commit allow me to place all four IP addresses of the interfaces into the same subnet and have FreeBSD re-route the packets through Firewire if the Ethernet link goes down (or vice versa)? Or do I need to go CARP for this to work? Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBk9mwmArGtfDbn0QRAm/7AJ4zWIBMlcgZDAZIK+8bTHpyHNXSdgCgrz5d iKehlCxeLAS/qGBh9dDWB1M= =3kwc -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 11 21:55:08 2004 Return-Path: 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 ADC5516A4CE; Thu, 11 Nov 2004 21:55:08 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DB1243D1D; Thu, 11 Nov 2004 21:55:08 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id DDF68F; Thu, 11 Nov 2004 22:55:06 +0100 (CET) Date: Thu, 11 Nov 2004 22:55:06 +0100 From: Andrea Campi To: Max Laier Message-ID: <20041111215506.GA60227@webcom.it> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2004 21:55:08 -0000 On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived from > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix > routes. Sounds like a very useful change indeed. One comment though: > @@ -743,26 +766,7 @@ > return (0); > flags |= RTF_HOST; > } > - > - /*- > - * Don't add host routes for interface addresses of > - * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it > - * possible to assign several such address pairs with consistent > - * results (no host route) and is required by BOOTP. > - * > - * XXX: This is ugly ! There should be a way for the caller to > - * say that they don't want a host route. > - */ > - if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY || > - ia->ia_netmask != IN_CLASSA_NET || > - ia->ia_dstaddr.sin_addr.s_addr != htonl(IN_CLASSA_HOST)) { > - if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) { > - ia->ia_addr = oldaddr; > - return (error); > - } > - ia->ia_flags |= IFA_ROUTE; > - } > - > + error = in_addprefix(ia, flags); > /* > * If the interface supports multicast, join the "all hosts" > * multicast group on that interface. Are you sure you want to go on if you got an error? Regardless, you should probably have an empty line after in_addrprefix. > + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > + if (rtinitflags(ia)) > + p = ia->ia_dstaddr.sin_addr; > + else { The if() is misindented. The rest looks good. Bye, Andrea -- ...and that is how we know the Earth to be banana-shaped. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 00:10:41 2004 Return-Path: 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 2D23816A4CE; Fri, 12 Nov 2004 00:10:41 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B4F643D5D; Fri, 12 Nov 2004 00:10:40 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CSP1T-00040o-00; Fri, 12 Nov 2004 01:10:39 +0100 Received: from [84.128.130.223] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CSP1T-00058B-00; Fri, 12 Nov 2004 01:10:39 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Fri, 12 Nov 2004 01:10:43 +0100 User-Agent: KMail/1.7.1 References: <200411112124.12616.max@love2party.net> <20041111212920.GA902@galgenberg.net> In-Reply-To: <20041111212920.GA902@galgenberg.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1688102.c5n1zZPv4L"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411120110.51145.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Ulrich Spoerlein cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 00:10:41 -0000 --nextPart1688102.c5n1zZPv4L Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 11 November 2004 22:29, Ulrich Spoerlein wrote: > On Thu, 11.11.2004 at 21:24:05 +0100, Max Laier wrote: > > The patch allows to add more than on IPv4 address with the same prefix. > > In the case that there is a route already, we leave it alone and add the > > new address without the IFA_ROUTE flag. When we remove an address later > > on, that has a route associated, we try to find an alternative address = to > > use for the route and hand it over. > > Assume I have two computers hooked up via Ethernet and via Firewire > (if_fwe). Will this commit allow me to place all four IP addresses of > the interfaces into the same subnet and have FreeBSD re-route the > packets through Firewire if the Ethernet link goes down (or vice versa)? > > Or do I need to go CARP for this to work? The route is only handed over when the address is removed. It might help yo= u=20 when you have a laptop with a wireless card. You can first surf on your cou= ch=20 and later walk to your desktop, plug in the cable and unplug the PCMCIA ... This however, is not the primary goal here and CARP might indeed be what yo= u=20 are looking for ... BTW: I forgot to advertise (and people actually asked) CARP patches can be= =20 found at: http://people.freebsd.org/~mlaier/CARP/ =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1688102.c5n1zZPv4L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBk/+LXyyEoT62BG0RAuSuAJ9mDTxSwkEbQaYDSAKPW5wEGwFK+QCdE532 Fovh96LRbsZERiAoqcw3KVw= =9fbk -----END PGP SIGNATURE----- --nextPart1688102.c5n1zZPv4L-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 00:16:26 2004 Return-Path: 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 EB91B16A4CE; Fri, 12 Nov 2004 00:16:25 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78F3043D39; Fri, 12 Nov 2004 00:16:23 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CSP70-00052M-00; Fri, 12 Nov 2004 01:16:22 +0100 Received: from [84.128.130.223] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CSP70-0000rr-00; Fri, 12 Nov 2004 01:16:22 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Fri, 12 Nov 2004 01:16:31 +0100 User-Agent: KMail/1.7.1 References: <200411112124.12616.max@love2party.net> <20041111215506.GA60227@webcom.it> In-Reply-To: <20041111215506.GA60227@webcom.it> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2998521.leMBpdJXmZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411120116.33771.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-arch@freebsd.org cc: Andrea Campi Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 00:16:26 -0000 --nextPart2998521.leMBpdJXmZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 11 November 2004 22:55, Andrea Campi wrote: > On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) deriv= ed > > from WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic > > prefix routes. > > Sounds like a very useful change indeed. > > One comment though: > > @@ -743,26 +766,7 @@ > > return (0); > > flags |=3D RTF_HOST; > > } > > - > > - /*- > > - * Don't add host routes for interface addresses of > > - * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it > > - * possible to assign several such address pairs with consistent > > - * results (no host route) and is required by BOOTP. > > - * > > - * XXX: This is ugly ! There should be a way for the caller to > > - * say that they don't want a host route. > > - */ > > - if (ia->ia_addr.sin_addr.s_addr !=3D INADDR_ANY || > > - ia->ia_netmask !=3D IN_CLASSA_NET || > > - ia->ia_dstaddr.sin_addr.s_addr !=3D htonl(IN_CLASSA_HOST)) { > > - if ((error =3D rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) !=3D 0) { > > - ia->ia_addr =3D oldaddr; > > - return (error); > > - } > > - ia->ia_flags |=3D IFA_ROUTE; > > - } > > - > > + error =3D in_addprefix(ia, flags); > > /* > > * If the interface supports multicast, join the "all hosts" > > * multicast group on that interface. > > Are you sure you want to go on if you got an error? Regardless, you should > probably have an empty line after in_addrprefix. Not sure how to deal with the error case. All errors we should get are memo= ry=20 related (as we check carefully that the rtinit will success). This means th= at=20 the following in_addmulti will sleep if we hit it (in_addmulti mallocs with= =20 M_WAITOK) ... so I guess you are right and it's the least intrusive if we d= o=20 return. > > + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { > > + if (rtinitflags(ia)) > > + p =3D ia->ia_dstaddr.sin_addr; > > + else { > > The if() is misindented. Right, thanks. Patch at: http://people.freebsd.org/~mlaier/in.c.patch updated accordingly. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2998521.leMBpdJXmZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBlADhXyyEoT62BG0RAiqXAJ9vmIRYQO8Trr94o1cFZK3J7dv1CgCeOJcx yym8dnddM9LXO8FJPiWPt/c= =fe8I -----END PGP SIGNATURE----- --nextPart2998521.leMBpdJXmZ-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 00:17:17 2004 Return-Path: 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 2F36F16A4CE; Fri, 12 Nov 2004 00:17:17 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C531543D31; Fri, 12 Nov 2004 00:17:16 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAC0IupA001455; Thu, 11 Nov 2004 17:18:56 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41940142.2040401@freebsd.org> Date: Thu, 11 Nov 2004 17:18:10 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <20041111030035.GA70923@VARK.MIT.EDU> In-Reply-To: <20041111030035.GA70923@VARK.MIT.EDU> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 00:17:17 -0000 David Schultz wrote: > Over the years, the amount of data we have stored in each process' U > area has eroded to the point where all we have left are the following: > > - A struct kinfo_proc that is only used for a.out core dumps. > This can be reconstructed at the time of the core dump, so > it doesn't need to be there. > > - The struct pstats for the process, which takes a mere 216 bytes > on i386. > > In exchange for the ability to swap out this 216-byte structure, we > keep around a 4096-byte page, a 132-byte vm_object, and a couple of > pointers. Moreover, there is a small amount of runtime overhead > associated with this, and developers need to remember to PHOLD() and > PRELE() the process as appropriate.[1] > > I propose to remove the ability to swap the U area, allocating p_stats > from malloced memory instead. Medium-term scheduling and swapping of > kernel stacks would be retained. Here are the patches; !i386 testers > wanted: > > http://www.freebsd.org/~das/patches/upages.diff > > > [1] Most of the instances of PHOLD() and PRELE() right now never > needed to be there or have been unnecessary ever since the PCB > was moved out of the U area. This breaks amd64 in bad ways on boot. I'll send a trace and more info when I get a serial console hooked up. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 01:01:58 2004 Return-Path: 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 C2D7716A4CE; Fri, 12 Nov 2004 01:01:58 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7490E43D2D; Fri, 12 Nov 2004 01:01:58 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id iAC126h9006869; Thu, 11 Nov 2004 20:02:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id iAC126Ir006868; Thu, 11 Nov 2004 20:02:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 11 Nov 2004 20:02:06 -0500 From: David Schultz To: Scott Long Message-ID: <20041112010206.GA6657@VARK.MIT.EDU> Mail-Followup-To: Scott Long , arch@FreeBSD.ORG References: <20041111030035.GA70923@VARK.MIT.EDU> <41940142.2040401@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41940142.2040401@freebsd.org> cc: arch@FreeBSD.ORG Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 01:01:58 -0000 On Thu, Nov 11, 2004, Scott Long wrote: > >I propose to remove the ability to swap the U area, allocating p_stats > >from malloced memory instead. Medium-term scheduling and swapping of > >kernel stacks would be retained. Here are the patches; !i386 testers > >wanted: > > > > http://www.freebsd.org/~das/patches/upages.diff > > > > > >[1] Most of the instances of PHOLD() and PRELE() right now never > > needed to be there or have been unnecessary ever since the PCB > > was moved out of the U area. > > > This breaks amd64 in bad ways on boot. I'll send a trace and more info > when I get a serial console hooked up. The bug jhb mentioned may be responsible for this: | +struct pstats * | +pstats_alloc(void) | +{ | + | + return (malloc(sizeof(struct plimit), M_SUBPROC, M_ZERO|M_WAITOK)); | +} | | I think you mean s/plimit/pstats/ there. On 32-bit architectures, sizeof(struct plimit) is 184 bytes and sizeof(struct pstats) is 216 bytes, so requests for either would get a 256-byte allocation and things work fine. But on 64-bit architectures, sizeof(struct plimit) is 192 bytes and sizeof(struct pstats) is 432 bytes... In any case, I've updated the patch to correct this cut-and-paste-o. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 03:13:15 2004 Return-Path: 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 3183A16A4CE; Fri, 12 Nov 2004 03:13:15 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C9A843D1D; Fri, 12 Nov 2004 03:13:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iAC3DJGI004851; Thu, 11 Nov 2004 19:13:19 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAC3DIPO004850; Thu, 11 Nov 2004 19:13:18 -0800 Date: Thu, 11 Nov 2004 19:13:18 -0800 From: Brooks Davis To: Max Laier Message-ID: <20041112031318.GC1809@odin.ac.hmc.edu> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 03:13:15 -0000 --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > All, >=20 > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 > This is required for CARP, but should be helpful for other situations as = well. I have no objections so this change. Does this help or hurt our quest to be able to usefully bind to 0.0.0.0? It would be really nice if we could eventually do this so we could stop running bpf on 90+% of all machines just so we could use DHCP. -- Brooks --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBlCpNXY6L6fI4GtQRAipzAKCdvYyPyE3Sts/yUbdDB+/4PKClMwCgh1Be nuaMa9WAlet2jsCi4/WCx/k= =p6N3 -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 03:28:32 2004 Return-Path: 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 E7A1C16A4D0; Fri, 12 Nov 2004 03:28:32 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F4F43D48; Fri, 12 Nov 2004 03:28:32 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9782D65339; Fri, 12 Nov 2004 03:28:30 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51672-01; Fri, 12 Nov 2004 03:28:30 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D00006530A; Fri, 12 Nov 2004 03:28:28 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id A0A436482; Thu, 11 Nov 2004 19:28:17 -0800 (PST) Date: Thu, 11 Nov 2004 19:28:17 -0800 From: Bruce M Simpson To: Brooks Davis Message-ID: <20041112032817.GB7195@dhcp120.icir.org> Mail-Followup-To: Brooks Davis , Max Laier , freebsd-net@freebsd.org, freebsd-arch@freebsd.org References: <200411112124.12616.max@love2party.net> <20041112031318.GC1809@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <20041112031318.GC1809@odin.ac.hmc.edu> cc: Max Laier cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 03:28:33 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 11, 2004 at 07:13:18PM -0800, Brooks Davis wrote: > I have no objections so this change. Does this help or hurt our quest > to be able to usefully bind to 0.0.0.0? It would be really nice if we > could eventually do this so we could stop running bpf on 90+% of all > machines just so we could use DHCP. Nope, that's a job for my IP_SENDIF change (as yet unimplemented). This change, however, may make things somewhat easier for interfaces configured with the same broadcast address; IP_ONESBCAST currently relies on the fact that an interface is numbered and has a network broadcast address to do what it does, but I can see that changing or perhaps even becoming obsolete if IP_SENDIF is implemented. It's a trivial change to implement SO_BINDTODEVICE on top for Linux compatibility. Regards, BMS --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBlC3RueUpAYYNtTsRAiiDAJwMwK5OhSdsz50ahK5KQQ3ls2m/6gCeJPun /VC+Qe3JIrNyYPYv6NFROAo= =ctzK -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 03:51:37 2004 Return-Path: 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 07C6C16A4CE; Fri, 12 Nov 2004 03:51:37 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B84843D2D; Fri, 12 Nov 2004 03:51:36 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id iAC3pYjB058411; Thu, 11 Nov 2004 19:51:36 -0800 (PST) (envelope-from marcel@xcllnt.net) In-Reply-To: <20041112010206.GA6657@VARK.MIT.EDU> References: <20041111030035.GA70923@VARK.MIT.EDU> <41940142.2040401@freebsd.org> <20041112010206.GA6657@VARK.MIT.EDU> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <24C5D808-345E-11D9-97EF-000D93C47836@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 11 Nov 2004 19:51:33 -0800 To: David Schultz X-Mailer: Apple Mail (2.619) cc: arch@freebsd.org cc: Scott Long Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 03:51:37 -0000 On Nov 11, 2004, at 5:02 PM, David Schultz wrote: > The bug jhb mentioned may be responsible for this: > > | +struct pstats * > | +pstats_alloc(void) > | +{ > | + > | + return (malloc(sizeof(struct plimit), M_SUBPROC, > M_ZERO|M_WAITOK)); > | +} > | > | I think you mean s/plimit/pstats/ there. Yup. ia64 boots fine after the substitution. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 06:27:06 2004 Return-Path: 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 CA50916A4CE; Fri, 12 Nov 2004 06:27:06 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7588C43D1D; Fri, 12 Nov 2004 06:27:06 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAC6Sl30002676; Thu, 11 Nov 2004 23:28:47 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <419457F0.70607@freebsd.org> Date: Thu, 11 Nov 2004 23:28:00 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <20041111030035.GA70923@VARK.MIT.EDU> <41940142.2040401@freebsd.org> <20041112010206.GA6657@VARK.MIT.EDU> <24C5D808-345E-11D9-97EF-000D93C47836@xcllnt.net> In-Reply-To: <24C5D808-345E-11D9-97EF-000D93C47836@xcllnt.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org cc: David Schultz Subject: Re: U Area Removal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 06:27:06 -0000 Marcel Moolenaar wrote: > On Nov 11, 2004, at 5:02 PM, David Schultz wrote: > >> The bug jhb mentioned may be responsible for this: >> >> | +struct pstats * >> | +pstats_alloc(void) >> | +{ >> | + >> | + return (malloc(sizeof(struct plimit), M_SUBPROC, >> M_ZERO|M_WAITOK)); >> | +} >> | >> | I think you mean s/plimit/pstats/ there. > > > Yup. ia64 boots fine after the substitution. > Works on amd64 now too. Haven't stessed it much though. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 07:49:25 2004 Return-Path: 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 5A5E516A4CE for ; Fri, 12 Nov 2004 07:49:25 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06A3843D41 for ; Fri, 12 Nov 2004 07:49:25 +0000 (GMT) (envelope-from philip@nixsys.be) Received: from loge.nixsys.be (loge.nixsys.be [195.144.77.45]) by gateway.nixsys.be (Postfix) with ESMTP id CECCA76 for ; Fri, 12 Nov 2004 08:49:23 +0100 (CET) Received: from loge.nixsys.be (philip@localhost [127.0.0.1]) by loge.nixsys.be (8.13.1/8.13.1) with ESMTP id iAC7nNc2000832 for ; Fri, 12 Nov 2004 08:49:23 +0100 (CET) (envelope-from philip@loge.nixsys.be) Received: (from philip@localhost) by loge.nixsys.be (8.13.1/8.13.1/Submit) id iAC7nMPd000831 for freebsd-arch@freebsd.org; Fri, 12 Nov 2004 08:49:22 +0100 (CET) (envelope-from philip) Date: Fri, 12 Nov 2004 08:49:22 +0100 From: Philip Paeps To: freebsd-arch@freebsd.org Message-ID: <20041112074922.GA727@loge.nixsys.be> Mail-Followup-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Date-in-Rome: pridie Idius Novembres MMDCCLVII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.6i Subject: Generic 'input device' layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 07:49:25 -0000 I've been spending the last few weeks writing and hacking touchscreen drivers in the Linux kernel for one of my clients. Thanks to the simple 'input core' framework, this was pretty easy to do. It wasn't fun, but it was easy. Trying to port these drivers to FreeBSD is a lot more painful than it should be, and I'm finding myself duplicating heaps of code (translating absolute coordinates to dx/dy motions, mapping buttons, etc). Has anyone else tried to write something like 'input core' for FreeBSD? A quick Google doesn't turn up anything of particular interest. Basically, I'm looking for a way to get from hardware events to something syscons will understand, without having to do all sorts of really disgusting magic in sys/isa/psm.c or usr.sbin/moused/moused.c. If no one else is working on this, I'd like to solicit ideas for what others would like this interface to look like, and I'll go and write it myself :-) Ideas are welcome! - Philip -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. BOFH Excuse #232: Ionization from the air-conditioning From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 08:03:06 2004 Return-Path: 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 B07B316A4CE; Fri, 12 Nov 2004 08:03:06 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FBC43D39; Fri, 12 Nov 2004 08:03:06 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iAC834FR093102; Fri, 12 Nov 2004 09:03:04 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Philip Paeps From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 12 Nov 2004 08:49:22 +0100." <20041112074922.GA727@loge.nixsys.be> Date: Fri, 12 Nov 2004 09:03:04 +0100 Message-ID: <93101.1100246584@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-arch@freebsd.org Subject: Re: Generic 'input device' layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 08:03:06 -0000 In message <20041112074922.GA727@loge.nixsys.be>, Philip Paeps writes: >I've been spending the last few weeks writing and hacking touchscreen drivers >in the Linux kernel for one of my clients. Thanks to the simple 'input core' >framework, this was pretty easy to do. It wasn't fun, but it was easy. > >Trying to port these drivers to FreeBSD is a lot more painful than it should >be, and I'm finding myself duplicating heaps of code (translating absolute >coordinates to dx/dy motions, mapping buttons, etc). > >Has anyone else tried to write something like 'input core' for FreeBSD? A >quick Google doesn't turn up anything of particular interest. > >Basically, I'm looking for a way to get from hardware events to something >syscons will understand, without having to do all sorts of really disgusting >magic in sys/isa/psm.c or usr.sbin/moused/moused.c. > >If no one else is working on this, I'd like to solicit ideas for what others >would like this interface to look like, and I'll go and write it myself :-) Well, I think that somebody tried something of the kind, but after I spent a day in syscons I can say that it wasn't a success. If you think you can improve on the tangled mess we have there now, I think it would be a great thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 08:04:55 2004 Return-Path: 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 B75D716A4CE; Fri, 12 Nov 2004 08:04:55 +0000 (GMT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35DD443D39; Fri, 12 Nov 2004 08:04:55 +0000 (GMT) (envelope-from dodell@sitetronics.com) Received: from [213.51.128.135] (port=33652 helo=smtp4.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1CSWQP-0002zd-Ml; Fri, 12 Nov 2004 09:04:53 +0100 Received: from cc740438-a.deven1.ov.home.nl ([82.75.136.183]:3603 helo=[192.168.1.3]) by smtp4.home.nl with esmtp (Exim 4.30) id 1CSWQN-0003Ud-S8; Fri, 12 Nov 2004 09:04:51 +0100 Message-ID: <41946EA4.3000500@sitetronics.com> Date: Fri, 12 Nov 2004 09:04:52 +0100 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Paeps References: <20041112074922.GA727@loge.nixsys.be> In-Reply-To: <20041112074922.GA727@loge.nixsys.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean cc: freebsd-arch@freebsd.org Subject: Re: Generic 'input device' layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 08:04:55 -0000 Philip Paeps wrote: > I've been spending the last few weeks writing and hacking touchscreen drivers > in the Linux kernel for one of my clients. Thanks to the simple 'input core' > framework, this was pretty easy to do. It wasn't fun, but it was easy. > > Trying to port these drivers to FreeBSD is a lot more painful than it should > be, and I'm finding myself duplicating heaps of code (translating absolute > coordinates to dx/dy motions, mapping buttons, etc). > > Has anyone else tried to write something like 'input core' for FreeBSD? A > quick Google doesn't turn up anything of particular interest. > > Basically, I'm looking for a way to get from hardware events to something > syscons will understand, without having to do all sorts of really disgusting > magic in sys/isa/psm.c or usr.sbin/moused/moused.c. > > If no one else is working on this, I'd like to solicit ideas for what others > would like this interface to look like, and I'll go and write it myself :-) > > Ideas are welcome! > > - Philip I've recently offered my help in the ARM area; I expect to own a Siemens SIMpad shortly. It also happens to be a touchscreen device. I don't have any idea how these things work (though I suppose it's not terribly difficult to understand), but keep me informed about what you're doing and what needs to be done. If we can get a TODO list set up for things that need to happen to get a working touchscreen driver, I can probably help take a few of those things off the list. --Devon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 08:30:43 2004 Return-Path: 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 4CDF116A4CE; Fri, 12 Nov 2004 08:30:43 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7526043D2D; Fri, 12 Nov 2004 08:30:42 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8Ueho084326; Fri, 12 Nov 2004 10:30:41 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 04757-19; Fri, 12 Nov 2004 10:30:36 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8UEqs084054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 10:30:14 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAC8UE0w051003; Fri, 12 Nov 2004 10:30:14 +0200 (EET) (envelope-from ru) Date: Fri, 12 Nov 2004 10:30:14 +0200 From: Ruslan Ermilov To: Max Laier Message-ID: <20041112083014.GB41844@ip.net.ua> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 08:30:43 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 Hey, you did it! ;) > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 I cannot give your patch a thorough review at the moment, but I like the algorithm, and I don't see how it can hurt anything. > --- ../dist/sys/netinet/in.c Sat Nov 6 21:01:08 2004 > +++ sys/netinet/in.c Mon Nov 8 02:05:17 2004 > @@ -654,14 +684,7 @@ > register struct ifnet *ifp; > register struct in_ifaddr *ia; > { > - > - if ((ia->ia_flags & IFA_ROUTE) =3D=3D 0) > - return; > - if (ifp->if_flags & (IFF_LOOPBACK|IFF_POINTOPOINT)) > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); > - else > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, 0); > - ia->ia_flags &=3D ~IFA_ROUTE; > + in_scrubprefix(ia); > } > =20 Looks like "ifp" argument is no longer needed for in_ifscrub(), perhaps it should be killed then. Also, there are a lot of style bugs (besides those that others have already mentioned), the most annoying is comments -- they should be written as per style(9) (make them look like the real sentences). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlHSWqRfpzJluFF4RAsJbAJ9MrlyCTjeeC7Db9kC5iZ/xBrt8KQCeIdRy 3pYQvaSeF7SeF+iohADcOmM= =4Ken -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 08:36:39 2004 Return-Path: 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 A1FBB16A4CE; Fri, 12 Nov 2004 08:36:39 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4DE843D3F; Fri, 12 Nov 2004 08:36:38 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8acMs086192; Fri, 12 Nov 2004 10:36:38 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 06169-01; Fri, 12 Nov 2004 10:36:36 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8aaSV086183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 10:36:36 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAC8aa9c051052; Fri, 12 Nov 2004 10:36:36 +0200 (EET) (envelope-from ru) Date: Fri, 12 Nov 2004 10:36:36 +0200 From: Ruslan Ermilov To: Max Laier Message-ID: <20041112083636.GC41844@ip.net.ua> References: <200411112124.12616.max@love2party.net> <20041111215506.GA60227@webcom.it> <200411120116.33771.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <200411120116.33771.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: freebsd-net@freebsd.org cc: Andrea Campi cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 08:36:39 -0000 --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2004 at 01:16:31AM +0100, Max Laier wrote: > On Thursday 11 November 2004 22:55, Andrea Campi wrote: > > On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) der= ived > > > from WIDE via OpenBSD in.c, rev 1.21 improves the handling of automat= ic > > > prefix routes. > > > > Sounds like a very useful change indeed. > > > > One comment though: > > > @@ -743,26 +766,7 @@ > > > return (0); > > > flags |=3D RTF_HOST; > > > } > > > - > > > - /*- > > > - * Don't add host routes for interface addresses of > > > - * 0.0.0.0 --> 0.255.255.255 netmask 255.0.0.0. This makes it > > > - * possible to assign several such address pairs with consistent > > > - * results (no host route) and is required by BOOTP. > > > - * > > > - * XXX: This is ugly ! There should be a way for the caller to > > > - * say that they don't want a host route. > > > - */ > > > - if (ia->ia_addr.sin_addr.s_addr !=3D INADDR_ANY || > > > - ia->ia_netmask !=3D IN_CLASSA_NET || > > > - ia->ia_dstaddr.sin_addr.s_addr !=3D htonl(IN_CLASSA_HOST)) { > > > - if ((error =3D rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) !=3D 0) { > > > - ia->ia_addr =3D oldaddr; > > > - return (error); > > > - } > > > - ia->ia_flags |=3D IFA_ROUTE; > > > - } > > > - > > > + error =3D in_addprefix(ia, flags); > > > /* > > > * If the interface supports multicast, join the "all hosts" > > > * multicast group on that interface. > > > > Are you sure you want to go on if you got an error? Regardless, you sho= uld > > probably have an empty line after in_addrprefix. >=20 > Not sure how to deal with the error case. All errors we should get are me= mory=20 > related (as we check carefully that the rtinit will success). This means = that=20 > the following in_addmulti will sleep if we hit it (in_addmulti mallocs wi= th=20 > M_WAITOK) ... so I guess you are right and it's the least intrusive if we= do=20 > return. >=20 The old code did: if ((error =3D rtinit()) !=3D 0) return (error); Why the new code should behave differently, I fail to see? in_addprefix() is just a wrapper around rtinit(), after all. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlHYUqRfpzJluFF4RAgy6AJ4qwETEoghRRzlWwtnipxrcIhU9SQCgiDGY A3PGCLtB+a+fLw3TCwlLfmc= =a0HD -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 09:27:20 2004 Return-Path: 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 2D4C216A4CE; Fri, 12 Nov 2004 09:27:20 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id D81E943D48; Fri, 12 Nov 2004 09:27:19 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id F3C741F1DF; Fri, 12 Nov 2004 10:27:18 +0100 (CET) Received: by hammer.stack.nl (Postfix, from userid 333) id CC07861D2; Fri, 12 Nov 2004 10:27:18 +0100 (CET) Date: Fri, 12 Nov 2004 10:27:18 +0100 From: Marc Olzheim To: John Baldwin Message-ID: <20041112092718.GA28754@stack.nl> References: <418AB176.9030604@withagen.nl> <200411081353.15394.jhb@FreeBSD.org> <418FD6B3.4040600@withagen.nl> <200411100825.33982.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <200411100825.33982.jhb@FreeBSD.org> X-Operating-System: FreeBSD hammer.stack.nl 6.0-CURRENT FreeBSD 6.0-CURRENT X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.6i cc: Willem Jan Withagen cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 09:27:20 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 10, 2004 at 08:25:33AM -0500, John Baldwin wrote: > Note that amd64 uses PAE, so if you want an amd64 version that can do mor= e=20 > than 4 GB you will have to handle PAE. Erhm... You're talking about amd64 running in i386 mode perhaps. Why would amd64 in native 64-bit mode need PAE ? Marc --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlIH2ezjnobFOgrERAnifAJ9m5zUHpuFoBNYM/dBNbnlcxcf27ACfbQlR 40wkdR7w/7uFTEM/Klp75HM= =AN2Y -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 13:54:15 2004 Return-Path: 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 2C4E416A4D0 for ; Fri, 12 Nov 2004 13:54:15 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 3F78243D2D for ; Fri, 12 Nov 2004 13:54:14 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 31236 invoked by uid 0); 12 Nov 2004 13:52:18 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.165.87) by node15.coopprint.com with SMTP; 12 Nov 2004 13:52:18 -0000 Message-ID: <4194C087.6090709@gamersimpact.com> Date: Fri, 12 Nov 2004 07:54:15 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Paeps References: <20041112074922.GA727@loge.nixsys.be> In-Reply-To: <20041112074922.GA727@loge.nixsys.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Generic 'input device' layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 13:54:15 -0000 Philip Paeps wrote: >If no one else is working on this, I'd like to solicit ideas for what others >would like this interface to look like, and I'll go and write it myself :-) > >Ideas are welcome! > > Don't have any ideas on the interface, just That It Works. One of my coming projects is building about 1-2 dozen Intranet kiosks to access a web-deployed application. Any work in this area would be greatly appreciated. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 14:59:11 2004 Return-Path: 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 18C4716A4CE for ; Fri, 12 Nov 2004 14:59:11 +0000 (GMT) Received: from vampire.homelinux.org (p548082DF.dip.t-dialin.net [84.128.130.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD2BE43D3F for ; Fri, 12 Nov 2004 14:59:09 +0000 (GMT) (envelope-from mlaier@vampire.homelinux.org) Received: (qmail 92219 invoked by uid 1001); 12 Nov 2004 14:58:14 -0000 Date: Fri, 12 Nov 2004 15:58:14 +0100 From: Max Laier To: Ruslan Ermilov Message-ID: <20041112145814.GA92163@router.laiers.local> References: <200411112124.12616.max@love2party.net> <20041112083014.GB41844@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041112083014.GB41844@ip.net.ua> User-Agent: Mutt/1.4.2.1i cc: Max Laier cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 14:59:11 -0000 On Fri, Nov 12, 2004 at 10:30:14AM +0200, Ruslan Ermilov wrote: > Hi Max, > > On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > > I know I have sent this a couple of times before, but never got anywhere. This > > time I am set to commit! > > > Hey, you did it! ;) > > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived from > > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix > > routes. > > > > Right now you can't have two legs into the same network. If you want to, you > > must give on of the interfaces a host address only (netmask /32). This way it > > is not possible to hand over the route if one of the interfaces is > > "removed" (however this is done in the special case). > > > > The patch allows to add more than on IPv4 address with the same prefix. In the > > case that there is a route already, we leave it alone and add the new address > > without the IFA_ROUTE flag. When we remove an address later on, that has a > > route associated, we try to find an alternative address to use for the route > > and hand it over. > > > I cannot give your patch a thorough review at the moment, but I like the > algorithm, and I don't see how it can hurt anything. > > > --- ../dist/sys/netinet/in.c Sat Nov 6 21:01:08 2004 > > +++ sys/netinet/in.c Mon Nov 8 02:05:17 2004 > > @@ -654,14 +684,7 @@ > > register struct ifnet *ifp; > > register struct in_ifaddr *ia; > > { > > - > > - if ((ia->ia_flags & IFA_ROUTE) == 0) > > - return; > > - if (ifp->if_flags & (IFF_LOOPBACK|IFF_POINTOPOINT)) > > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); > > - else > > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, 0); > > - ia->ia_flags &= ~IFA_ROUTE; > > + in_scrubprefix(ia); > > } > > > Looks like "ifp" argument is no longer needed for in_ifscrub(), > perhaps it should be killed then. As in_ifscrub() isn't static in in.c I think it must be considered kernel API and hence I will wait with this cleanup 'till after the MFC. I otherwise agree that it should be done. > Also, there are a lot of style bugs (besides those that others > have already mentioned), the most annoying is comments -- they > should be written as per style(9) (make them look like the real > sentences). I updated the patch at: http://people.freebsd.org/~mlaier/in.c.patch with new comments. Can you be more specific about the other style(9) violations, as I don't seem to find them. K&R was choosen as the rest of in.c is K&R still and I think style(9) requires that the overall style of a file is maintained. Thanks. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Fri Nov 12 20:30:37 2004 Return-Path: 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 B4AB616A4CE for ; Fri, 12 Nov 2004 20:30:37 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A88943D31 for ; Fri, 12 Nov 2004 20:30:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30251 invoked from network); 12 Nov 2004 20:30:37 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Nov 2004 20:30:36 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iACKUJo3053969; Fri, 12 Nov 2004 15:30:33 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Marc Olzheim Date: Fri, 12 Nov 2004 13:52:58 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> <200411100825.33982.jhb@FreeBSD.org> <20041112092718.GA28754@stack.nl> In-Reply-To: <20041112092718.GA28754@stack.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411121352.58518.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Willem Jan Withagen cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2004 20:30:37 -0000 On Friday 12 November 2004 04:27 am, Marc Olzheim wrote: > On Wed, Nov 10, 2004 at 08:25:33AM -0500, John Baldwin wrote: > > Note that amd64 uses PAE, so if you want an amd64 version that can do > > more than 4 GB you will have to handle PAE. > > Erhm... You're talking about amd64 running in i386 mode perhaps. Why > would amd64 in native 64-bit mode need PAE ? PAE is how native 64-bit mode does paging. Basically an extended PAE. Perhaps there's a kind of flat mode for 64-bit mode, but I don't think there is. In the kernel we use a psuedo flat-mode by having a direct-mapped region ala the K0seg on Alpha. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org