From owner-freebsd-arch Sun Dec 9 0:57:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 9865537B416 for ; Sun, 9 Dec 2001 00:57:21 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB98uoq50876; Sun, 9 Dec 2001 00:56:50 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Sat, 08 Dec 2001 14:11:16 PST." <200112082211.fB8MBGm18685@apollo.backplane.com> Date: Sun, 09 Dec 2001 00:56:50 -0800 Message-ID: <50872.1007888210@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > /var/tmp and /home are fairly standard partition names... nothing > new in my book. I certainly didn't invent them! In particular, Well, from my perspective you might as well have invented /var/tmp, at least, since that's a filesystem I *never* create. I either move /var entirely off of / (with no sub-mounts) or I leave it there, depending on the mission profile of the machine. /home, yeah, *sometimes* I make /home its own filesystem and sometimes I have it linked to /usr/home or /vol1/local/homedirs or somesuch. You see my point? We're already in disagreement that there's anything "standard" about those two at all since our "standard practices" vary considerably, and that's just the two of us disagreeing. Add several hundred thousand more people to the mix and now you have a lot of people expending keystrokes they didn't have to before, deleting these two new and entirely gratuitous creations of (A)uto. Why tie new mechanism and new policy together, I say. Introduce the more powerful default sizing mechanism as a general improvement first and then go to the next level and introduce proper profiles, don't just add two pet filesystems from your list and consider that particular problem somehow solved. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1: 2:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 723AB37B41B for ; Sun, 9 Dec 2001 01:02:36 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB9926q50929; Sun, 9 Dec 2001 01:02:07 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Bernd Walter Cc: Matthew Dillon , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Bernd Walter of "Sun, 09 Dec 2001 01:33:40 +0100." <20011209013340.D6171@cicely8.cicely.de> Date: Sun, 09 Dec 2001 01:02:06 -0800 Message-ID: <50925.1007888526@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oh yeah, I forgot to comment on this part: In that light perhaps what we need to do is have an auto-resizing feature, so if the user deletes an auto-created partition sysinstall automatically resizes the auto-created partitions before it to fill up the space. So if the user hits 'A' and doesn't want /var/tmp, they simply delete /var/tmp and /var gets its space. And if they don't want /home they simply delete it and /usr gets its space. I think this is a much easier mechanism for the user then requiring him to select which Auto-profile to use. I think this is another good feature to add, but it's purely orthogonal to the suggestions I had. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:18:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 46E2037B416 for ; Sun, 9 Dec 2001 01:18:14 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB99HJq50983; Sun, 9 Dec 2001 01:17:19 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Bernd Walter , Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Sat, 08 Dec 2001 18:23:20 PST." <200112090223.fB92NKf34327@apollo.backplane.com> Date: Sun, 09 Dec 2001 01:17:19 -0800 Message-ID: <50979.1007889439@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Ah well. Perhaps my expectations were a little too high. They were. :-) One of the "bigger picture points" I tried to make at the beginning of my own counter-arguments were that once you try and expand the set of default filesystems, you're defining contraversial policy whether you like it or not and people have as many views on filesystem layout as they do on window managers or screen editors. The set of defaults currently in sysinstall certainly does piss people off and it, by definition, cannot even avoid doing so because it defines a fixed policy. I knew that going into it and hence chose the absolute minimum number of filesystems to make such policy decisions about. It absolutely goes without saying that filesystems should be auto-sized by having minimum and perferred sizes which can also be "floating" sizes, not simply one fixed size. It also goes without saying that it would be a really cool interface feature if deleting a filesystem caused its space to go to the nearest float-sized filesystem, or if growing/shrinking a filesystem could also produce that effect in its relevant neighbor(s). However, if you're going to change default creation policy at all (and, again, this is why I've stayed away from the idea for so long), you need to at least provide a good set of canned policies so that people can cycle through them and find the one which pisses them off the least, including the default of "minimum" if they already like the current behavior. That will give you both your cake and a nice corner to eat it in. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:20:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 93B9A37B405 for ; Sun, 9 Dec 2001 01:20:05 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB99JSq51013; Sun, 9 Dec 2001 01:19:28 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Peter Wemm Cc: Matthew Dillon , Bernd Walter , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Peter Wemm of "Sat, 08 Dec 2001 20:14:00 PST." <20011209041400.28C423808@overcee.netplex.com.au> Date: Sun, 09 Dec 2001 01:19:28 -0800 Message-ID: <51010.1007889568@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Once we know what is going to be installed, we can make fairly realistic > extrapolations about how to size things. Nothing sucks more than having > sysinstall bomb out due to lack of space.Maybe we should be doing the > partition sizing *last* ? This is part of the design of libh, for exactly that reason. You define which filesystems you'd like and a set of *advisory* sizes at the beginning and then it auto-adjusts them once you've selected all the components to install. Libh, however, has package size information available up-front. Sysinstall does not. :-( - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:21:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 304D737B405 for ; Sun, 9 Dec 2001 01:21:15 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB99Klq51040; Sun, 9 Dec 2001 01:20:47 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Bernd Walter , Matthew Dillon , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from "David O'Brien" of "Sat, 08 Dec 2001 21:04:57 PST." <20011208210457.C332@dragon.nuxi.com> Date: Sun, 09 Dec 2001 01:20:47 -0800 Message-ID: <51037.1007889647@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > /home has become *The* standard place for one's home dir. And you're smoking some bad crack if you think there's *any such thing* as a standard here, much less "*The* standard" :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:22:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 6734B37B405 for ; Sun, 9 Dec 2001 01:22:39 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB99M6q51062; Sun, 9 Dec 2001 01:22:06 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Bernd Walter , Peter Wemm , Wilko Bulte , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Sat, 08 Dec 2001 21:41:56 PST." <200112090541.fB95fuJ35335@apollo.backplane.com> Date: Sun, 09 Dec 2001 01:22:06 -0800 Message-ID: <51059.1007889726@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG So, just to change the subject for a moment, which editor do people here prefer? Vi or Emacs? :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:41:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9739737B416 for ; Sun, 9 Dec 2001 01:41:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB99fGV36341; Sun, 9 Dec 2001 01:41:16 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 01:41:16 -0800 (PST) From: Matthew Dillon Message-Id: <200112090941.fB99fGV36341@apollo.backplane.com> To: Jordan Hubbard Cc: Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <50925.1007888526@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sigh. Look, the whole point of 'A'uto is to create a reasonable setup for a layperson installing a system. It is not there to cow-tow to a minimalist status-quo. It is there to give a layperson a reasonable system that does not require him to screw around with the infrastructure when he does reasonable things, like add an account for themselves or install a bunch of ports or follow OUR directions on how to retrieve, compile, and install system source. That is what the option is there for and right now sysinstall doesn't even come CLOSE to providing that. It creates partitions that are too small. It creates relatively unsafe partitions - for example, leaving /var/tmp on /var where /var itself is ALREADY too small for a number of ports, including our printing mechanism and vmware. You may be smart enough to ensure that your mail spool and /var/tmp don't fill up and screw each other over (it can go in either direction), but the layperson is NOT. You may be smart enough to know how to manage /usr but the layperson is not. We can't solve every problem in sysinstall but we can easily and trivially solve a number of them. My patch creates a far safer default partitioning for the layperson and, you know what? I think it creates a far better default partitioning for many FreeBSD developers and power users as well. It is certainly far, far, FAR superior to what sysinstall does now. Now I've spent the time and effort to fix this, and I am getting rather sick and tired of people trying to impose a minimalist view on sysinstall's actions on the one hand, and a complex view on the other. I am sick and tired of people who complain that it doesn't reflect their view of reality. Well, guess what? IT NEVER WILL! These views are why sysinstall's auto-partitioning has essentially been broken for years now. Hell, all of you have had YEARS to fix this and haven't lifted a finger. You all have complained and argued a lot, but code? Nope! Nothing beyond a few hacks and tweeks. And more arguing. I am fixing it. I have fixed it. Try living with my solution for a while rather then complaining about it, you may even grow to like it. My bet is that our users will love it. In she goes... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:52: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A58E337B417 for ; Sun, 9 Dec 2001 01:51:57 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB99pvM36406; Sun, 9 Dec 2001 01:51:57 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 01:51:57 -0800 (PST) From: Matthew Dillon Message-Id: <200112090951.fB99pvM36406@apollo.backplane.com> To: Jordan Hubbard Cc: Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <51037.1007889647@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :> /home has become *The* standard place for one's home dir. : :And you're smoking some bad crack if you think there's *any such :thing* as a standard here, much less "*The* standard" :-) : :- Jordan The path '/home' is certainly a defacto standard. As its own partition, directory in some other partition, softlink, or other contrivance, there is no standard, so for the layperson we choose something reasonable -- A directory is quite reasonable. We get logical separation for backup/restore/transfer/management purposes, and we get a nice place to put all that extra disk space. Perfect for the layperson. Not perfect for the developer but still quite reasonable, and the developer is smart enough to adjust the partitioning the way he wants (just as we do now considering the crap 'A'uto gneerates pre-patch). So don't complain, this is actually an improvement over what we have. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 1:58:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 818AB37B416 for ; Sun, 9 Dec 2001 01:58:09 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB99vbq03864; Sun, 9 Dec 2001 01:57:37 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Sun, 09 Dec 2001 01:41:16 PST." <200112090941.fB99fGV36341@apollo.backplane.com> Date: Sun, 09 Dec 2001 01:57:37 -0800 Message-ID: <3839.1007891857@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Sigh. Look, the whole point of 'A'uto is to create a reasonable > [rant deleted] All in your humble opinion, to be sure. I don't agree with it, however, and enough other people clearly don't agree with it that I most certainly can't see it as a -stable candidate for 4.5 as you evidently do since you have the MFC marked as a week away. It's up to the release engineers to decide, of course, but I'm just telling you now that I'll argue against it and that's probably the last we need to say about it. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 2: 0:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7587E37B416 for ; Sun, 9 Dec 2001 02:00:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB9A0sg36797; Sun, 9 Dec 2001 02:00:54 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 02:00:54 -0800 (PST) From: Matthew Dillon Message-Id: <200112091000.fB9A0sg36797@apollo.backplane.com> To: Jordan Hubbard Cc: Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <3839.1007891857@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> [rant deleted] : :All in your humble opinion, to be sure. I don't agree with it, :however, and enough other people clearly don't agree with it that I :most certainly can't see it as a -stable candidate for 4.5 as you :evidently do since you have the MFC marked as a week away. : :It's up to the release engineers to decide, of course, but I'm just :telling you now that I'll argue against it and that's probably the :last we need to say about it. : :- Jordan We aren't in code freeze yet. Go ahead, argue against it. I'll argue for it. It would be a shame for it to not reach -stable considering how screwed up sysinstall's auto defaults are now, but you will have to get a CORE decision to achieve that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 3:11:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 98B7137B417; Sun, 9 Dec 2001 03:11:27 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id fB9AibN80964; Sun, 9 Dec 2001 10:44:37 GMT (envelope-from nik) Date: Sun, 9 Dec 2001 10:44:37 +0000 From: Nik Clayton To: Greg Lehey Cc: Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011209104437.A69671@clan.nothing-going-on.org> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011209164606.C83634@monorchid.lemis.com>; from grog@FreeBSD.org on Sun, Dec 09, 2001 at 04:46:06PM +1030 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 09, 2001 at 04:46:06PM +1030, Greg Lehey wrote: > Well, since we're all being personal, here's my opinion. =20 / 50M - 150M swap 2-4 x RAM, depending on what the machine's doing /var 50M - 100M /usr 250 - 300M /local/0 Rest of disk /usr/local is a symlink to /local/0/usr/local /usr/src is a symlink to /local/0/usr/src /home is a symlink to /local/0/home /var/tmp is a symlink to /local/0/var/tmp Other symlinks exist as necessary, depending what the machine's going to be doing. Any additional disks are mounted as /local/1, /local/2, and so on. This=20 makes it pretty easy to shuffle stuff between disks as necessary (for=20 example, making sure that /home/ncvs isn't on the same disk as any home=20 directories that might checkout from it, putting /usr/src and /usr/obj on different disks, etc), and because most of the data is kept in big=20 partitions you don't have to worry about running out of space because=20 you made a partition too small. # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 148823 73712 63206 54% / /dev/da0s1g 16428378 1865688 13248420 12% /local/0 /dev/da1s1e 16974442 8232228 7384259 53% /local/1 /dev/ad0s1e 38711699 7074308 28540456 20% /local/2 /dev/da0s1f 297663 189788 84062 69% /usr /dev/da0s1e 99183 45944 45305 50% /var procfs 4 4 0 100% /proc linprocfs 4 4 0 100% /usr/compat/linux/proc # ls -l /var total 19 drwxr-xr-x 2 root wheel 512 Nov 20 2000 account/ drwxr-xr-x 4 root wheel 512 Nov 20 2000 at/ drwxr-x--- 2 root wheel 512 Sep 27 03:01 backups/ drwxr-x--- 2 root wheel 512 Jun 7 2001 crash/ drwxr-x--- 3 root wheel 512 Nov 20 2000 cron/ drwxr-xr-x 7 root wheel 512 Oct 2 10:35 db/ drwxrwxr-x 5 root games 512 Jun 7 2001 games/ drwxr-xr-x 3 root wheel 512 Oct 20 09:38 lib/ drwxr-xr-x 2 root wheel 512 Dec 9 10:25 lock/ drwxr-xr-x 3 root wheel 2048 Dec 9 10:32 log/ drwxrwxr-x 2 root mail 512 Oct 2 14:23 mail/ drwxr-xr-x 2 daemon wheel 512 Jun 7 2001 msgs/ drwxr-xr-x 2 root wheel 512 Nov 20 2000 preserve/ drwxrwx--- 2 cyrus cyrus 512 Oct 7 14:48 pwcheck/ drwxr-xr-x 3 root wheel 512 Dec 9 10:08 run/ drwxrwxr-x 2 root daemon 512 Nov 20 2000 rwho/ drwxr-xr-x 10 root wheel 512 Jun 8 2001 spool/ lrwxr-xr-x 1 root wheel 16 Jun 8 2001 tmp@ -> /local/1/var/tmp drwxr-xr-x 4 root wheel 512 Sep 13 14:19 yp/ # ls -l /usr total 32 lrwxr-xr-x 1 root wheel 18 Jun 7 2001 X11R6@ -> /local/0/usr/X11R6 drwxr-xr-x 2 root wheel 6656 Oct 20 09:53 bin/ drwxr-xr-x 3 root wheel 512 Jun 10 2001 compat/ drwxr-xr-x 3 root wheel 512 Sep 14 22:58 etc/ drwxr-xr-x 3 root wheel 1024 Jun 7 2001 games/ lrwxr-xr-x 1 root wheel 18 Jul 11 13:49 gnats@ -> /local/1/usr/gnats drwxr-xr-x 37 root wheel 3584 Jun 7 2001 include/ drwxr-xr-x 2 root wheel 512 Sep 14 22:58 info/ drwxr-xr-x 5 root wheel 7168 Sep 14 22:58 lib/ drwxr-xr-x 9 root wheel 512 Nov 20 2000 libdata/ drwxr-xr-x 8 root wheel 1536 Jun 7 2001 libexec/ lrwxr-xr-x 1 root wheel 18 Jun 7 2001 local@ -> /local/1/usr/local lrwxr-xr-x 1 root wheel 24 Jun 21 09:59 local.debug@ -> /local/1/usr/= local.debug drwxr-xr-x 26 root wheel 512 Sep 14 22:58 man/ lrwxr-xr-x 1 root wheel 16 Jun 7 2001 obj@ -> /local/0/usr/obj lrwxr-xr-x 1 root wheel 18 Jun 7 2001 ports@ -> /local/1/usr/ports drwxr-xr-x 2 root wheel 4096 Jun 15 14:32 sbin/ drwxr-xr-x 26 root wheel 512 Sep 14 22:58 share/ lrwxr-xr-x 1 root wheel 16 Jun 7 2001 src@ -> /local/1/usr/src drwxr-xr-x 7 root wheel 512 Jul 11 13:55 sup/ N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwTQJQACgkQk6gHZCw343UcIgCfeKaWbMPeUidnIsBa6uJKwAzx GzUAn1HsOU5yg4BzHsimCeuDrHE28LyG =IApp -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 3:11:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 98B7137B417; Sun, 9 Dec 2001 03:11:27 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id fB9AibN80964; Sun, 9 Dec 2001 10:44:37 GMT (envelope-from nik) Date: Sun, 9 Dec 2001 10:44:37 +0000 From: Nik Clayton To: Greg Lehey Cc: Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011209104437.A69671@clan.nothing-going-on.org> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011209164606.C83634@monorchid.lemis.com>; from grog@FreeBSD.org on Sun, Dec 09, 2001 at 04:46:06PM +1030 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 09, 2001 at 04:46:06PM +1030, Greg Lehey wrote: > Well, since we're all being personal, here's my opinion. =20 / 50M - 150M swap 2-4 x RAM, depending on what the machine's doing /var 50M - 100M /usr 250 - 300M /local/0 Rest of disk /usr/local is a symlink to /local/0/usr/local /usr/src is a symlink to /local/0/usr/src /home is a symlink to /local/0/home /var/tmp is a symlink to /local/0/var/tmp Other symlinks exist as necessary, depending what the machine's going to be doing. Any additional disks are mounted as /local/1, /local/2, and so on. This=20 makes it pretty easy to shuffle stuff between disks as necessary (for=20 example, making sure that /home/ncvs isn't on the same disk as any home=20 directories that might checkout from it, putting /usr/src and /usr/obj on different disks, etc), and because most of the data is kept in big=20 partitions you don't have to worry about running out of space because=20 you made a partition too small. # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 148823 73712 63206 54% / /dev/da0s1g 16428378 1865688 13248420 12% /local/0 /dev/da1s1e 16974442 8232228 7384259 53% /local/1 /dev/ad0s1e 38711699 7074308 28540456 20% /local/2 /dev/da0s1f 297663 189788 84062 69% /usr /dev/da0s1e 99183 45944 45305 50% /var procfs 4 4 0 100% /proc linprocfs 4 4 0 100% /usr/compat/linux/proc # ls -l /var total 19 drwxr-xr-x 2 root wheel 512 Nov 20 2000 account/ drwxr-xr-x 4 root wheel 512 Nov 20 2000 at/ drwxr-x--- 2 root wheel 512 Sep 27 03:01 backups/ drwxr-x--- 2 root wheel 512 Jun 7 2001 crash/ drwxr-x--- 3 root wheel 512 Nov 20 2000 cron/ drwxr-xr-x 7 root wheel 512 Oct 2 10:35 db/ drwxrwxr-x 5 root games 512 Jun 7 2001 games/ drwxr-xr-x 3 root wheel 512 Oct 20 09:38 lib/ drwxr-xr-x 2 root wheel 512 Dec 9 10:25 lock/ drwxr-xr-x 3 root wheel 2048 Dec 9 10:32 log/ drwxrwxr-x 2 root mail 512 Oct 2 14:23 mail/ drwxr-xr-x 2 daemon wheel 512 Jun 7 2001 msgs/ drwxr-xr-x 2 root wheel 512 Nov 20 2000 preserve/ drwxrwx--- 2 cyrus cyrus 512 Oct 7 14:48 pwcheck/ drwxr-xr-x 3 root wheel 512 Dec 9 10:08 run/ drwxrwxr-x 2 root daemon 512 Nov 20 2000 rwho/ drwxr-xr-x 10 root wheel 512 Jun 8 2001 spool/ lrwxr-xr-x 1 root wheel 16 Jun 8 2001 tmp@ -> /local/1/var/tmp drwxr-xr-x 4 root wheel 512 Sep 13 14:19 yp/ # ls -l /usr total 32 lrwxr-xr-x 1 root wheel 18 Jun 7 2001 X11R6@ -> /local/0/usr/X11R6 drwxr-xr-x 2 root wheel 6656 Oct 20 09:53 bin/ drwxr-xr-x 3 root wheel 512 Jun 10 2001 compat/ drwxr-xr-x 3 root wheel 512 Sep 14 22:58 etc/ drwxr-xr-x 3 root wheel 1024 Jun 7 2001 games/ lrwxr-xr-x 1 root wheel 18 Jul 11 13:49 gnats@ -> /local/1/usr/gnats drwxr-xr-x 37 root wheel 3584 Jun 7 2001 include/ drwxr-xr-x 2 root wheel 512 Sep 14 22:58 info/ drwxr-xr-x 5 root wheel 7168 Sep 14 22:58 lib/ drwxr-xr-x 9 root wheel 512 Nov 20 2000 libdata/ drwxr-xr-x 8 root wheel 1536 Jun 7 2001 libexec/ lrwxr-xr-x 1 root wheel 18 Jun 7 2001 local@ -> /local/1/usr/local lrwxr-xr-x 1 root wheel 24 Jun 21 09:59 local.debug@ -> /local/1/usr/= local.debug drwxr-xr-x 26 root wheel 512 Sep 14 22:58 man/ lrwxr-xr-x 1 root wheel 16 Jun 7 2001 obj@ -> /local/0/usr/obj lrwxr-xr-x 1 root wheel 18 Jun 7 2001 ports@ -> /local/1/usr/ports drwxr-xr-x 2 root wheel 4096 Jun 15 14:32 sbin/ drwxr-xr-x 26 root wheel 512 Sep 14 22:58 share/ lrwxr-xr-x 1 root wheel 16 Jun 7 2001 src@ -> /local/1/usr/src drwxr-xr-x 7 root wheel 512 Jul 11 13:55 sup/ N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwTQJQACgkQk6gHZCw343UcIgCfeKaWbMPeUidnIsBa6uJKwAzx GzUAn1HsOU5yg4BzHsimCeuDrHE28LyG =IApp -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 5:33:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id C212537B41B for ; Sun, 9 Dec 2001 05:33:16 -0800 (PST) Received: from ipv16 (as1b-48.chi.il.dial.anet.com [198.92.157.48]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id HAA01795; Sun, 9 Dec 2001 07:32:09 -0600 (CST) Message-ID: <00e201c180b7$66d39f80$a300a8c0@ipv16> From: "Jim Fleming" To: "Bernd Walter" , "Matthew Dillon" , "Garance A Drosihn" , "Louis A. Mamakos" , "Sheldon Hearn" , "Kirk McKusick" , , "Jordan Hubbard" References: <51037.1007889647@winston.freebsd.org> Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Date: Sun, 9 Dec 2001 07:42:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Jordan Hubbard" To: "Bernd Walter" ; "Matthew Dillon" ; "Garance A Drosihn" ; "Louis A. Mamakos" ; "Sheldon Hearn" ; "Kirk McKusick" ; Sent: Sunday, December 09, 2001 3:20 AM Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) > > /home has become *The* standard place for one's home dir. > > And you're smoking some bad crack if you think there's *any such > thing* as a standard here, much less "*The* standard" :-) > I will have to remember that....the next time Jordan tells me that IPv8 will not be allowed into FreeBSD..... :-) This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 5:56:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id CE0AE37B405 for ; Sun, 9 Dec 2001 05:56:33 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id FAA00997; Sun, 9 Dec 2001 05:54:50 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda00995; Sun Dec 9 05:54:30 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id fB9DsP157259; Sun, 9 Dec 2001 05:54:25 -0800 (PST) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdG57245; Sun Dec 9 05:53:39 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id fB9Drcq44545; Sun, 9 Dec 2001 05:53:38 -0800 (PST) Message-Id: <200112091353.fB9Drcq44545@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdV44541; Sun Dec 9 05:53:35 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Jordan Hubbard Cc: Bernd Walter , Matthew Dillon , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-reply-to: Your message of "Sun, 09 Dec 2001 01:20:47 PST." <51037.1007889647@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 05:53:35 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <51037.1007889647@winston.freebsd.org>, Jordan Hubbard writes: > > /home has become *The* standard place for one's home dir. > > And you're smoking some bad crack if you think there's *any such > thing* as a standard here, much less "*The* standard" :-) The thing about standards is that there's so many to choose from. Of the few systems we (OSG) owns, we conform to the "OSG" standard. Each of the customers that I have inherited, e.g. they had an installed base of machines my team had not installed from scratch, have their own standards different from my standards and different from each other's standards. In a couple of cases it appears there are no standards whatsoever where in fact various standards used by these customers are an evolution of various standards used by various sysadmins and contractors who had worked at these customer sites over the years. In short, personally, I would like to think that my approach is the standard (or the right way to do it), however I would be in a state of delusion if I actually believed that. Before we roll up our sleeves and build this bikeshed, could we decide on its color please. My vote is green. :) Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 5:59:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7EE6037B417 for ; Sun, 9 Dec 2001 05:59:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA20909; Mon, 10 Dec 2001 00:59:11 +1100 Date: Mon, 10 Dec 2001 00:59:48 +1100 (EST) From: Bruce Evans X-X-Sender: To: Wilko Bulte Cc: Matthew Dillon , "David O'Brien" , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <20011208205131.A56648@freebie.xs4all.nl> Message-ID: <20011210005425.R25028-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 8 Dec 2001, Wilko Bulte wrote: > On Sat, Dec 08, 2001 at 11:11:29AM -0800, Matthew Dillon wrote: > > > > : > > :On Fri, Dec 07, 2001 at 07:49:32PM -0800, Matthew Dillon wrote: > > :> We do not have enough partition id's to make a separate > > :> /usr/local. > > : > > :Has anyone considered raising the max number of partitions from 8 to 16 > > :as OpenBSD did years ago? > > > > Oh, by the way... there is actually a way you can bump up the number > > of partitions. What you do is split the disk up into multiple slices. > > We have 4, after all. You can then disklabel each one. We have 30. More would require much the same minor number surgery as more partitions. > This works on x86 but not on alpha which does not use slices. If so, then this is a bug on alphas. Slices are not machine-dependent, except possibily ones that you want to boot from. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 8: 2:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 321A237B405 for ; Sun, 9 Dec 2001 08:02:08 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fB9G1Li85853; Sun, 9 Dec 2001 11:01:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 9 Dec 2001 11:01:21 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jordan Hubbard Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <50872.1007888210@winston.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Dec 2001, Jordan Hubbard wrote: > > /var/tmp and /home are fairly standard partition names... nothing > > new in my book. I certainly didn't invent them! In particular, > > Well, from my perspective you might as well have invented /var/tmp, at > least, since that's a filesystem I *never* create. I either move /var > entirely off of / (with no sub-mounts) or I leave it there, depending on > the mission profile of the machine. /home, yeah, *sometimes* I make > /home its own filesystem and sometimes I have it linked to /usr/home or > /vol1/local/homedirs or somesuch. You see my point? We're already in > disagreement that there's anything "standard" about those two at all > since our "standard practices" vary considerably, and that's just the > two of us disagreeing. Add several hundred thousand more people to the > mix and now you have a lot of people expending keystrokes they didn't > have to before, deleting these two new and entirely gratuitous creations > of (A)uto. Well, I have to agree with Jordan here. This went from a discussion of how the current sizing in (A)uto for the current layout was inadequate to a discussion of everyone's personal favorite layout, and how it's the only one anyone should ever put in (A)uto. I think both these discussions have their merits, needless to say, but it does seem like a lot of teeth are being dug in pretty deep over something that we all need to just disagree on anyway. What we should probably be doing is two-phase: (1) make sure our current Auto does something useful in terms of sizes, and (2) discuss what a reasonable default layout might be. The primary problems I run into with today's (A)uto for many users are that the temporary directories and root partitions are too small for currently deployed software. I think Matt's commit to -CURRENT resolves this problem. What I would like to see is a delay before MFC: Matt proposed a one week MFC, but I think actually waiting several weeks would be prefered. > Why tie new mechanism and new policy together, I say. Introduce the > more powerful default sizing mechanism as a general improvement first > and then go to the next level and introduce proper profiles, don't just > add two pet filesystems from your list and consider that particular > problem somehow solved. Sure, sounds good to me. I regularly deploy systems with several different layouts, including: Big root, swap partition 128Mb or 256Mb root, swap partition, /usr, /var, MD-backed /tmp and /var/tmp, /home, and /data (A)uto's defaults from 4.4-RELEASE, modulo larger root, and /tmp symlinked to /usr/tmp. The recurring theme there is really the larger root, and special handling of temporary directories. In 4.3, we shipped a number of packages that could be installed using the default layout, because /var/tmp was too small. That's easy to fix. I think what people do need to do in such a discussion is recognize that (a) their experience isn't everyone's experience, and as a result (b) their optimum configuration isn't the same as everyone else's. (A)uto probably simply needs to be "decent" for expected needs for the next few years in terms of temporary space usage, expected bloat of software, and package installs. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 10:19:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id DFD5D37B417 for ; Sun, 9 Dec 2001 10:19:33 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA11979; Sun, 9 Dec 2001 11:19:10 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB9IJ9183787; Sun, 9 Dec 2001 11:19:09 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15379.43805.336137.177646@caddis.yogotech.com> Date: Sun, 9 Dec 2001 11:19:09 -0700 To: Matthew Dillon Cc: Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112090941.fB99fGV36341@apollo.backplane.com> References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > Sigh. Look, the whole point of 'A'uto is to create a reasonable > setup for a layperson installing a system. It is not there to > cow-tow to a minimalist status-quo. It is there to give a layperson > a reasonable system that does not require him to screw around > with the infrastructure when he does reasonable things, like add an > account for themselves or install a bunch of ports or follow OUR > directions on how to retrieve, compile, and install system source. So far we agree. > That is what the option is there for and right now sysinstall doesn't > even come CLOSE to providing that. This is where we disagree. I just installed 4 systems in the last month, and all were installed using 'auto' partitions, and all are using defaults that are acceptable for single-user systems. > It creates partitions that are > too small. I disagree. They may not be optimal, but they are acceptable. > It creates relatively unsafe partitions - for example, > leaving /var/tmp on /var where /var itself is ALREADY too small for > a number of ports, including our printing mechanism and vmware. Completely disagreed. /var/tmp doesn't need to be any bigger *IF* you don't symlink /tmp into /var/tmp. (Which I still think is a *REALLY* *REALLY* *BAD* idea, but unfortunately I'm certain this will become the point to argue about, because I think this is the basis for most of your othe changes. :() > You > may be smart enough to ensure that your mail spool and /var/tmp > don't fill up and screw each other over (it can go in either direction), > but the layperson is NOT. Disagreed. For most single-user systems, or 'server-type' systems, the defaults we're using now aren't that bad. For shell servers used by ISP's, or other servers with specific purposes, the defaults aren't that great, but if you're building one of those, you shouldn't be using the defaults and you should be clueful enough to know how to build a big system. (There are tons of great resource to help you out on this, including books, mailing lists, etc....,) > You may be smart enough to know how to > manage /usr but the layperson is not. We can't solve every problem > in sysinstall but we can easily and trivially solve a number of them. > > My patch creates a far safer default partitioning for the layperson > and, you know what? I think it creates a far better default partitioning > for many FreeBSD developers and power users as well. It is certainly > far, far, FAR superior to what sysinstall does now. That is where we disagree. And, many of the other developers disagree that your scheme is 'superior' to the current defaults. Hence, the quandry. If so many people disagree, I think it implies that your opinions don't necessarily reflect the opinions of others who are *equally* qualified to judge your defaults. Therefore, either we're all completely clueless (my guess is that's your opinion of the matter), or that your defaults aren't complete, and need more than what you've done now to be a better solution than what we have now. Changing the defaults doesn't necessarily make things better, and in my opinion I think they will make things *more* difficult for many types of configuration. Having lots of small partitions is a step in the wrong direction for *many* installations, because when /var fills up, or /usr fills up, or /home fills up, there is almost invariably space in the other partitions that they can't use. Having '/' on one partition (appropriate sized, but as small as possible for fsck to be able to fix it quickly), having /var (so that / doesn't need to be written to decreasing the chances of having FS corruption, plus /var tends to fill up while / does), and having /usr is a good first start. Then, having the ability to create an memory-based /tmp is a good next step, since for most people /tmp *should* be files that don't stick around much, and enabling soft-updates on / doesn't work so well when disk space gets tight. Finally, having the ability to create a separate /home partition is the next logical step, since /home is for most folks the directory for logins. From here, we can get nuts, and start creating /var/tmp, and /usr/obj, and /usr/local, and all sorts of other partitions. But, I think we either need to stick with the current very simple (and *VERY* workable defaults), or provide a more flexible mechanism so that the user can get reasonable defaults without forcing them into an out-of-diskspace setup. Note, *MANY* of the people that use FreeBSD are installing it on 'older' hardware that want to try it out, or are sticking FreeBSD into places where there isn't much 'user' traffic on the box aside from email. These kinds of machines don't need /home, or /var/tmp. > > Now I've spent the time and effort to fix this, and I am getting rather > sick and tired of people trying to impose a minimalist view on > sysinstall's actions on the one hand, and a complex view on the other. Because sysinstall > I am sick and tired of people who complain that it doesn't reflect their > view of reality. Well, guess what? IT NEVER WILL! These views are > why sysinstall's auto-partitioning has essentially been broken for > years now. This is where we disagree. The only one who has been complaining about it being completely broken is you. Now, I'm not saying it's been optimal, but it hasn't been broken. > Hell, all of you have had YEARS to fix this and haven't lifted a finger. > You all have complained and argued a lot, but code? I haven't complained about sysinstall. I've complained about you're current forcing your opinion into something that isn't broken, thus making the 'Auto' feature much less useful for me and a number of folks I support. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 11: 8:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 0272137B419 for ; Sun, 9 Dec 2001 11:08:56 -0800 (PST) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.4/8.11.4) id fB9J8gu70896; Sun, 9 Dec 2001 11:08:42 -0800 (PST) (envelope-from sgk) Date: Sun, 9 Dec 2001 11:08:42 -0800 From: Steve Kargl To: Nate Williams Cc: Matthew Dillon , Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209110842.A70153@troutmask.apl.washington.edu> References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> <15379.43805.336137.177646@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15379.43805.336137.177646@caddis.yogotech.com>; from nate@yogotech.com on Sun, Dec 09, 2001 at 11:19:09AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 11:19:09AM -0700, Nate Williams wrote: > Matthew Dillon writes: > > > It creates relatively unsafe partitions - for example, > > leaving /var/tmp on /var where /var itself is ALREADY too small for > > a number of ports, including our printing mechanism and vmware. > > Completely disagreed. /var/tmp doesn't need to be any bigger *IF* you > don't symlink /tmp into /var/tmp. (Which I still think is a *REALLY* > *REALLY* *BAD* idea, but unfortunately I'm certain this will become the > point to argue about, because I think this is the basis for most of your > othe changes. :() > Nate, drop by USENET. There are two threads about why /var is full and what to do about the problem. These are the people that Matt is targetting. The solutions that people are offering include deleting garbage, symlinking /var/tmp to various locations, and rebuilding a new, larger, filesystem. I'm surprised that Matt hasn't throw his hands up and walked away from this bikeshed. From a selfish point of view, I hope he does. I'd rather have him spend his *limited* time locking down the VM subsystem. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 11:44:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A2E237B405 for ; Sun, 9 Dec 2001 11:44:11 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB9Jhc438335; Sun, 9 Dec 2001 11:43:38 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 11:43:38 -0800 (PST) From: Matthew Dillon Message-Id: <200112091943.fB9Jhc438335@apollo.backplane.com> To: Nate Williams Cc: Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> <15379.43805.336137.177646@caddis.yogotech.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :I disagree. They may not be optimal, but they are acceptable. It is far easier to present a rich set of partitions and allow the user, in a few flicks of the keys, to delete the ones he doesn't want then to present a minimalist set of partitions and require the user to then screw around with them if he wants more (he'd also have to delete & recreate the overlarge /usr and then create the additional ones). Frankly I don't see how the minimalist set could possibly be better. It requires far more work and understanding of the system. You may like the minimalist defaults, but I sure as hell don't, and many other people don't either. My way encompasses a much larger crowd (including encompassing your requirements if you don't mind two flicks of the keyboard to 'restore' it back to what you had before). :> It creates relatively unsafe partitions - for example, :> leaving /var/tmp on /var where /var itself is ALREADY too small for :> a number of ports, including our printing mechanism and vmware. : :Completely disagreed. /var/tmp doesn't need to be any bigger *IF* you :don't symlink /tmp into /var/tmp. (Which I still think is a *REALLY* :*REALLY* *BAD* idea, but unfortunately I'm certain this will become the :point to argue about, because I think this is the basis for most of your :othe changes. :() This is nonsense. Many programs operate directly on /var/tmp. In fact, considering how small /tmp often is (being on / if you screw around with it), many programs, and users, wound up not having a choice. Not to mention the fact that having /tmp on / by default is unncessarily dangerous in regards to a crash. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 11:58:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 686DD37B416 for ; Sun, 9 Dec 2001 11:58:22 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB9JwBi46876; Sun, 9 Dec 2001 11:58:11 -0800 (PST) (envelope-from obrien) Date: Sun, 9 Dec 2001 11:58:11 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209115811.A41708@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <3839.1007891857@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3839.1007891857@winston.freebsd.org>; from jkh@winston.freebsd.org on Sun, Dec 09, 2001 at 01:57:37AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 01:57:37AM -0800, Jordan Hubbard wrote: > > Sigh. Look, the whole point of 'A'uto is to create a reasonable > > [rant deleted] > > All in your humble opinion, to be sure. I don't agree with it, > however, and enough other people clearly don't agree with it that I > most certainly can't see it as a -stable candidate for 4.5 as you > evidently do since you have the MFC marked as a week away. Then rather than stop this needed band-aid solution, when will we see your sysinstall commit that implements what you desired in your earlier message? The last several (A)uto size bumps were done by myself. You haven't been that active in this issue of Sysinstall for a while. In fact in a way you've dropped the ball WRT Sysinstall. You said for years you were having it replaced and that kept interested people from enhancing it. We still don't have a replacement, so please don't get in the way of others enhancing it. > It's up to the release engineers to decide, of course, but I'm just > telling you now that I'll argue against it and that's probably the > last we need to say about it. Sounds like you are threatening to put your RE weight behind stopping this by threatening to pressure re@ to not allow an MFC, when it is simply your personal opinion. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 12:17:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id D8A0437B405 for ; Sun, 9 Dec 2001 12:17:22 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB9KGJq38875; Sun, 9 Dec 2001 12:16:19 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Steve Kargl Cc: Nate Williams , Matthew Dillon , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Steve Kargl of "Sun, 09 Dec 2001 11:08:42 PST." <20011209110842.A70153@troutmask.apl.washington.edu> Date: Sun, 09 Dec 2001 12:16:19 -0800 Message-ID: <38872.1007928979@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'm surprised that Matt hasn't throw his hands up > and walked away from this bikeshed. From a selfish > point of view, I hope he does. I'd rather have him > spend his *limited* time locking down the VM subsystem. So would I. The quality of his work there is far less in dispute, for one thing. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 12:28:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 53B0737B405; Sun, 9 Dec 2001 12:28:52 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB9KSWq38956; Sun, 9 Dec 2001 12:28:33 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: obrien@FreeBSD.ORG Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from "David O'Brien" of "Sun, 09 Dec 2001 11:58:11 PST." <20011209115811.A41708@dragon.nuxi.com> Date: Sun, 09 Dec 2001 12:28:32 -0800 Message-ID: <38952.1007929712@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Then rather than stop this needed band-aid solution, when will we see > your sysinstall commit that implements what you desired in your earlier > message? Now that I've been forced to think about it and see things going in the wrong direction in -current, perhaps sooner than you think. I already got the last of the data structures and the interface details worked out last night. > We still don't have a replacement, so please don't get in > the way of others enhancing it. If I considered this a genuine enhancement, that argument might mean something to me. If I were totally alone in arguing against the change, I would also take that into account and probably not even bother. The fact is, however, that we've done a lot of arguing lately, both in and out of core, about how just running over people's complaints and committing a contraversial change with middle-digit extended is a bad thing, both from a procedural perspective and from the damage it does to interpersonal relations. It also sets the precedent that the best way to silence an argument is to simply commit the code in question over people's objections and move on. It's not even like the debate lasted all that long - 2 days is all it took for Matt to go "screw you guys, I'm committing the change" and that was that. Yeah, I'm annoyed by it, and if the intention was to annoy me enough to commit my own more comprehensive set of changes over Matt's then maybe you guys are more clever than I thought because your plan seems to be working! :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 12:39:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 3760537B416; Sun, 9 Dec 2001 12:39:30 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fB9Kiqe01497; Sun, 9 Dec 2001 12:44:53 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112092044.fB9Kiqe01497@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jordan Hubbard Cc: obrien@FreeBSD.ORG, Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-reply-to: Your message of "Sun, 09 Dec 2001 12:28:32 PST." <38952.1007929712@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 12:44:52 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > It's not even like the debate lasted all that long - 2 days is all > it took for Matt to go "screw you guys, I'm committing the change" > and that was that. I'm not entirely enthused by this. But... > Yeah, I'm annoyed by it, and if the intention was to annoy me enough > to commit my own more comprehensive set of changes over Matt's then > maybe you guys are more clever than I thought because your plan seems > to be working! :) ... this sounds like a better solution is in the works, which is a Good Thing. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 12:50:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by hub.freebsd.org (Postfix) with ESMTP id 194BA37B405 for ; Sun, 9 Dec 2001 12:50:50 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by glatton.cnchost.com id PAA26830; Sun, 9 Dec 2001 15:50:49 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200112092050.PAA26830@glatton.cnchost.com> To: freebsd-arch@FreeBSD.ORG Subject: Real world Root Resizing (was Re: Proposed auto-sizing patch ... Date: Sun, 09 Dec 2001 12:50:49 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Changing sysinstall helps new installations but doesn't help existing systems with a "tiny" root fs -- something I had to fix recently. I was surprised to see how easy it was! Here is the procedure I used, in case anyone else needs to do the same. Assume ad0s1a is the root filesystem and ad0s1b is the swap partition and its size is atleast new root fs size + old root fs size. Do this as single user on a freshly booted system. 1. disklabel ad0s1 > label # save a copy of the disklabel 2. disklabel -e ad0s1 if the new root size is N, change the b partition to start at offset N. make its size the same as partition a and make its type 4.2BSD type. 3. dd /dev/ad0s1b bs=1m 4. fsck /dev/ad0s1b 5. echo 'boot_askname="YES"' >> /boot/loader.conf 6. shutdown -r now 7. boot in single user mode and when asked, choose the b partition as root. 8. disklabel -e ad0s1 change 'a' partition size to N. 9. growfs -s N /dev/ad0s1a 10. fsck /dev/ad0s1a # just to convince yourself everything is okay 11. shutdown -r now 12. boot in single user mode and when aske, choose the a partition as root. 13. disklabel -e ad0s1 restore the swap partition (to its new reduced size) 14. remove the change to /boot/loader.conf made in step 5. 15. reboot If there is an easier way, I'd like to hear about it. In particular if / can be switched at runtime, all of this can be done in one program without so many reboots. One can even write a program to shuffle filesystems around to grow any fs so long as there is some space somewhere! Disclaimer: use at your own risk. make backups and keep a cleenex handy in case you screw up. make notes while doing this to aid in debugging in case things go wrong. growfs should take an optional argument -A (for Auto :-) to grow a fs to fill up the partition. growfs needs to be renamed grow_ufs in case in future growfs is extended to grow other fs types. Ditto for newfs, dumpfs, tunafish and so on. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 12:56:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C494137B419; Sun, 9 Dec 2001 12:56:33 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fB9KuXY39015; Sun, 9 Dec 2001 12:56:33 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 12:56:33 -0800 (PST) From: Matthew Dillon Message-Id: <200112092056.fB9KuXY39015@apollo.backplane.com> To: Greg Lehey , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.org Subject: Auto-resize-on-delete patch References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209165725.D83634@monorchid.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This patch is relatve to -current. Note: This patch also contains changes required to test with the "md" device which will not be in the final committed patch. I haven't tested it much yet, but it appears to work visually. This patch will collapse a 'D'eleted partition's space into the previous partition. For example, removing /var/tmp collapses that space into /var, removing /home collapses that space into /usr. This patch only collapses space into an auto-created partition. It will not extend a manually created partition. I still have some work to do... I need to add a NEWFS flag to libdisk so the code only extends partitions which are marked for NEWFSing (at the moment limiting it to auto-created partitions is good enough for testing purposes). -Matt Index: lib/libdisk/chunk.c =================================================================== RCS file: /home/ncvs/src/lib/libdisk/chunk.c,v retrieving revision 1.28 diff -u -r1.28 chunk.c --- lib/libdisk/chunk.c 2001/09/30 21:16:57 1.28 +++ lib/libdisk/chunk.c 2001/12/09 20:48:57 @@ -363,6 +363,7 @@ { struct chunk *c1=0, *c2, *c3; chunk_e type = c->type; + long offset = c->offset; if(type == whole) return 1; @@ -398,9 +399,18 @@ } return 1; scan: + /* + * Collapse multiple unused elements together, and attempt + * to extend the previous chunk into the freed chunk. + */ for(c2 = c1->part; c2; c2 = c2->next) { - if (c2->type != unused) - continue; + if (c2->type != unused) { + if (c2->offset + c2->size != offset || + (c2->flags & CHUNK_AUTO_SIZE) == 0) { + continue; + } + /* else extend into free area */ + } if (!c2->next) continue; if (c2->next->type != unused) Index: lib/libdisk/disk.c =================================================================== RCS file: /home/ncvs/src/lib/libdisk/disk.c,v retrieving revision 1.72 diff -u -r1.72 disk.c --- lib/libdisk/disk.c 2001/10/15 07:25:29 1.72 +++ lib/libdisk/disk.c 2001/12/09 20:48:16 @@ -478,9 +478,9 @@ #endif #ifdef PC98 -static char * device_list[] = {"wd", "aacd", "ad", "da", "afd", "fla", "idad", "mlxd", "amrd", "twed", "ar", "fd", 0}; +static char * device_list[] = {"wd", "aacd", "ad", "da", "afd", "fla", "idad", "mlxd", "amrd", "twed", "ar", "fd", "md", 0}; #else -static char * device_list[] = {"aacd", "ad", "da", "afd", "fla", "idad", "mlxd", "amrd", "twed", "ar", "fd", 0}; +static char * device_list[] = {"aacd", "ad", "da", "afd", "fla", "idad", "mlxd", "amrd", "twed", "ar", "fd", "md", 0}; #endif char ** Index: lib/libdisk/libdisk.h =================================================================== RCS file: /home/ncvs/src/lib/libdisk/libdisk.h,v retrieving revision 1.39 diff -u -r1.39 libdisk.h --- lib/libdisk/libdisk.h 2001/05/13 20:08:54 1.39 +++ lib/libdisk/libdisk.h 2001/12/09 20:36:35 @@ -69,21 +69,6 @@ chunk_e type; int subtype; u_long flags; -# define CHUNK_BSD_COMPAT 2 - /* this chunk is in the BSD-compatibility, and has a - * short name too, ie wd0s4f -> wd0f - */ -# define CHUNK_ALIGN 8 - /* This chunk should be aligned */ -# define CHUNK_IS_ROOT 16 - /* This 'part' is a rootfs, allocate 'a' */ -# define CHUNK_ACTIVE 32 - /* This is the active slice in the MBR */ -# define CHUNK_FORCE_ALL 64 - /* Force a dedicated disk for FreeBSD, bypassing - * all BIOS geometry considerations - */ - void (*private_free)(void*); void *(*private_clone)(void*); void *private_data; @@ -93,6 +78,28 @@ * and freeing will just forget it. */ }; + +/* + * flags: + * + * BSD_COMPAT - This chunk is in the BSD-compatibility, and has + * a short name too, ie wd0s4f -> wd0f + * ALIGN - This chunk should be aligned + * IS_ROOT - This 'part' is a rootfs, allocate 'a' + * ACTIVE - This is the active slice in the MBR + * FORCE_ALL - Force a dedicated disk for FreeBSD, bypassing + * all BIOS geometry considerations + * AUTO_SIZE - This chunk was auto-sized and can fill-out a + * following chunk if the following chunk is deleted. + */ + +#define CHUNK_BSD_COMPAT 0x0002 +#define CHUNK_ALIGN 0x0008 +#define CHUNK_IS_ROOT 0x0010 +#define CHUNK_ACTIVE 0x0020 +#define CHUNK_FORCE_ALL 0x0040 +#define CHUNK_AUTO_SIZE 0x0080 + extern const char *chunk_n[]; Index: usr.sbin/sysinstall/devices.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/devices.c,v retrieving revision 1.137 diff -u -r1.137 devices.c --- usr.sbin/sysinstall/devices.c 30 Sep 2001 00:43:32 -0000 1.137 +++ usr.sbin/sysinstall/devices.c 9 Dec 2001 20:51:21 -0000 @@ -439,9 +439,11 @@ Chunk *c1; Disk *d; +#if 0 /* Ignore memory disks */ if (!strncmp(names[i], "md", 2)) continue; +#endif d = Open_Disk(names[i]); if (!d) { Index: usr.sbin/sysinstall/label.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/label.c,v retrieving revision 1.111 diff -u -r1.111 label.c --- usr.sbin/sysinstall/label.c 9 Dec 2001 09:47:09 -0000 1.111 +++ usr.sbin/sysinstall/label.c 9 Dec 2001 20:51:22 -0000 @@ -1183,8 +1183,9 @@ if (!rootdev) { sz = requested_part_size(VAR_ROOT_SIZE, ROOT_NOMINAL_SIZE, ROOT_DEFAULT_SIZE, perc); - root_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - sz, part, FS_BSDFFS, CHUNK_IS_ROOT); + root_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, sz, part, + FS_BSDFFS, CHUNK_IS_ROOT | CHUNK_AUTO_SIZE); if (!root_chunk) { *req = 1; msg = "Unable to create the root partition. Too big?"; @@ -1212,8 +1213,9 @@ nom = (int)(physmem / 512) / 2; sz = nom + (def - nom) * perc / 100; } - swap_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - sz, part, FS_SWAP, 0); + swap_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, sz, part, + FS_SWAP, CHUNK_AUTO_SIZE); if (!swap_chunk) { *req = 1; msg = "Unable to create the swap partition. Too big?"; @@ -1226,8 +1228,9 @@ if (!vardev) { sz = requested_part_size(VAR_VAR_SIZE, VAR_NOMINAL_SIZE, VAR_DEFAULT_SIZE, perc); - var_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); + var_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, sz, part, + FS_BSDFFS, CHUNK_AUTO_SIZE); if (!var_chunk) { *req = 1; msg = "Not enough free space for /var - you will need to\n" @@ -1241,8 +1244,9 @@ if (!vartmpdev && !variable_get(VAR_NO_VARTMP)) { sz = requested_part_size(VAR_VARTMP_SIZE, VARTMP_NOMINAL_SIZE, VARTMP_DEFAULT_SIZE, perc); - vartmp_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); + vartmp_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, + label_chunk_info[here].c, sz, part, + FS_BSDFFS, CHUNK_AUTO_SIZE); if (!vartmp_chunk) { *req = 1; msg = "Not enough free space for /var/tmp - you will need to\n" @@ -1266,8 +1270,8 @@ } usr_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, - label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); + label_chunk_info[here].c, sz, part, + FS_BSDFFS, CHUNK_AUTO_SIZE); if (!usr_chunk) { msg = "Unable to create the /usr partition. Not enough space?\n" "You will need to partition your disk manually with a custom install!"; @@ -1291,8 +1295,8 @@ } home_chunk = Create_Chunk_DWIM(label_chunk_info[here].c->disk, - label_chunk_info[here].c, - sz, part, FS_BSDFFS, 0); + label_chunk_info[here].c, sz, part, + FS_BSDFFS, CHUNK_AUTO_SIZE); if (!home_chunk) { msg = "Unable to create the /home partition. Not enough space?\n" "You will need to partition your disk manually with a custom install!"; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 15:23:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 2CB8C37B416 for ; Sun, 9 Dec 2001 15:23:32 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id fB9NNTT36930; Sun, 9 Dec 2001 15:23:29 -0800 (PST) (envelope-from obrien) Date: Sun, 9 Dec 2001 15:23:29 -0800 From: "David O'Brien" To: Jordan Hubbard Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <20011209152329.C92399@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <38952.1007929712@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <38952.1007929712@winston.freebsd.org>; from jkh@winston.freebsd.org on Sun, Dec 09, 2001 at 12:28:32PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Dec 09, 2001 at 12:28:32PM -0800, Jordan Hubbard wrote: > Yeah, I'm annoyed by it, and if the intention was to annoy me enough > to commit my own more comprehensive set of changes over Matt's then > maybe you guys are more clever than I thought because your plan seems > to be working! :) I would love to see the functionality mentioned in your earlier email. You above many others, know what Sysinstall (and that type of application) should be. I've wished for a very long time, we could remove the external demands on you, send you to the back country of your choice with a laptop or two and a really slow Internet connection -- just good enough for you to send an "all done!" email. :-) Maybe Santa will grant this for Xmas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 15:47:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E6A3937B41B; Sun, 9 Dec 2001 15:47:41 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA24917; Sun, 9 Dec 2001 16:47:39 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fB9NlT585442; Sun, 9 Dec 2001 16:47:29 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15379.63504.607656.273730@caddis.yogotech.com> Date: Sun, 9 Dec 2001 16:47:28 -0700 To: Matthew Dillon Cc: Greg Lehey , Jordan Hubbard , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch In-Reply-To: <200112092056.fB9KuXY39015@apollo.backplane.com> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209165725.D83634@monorchid.lemis.com> <200112092056.fB9KuXY39015@apollo.backplane.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > This patch is relatve to -current. Note: This patch also contains > changes required to test with the "md" device which will not be in the > final committed patch. > > I haven't tested it much yet, but it appears to work visually. This > patch will collapse a 'D'eleted partition's space into the previous > partition. For example, removing /var/tmp collapses that space into /var, > removing /home collapses that space into /usr. FWIW, I *like* this feature very much. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 15:57: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3D83237B417; Sun, 9 Dec 2001 15:57:01 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id B729281D01; Sun, 9 Dec 2001 17:56:55 -0600 (CST) Date: Sun, 9 Dec 2001 17:56:55 -0600 From: Alfred Perlstein To: Nate Williams Cc: Matthew Dillon , Greg Lehey , Jordan Hubbard , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch Message-ID: <20011209175655.S92148@elvis.mu.org> References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209165725.D83634@monorchid.lemis.com> <200112092056.fB9KuXY39015@apollo.backplane.com> <15379.63504.607656.273730@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15379.63504.607656.273730@caddis.yogotech.com>; from nate@yogotech.com on Sun, Dec 09, 2001 at 04:47:28PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Nate Williams [011209 17:47] wrote: > > This patch is relatve to -current. Note: This patch also contains > > changes required to test with the "md" device which will not be in the > > final committed patch. > > > > I haven't tested it much yet, but it appears to work visually. This > > patch will collapse a 'D'eleted partition's space into the previous > > partition. For example, removing /var/tmp collapses that space into /var, > > removing /home collapses that space into /usr. > > FWIW, I *like* this feature very much. :) Ugh no way! Make it a seperate key or something, it's nice but it's not an adequite reaplcement for 'delete' . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 16:12:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3686C37B405; Sun, 9 Dec 2001 16:12:31 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA0CT741394; Sun, 9 Dec 2001 16:12:29 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 16:12:29 -0800 (PST) From: Matthew Dillon Message-Id: <200112100012.fBA0CT741394@apollo.backplane.com> To: Alfred Perlstein Cc: Nate Williams , Greg Lehey , Jordan Hubbard , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch References: <49294.1007846108@winston.freebsd.org> <200112082211.fB8MBGm18685@apollo.backplane.com> <20011209165725.D83634@monorchid.lemis.com> <200112092056.fB9KuXY39015@apollo.backplane.com> <15379.63504.607656.273730@caddis.yogotech.com> <20011209175655.S92148@elvis.mu.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :> FWIW, I *like* this feature very much. :) : :Ugh no way! Make it a seperate key or something, it's nice :but it's not an adequite reaplcement for 'delete' :. Try it. build/install libdisk and sysinstall on -current and try it. You won't screw up your system unless you actually commit :-). Just go into sysinstall, select your hard disk, 'D'elete everything, hit 'A'uto, and then play with 'D'elete in the auto'd stuff. Just don't commit it :-) Personally I think it is easy and straightforward, and no complexity to a layperson installing the system. A separate key, or even JKH's idea adds unnecessary complexity (though I am partial to having partitioning templates, I think it's overkill for sysinstall because it is simply not possible to cover all our bases for the more experienced developers we would be targeting). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 16:44:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 0367E37B41D; Sun, 9 Dec 2001 16:44:27 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBA0i7q39830; Sun, 9 Dec 2001 16:44:07 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: obrien@FreeBSD.ORG Cc: Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from "David O'Brien" of "Sun, 09 Dec 2001 15:23:29 PST." <20011209152329.C92399@dragon.nuxi.com> Date: Sun, 09 Dec 2001 16:44:07 -0800 Message-ID: <39825.1007945047@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I would love to see the functionality mentioned in your earlier email. > You above many others, know what Sysinstall (and that type of > application) should be. I've wished for a very long time, we could > remove the external demands on you, send you to the back country of your > choice with a laptop or two and a really slow Internet connection -- just > good enough for you to send an "all done!" email. :-) > > Maybe Santa will grant this for Xmas? I think so. I'm making good progress on it and should have something for review later on tonite. I've completely gutted and re-written the auto-sizing code and there's hardly a #define to be seen in there now. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 16:45:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 0B1AB37B416; Sun, 9 Dec 2001 16:45:20 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBA0iuq39847; Sun, 9 Dec 2001 16:44:56 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: nate@yogotech.com (Nate Williams) Cc: Matthew Dillon , Greg Lehey , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch In-Reply-To: Message from Nate Williams of "Sun, 09 Dec 2001 16:47:28 MST." <15379.63504.607656.273730@caddis.yogotech.com> Date: Sun, 09 Dec 2001 16:44:56 -0800 Message-ID: <39843.1007945096@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > FWIW, I *like* this feature very much. :) Good, since I have both this and resizing on the feature list. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 16:46:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 51D9237B405; Sun, 9 Dec 2001 16:46:33 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBA0k8q39872; Sun, 9 Dec 2001 16:46:08 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Alfred Perlstein Cc: Nate Williams , Matthew Dillon , Greg Lehey , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch In-Reply-To: Message from Alfred Perlstein of "Sun, 09 Dec 2001 17:56:55 CST." <20011209175655.S92148@elvis.mu.org> Date: Sun, 09 Dec 2001 16:46:08 -0800 Message-ID: <39869.1007945168@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Ugh no way! Make it a seperate key or something, it's nice > but it's not an adequite reaplcement for 'delete' In my version, each filesystem has an optional "buddy" filesystem which inherits its space when it's deleted and the buddy is set to auto-size. Does that make you happier? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 17: 9:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id C52B137B41B for ; Sun, 9 Dec 2001 17:09:37 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 44668786E6; Mon, 10 Dec 2001 11:39:29 +1030 (CST) Date: Mon, 10 Dec 2001 11:39:29 +1030 From: Greg Lehey To: Jordan Hubbard Cc: Alfred Perlstein , Nate Williams , Matthew Dillon , freebsd-arch@FreeBSD.ORG Subject: Re: Auto-resize-on-delete patch Message-ID: <20011210113929.A63585@monorchid.lemis.com> References: <20011209175655.S92148@elvis.mu.org> <39869.1007945168@winston.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39869.1007945168@winston.freebsd.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 16:46:08 -0800, Jordan Hubbard wrote: >> Ugh no way! Make it a seperate key or something, it's nice >> but it's not an adequite reaplcement for 'delete' > > In my version, each filesystem has an optional "buddy" filesystem > which inherits its space when it's deleted and the buddy is set to > auto-size. That sounds more reasonable. > Does that make you happier? Only if you commit it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 17:33:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DD9E637B417; Sun, 9 Dec 2001 17:33:28 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBA1XSx27617; Sun, 9 Dec 2001 20:33:28 -0500 (EST) (envelope-from wollman) Date: Sun, 9 Dec 2001 20:33:28 -0500 (EST) From: Garrett Wollman Message-Id: <200112100133.fBA1XSx27617@khavrinen.lcs.mit.edu> To: nik@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: <20011209104437.A69671@clan.nothing-going-on.org> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Quoting Nik Clayton: >On Sun, Dec 09, 2001 at 04:46:06PM +1030, Greg Lehey wrote: >> Well, since we're all being personal, here's my opinion. [Nik's layout deleted] If we're all going to give our layout plans.... I belong to the old school, but I'll gladly admit that this is very much a comfort issue and hard to empirically justify. Our servers are configured in approximately the following manner: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 126M 48M 68M 42% / ; 128M allocated /dev/da0s1e 504M 75M 388M 16% /var ; 512M allocated /dev/da0s1f 2.0G 969M 886M 52% /usr /dev/da0s1g 2.0G 17M 1.8G 1% /var/spool /dev/da0s1h 6.9G 1.2G 5.1G 19% /home /dev/da0s1d 1.8G 1.3G 375M 78% /home/ncvs The `f' and `d' partitions (which should have been `e' and `h' instead) are assigned to purposes appropriate to the machine; we keep the (mail and print) spools on a separate filesystem because they only contain data which should never be backed up. (Some of the contents of /var is backed up, although not the log files.) /usr would need to be bigger on a workstation, if the user expected to use one of the more piggish graphical environments. (Oh, and swap is 1536 kbytes, or 1.5 times physical memory. Most of these machines never swap except when being attacked.) da0 is a 15-Gbyte volume on our Fibre Channel RAID system. We used to have a quarter-gig for /var, but that ran out during an attack on the previous generation of this setup, so we increased it for this round. We generally copy the partition sizes on all of our servers, because of the way we distribute software to the machines (they all end up with an identical complement). Just for comparison, xyz (cvsup3/ftp5) has the following configuration: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 124M 47M 67M 41% / /dev/da0s1e 504M 99M 365M 21% /var /dev/da0s1f 2.0G 1000M 854M 54% /usr /dev/da0s1g 11G 357M 9.5G 4% /home /dev/da1s1d 3.9G 2.4G 1.2G 67% /u /dev/da1s1e 81G 52G 23G 69% /y /dev/ccd0c 93G 45G 40G 53% /y/ftp/pub/FreeBSD In this example, you can see that we gave most of the space on the RAID 5 to /home, which doesn't get used much anyway. da1 is a RAID-0 volume on the Fibre Channel array, which we split up into /u (for fast access to the cvsup tree) and /y (for slow access to less-popular ftp mirrors). ccd0 is composed of two internal ST150176LCs, striped; the filesystem parameters on that disk are configured to spread the workload over both drives without unnecessarily breaking up large requests (or putting all of the superblocks on a single drive). My workstation is not part of the shared configuration system (it can't be, since it runs -stale^H^H^H^H^Hcurrent). It looks like this: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 124M 73M 41M 64% / /dev/da0s1e 124M 24M 90M 21% /var /dev/da0s1f 1.9G 1.2G 598M 67% /usr /dev/da0s1g 4.9G 800M 3.7G 17% /usr/ports /dev/da0s1h 719M 368M 294M 56% /usr/obj /dev/da1s1d 1008M 562M 365M 61% /usr/src /dev/da1s1e 7.4G 4.7G 2.0G 70% /homes da1 is an old Barracuda 9LP with a narrow interface that I really should replace (since it's slowing down my bus). My / and /usr have seven years' worth of accumulated crap and are perhaps not the best examples. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 17:54:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9B1F337B417 for ; Sun, 9 Dec 2001 17:54:21 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBA1sJ927780; Sun, 9 Dec 2001 20:54:19 -0500 (EST) (envelope-from wollman) Date: Sun, 9 Dec 2001 20:54:19 -0500 (EST) From: Garrett Wollman Message-Id: <200112100154.fBA1sJ927780@khavrinen.lcs.mit.edu> To: jkh@winston.freebsd.org Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <3839.1007891857@winston.freebsd.org> References: Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <3839.1007891857@winston.freebsd.org> you write: >> Sigh. Look, the whole point of 'A'uto is to create a reasonable >> [rant deleted] > >All in your humble opinion, to be sure. I don't agree with it, >however, and enough other people clearly don't agree with it that When I first implemented an `A'uto option, it had one and only one point: to make it possible a bunch of computer scientists who were used to SunOS to install FreeBSD without PC-hardware-expert intervention. Not long after, Paul Traina came up with the scripting features which (IMHO) were a much better way of achieving that goal (since we were already distributing our own FreeBSD installation media, with the `confusing' options ripped out). For some reason, I cannot seem to find the original patch I wrote for this purpose. (I know it didn't go directly into sysinstall -- for one thing, it was not documented, not even on-screen, since I was a total curses loser at the time and didn't want to spend any more time on this particular hack.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18: 9:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 7AA4A37B405 for ; Sun, 9 Dec 2001 18:09:38 -0800 (PST) Received: from pool0370.cvx22-bradley.dialup.earthlink.net ([209.179.199.115] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DFsX-0001Hh-00; Sun, 09 Dec 2001 18:09:14 -0800 Message-ID: <3C141950.E809DED1@mindspring.com> Date: Sun, 09 Dec 2001 18:09:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Sigh. Look, the whole point of 'A'uto is to create a reasonable > setup for a layperson installing a system. It is not there to > cow-tow to a minimalist status-quo. It is there to give a layperson > a reasonable system that does not require him to screw around > with the infrastructure when he does reasonable things, like add an > account for themselves or install a bunch of ports or follow OUR > directions on how to retrieve, compile, and install system source. You guys are all shooting at the symptoms. What is the root cause for wanting to limit the number of partitions, and to autosize them in the first place? I would argue that it's the llack of ability to grow FS's in small sized chunks (and, perhaps, shrink them as well, but that is significantly less important, since we are talking about the installation process). If you could grow FSs in 4M chunks, as AIX can, automatically, and without serious problems (e.g. fragmentation due to layout policy applying equally across old and new chunks, as is the case when you add to an FFS), then this would be a non-issue entirely. Further, I would argue that it would make sense to install each and every software package into its own partition. Not only would this avoid the Windows problem of everyone installing their own version of MSVCRT42.DLL, or the 3D control library that argues about Unicode vs. Ole wchar_t support (and breaks things in the process), it would also make it very easy to do network mounting of particular applications onto workstations, and, if it ever came to it, license management and application access over the Internet. Need an application? Mount it. Each partition would end up being only as large as it needed to be to handle what it needed to handle. This whole idea of "making the defaults reasonable" is predicated on the false idea that fixed defaults are even necessary. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:12:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 47B1137B416; Sun, 9 Dec 2001 18:12:52 -0800 (PST) Received: from pool0370.cvx22-bradley.dialup.earthlink.net ([209.179.199.115] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DFvz-0005Gy-00; Sun, 09 Dec 2001 18:12:48 -0800 Message-ID: <3C141A26.9D8BC688@mindspring.com> Date: Sun, 09 Dec 2001 18:12:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Greg Lehey , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think we are all forgetting that the reason Sun introduced /usr in the first place was to permit / to be NFS mounted as a result of a network boot, and shared -- therefore, read-only. Sun had several configurations: o Fully NFS o Fully local o NFS everything but swap ("dataless") o NFS everyuthing but swap and user data ("workstation") -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:13: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 47B1137B416; Sun, 9 Dec 2001 18:12:52 -0800 (PST) Received: from pool0370.cvx22-bradley.dialup.earthlink.net ([209.179.199.115] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16DFvz-0005Gy-00; Sun, 09 Dec 2001 18:12:48 -0800 Message-ID: <3C141A26.9D8BC688@mindspring.com> Date: Sun, 09 Dec 2001 18:12:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton Cc: Greg Lehey , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think we are all forgetting that the reason Sun introduced /usr in the first place was to permit / to be NFS mounted as a result of a network boot, and shared -- therefore, read-only. Sun had several configurations: o Fully NFS o Fully local o NFS everything but swap ("dataless") o NFS everyuthing but swap and user data ("workstation") -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:15: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 47D8D37B405; Sun, 9 Dec 2001 18:15:00 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 65684786E7; Mon, 10 Dec 2001 12:44:58 +1030 (CST) Date: Mon, 10 Dec 2001 12:44:58 +1030 From: Greg Lehey To: Terry Lambert Cc: Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011210124458.B63585@monorchid.lemis.com> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C141A26.9D8BC688@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 18:12:54 -0800, Terry Lambert wrote: > I think we are all forgetting that the reason Sun introduced /usr /var? > in the first place was to permit / to be NFS mounted as a result > of a network boot, and shared -- therefore, read-only. Well, I'm not forgetting this, I didn't know it. But it seems to make sense. This was one of the things I mentioned earlier. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:15: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 47D8D37B405; Sun, 9 Dec 2001 18:15:00 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 65684786E7; Mon, 10 Dec 2001 12:44:58 +1030 (CST) Date: Mon, 10 Dec 2001 12:44:58 +1030 From: Greg Lehey To: Terry Lambert Cc: Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011210124458.B63585@monorchid.lemis.com> References: <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C141A26.9D8BC688@mindspring.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 9 December 2001 at 18:12:54 -0800, Terry Lambert wrote: > I think we are all forgetting that the reason Sun introduced /usr /var? > in the first place was to permit / to be NFS mounted as a result > of a network boot, and shared -- therefore, read-only. Well, I'm not forgetting this, I didn't know it. But it seems to make sense. This was one of the things I mentioned earlier. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:20:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 32AE937B41B for ; Sun, 9 Dec 2001 18:20:22 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA2KLh42688; Sun, 9 Dec 2001 18:20:21 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 18:20:21 -0800 (PST) From: Matthew Dillon Message-Id: <200112100220.fBA2KLh42688@apollo.backplane.com> To: Terry Lambert Cc: Jordan Hubbard , Bernd Walter , Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <50925.1007888526@winston.freebsd.org> <200112090941.fB99fGV36341@apollo.backplane.com> <3C141950.E809DED1@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG (Matt places hands on face and slowly drags them down, with appropriate sound effects) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:38:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id B08CE37B41B for ; Sun, 9 Dec 2001 18:38:28 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011210023818.QDZO5859.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Mon, 10 Dec 2001 02:38:18 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBA2cSs32238 for ; Sun, 9 Dec 2001 18:38:28 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 15C963810; Sun, 9 Dec 2001 18:38:28 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <200112100220.fBA2KLh42688@apollo.backplane.com> Date: Sun, 09 Dec 2001 18:38:28 -0800 From: Peter Wemm Message-Id: <20011210023828.15C963810@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > (Matt places hands on face and slowly drags them down, with appropriate > sound effects) While on the subject, we could do what VXFS (an extent-based filesystem, vaguely like variable block sizes) does and auto-allocate inodes on the fly. That would solve the fixed number of inodes part of this problem. (Yes, I am kidding :-). Seriously though, I like the concept but I wonder if it would be better query the user.. ie: something like: "(D)elete this partition or (M)erge the space into parent?" Otherwise it becomes harder to delete /home, carve out some space for something and recreate a new slightly smaller /home. BTW#2: I dont think there is any reason why we cant use the 'd' partition anymore, is there? There does not seem to be any leftover magic gunk that maps this onto the 'dos' fdisk partition anywhere that I can find. We may have had a magic 'd' for FreeBSD-1.x or 2.0, but I'm quite sure it died well before 2.1.0. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 18:53:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C36CD37B417 for ; Sun, 9 Dec 2001 18:53:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBA2rHk42937; Sun, 9 Dec 2001 18:53:17 -0800 (PST) (envelope-from dillon) Date: Sun, 9 Dec 2001 18:53:17 -0800 (PST) From: Matthew Dillon Message-Id: <200112100253.fBA2rHk42937@apollo.backplane.com> To: Peter Wemm Cc: Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <20011210023828.15C963810@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :BTW#2: I dont think there is any reason why we cant use the 'd' partition :anymore, is there? There does not seem to be any leftover magic gunk that We can use the 'd' partition (and have been able to use it for many years). sysinstall is rather annoying in that regard. -Matt :maps this onto the 'dos' fdisk partition anywhere that I can find. We :may have had a magic 'd' for FreeBSD-1.x or 2.0, but I'm quite sure it :died well before 2.1.0. : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 21:39:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 93A3437B405; Sun, 9 Dec 2001 21:39:31 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA10014; Mon, 10 Dec 2001 16:39:25 +1100 Date: Mon, 10 Dec 2001 16:40:04 +1100 (EST) From: Bruce Evans X-X-Sender: To: Robert Watson Cc: Subject: Re: Default value for maxusers In-Reply-To: Message-ID: <20011210163742.N27402-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 7 Dec 2001, Robert Watson wrote: > It seems rediculous to have a default that is known to be inadequate (or > worse, "incredibly low"). I have to admit that the first thing I do with It is only "incredibly low" for some users. It is credibly high for me. I still use the old default of 10 and haven't had any problems, but I don't run much bloatware. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Dec 9 21:45:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id DA8F337B416; Sun, 9 Dec 2001 21:45:40 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id VAA04319; Sun, 9 Dec 2001 21:45:36 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda04317; Sun Dec 9 21:45:21 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.6/8.9.1) id fBA5jFA00533; Sun, 9 Dec 2001 21:45:15 -0800 (PST) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdfsw531; Sun Dec 9 21:45:07 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.6/8.9.1) id fBA5j6H74570; Sun, 9 Dec 2001 21:45:06 -0800 (PST) Message-Id: <200112100545.fBA5j6H74570@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdx74542; Sun Dec 9 21:45:04 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Bruce Evans Cc: Robert Watson , arch@FreeBSD.ORG Subject: Re: Default value for maxusers In-reply-to: Your message of "Mon, 10 Dec 2001 16:40:04 +1100." <20011210163742.N27402-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Dec 2001 21:45:04 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011210163742.N27402-100000@gamplex.bde.org>, Bruce Evans writes: > On Fri, 7 Dec 2001, Robert Watson wrote: > > > It seems rediculous to have a default that is known to be inadequate (or > > worse, "incredibly low"). I have to admit that the first thing I do with > > It is only "incredibly low" for some users. It is credibly high for me. > I still use the old default of 10 and haven't had any problems, but I > don't run much bloatware. Same here. I use 10 on 3 machines and 20 on the rest. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 0:30:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 7EA0B37B41F for ; Mon, 10 Dec 2001 00:30:05 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16DLpz-000Dc5-00; Mon, 10 Dec 2001 10:30:59 +0200 From: Sheldon Hearn To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-reply-to: Your message of "Fri, 07 Dec 2001 19:49:32 PST." <200112080349.fB83nWU00292@apollo.backplane.com> Date: Mon, 10 Dec 2001 10:30:59 +0200 Message-ID: <52332.1007973059@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 07 Dec 2001 19:49:32 PST, Matthew Dillon wrote: > Ok, I've finally gone and done it... cleaned up the sysinstall > 'Auto' option. :-) You complained about considered responses, so I hope you find this refreshing, since I've mulled over it for a week-end. I think the way forward with automatic partitioning is simple: the scheme selected should be based on the intended role of the system. By this, I mean that "Auto" needs to know at least whether the system will be a workstation or a server. You might want to make further distinctions. However, _some_ kind of distinction is required for an intelligent "Auto" scheme. Consider that someone using XFree86 and StarOffice probably wants a completely different scheme from what I want when I set up a mail server. The latter requires as much space as possible in /var, while the former probably wants as much space as possible in /usr (and /home if /home is not a symlink). While I'm glad that you're interested in this, and looking to improve the status quo, I don't think you can do so without the introduction of role-based decision-making. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 1:33:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 985B737B416 for ; Mon, 10 Dec 2001 01:33:40 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16DMqE-000DtB-00; Mon, 10 Dec 2001 11:35:18 +0200 From: Sheldon Hearn To: Kirk McKusick Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Fri, 07 Dec 2001 11:12:57 PST." <200112071913.fB7JCvf29494@beastie.mckusick.com> Date: Mon, 10 Dec 2001 11:35:18 +0200 Message-ID: <53392.1007976918@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 07 Dec 2001 11:12:57 PST, Kirk McKusick wrote: > FYA, we had this same debate a bit over a decade ago when we changed > the default from 4K/512 to 8K/1K. Obviously, we decided not to > special case small filesystems then despite great hand-wringing over > what would happen... Thanks. This takes a load off my shoulders with respect to our tendency to repeat our mistakes in ignorance of our history. :-) Here's what I intend to commit. Ciao, Sheldon. Index: share/man/man7/tuning.7 =================================================================== RCS file: /home/ncvs/src/share/man/man7/tuning.7,v retrieving revision 1.29 diff -u -d -r1.29 tuning.7 --- share/man/man7/tuning.7 7 Dec 2001 18:17:37 -0000 1.29 +++ share/man/man7/tuning.7 10 Dec 2001 09:23:48 -0000 @@ -199,19 +199,29 @@ .Pp .Fx performs best when using 8K or 16K filesystem block sizes. -The default filesystem block size is 8K. -For larger partitions it is usually a good -idea to use a 16K block size. -This also requires you to specify a larger +The default filesystem block size is 16K, +which provides best performance for most applications, +with the exception of those that perform random access on large files +(such as database server software). +Such applications tend to perform better with a smaller block size, +although modern disk characteristics are such that the performance +gain from using a smaller block size may not be worth consideration. +Using a block size larger than 16K +can cause fragmentation of the buffer cache and +lead to lower performance. +.Pp +The defaults may be unsuitable +for a filesystem that requires a very large number of inodes +or is intended to hold a large number of very small files. +Such a filesystem should be created with an 8K or 4K block size. +This also requires you to specify a smaller fragment size. We recommend always using a fragment size that is 1/8 the block size (less testing has been done on other fragment size factors). The .Xr newfs 8 options for this would be -.Dq Li "newfs -f 2048 -b 16384 ..." . -Using a larger block size can cause fragmentation of the buffer cache and -lead to lower performance. +.Dq Li "newfs -f 1024 -b 8192 ..." . .Pp If a large partition is intended to be used to hold fewer, larger files, such as a database files, you can increase the Index: sbin/newfs/newfs.8 =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.8,v retrieving revision 1.47 diff -u -d -r1.47 newfs.8 --- sbin/newfs/newfs.8 7 Dec 2001 13:18:28 -0000 1.47 +++ sbin/newfs/newfs.8 10 Dec 2001 09:11:49 -0000 @@ -110,7 +110,7 @@ for more details on how to set this option. .It Fl b Ar block-size The block size of the file system, in bytes. It must be a power of 2. The -default size is 8192 bytes, and the smallest allowable size is 4096 bytes. +default size is 16384 bytes, and the smallest allowable size is 4096 bytes. The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce unpredictable results. @@ -141,7 +141,7 @@ .Ar blocksize Ns /8 and .Ar blocksize . -The default is 1024 bytes. +The default is 2048 bytes. .It Fl g Ar avgfilesize The expected average file size for the file system. .It Fl h Ar avgfpdir @@ -271,15 +271,19 @@ bad sector allocation. .El .Sh EXAMPLES -.Dl newfs -b 16384 -f 2048 /dev/ad3s1a +.Dl newfs /dev/ad3s1a .Pp Creates a new ufs file system on .Pa ad3s1a . .Nm will use a block size of 16384 bytes, a fragment size of 2048 bytes and the largest possible number of cylinders per group. -These values tend to produce better performance than the defaults -for most applications. +These values tend to produce better performance for most applications +than the historical defaults +(8192 byte block size and 1024 byte fragment size). +This large fragment size +may lead to large amounts of wasted space +on filesystems that contain a large number of small files. .Sh SEE ALSO .Xr fdformat 1 , .Xr disktab 5 , Index: sbin/newfs/newfs.c =================================================================== RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v retrieving revision 1.45 diff -u -d -r1.45 newfs.c --- sbin/newfs/newfs.c 3 Nov 2001 08:35:11 -0000 1.45 +++ sbin/newfs/newfs.c 7 Dec 2001 15:09:18 -0000 @@ -98,8 +98,8 @@ * sectorsize <= DESFRAGSIZE <= DESBLKSIZE * DESBLKSIZE / DESFRAGSIZE <= 8 */ -#define DFL_FRAGSIZE 1024 -#define DFL_BLKSIZE 8192 +#define DFL_FRAGSIZE 2048 +#define DFL_BLKSIZE 16384 /* * Cylinder groups may have up to many cylinders. The actual Index: usr.sbin/sysinstall/install.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/sysinstall/install.c,v retrieving revision 1.312 diff -u -d -r1.312 install.c --- usr.sbin/sysinstall/install.c 9 Dec 2001 09:47:09 -0000 1.312 +++ usr.sbin/sysinstall/install.c 10 Dec 2001 00:20:21 -0000 @@ -1121,7 +1121,7 @@ variable_set2(SYSTEM_STATE, "update", 0); else variable_set2(SYSTEM_STATE, "init", 0); - variable_set2(VAR_NEWFS_ARGS, "-b 8192 -f 1024", 0); + variable_set2(VAR_NEWFS_ARGS, "", 0); variable_set2(VAR_CONSTERM, "NO", 0); return DITEM_SUCCESS; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 1:47:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 066BA37B416; Mon, 10 Dec 2001 01:47:11 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16DN31-000E5u-00; Mon, 10 Dec 2001 11:48:31 +0200 From: Sheldon Hearn To: nate@yogotech.com (Nate Williams) Cc: Matthew Dillon , Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Re: Patch for auto-default value for maxusers In-reply-to: Your message of "Sat, 08 Dec 2001 17:54:06 MST." <15378.46638.217290.407771@caddis.yogotech.com> Date: Mon, 10 Dec 2001 11:48:30 +0200 Message-ID: <54181.1007977710@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 08 Dec 2001 17:54:06 MST, Nate Williams wrote: > > + /* printf("maxusers not specified; will auto-size\n"); */ > > + maxusers = 0; > > Isn't this line kind of redundant, since we already know that maxusers == 0? I actually like this, because it clues me in if I think I've set maxusers, but haven't (or didn't do it properly). Of course, I'd like it to actually tell me _what_ value it auto-sized to. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 3:52:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id 389DE37B419 for ; Mon, 10 Dec 2001 03:52:03 -0800 (PST) Received: (qmail 83676 invoked from network); 10 Dec 2001 11:51:51 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.179]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 11:51:51 -0000 Message-ID: <3C14A144.B3B365E5@pipeline.ch> Date: Mon, 10 Dec 2001 12:49:24 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Kirk McKusick , Robert Watson , arch@FreeBSD.ORG Subject: Re: Patch for auto-default value for maxusers References: <200112071957.fB7Jvef29774@beastie.mckusick.com> <200112082256.fB8MuwL19001@apollo.backplane.com> <200112082340.fB8NeI329704@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > This patch is against -stable. It allows maxusers to be set to 0 in > the kernel config. It will scale maxusers according to main > memory, one per megabyte of main memory with a minimum of 32 and > a maximum of 512. > > I did some preliminary testing of this patch (note: it also includes > a page->kbyte fix for nbuf sizing). I had to reorder init_param() > a bit because it was being called prior to physical memory sizing. > A review of that would be nice. Sorry, but my vote would go to Mike Silbersack's version of this because he also takes care of adjusting the relations of the individual values to each other. -- Andre > -Matt > > Index: usr.sbin/config/mkoptions.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/config/mkoptions.c,v > retrieving revision 1.17.2.2 > diff -u -r1.17.2.2 mkoptions.c > --- usr.sbin/config/mkoptions.c 2000/11/21 20:03:38 1.17.2.2 > +++ usr.sbin/config/mkoptions.c 2001/12/08 23:26:16 > @@ -93,8 +93,8 @@ > } else > up = &users[machine - 1]; > if (maxusers == 0) { > - printf("maxusers not specified; %d assumed\n", up->u_default); > - maxusers = up->u_default; > + /* printf("maxusers not specified; will auto-size\n"); */ > + maxusers = 0; > } else if (maxusers < up->u_min) { > printf("minimum of %d maxusers assumed\n", up->u_min); > maxusers = up->u_min; > Index: sys/alpha/alpha/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/alpha/alpha/machdep.c,v > retrieving revision 1.68.2.14 > diff -u -r1.68.2.14 machdep.c > --- sys/alpha/alpha/machdep.c 2001/10/04 13:09:36 1.68.2.14 > +++ sys/alpha/alpha/machdep.c 2001/12/08 23:12:38 > @@ -329,13 +329,14 @@ > */ > > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -698,7 +699,7 @@ > kern_envp = bootinfo.envp; > > /* Do basic tuning, hz etc */ > - init_param(); > + init_param1(); > > /* > * Initalize the (temporary) bootstrap console interface, so > @@ -1004,6 +1005,7 @@ > physmem -= (sz - nsz); > } > } > + init_param2(physmem); > > /* > * Initialize error message buffer (at end of core). > Index: sys/i386/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v > retrieving revision 1.385.2.20 > diff -u -r1.385.2.20 machdep.c > --- sys/i386/i386/machdep.c 2001/10/02 23:34:22 1.385.2.20 > +++ sys/i386/i386/machdep.c 2001/12/08 23:11:09 > @@ -331,13 +331,14 @@ > * factor represents the 1/4 x ram conversion. > */ > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -1829,7 +1830,7 @@ > kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; > > /* Init basic tunables, hz etc */ > - init_param(); > + init_param1(); > > /* > * make gdt memory segments, the code segment goes up to end of the > @@ -1963,6 +1964,7 @@ > > vm86_initialize(); > getmemsize(first); > + init_param2(physmem); > > /* now running on new page tables, configured,and u/iom is accessible */ > > Index: sys/kern/subr_param.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/subr_param.c,v > retrieving revision 1.42.2.3 > diff -u -r1.42.2.3 subr_param.c > --- sys/kern/subr_param.c 2001/11/03 01:41:08 1.42.2.3 > +++ sys/kern/subr_param.c 2001/12/08 23:28:49 > @@ -98,33 +98,16 @@ > struct buf *swbuf; > > /* > - * Boot time overrides > + * Boot time overrides that are not scaled against main memory > */ > void > -init_param(void) > +init_param1(void) > { > - > - /* Base parameters */ > - maxusers = MAXUSERS; > - TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > hz = HZ; > TUNABLE_INT_FETCH("kern.hz", &hz); > tick = 1000000 / hz; > tickadj = howmany(30000, 60 * hz); /* can adjust 30ms in 60s */ > > - /* The following can be overridden after boot via sysctl */ > - maxproc = NPROC; > - TUNABLE_INT_FETCH("kern.maxproc", &maxproc); > - maxfiles = MAXFILES; > - TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); > - maxprocperuid = maxproc - 1; > - maxfilesperproc = maxfiles; > - > - /* Cannot be changed after boot */ > - nsfbufs = NSFBUFS; > - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > - nbuf = NBUF; > - TUNABLE_INT_FETCH("kern.nbuf", &nbuf); > #ifdef VM_SWZONE_SIZE_MAX > maxswzone = VM_SWZONE_SIZE_MAX; > #endif > @@ -133,8 +116,6 @@ > maxbcache = VM_BCACHE_SIZE_MAX; > #endif > TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache); > - ncallout = 16 + maxproc + maxfiles; > - TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > > maxtsiz = MAXTSIZ; > TUNABLE_QUAD_FETCH("kern.maxtsiz", &maxtsiz); > @@ -149,3 +130,45 @@ > sgrowsiz = SGROWSIZ; > TUNABLE_QUAD_FETCH("kern.sgrowsiz", &sgrowsiz); > } > + > +/* > + * Boot time overrides that are scaled against main memory > + */ > +void > +init_param2(int physpages) > +{ > + > + /* Base parameters */ > + if ((maxusers = MAXUSERS) == 0) { > + maxusers = physpages / (1024 * 1024 / PAGE_SIZE); > + if (maxusers < 32) > + maxusers = 32; > + if (maxusers > 512) > + maxusers = 512; > + } > + TUNABLE_INT_FETCH("kern.maxusers", &maxusers); > + > + /* > + * The following can be overridden after boot via sysctl. Note: > + * unless overriden, these macros are ultimately based on maxusers. > + */ > + maxproc = NPROC; > + TUNABLE_INT_FETCH("kern.maxproc", &maxproc); > + maxfiles = MAXFILES; > + TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles); > + maxprocperuid = maxproc - 1; > + maxfilesperproc = maxfiles; > + > + /* > + * Cannot be changed after boot. Unless overriden, NSFBUFS is based > + * on maxusers and NBUF is typically 0 (auto-sized later). > + */ > + nsfbufs = NSFBUFS; > + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > + nbuf = NBUF; > + TUNABLE_INT_FETCH("kern.nbuf", &nbuf); > + > + ncallout = 16 + maxproc + maxfiles; > + TUNABLE_INT_FETCH("kern.ncallout", &ncallout); > +} > + > Index: sys/pc98/i386/machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/pc98/i386/machdep.c,v > retrieving revision 1.151.2.23 > diff -u -r1.151.2.23 machdep.c > --- sys/pc98/i386/machdep.c 2001/10/08 03:29:43 1.151.2.23 > +++ sys/pc98/i386/machdep.c 2001/12/08 23:13:11 > @@ -344,13 +344,14 @@ > * factor represents the 1/4 x ram conversion. > */ > if (nbuf == 0) { > - int factor = 4 * BKVASIZE / PAGE_SIZE; > + int factor = 4 * BKVASIZE / 1024; > + int kbytes = physmem * (PAGE_SIZE / 1024); > > nbuf = 50; > - if (physmem > 1024) > - nbuf += min((physmem - 1024) / factor, 16384 / factor); > - if (physmem > 16384) > - nbuf += (physmem - 16384) * 2 / (factor * 5); > + if (kbytes > 4096) > + nbuf += min((kbytes - 4096) / factor, 65536 / factor); > + if (kbytes > 65536) > + nbuf += (kbytes - 65536) * 2 / (factor * 5); > if (maxbcache && nbuf > maxbcache / BKVASIZE) > nbuf = maxbcache / BKVASIZE; > } > @@ -1880,7 +1881,7 @@ > kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; > > /* Init basic tunables, hz etc */ > - init_param(); > + init_param1(); > > /* > * make gdt memory segments, the code segment goes up to end of the > @@ -2014,6 +2015,7 @@ > > vm86_initialize(); > getmemsize(first); > + init_param2(physmem); > > /* now running on new page tables, configured,and u/iom is accessible */ > > Index: sys/sys/systm.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/systm.h,v > retrieving revision 1.111.2.11 > diff -u -r1.111.2.11 systm.h > --- sys/sys/systm.h 2001/12/04 05:57:40 1.111.2.11 > +++ sys/sys/systm.h 2001/12/08 23:13:35 > @@ -126,7 +126,8 @@ > > void cpu_boot __P((int)); > void cpu_rootconf __P((void)); > -void init_param __P((void)); > +void init_param1 __P((void)); > +void init_param2 __P((int physpages)); > void tablefull __P((const char *)); > int addlog __P((const char *, ...)) __printflike(1, 2); > int kvprintf __P((char const *, void (*)(int, void*), void *, int, > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 9:42:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2526037B417 for ; Mon, 10 Dec 2001 09:42:26 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAHfnB47140; Mon, 10 Dec 2001 09:41:49 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 09:41:49 -0800 (PST) From: Matthew Dillon Message-Id: <200112101741.fBAHfnB47140@apollo.backplane.com> To: Sheldon Hearn Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems References: <53392.1007976918@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Looks good to me! -Matt :On Fri, 07 Dec 2001 11:12:57 PST, Kirk McKusick wrote: : :> FYA, we had this same debate a bit over a decade ago when we changed :> the default from 4K/512 to 8K/1K. Obviously, we decided not to :> special case small filesystems then despite great hand-wringing over :> what would happen... : :Thanks. This takes a load off my shoulders with respect to our tendency :to repeat our mistakes in ignorance of our history. :-) : :Here's what I intend to commit. : :Ciao, :Sheldon. : :Index: share/man/man7/tuning.7 :=================================================================== :RCS file: /home/ncvs/src/share/man/man7/tuning.7,v :retrieving revision 1.29 :diff -u -d -r1.29 tuning.7 :--- share/man/man7/tuning.7 7 Dec 2001 18:17:37 -0000 1.29 :+++ share/man/man7/tuning.7 10 Dec 2001 09:23:48 -0000 :@@ -199,19 +199,29 @@ : .Pp : .Fx : performs best when using 8K or 16K filesystem block sizes. :-The default filesystem block size is 8K. :-For larger partitions it is usually a good :-idea to use a 16K block size. :-This also requires you to specify a larger :+The default filesystem block size is 16K, :+which provides best performance for most applications, :+with the exception of those that perform random access on large files :+(such as database server software). :+Such applications tend to perform better with a smaller block size, :+although modern disk characteristics are such that the performance :+gain from using a smaller block size may not be worth consideration. :+Using a block size larger than 16K :+can cause fragmentation of the buffer cache and :+lead to lower performance. :+.Pp :+The defaults may be unsuitable :+for a filesystem that requires a very large number of inodes :+or is intended to hold a large number of very small files. :+Such a filesystem should be created with an 8K or 4K block size. :+This also requires you to specify a smaller : fragment size. : We recommend always using a fragment size that is 1/8 : the block size (less testing has been done on other fragment size factors). : The : .Xr newfs 8 : options for this would be :-.Dq Li "newfs -f 2048 -b 16384 ..." . :-Using a larger block size can cause fragmentation of the buffer cache and :-lead to lower performance. :+.Dq Li "newfs -f 1024 -b 8192 ..." . : .Pp : If a large partition is intended to be used to hold fewer, larger files, such : as a database files, you can increase the :Index: sbin/newfs/newfs.8 :=================================================================== :RCS file: /home/ncvs/src/sbin/newfs/newfs.8,v :retrieving revision 1.47 :diff -u -d -r1.47 newfs.8 :--- sbin/newfs/newfs.8 7 Dec 2001 13:18:28 -0000 1.47 :+++ sbin/newfs/newfs.8 10 Dec 2001 09:11:49 -0000 :@@ -110,7 +110,7 @@ : for more details on how to set this option. : .It Fl b Ar block-size : The block size of the file system, in bytes. It must be a power of 2. The :-default size is 8192 bytes, and the smallest allowable size is 4096 bytes. :+default size is 16384 bytes, and the smallest allowable size is 4096 bytes. : The optimal block:fragment ratio is 8:1. : Other ratios are possible, but are not recommended, : and may produce unpredictable results. :@@ -141,7 +141,7 @@ : .Ar blocksize Ns /8 : and : .Ar blocksize . :-The default is 1024 bytes. :+The default is 2048 bytes. : .It Fl g Ar avgfilesize : The expected average file size for the file system. : .It Fl h Ar avgfpdir :@@ -271,15 +271,19 @@ : bad sector allocation. : .El : .Sh EXAMPLES :-.Dl newfs -b 16384 -f 2048 /dev/ad3s1a :+.Dl newfs /dev/ad3s1a : .Pp : Creates a new ufs file system on : .Pa ad3s1a . : .Nm : will use a block size of 16384 bytes, a fragment size of 2048 bytes : and the largest possible number of cylinders per group. :-These values tend to produce better performance than the defaults :-for most applications. :+These values tend to produce better performance for most applications :+than the historical defaults :+(8192 byte block size and 1024 byte fragment size). :+This large fragment size :+may lead to large amounts of wasted space :+on filesystems that contain a large number of small files. : .Sh SEE ALSO : .Xr fdformat 1 , : .Xr disktab 5 , :Index: sbin/newfs/newfs.c :=================================================================== :RCS file: /home/ncvs/src/sbin/newfs/newfs.c,v :retrieving revision 1.45 :diff -u -d -r1.45 newfs.c :--- sbin/newfs/newfs.c 3 Nov 2001 08:35:11 -0000 1.45 :+++ sbin/newfs/newfs.c 7 Dec 2001 15:09:18 -0000 :@@ -98,8 +98,8 @@ : * sectorsize <= DESFRAGSIZE <= DESBLKSIZE : * DESBLKSIZE / DESFRAGSIZE <= 8 : */ :-#define DFL_FRAGSIZE 1024 :-#define DFL_BLKSIZE 8192 :+#define DFL_FRAGSIZE 2048 :+#define DFL_BLKSIZE 16384 : : /* : * Cylinder groups may have up to many cylinders. The actual :Index: usr.sbin/sysinstall/install.c :=================================================================== :RCS file: /home/ncvs/src/usr.sbin/sysinstall/install.c,v :retrieving revision 1.312 :diff -u -d -r1.312 install.c :--- usr.sbin/sysinstall/install.c 9 Dec 2001 09:47:09 -0000 1.312 :+++ usr.sbin/sysinstall/install.c 10 Dec 2001 00:20:21 -0000 :@@ -1121,7 +1121,7 @@ : variable_set2(SYSTEM_STATE, "update", 0); : else : variable_set2(SYSTEM_STATE, "init", 0); :- variable_set2(VAR_NEWFS_ARGS, "-b 8192 -f 1024", 0); :+ variable_set2(VAR_NEWFS_ARGS, "", 0); : variable_set2(VAR_CONSTERM, "NO", 0); : return DITEM_SUCCESS; : } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 11: 7:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1A6D937B41D for ; Mon, 10 Dec 2001 11:07:37 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBAJ7Di06796; Mon, 10 Dec 2001 14:07:14 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 10 Dec 2001 14:07:12 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Peter Wemm Cc: Matthew Dillon , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: <20011210023828.15C963810@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 9 Dec 2001, Peter Wemm wrote: > Matthew Dillon wrote: > > (Matt places hands on face and slowly drags them down, with appropriate > > sound effects) > > Seriously though, I like the concept but I wonder if it would be better > query the user.. ie: something like: "(D)elete this partition or > (M)erge the space into parent?" > > Otherwise it becomes harder to delete /home, carve out some space for > something and recreate a new slightly smaller /home. I have to admit I prefer this behavior: on the initial read through of Matt's description, I said to myself "But what if I just wanted to delete the partition, not merge it into another?" With the D key defined as proposed, it would be a lot harder to do this. I'm all for saving keystrokes, but not if it makes something useful like that substantially more complicated (or counter-intuitive). On a related note, is it currently possible to look at the partition list and see which ones are auto-sized and might behave that way? Or alternatively, the output might read: Partition Mountpoint Desired size Actual size /dev/ad0s1e /home 50% (1.2GB) 1GB Something to give an indication of the behavior that will result from doing something to the adjacent partitions. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 11:21: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A38837B416; Mon, 10 Dec 2001 11:21:01 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAJL0I48202; Mon, 10 Dec 2001 11:21:00 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 11:21:00 -0800 (PST) From: Matthew Dillon Message-Id: <200112101921.fBAJL0I48202@apollo.backplane.com> To: Robert Watson Cc: Peter Wemm , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Seriously though, I like the concept but I wonder if it would be better :> query the user.. ie: something like: "(D)elete this partition or :> (M)erge the space into parent?" :> :> Otherwise it becomes harder to delete /home, carve out some space for :> something and recreate a new slightly smaller /home. : :I have to admit I prefer this behavior: on the initial read through of :Matt's description, I said to myself "But what if I just wanted to delete :the partition, not merge it into another?" With the D key defined as :proposed, it would be a lot harder to do this. I'm all for saving :keystrokes, but not if it makes something useful like that substantially :more complicated (or counter-intuitive). : :On a related note, is it currently possible to look at the partition list :and see which ones are auto-sized and might behave that way? Or :alternatively, the output might read: : : Partition Mountpoint Desired size Actual size : /dev/ad0s1e /home 50% (1.2GB) 1GB : :Something to give an indication of the behavior that will result from :doing something to the adjacent partitions. It not that complicated. The vast majority of people use 'A'uto on an empty partition table. There wouldn't be any confusion. Another alternative would be to turn off the 'D'elete feature and have 'A'uto cycle through a number of different configurations. I don't see much of a difference, though I suppose we could put in some esoteric configurations like root-only (/) configs and such. It gets messy though because there are dozens of combinations... for example, root-only-with-swap, root-only-without-swap. I think it is far easier to be given a base set and 'D'elete what you don't want, and to partition things up manually for anything we can't cover with that. -Matt Matthew Dillon :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 12:31:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id A5B4F37B416 for ; Mon, 10 Dec 2001 12:31:30 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBAKVDJ155248; Mon, 10 Dec 2001 15:31:13 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200112080349.fB83nWU00292@apollo.backplane.com> References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> Date: Mon, 10 Dec 2001 15:31:09 -0500 To: Matthew Dillon From: Garance A Drosihn Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 7:49 PM -0800 12/7/01, Matthew Dillon wrote: > Ok, I've finally gone and done it... cleaned up the sysinstall > 'Auto' option. Boy, and don't you just regret that! :-) > The jist of it is that I have added a bunch of DEFAULT and NOMINAL > partition sizes. DEFAULT is the target 'A'uto tries to achieve, > but if the disk is not large enough it will loop and scale the > auto partitions down based on a fraction of NOMINAL to DEFAULT. I > added "vn" to libdisk (not in this patch, just so I could test) > and did some tests and it appears to work quite well. (Note: if > using the VN device for testing you have to use file-backed rather > then swap-backed because sysinstall gets really confused when the > sector size is not 512). This all sounds very good to me. I think you've done the project a bit of a favor by trying to do this, and stirring up the discussion. > I also added two more 'typical' partitions: /var/tmp, and /home. I > have not done anything with /tmp yet but I recommend that we have > sysinstall create a softlink /tmp -> /var/tmp. > > I also fixed auto mode to not create more then 4G of swap. > > Auto now attempts to create the following partitions: > > / 128M > swap 2 x phys memory, 32MB minimum > /var 128M > /var/tmp 128M > /usr 3G max > /home all remaining space > > Of course, these are all #defines so we can argue about them > separately from comments on the patchset itself. Well, as you perhaps expected, I think most of the rest of the 328 messages in this thread are arguing about the #define's you happened to pick... :-) I think that is inevitable. We have had a frozen list of partitions and sizes for many years, and a list that everyone could agree was bad. They might not say it that way, but every time the default partitioning was discussed, it seemed that there wasn't anyone who actually USED the defaults. I know there must be some, but it always seemed to me that the vast majority of people would chime in with their own favorite layouts. I have my own favorite layout, which looks nothing like the above. I will not argue for my own favorite layout, because my layout is meant for a multi-boot system (switching between 4.x-stable and 5.x-current). Clearly that is not the right layout for "the average dumb user". I say that deliberately, since expert wizard users aren't going to be using ANY auto-partition defaults you come up with, unless you come up with exactly the defaults that they are already using. I do not like the idea of /tmp being a softlink into /var/tmp. I would prefer that to be a directory on /, so it will be there when one boots in single user mode. Please note that here I am giving a specific reason for my objection, and not just saying "Well, gee, *I* would *like* it some other way than what you happened to pick". Other than that, I could live with all of the above, particularly after including your additional change to auto-resize-on-delete. For the average user, they will be much better off with the above selections than with what sysinstall had been doing. While there has been a lot of arguing against your particular choices, I did not notice many people who argued that the CURRENT auto-partition behavior is better than what you proposed. From other messages in this thread, I think that your changes have inspired Jordan to work on some alternate ideas, and maybe those alternate ideas will be even better. Certainly that is possible, so I'd like to wait to see how those turn out. Still, I think *any* work on this area is long-overdue, and thus it's good to see it happening, even though we're probably going to beat ourselves up bloody trying to come up with the right defaults... :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 13:39:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id B47DD37B405 for ; Mon, 10 Dec 2001 13:38:39 -0800 (PST) Received: (qmail 8945 invoked from network); 10 Dec 2001 21:38:38 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 21:38:38 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200112090555.fB95tDQ18827@khavrinen.lcs.mit.edu> Date: Mon, 10 Dec 2001 13:38:35 -0800 (PST) From: John Baldwin To: Garrett Wollman Subject: Re: Perl 5.6.1 in the base.... Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Dec-01 Garrett Wollman wrote: > [Apologies for getting into this discussion late... I just a few hours > ago got back from LISA in San Diego.] > >>Nope. The perl in -current is 5.6.0. The problem is that the Perl upgrades >>are quite hard to do and get right. > > And the Perl in -stable should stay as it is, unless you want to start > erecting a giant banner that reads, ``FreeBSD Project screws -stable > users yet again''. > > Remember, whenever the Perl version changes, every single Perl > extension on the system has to be (at best) reinstalled. That's > assuming, of course, that you can find them all. I don't mind that. Perhaps fixing the perl port so that perl 5.6.1 can be installed on 4.x systems as a port would be the best approach to take. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 13:39:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 07F1937B432 for ; Mon, 10 Dec 2001 13:38:50 -0800 (PST) Received: (qmail 9022 invoked from network); 10 Dec 2001 21:38:47 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 21:38:47 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15378.58581.711516.632169@grasshopper.cs.duke.edu> Date: Mon, 10 Dec 2001 13:38:43 -0800 (PST) From: John Baldwin To: Andrew Gallatin Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la Cc: freebsd-arch@FreeBSD.ORG, Matthew Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-Dec-01 Andrew Gallatin wrote: > Then our location of /var/crash appears to be in confict with the > purpose of /var, so we should move /var/crash to /usr/crash, or teach > "dump" to be smarter & not dump the entire memory of the machine in > the first place. Eg, don't dump vnode backed pages, free pages, or > portions of the address space which aren't backed by physical memory.. I vote for /usr/crash, it's what I use all the time anyways. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 13:39:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 0A59237B43C for ; Mon, 10 Dec 2001 13:38:51 -0800 (PST) Received: (qmail 9031 invoked from network); 10 Dec 2001 21:38:48 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 21:38:48 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <49294.1007846108@winston.freebsd.org> Date: Mon, 10 Dec 2001 13:38:44 -0800 (PST) From: John Baldwin To: Jordan Hubbard Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la Cc: freebsd-arch@FreeBSD.ORG, Kirk McKusick , Sheldon Hearn , "Louis A. Mamakos" , Garance A Drosihn , Matthew Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-Dec-01 Jordan Hubbard wrote: >> Ok, I've finally gone and done it... cleaned up the sysinstall >> 'Auto' option. > > OK, I have the following concerns with this: I agree with Jordan here, different machines use different layouts. Personally I like having a large /usr since I usually end up really hurting myself by trying to split it up into /usr and /v (where /v has /v/home). The problem usually being that I end up with too partitions both of which are just too small to build a release on, for example. The other really big problem is that new users don't know what they need for a given machine, so having a 'mail server', 'desktop', etc. option in sysinstall to help with layout would go a long way to actually making FreeBSD user to non-uber-hackers. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 14:21:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A93CF37B416; Mon, 10 Dec 2001 14:21:13 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAMLD648896; Mon, 10 Dec 2001 14:21:13 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 14:21:13 -0800 (PST) From: Matthew Dillon Message-Id: <200112102221.fBAMLD648896@apollo.backplane.com> To: John Baldwin Cc: Andrew Gallatin , freebsd-arch@FreeBSD.org Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : : :On 09-Dec-01 Andrew Gallatin wrote: :> Then our location of /var/crash appears to be in confict with the :> purpose of /var, so we should move /var/crash to /usr/crash, or teach :> "dump" to be smarter & not dump the entire memory of the machine in :> the first place. Eg, don't dump vnode backed pages, free pages, or :> portions of the address space which aren't backed by physical memory.. : :I vote for /usr/crash, it's what I use all the time anyways. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ I prefer the official path to be /var/crash (/var/). Since I typically export /usr via NFS read-only I usually put crash in /home. aka /var/crash->/home/crash, or some other partition, or I just leave /var/crash as is and if /var doesn't have any room I run 'savecore ' manually after booting is complete. In regards to the "dump" being smarter... system core dump is only a dump of physical memory. It does not dump VM Objects. Of course, it does wind up dumping whatever is in physical memory, such as the file cache, but it's important that it do so or we kernel hackers would have a hard time tracking problems down. Also, you don't want to make a system core dump too 'smart'... the system could be in a very corrupted state when dumping so we can't safely traverse dozens of system structures. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 14:30:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D9EE037B41B for ; Mon, 10 Dec 2001 14:30:13 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBAMTx848960; Mon, 10 Dec 2001 14:29:59 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 14:29:59 -0800 (PST) From: Matthew Dillon Message-Id: <200112102229.fBAMTx848960@apollo.backplane.com> To: Garance A Drosihn Cc: "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <31807.1007732134@axl.seasidesoftware.co.za> <200112072257.fB7MvjE95211@apollo.backplane.com> <200112072311.fB7NB2723789@whizzo.transsys.com> <200112080349.fB83nWU00292@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :At 7:49 PM -0800 12/7/01, Matthew Dillon wrote: :> Ok, I've finally gone and done it... cleaned up the sysinstall :> 'Auto' option. : :Boy, and don't you just regret that! :-) Next time I'm just going to commit the damn idea without discussing it first. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15: 1:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 966DC37B41B; Mon, 10 Dec 2001 15:01:15 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBAN0rq44310; Mon, 10 Dec 2001 15:00:53 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Robert Watson Cc: Peter Wemm , Matthew Dillon , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Robert Watson of "Mon, 10 Dec 2001 14:07:12 EST." Date: Mon, 10 Dec 2001 15:00:53 -0800 Message-ID: <44305.1008025253@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I have to admit I prefer this behavior: on the initial read through of > Matt's description, I said to myself "But what if I just wanted to delete > the partition, not merge it into another?" With the D key defined as > proposed, it would be a lot harder to do this. I've come up with a way of dealing with this that, I think, will work out nicely - I'm about 3/4 done with all the code and am working on some of the issues around making auto-layout a mode now vs a command. label.c also got a complete rewrite at the same time, so maybe this has all been for the good. Anyway, the way things now work is thusly: Upon entering the label editor, you see the current "traditional" view with the slices available for partitioning at the top and any partitions at the bottom. If you use the (C)reate option to create a partition, it's created in the usual way and a libdisk "chunk" is assigned to it. If you hit (A)uto, the label editor goes into "Auto layout mode" and that has the following effects: 1. The current profile is scanned (the default profile being fairly close to what we have today) and any filesystems on its 'wish list' are put into the to-be-created state with an auto-generated size. 2. Any filesystems in the to-be-created state have their disk device displayed as "" and have a lower precedence than any manually created partition. If you (c)reate a filesystem that already has an auto-placeholder, it replaces the placeholder and is assigned a libdisk chunk. If you (d)elete a manually created chunk, it simply goes away again. If you delete an automatically created filesystem, it goes away and the space it "occupied" is assigned to its "buddy". 3. If you switch (P)rofiles, all the auto-generated filesystems are recreated to match the new profile, e.g. if /usr was auto-generated and currently sized at 400MB from the current profile and it's 800MB in the new profile, /usr will change size along with any other auto-generated filesystems which need to. If the user has (c)reated a filesystem manually, its size is unchanged and all the other auto filesystems just sort of flow around it. 4. Upon (Q)uiting or (W)riting at the label editor, all auto-created filesystems have their corresponding libdisk chunks actually allocated and the device names are now printed, (Q)uit also now invoking a new "Does everything look correct (Y/N)?" if auto-layout was used (if you only manually create stuff, it won't bother asking). I realize that this is something of a shift from the previous paradigm and am interested in knowing if anyone other than Matt hates it. :) Personally, I think it's a really cool way of cycling through different canned system profiles and seeing what other people recommended as defaults for that type of configuration. It also deals nicely with the issue of having multiple slices - you no longer have to go to a specific slice and "lay it out", the auto-layout feature taking advantage of all available (FreeBSD) slices without any special user intervention. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:11:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 035CB37B41B; Mon, 10 Dec 2001 15:11:14 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBANBA849291; Mon, 10 Dec 2001 15:11:10 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 15:11:10 -0800 (PST) From: Matthew Dillon Message-Id: <200112102311.fBANBA849291@apollo.backplane.com> To: Jordan Hubbard Cc: Robert Watson , Peter Wemm , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <44305.1008025253@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : 4. Upon (Q)uiting or (W)riting at the label editor, all auto-created : filesystems have their corresponding libdisk chunks actually : allocated and the device names are now printed, (Q)uit also : now invoking a new "Does everything look correct (Y/N)?" : if auto-layout was used (if you only manually create stuff, it : won't bother asking). : :I realize that this is something of a shift from the previous paradigm :and am interested in knowing if anyone other than Matt hates it. :) I don't hate it, but I wish you had done it before I invested all sorts of time in this. I don't think we need a 'Does everything look correct' requester. If you haven't already, each profile needs to have a small paragraph associated with it documenting what it is designed to do. Then as you cycle through the 'P'rofiles this documentation appears in the window. So the layman can cycle through the profiles until he gets the 'workstation' profile or the 'big whopping mail server' profile or whatever it is he wants. The buddy idea is kind of silly. The ability of one partition to inherit the space freed up by another is based on whether the partition is adjacent to the other, not whether it's the other's buddy. -Matt Matthew Dillon :Personally, I think it's a really cool way of cycling through :different canned system profiles and seeing what other people :recommended as defaults for that type of configuration. It also deals :nicely with the issue of having multiple slices - you no longer have :to go to a specific slice and "lay it out", the auto-layout feature :taking advantage of all available (FreeBSD) slices without any special :user intervention. : :- Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:18:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id AEE4F37B41D for ; Mon, 10 Dec 2001 15:18:13 -0800 (PST) Received: (qmail 26466 invoked from network); 10 Dec 2001 23:18:12 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 23:18:12 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200112102311.fBANBA849291@apollo.backplane.com> Date: Mon, 10 Dec 2001 15:18:08 -0800 (PST) From: John Baldwin To: Matthew Dillon Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la Cc: freebsd-arch@FreeBSD.ORG, Terry Lambert , Peter Wemm , Robert Watson , Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Dec-01 Matthew Dillon wrote: > The buddy idea is kind of silly. The ability of one partition to inherit > the space freed up by another is based on whether the partition is > adjacent to the other, not whether it's the other's buddy. Nah. Think about it, the disklabel isn't created until the end when it is written to disk. You can easily shuffle the sizes around and not set the actual start sectors until commit time. It's just a generalization of your auto-resize thingie. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:24:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 61CA137B405 for ; Mon, 10 Dec 2001 15:24:28 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBANNlq44508; Mon, 10 Dec 2001 15:23:47 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Mon, 10 Dec 2001 14:29:59 PST." <200112102229.fBAMTx848960@apollo.backplane.com> Date: Mon, 10 Dec 2001 15:23:47 -0800 Message-ID: <44504.1008026627@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Next time I'm just going to commit the damn idea without discussing > it first. I'm sure that's just sarcasm in action, but lest anyone reading this be tempted to take it seriously as an option, I'll just say that taking this approach is virtually guaranteed to have someone else simply back out your changes (also without discussion since discussion clearly wasn't desired) and before you know it, -core's got a grievance on its hands and various other committers are lining up to take one side or the other, just like a schoolyard fight. Having people disagree with you, sometimes vehemently, is part of the dynamics of our little group project and it's actually of great benefit, even when it frustrates the hell out of the Lone Wolf that most of us have lurking somewhere inside us. The recent discussion, for example, pissed me off so much that I was finally motivated to re-write large chunks of sysinstall and, in so doing, virtually eliminate certain bodies of code which were truly abhorrent to the eye (checkLabels(), in particular, was so hideous that I'm now ashamed to have written it in the first place). I doubt that I would have been motivated to do so under any other circumstances and a number of the points made during the recent discussion have also had a very positive effect on the [re]design process. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:35:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id A2D3E37B405; Mon, 10 Dec 2001 15:35:24 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBANYqq44611; Mon, 10 Dec 2001 15:34:52 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Robert Watson , Peter Wemm , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Mon, 10 Dec 2001 15:11:10 PST." <200112102311.fBANBA849291@apollo.backplane.com> Date: Mon, 10 Dec 2001 15:34:52 -0800 Message-ID: <44607.1008027292@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I don't hate it, but I wish you had done it before I invested all > sorts of time in this. Sorry, but as I just admitted in another part of this thread, I don't think I'd have had the gumption to tackle a re-write if you hadn't, either, so this is a circular dependency. :) > I don't think we need a 'Does everything look correct' requester. The reason that it's there, and I disliked it too when I first thought about it, is that since the partitions are not created until the very end, you don't get the nice /dev/sd0s1f type of device names since the label editor doesn't know this until it creates the chunks with libdisk. The reason it doesn't create them initially is because everything except the manually created filesystems are done "speculatively" since it would be very expensive to create and delete chunks when shuffling between profiles, and libdisk is also fragile enough that I'd sort of expect that to break if you did it enough times. So I thought the user might like the chance to actually see the final layout before proceeding, and if I just exit the screen immediately on (Q)uit, you'd never see it. Perhaps that's just fine though. What do folks think? > If you haven't already, each profile needs to have a small paragraph > associated with it documenting what it is designed to do. Then as you Not a paragraph, but a single line, yes. It's displayed at the bottom of the screen whenever auto mode is invoked or the profile is switched. > The buddy idea is kind of silly. The ability of one partition to inherit > the space freed up by another is based on whether the partition is > adjacent to the other, not whether it's the other's buddy. Well, I thought that too initially, but the problem is that things aren't always adjacent in ways that make sense. You would probably want to collapse /usr or /var into /, for example, if either were deleted since it's fairly obvious that the user's headed in the direction of "one big root" if they're doing that (and whether or not that's a good idea is immaterial, some people just prefer it). In the traditional view, however, it's /, /usr and /var. Under your scenario, deleting /var would collapse its space into /usr! - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:40:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id F113E37B419; Mon, 10 Dec 2001 15:40:20 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id SAA09397; Mon, 10 Dec 2001 18:40:15 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id fBANdoT14965; Mon, 10 Dec 2001 18:39:50 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.18374.269597.931300@grasshopper.cs.duke.edu> Date: Mon, 10 Dec 2001 18:39:50 -0500 (EST) To: Matthew Dillon Cc: John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la In-Reply-To: <200112102221.fBAMLD648896@apollo.backplane.com> References: <200112102221.fBAMLD648896@apollo.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon writes: > > In regards to the "dump" being smarter... system core dump is only > a dump of physical memory. It does not dump VM Objects. Of course, > it does wind up dumping whatever is in physical memory, such as the > file cache, but it's important that it do so or we kernel hackers > would have a hard time tracking problems down. Also, you don't want I think you're one of the few people who might actually care about the contents of the buffercache. That's why it would be optional. > to make a system core dump too 'smart'... the system could be in a > very corrupted state when dumping so we can't safely traverse dozens of > system structures. True, but in nearly three years of using partial dumps, I can't remember that ever happening. And I was mucking with the VM system in my zero-copy work. Again, that's why it would be optional. Anyway, have a look at the partial dump diffs done 2 years ago by Darrell Anderson. http://www.cs.duke.edu/~anderson/freebsd/partialdump These are old, non-context diffs to 4.0 (at the time -current). There'd be some mergework to do, but I think it would be quite handy. Drew PS: We eventually abandoned partial dump in favor of netdump, which works on roughly the same principals but is quite a bit faster, but more of a local hack: http://www.cs.duke.edu/~anderson/freebsd/netdump/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 15:56:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 5628137B405 for ; Mon, 10 Dec 2001 15:56:06 -0800 (PST) Received: (qmail 27249 invoked from network); 10 Dec 2001 23:56:05 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 10 Dec 2001 23:56:05 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <44607.1008027292@winston.freebsd.org> Date: Mon, 10 Dec 2001 15:56:01 -0800 (PST) From: John Baldwin To: Jordan Hubbard Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la Cc: freebsd-arch@FreeBSD.ORG, Terry Lambert , Peter Wemm , Robert Watson , Matthew Dillon Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Dec-01 Jordan Hubbard wrote: >> I don't hate it, but I wish you had done it before I invested all >> sorts of time in this. > > Sorry, but as I just admitted in another part of this thread, I don't > think I'd have had the gumption to tackle a re-write if you hadn't, > either, so this is a circular dependency. :) > >> I don't think we need a 'Does everything look correct' requester. > > The reason that it's there, and I disliked it too when I first thought > about it, is that since the partitions are not created until the very > end, you don't get the nice /dev/sd0s1f type of device names since the > label editor doesn't know this until it creates the chunks with > libdisk. The reason it doesn't create them initially is because > everything except the manually created filesystems are done > "speculatively" since it would be very expensive to create and delete > chunks when shuffling between profiles, and libdisk is also fragile > enough that I'd sort of expect that to break if you did it enough > times. So I thought the user might like the chance to actually see > the final layout before proceeding, and if I just exit the screen > immediately on (Q)uit, you'd never see it. Perhaps that's just fine > though. What do folks think? I think having it is ok. It's not that big of a deal to hit 'y' Enter. It is nice to see the final results. One thing I would like is if one can delete an auto partition and create a new one and have the other auto's adjust. (I think you can do this, right?) For example, I usually like to make / bigger than usual, so I would prefer ot do 'A', select workstation or testbox or whatever, delete /, create a bigger /, and have the swap and /var stay the same and /usr adjust as needed. I would almost vote for deferring the assignment of all partitions (manual or automatic) until the end. The only difference in a manual partition is that it has a fixed size IMO. This would allow one to simply set the size of an auto partition to tweak a setup. For example, for my scenario, I would just have to set a size for / and then everything would be done. So, if I create a partition, it doesn't get allocated a letter yet until we commit the changes. It's just like an auto partition except that it has a fixed size and is tied to a specific slice/disk. How does that sound? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 17: 1:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id C7BB337B405 for ; Mon, 10 Dec 2001 17:01:04 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBB112J59166; Mon, 10 Dec 2001 20:01:02 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <44607.1008027292@winston.freebsd.org> References: <44607.1008027292@winston.freebsd.org> Date: Mon, 10 Dec 2001 20:00:58 -0500 To: Jordan Hubbard From: Garance A Drosihn Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Cc: freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 3:34 PM -0800 12/10/01, Jordan Hubbard wrote: >Matt writes: > > I don't think we need a 'Does everything look correct' requester. > >The reason that it's there, and I disliked it too when I first thought >about it, is that since the partitions are not created until the very >end, you don't get the nice /dev/sd0s1f type of device names since the >label editor doesn't know this until it creates the chunks with >libdisk. The reason it doesn't create them initially is because >everything except the manually created filesystems are done >"speculatively" since it would be very expensive to create and delete >chunks when shuffling between profiles, and libdisk is also fragile >enough that I'd sort of expect that to break if you did it enough >times. So I thought the user might like the chance to actually see >the final layout before proceeding, and if I just exit the screen >immediately on (Q)uit, you'd never see it. Perhaps that's just fine >though. What do folks think? I think it "feels stupid" to have it ask "Does everything look correct?" at that point, even though I understand the issue you're trying to address. Perhaps another way of doing this is that the "Auto mode" should not have a (Q)uit option. Instead, it could have some option like (F)reeze or (F)inish or (B)ack, and that option drops the user back into the standard screen with all the partitions and partition-settings filled in. The person then gets to see exactly how all the partitions look, and can decide if things looks right before typing (Q)uit. So, the effect is the same, but we won't have the oddity that we ask the user "does everything look right?" when they pick an automatic partition scheme, but we don't ask when they build the partitions by hand. I guess the other question which comes to mind is how does this handle settings like "softupdates", or existing partitions which someone might want to keep? (and which, therefore, one would not want to NEWFS) From an earlier message: >It also deals nicely with the issue of having multiple slices - you no >longer have to go to a specific slice and "lay it out", the auto-layout >feature taking advantage of all available (FreeBSD) slices without any >special user intervention. I assume it is only taking advantage of slices which were selected in the earlier fdisk step? Or to ask the question another way, what if the user does NOT want to use all available FreeBSD slices? I always have multiple bootable freebsd systems on my machines, and so usually I want the installation process to play with only one specific slice, and not every freebsd slice that it can find. I would probably have to see this in action to understand how well it works, but I'm just trying to think up some oddball situations which might be a problem. From your description so far, I think that what you're working towards will be very nice. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 17:32:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C4DB237B419; Mon, 10 Dec 2001 17:32:17 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBB1WH749829; Mon, 10 Dec 2001 17:32:17 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 17:32:17 -0800 (PST) From: Matthew Dillon Message-Id: <200112110132.fBB1WH749829@apollo.backplane.com> To: John Baldwin Cc: Jordan Hubbard , freebsd-arch@FreeBSD.ORG, Terry Lambert , Peter Wemm , Robert Watson Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I think having it is ok. It's not that big of a deal to hit 'y' Enter. It is :nice to see the final results. One thing I would like is if one can delete an :auto partition and create a new one and have the other auto's adjust. (I think :you can do this, right?) For example, I usually like to make / bigger than :usual, so I would prefer ot do 'A', select workstation or testbox or whatever, :delete /, create a bigger /, and have the swap and /var stay the same and /usr :adjust as needed. I would almost vote for deferring the assignment of all :partitions (manual or automatic) until the end. The only difference in a :manual partition is that it has a fixed size IMO. This would allow one to :simply set the size of an auto partition to tweak a setup. For example, for my :scenario, I would just have to set a size for / and then everything would be :done. : :So, if I create a partition, it doesn't get allocated a letter yet until we :commit the changes. It's just like an auto partition except that it has a :fixed size and is tied to a specific slice/disk. How does that sound? : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ Well, the code to do the above isn't entirely trivial. I don't know how Jordan is doing it but what I would do is make a copy of the selected disk template and then adjust it's parameters (like masking off partitions that the user deletes) as the user messes around manually after that. One would have to go through and delete ALL the auto partitions and re-run the auto-partition generator on the temporary template for each keystroke to really make it work right. The code winds up being too complex otherwise. You definitely do *not* want to defer partition assignment. The user really needs to be able to see what is going on in real time. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 17:34:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 663A337B417; Mon, 10 Dec 2001 17:34:54 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBB1YNs49856; Mon, 10 Dec 2001 17:34:23 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 17:34:23 -0800 (PST) From: Matthew Dillon Message-Id: <200112110134.fBB1YNs49856@apollo.backplane.com> To: Andrew Gallatin Cc: John Baldwin , freebsd-arch@FreeBSD.org Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a la References: <200112102221.fBAMLD648896@apollo.backplane.com> <15381.18374.269597.931300@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :True, but in nearly three years of using partial dumps, I can't :remember that ever happening. And I was mucking with the VM system :in my zero-copy work. Again, that's why it would be optional. : :Anyway, have a look at the partial dump diffs done 2 years ago by :Darrell Anderson. :http://www.cs.duke.edu/~anderson/freebsd/partialdump :These are old, non-context diffs to 4.0 (at the time -current). :There'd be some mergework to do, but I think it would be quite handy. : :Drew : :PS: We eventually abandoned partial dump in favor of netdump, which works :on roughly the same principals but is quite a bit faster, but more of :a local hack: http://www.cs.duke.edu/~anderson/freebsd/netdump/ I'd like to see a working netdump for FreeBSD. There are MANY instances where it would have helped a lot... like when the panic is in the middle of the SCSI code and dumps don't work. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 17:37:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0E8B837B416; Mon, 10 Dec 2001 17:37:49 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fBB1bm149878; Mon, 10 Dec 2001 17:37:48 -0800 (PST) (envelope-from dillon) Date: Mon, 10 Dec 2001 17:37:48 -0800 (PST) From: Matthew Dillon Message-Id: <200112110137.fBB1bm149878@apollo.backplane.com> To: Jordan Hubbard Cc: Robert Watson , Peter Wemm , Terry Lambert , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) References: <44607.1008027292@winston.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :The reason that it's there, and I disliked it too when I first thought :about it, is that since the partitions are not created until the very :end, you don't get the nice /dev/sd0s1f type of device names since the :label editor doesn't know this until it creates the chunks with Oh. It's REAL easy to create the partitions in real time. If you look at the code I comitted to -current to do the scale retry loop and then consider that I also added a flag to the Chunk structure indicating the automatically created chunks, all you have to do is maintain a temporary copy of your disk template and delete/regenerate the auto partitions every time someone makes a change. I think it's very important for the user to see what is going on in real time. :libdisk. The reason it doesn't create them initially is because :everything except the manually created filesystems are done :"speculatively" since it would be very expensive to create and delete :chunks when shuffling between profiles, and libdisk is also fragile It's inexpensive. A few microseconds per keystroke at most... nothing is actually going to disk after all, you are just manipulating a bunch of malloc()'d libdisk structures. :enough that I'd sort of expect that to break if you did it enough :times. So I thought the user might like the chance to actually see If so we'll fix the bugs. It's been fairly dependable in my tests. : :> If you haven't already, each profile needs to have a small paragraph :> associated with it documenting what it is designed to do. Then as you : :Not a paragraph, but a single line, yes. It's displayed at the bottom :of the screen whenever auto mode is invoked or the profile is switched. : :- Jordan -MAtt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 17:39:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7BF8637B417; Mon, 10 Dec 2001 17:39:20 -0800 (PST) Received: from isi.edu (ras34.isi.edu [128.9.176.134]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fBB1dJN19002; Mon, 10 Dec 2001 17:39:19 -0800 (PST) Message-ID: <3C1563C7.8010007@isi.edu> Date: Mon, 10 Dec 2001 17:39:19 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011203 X-Accept-Language: en, de MIME-Version: 1.0 To: John Baldwin Cc: Garrett Wollman , arch@FreeBSD.ORG Subject: Re: Perl 5.6.1 in the base.... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > I don't mind that. Perhaps fixing the perl port so that perl 5.6.1 can be > installed on 4.x systems as a port would be the best approach to take. Are there any issues that I should be aware of? We're running 5.6.1 happily on all our 4.4 boxes (we need some CPAN stuff that requires 5.6 for our daily work). The only thing to keep in mind is to install the perl port before any other perl packages, patch bsd.port.mk to set the environment correctly, and optionally move the old perl binaries out of the way. Seems to work like a charm. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Dec 10 23:54:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 1EEFB37B416 for ; Mon, 10 Dec 2001 23:54:46 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16Dhly-0008It-00; Tue, 11 Dec 2001 09:56:18 +0200 From: Sheldon Hearn To: Matthew Dillon Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Mon, 10 Dec 2001 09:41:49 PST." <200112101741.fBAHfnB47140@apollo.backplane.com> Date: Tue, 11 Dec 2001 09:56:18 +0200 Message-ID: <31922.1008057378@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Dec 2001 09:41:49 PST, Matthew Dillon wrote: > Looks good to me! [...] > :Here's what I intend to commit. > :- variable_set2(VAR_NEWFS_ARGS, "-b 8192 -f 1024", 0); > :+ variable_set2(VAR_NEWFS_ARGS, "", 0); Eek, that's stale. I actually plan to set sysinstall's newfs default flags to "-b 16384 -f 2048" so folks can see what the defaults are, just as they did before. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 1:46:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 061F537B419; Tue, 11 Dec 2001 01:46:28 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBB9kQa79412; Tue, 11 Dec 2001 02:46:26 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBB9kMM26143; Tue, 11 Dec 2001 02:46:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112110946.fBB9kMM26143@harmony.village.org> To: Greg Lehey Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 10 Dec 2001 12:44:58 +1030." <20011210124458.B63585@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> Date: Tue, 11 Dec 2001 02:46:22 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: : Well, I'm not forgetting this, I didn't know it. But it seems to make : sense. This was one of the things I mentioned earlier. I have had systems that have separate / and /usr, and others that have one big /. I don't mind so much that / and /usr are on the same partition by default, but I don't want to see us go to one big '/'. That does cause more problems than it solves (and makes it impossible to do fastish boots by kicking the fsck into the back ground). However, I've had occasion to have systems where / and /usr need to be separate partitions, so as long as we don't require them to be on the same partition, I'd say go for it. I suspect, however, that we'll find that crash recovery really is a big factor since /usr does get written to on every man command that generates a new man page... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 1:46:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 061F537B419; Tue, 11 Dec 2001 01:46:28 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBB9kQa79412; Tue, 11 Dec 2001 02:46:26 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBB9kMM26143; Tue, 11 Dec 2001 02:46:22 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112110946.fBB9kMM26143@harmony.village.org> To: Greg Lehey Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 10 Dec 2001 12:44:58 +1030." <20011210124458.B63585@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> Date: Tue, 11 Dec 2001 02:46:22 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: : Well, I'm not forgetting this, I didn't know it. But it seems to make : sense. This was one of the things I mentioned earlier. I have had systems that have separate / and /usr, and others that have one big /. I don't mind so much that / and /usr are on the same partition by default, but I don't want to see us go to one big '/'. That does cause more problems than it solves (and makes it impossible to do fastish boots by kicking the fsck into the back ground). However, I've had occasion to have systems where / and /usr need to be separate partitions, so as long as we don't require them to be on the same partition, I'd say go for it. I suspect, however, that we'll find that crash recovery really is a big factor since /usr does get written to on every man command that generates a new man page... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 14:36:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 09AAF37B41D; Tue, 11 Dec 2001 14:36:12 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 4306A786E6; Wed, 12 Dec 2001 09:06:10 +1030 (CST) Date: Wed, 12 Dec 2001 09:06:10 +1030 From: Greg Lehey To: Warner Losh Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011212090610.D67986@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112110946.fBB9kMM26143@harmony.village.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 2:46:22 -0700, Warner Losh wrote: > In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: > : Well, I'm not forgetting this, I didn't know it. But it seems to make > : sense. This was one of the things I mentioned earlier. > > I have had systems that have separate / and /usr, and others that have > one big /. I don't mind so much that / and /usr are on the same > partition by default, but I don't want to see us go to one big '/'. > That does cause more problems than it solves (and makes it impossible > to do fastish boots by kicking the fsck into the back ground). > However, I've had occasion to have systems where / and /usr need to be > separate partitions, so as long as we don't require them to be on the > same partition, I'd say go for it. > > I suspect, however, that we'll find that crash recovery really is a > big factor since /usr does get written to on every man command that > generates a new man page... That's pretty seldom. $ find /usr/share/man/cat* -type f | wc -l 3277 $uname -v FreeBSD 5.0-CURRENT #0: Sat Sep 30 17:31:17 CST 2000 grog@wantadilla.lemis.com:/src/FreeBSD/WANTADILLA/src/sys/compile/WANTADILLA That's about 7.5 man pages per day. This is on my main machine, and I suspect I use man pages more than most. More to the point, how many broken /usr file systems have you *ever* had with FreeBSD? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 14:36:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 09AAF37B41D; Tue, 11 Dec 2001 14:36:12 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 4306A786E6; Wed, 12 Dec 2001 09:06:10 +1030 (CST) Date: Wed, 12 Dec 2001 09:06:10 +1030 From: Greg Lehey To: Warner Losh Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.ORG, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011212090610.D67986@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112110946.fBB9kMM26143@harmony.village.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 2:46:22 -0700, Warner Losh wrote: > In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: > : Well, I'm not forgetting this, I didn't know it. But it seems to make > : sense. This was one of the things I mentioned earlier. > > I have had systems that have separate / and /usr, and others that have > one big /. I don't mind so much that / and /usr are on the same > partition by default, but I don't want to see us go to one big '/'. > That does cause more problems than it solves (and makes it impossible > to do fastish boots by kicking the fsck into the back ground). > However, I've had occasion to have systems where / and /usr need to be > separate partitions, so as long as we don't require them to be on the > same partition, I'd say go for it. > > I suspect, however, that we'll find that crash recovery really is a > big factor since /usr does get written to on every man command that > generates a new man page... That's pretty seldom. $ find /usr/share/man/cat* -type f | wc -l 3277 $uname -v FreeBSD 5.0-CURRENT #0: Sat Sep 30 17:31:17 CST 2000 grog@wantadilla.lemis.com:/src/FreeBSD/WANTADILLA/src/sys/compile/WANTADILLA That's about 7.5 man pages per day. This is on my main machine, and I suspect I use man pages more than most. More to the point, how many broken /usr file systems have you *ever* had with FreeBSD? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 14:40:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 860CC37B419; Tue, 11 Dec 2001 14:40:40 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBBMeca82591; Tue, 11 Dec 2001 15:40:38 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBBMebM31038; Tue, 11 Dec 2001 15:40:37 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112112240.fBBMebM31038@harmony.village.org> To: Greg Lehey Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.org, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.org In-reply-to: Your message of "Wed, 12 Dec 2001 09:06:10 +1030." <20011212090610.D67986@monorchid.lemis.com> References: <20011212090610.D67986@monorchid.lemis.com> <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> Date: Tue, 11 Dec 2001 15:40:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011212090610.D67986@monorchid.lemis.com> Greg Lehey writes: : On Tuesday, 11 December 2001 at 2:46:22 -0700, Warner Losh wrote: : > In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: : > : Well, I'm not forgetting this, I didn't know it. But it seems to make : > : sense. This was one of the things I mentioned earlier. : > : > I have had systems that have separate / and /usr, and others that have : > one big /. I don't mind so much that / and /usr are on the same : > partition by default, but I don't want to see us go to one big '/'. : > That does cause more problems than it solves (and makes it impossible : > to do fastish boots by kicking the fsck into the back ground). : > However, I've had occasion to have systems where / and /usr need to be : > separate partitions, so as long as we don't require them to be on the : > same partition, I'd say go for it. : > : > I suspect, however, that we'll find that crash recovery really is a : > big factor since /usr does get written to on every man command that : > generates a new man page... : : That's pretty seldom. : : $ find /usr/share/man/cat* -type f | wc -l : 3277 : $uname -v : FreeBSD 5.0-CURRENT #0: Sat Sep 30 17:31:17 CST 2000 grog@wantadilla.lemis.com:/src/FreeBSD/WANTADILLA/src/sys/compile/WANTADILLA : : That's about 7.5 man pages per day. This is on my main machine, and I : suspect I use man pages more than most. : : More to the point, how many broken /usr file systems have you *ever* : had with FreeBSD? Maybe 5. I've rarely had one when / wasn't also broken. :-) However, the argument for /usr is more than just that it is for crash recovery. I'd have fewer if /usr was mounted read only (which it can't be for the man page issue, and other problems). We mount / read only on our embedded systems and combine / and /usr onto one partition and like everything dynamic. We also mount /var on MFS and have a read/write /mod for things that change (but that can be recovered by some means, should we need to newfs things). The argument is that if / is small, the chances of it being corrupt are smaller and the risk is lower of using it as an unchecked file system. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 14:40:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 860CC37B419; Tue, 11 Dec 2001 14:40:40 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBBMeca82591; Tue, 11 Dec 2001 15:40:38 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBBMebM31038; Tue, 11 Dec 2001 15:40:37 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112112240.fBBMebM31038@harmony.village.org> To: Greg Lehey Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: Terry Lambert , Nik Clayton , Mike Smith , arch@FreeBSD.org, Marko Zec , "Louis A. Mamakos" , Matthew Dillon , Sheldon Hearn , freebsd-arch@FreeBSD.org In-reply-to: Your message of "Wed, 12 Dec 2001 09:06:10 +1030." <20011212090610.D67986@monorchid.lemis.com> References: <20011212090610.D67986@monorchid.lemis.com> <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> Date: Tue, 11 Dec 2001 15:40:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011212090610.D67986@monorchid.lemis.com> Greg Lehey writes: : On Tuesday, 11 December 2001 at 2:46:22 -0700, Warner Losh wrote: : > In message <20011210124458.B63585@monorchid.lemis.com> Greg Lehey writes: : > : Well, I'm not forgetting this, I didn't know it. But it seems to make : > : sense. This was one of the things I mentioned earlier. : > : > I have had systems that have separate / and /usr, and others that have : > one big /. I don't mind so much that / and /usr are on the same : > partition by default, but I don't want to see us go to one big '/'. : > That does cause more problems than it solves (and makes it impossible : > to do fastish boots by kicking the fsck into the back ground). : > However, I've had occasion to have systems where / and /usr need to be : > separate partitions, so as long as we don't require them to be on the : > same partition, I'd say go for it. : > : > I suspect, however, that we'll find that crash recovery really is a : > big factor since /usr does get written to on every man command that : > generates a new man page... : : That's pretty seldom. : : $ find /usr/share/man/cat* -type f | wc -l : 3277 : $uname -v : FreeBSD 5.0-CURRENT #0: Sat Sep 30 17:31:17 CST 2000 grog@wantadilla.lemis.com:/src/FreeBSD/WANTADILLA/src/sys/compile/WANTADILLA : : That's about 7.5 man pages per day. This is on my main machine, and I : suspect I use man pages more than most. : : More to the point, how many broken /usr file systems have you *ever* : had with FreeBSD? Maybe 5. I've rarely had one when / wasn't also broken. :-) However, the argument for /usr is more than just that it is for crash recovery. I'd have fewer if /usr was mounted read only (which it can't be for the man page issue, and other problems). We mount / read only on our embedded systems and combine / and /usr onto one partition and like everything dynamic. We also mount /var on MFS and have a read/write /mod for things that change (but that can be recovered by some means, should we need to newfs things). The argument is that if / is small, the chances of it being corrupt are smaller and the risk is lower of using it as an unchecked file system. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 15:23:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 92BD237B416; Tue, 11 Dec 2001 15:23:18 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBBNNHs150002; Tue, 11 Dec 2001 18:23:17 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011212090610.D67986@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> <20011212090610.D67986@monorchid.lemis.com> Date: Tue, 11 Dec 2001 18:23:15 -0500 To: Greg Lehey , Warner Losh From: Garance A Drosihn Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:06 AM +1030 12/12/01, Greg Lehey wrote: >On Tuesday, 11 Dec 2001, Warner Losh wrote: > > I suspect, however, that we'll find that crash recovery really is a >> big factor since /usr does get written to on every man command that >> generates a new man page... > >That's pretty seldom. > > $ find /usr/share/man/cat* -type f | wc -l > 3277 In the land of weird suggestions, just how weird would it be to suggest that we create some way for 'cat' versions of man pages to land somewhere else? Maybe /var/man/usr/share/cat* for ones from /usr/share/man/man* etc? I'm not suggesting this, of course. I'm just asking how weird it would be if someone *were* to suggest it... Or is there any other way to get the same effect? (I don't think this makes much difference for the question of corrupted partitions, but I just like the idea of trying to get it so /usr is written to less often. I've sometimes thought I should try this with a bunch of symlinks, but that gets messy given all the different sources for man pages) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 15:57:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id C4FBD37B41B; Tue, 11 Dec 2001 15:57:51 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.6/8.11.6) id fBBNiXR02635; Tue, 11 Dec 2001 23:44:33 GMT (envelope-from nik) Date: Tue, 11 Dec 2001 23:44:33 +0000 From: Nik Clayton To: Garance A Drosihn Cc: Greg Lehey , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011211234433.B697@clan.nothing-going-on.org> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> <20011212090610.D67986@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Tue, Dec 11, 2001 at 06:23:15PM -0500 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2001 at 06:23:15PM -0500, Garance A Drosihn wrote: > In the land of weird suggestions, just how weird would it be to > suggest that we create some way for 'cat' versions of man pages > to land somewhere else? >=20 > Maybe /var/man/usr/share/cat* > for ones from /usr/share/man/man* > etc? Sounds like a good idea. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwWmmEACgkQk6gHZCw343XHnwCgkqXkzkiFjog1pr2gitoH7MrK O9sAniqu0vPMxNgsC28zrbMFU2a7X+cG =H5nm -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 16:16:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id C34FC37B41B; Tue, 11 Dec 2001 16:16:13 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212001613.JHUN24045.rwcrmhc53.attbi.com@peter3.wemm.org>; Wed, 12 Dec 2001 00:16:13 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fBC0GAs40877; Tue, 11 Dec 2001 16:16:10 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9AEA739EA; Tue, 11 Dec 2001 16:16:10 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Nik Clayton Cc: Garance A Drosihn , Greg Lehey , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: <20011211234433.B697@clan.nothing-going-on.org> Date: Tue, 11 Dec 2001 16:16:10 -0800 From: Peter Wemm Message-Id: <20011212001610.9AEA739EA@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nik Clayton wrote: > > --gj572EiMnwbLXET9 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Dec 11, 2001 at 06:23:15PM -0500, Garance A Drosihn wrote: > > In the land of weird suggestions, just how weird would it be to > > suggest that we create some way for 'cat' versions of man pages > > to land somewhere else? > >=20 > > Maybe /var/man/usr/share/cat* > > for ones from /usr/share/man/man* > > etc? > > Sounds like a good idea. I for one would like it a lot. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 18:47:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id A9A3437B416 for ; Tue, 11 Dec 2001 18:47:36 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 11F70786E3; Wed, 12 Dec 2001 13:17:35 +1030 (CST) Date: Wed, 12 Dec 2001 13:17:35 +1030 From: Greg Lehey To: Garance A Drosihn Cc: Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011212131734.B82733@monorchid.lemis.com> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> <20011212090610.D67986@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, 11 December 2001 at 18:23:15 -0500, Garance A Drosihn wrote: > At 9:06 AM +1030 12/12/01, Greg Lehey wrote: >> On Tuesday, 11 Dec 2001, Warner Losh wrote: >>> I suspect, however, that we'll find that crash recovery really is a >>> big factor since /usr does get written to on every man command that >>> generates a new man page... >> >> That's pretty seldom. >> >> $ find /usr/share/man/cat* -type f | wc -l >> 3277 > > In the land of weird suggestions, just how weird would it be to > suggest that we create some way for 'cat' versions of man pages > to land somewhere else? > > Maybe /var/man/usr/share/cat* > for ones from /usr/share/man/man* This seems to make a lot of sense. If we could find a way to make a / file system (including /usr) read only, this would be a great advantage. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 21: 3:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id B354337B41B for ; Tue, 11 Dec 2001 21:03:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBC59Qk07926; Tue, 11 Dec 2001 21:09:26 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112120509.fBC59Qk07926@mass.dis.org> To: Warner Losh Cc: freebsd-arch@FreeBSD.org Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: Message from Warner Losh of "Tue, 11 Dec 2001 15:40:37 MST." <200112112240.fBBMebM31038@harmony.village.org> Date: Tue, 11 Dec 2001 21:09:26 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > However, the argument for /usr is more than just that it is for crash > recovery. It is? Sounds like there are lots of retconned reasons that could equally easily be worked around. 8) > I'd have fewer if /usr was mounted read only (which it > can't be for the man page issue, and other problems). For manpages, we should be using /var/man/catman. I'm not sure what other problems you're referring to; perhaps enumerating them would help? > The argument is that if / is small, the chances of it being corrupt > are smaller and the risk is lower of using it as an unchecked file > system. The counter-argument is that making it "small" doesn't help it much, wheras making it "passive" (readonly) would. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Dec 11 21:10:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4E0E037B405; Tue, 11 Dec 2001 21:10:16 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBC5AFa83787; Tue, 11 Dec 2001 22:10:15 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBC5AEM33040; Tue, 11 Dec 2001 22:10:14 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112120510.fBC5AEM33040@harmony.village.org> To: Mike Smith Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: freebsd-arch@FreeBSD.org In-reply-to: Your message of "Tue, 11 Dec 2001 21:09:26 PST." <200112120509.fBC59Qk07926@mass.dis.org> References: <200112120509.fBC59Qk07926@mass.dis.org> Date: Tue, 11 Dec 2001 22:10:14 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200112120509.fBC59Qk07926@mass.dis.org> Mike Smith writes: : > However, the argument for /usr is more than just that it is for crash : > recovery. : : It is? Sounds like there are lots of retconned reasons that could : equally easily be worked around. 8) Well, small / is useful for NFS situations as well, but those can be worked around. : > I'd have fewer if /usr was mounted read only (which it : > can't be for the man page issue, and other problems). : : For manpages, we should be using /var/man/catman. I'm not sure what : other problems you're referring to; perhaps enumerating them would help? /var/tmp sometimes is a symlink to /usr/tmp. /usr/local gets lots of things written to it by many packages. /usr/src and /usr/obj present minor problem. I know that a few other things write to /usr, but I don't recall them. I remember having to move things off /usr when I made it readonly for a real system. Also, /var is traditionally undersized for catman. We can fix that in new installs, but the long dead of the past makes it a little hard to retrofit into old systems. : > The argument is that if / is small, the chances of it being corrupt : > are smaller and the risk is lower of using it as an unchecked file : > system. : : The counter-argument is that making it "small" doesn't help it much, : wheras making it "passive" (readonly) would. Well, making it small makes it fast to recover too. I'm not trying to be difficult, btw. I just happen to like /,/usr separte based on the number of problems I've had in the past making /usr readonly on a large system. Most can be worked around, but there are a number of minor things that you need to find the hard way. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 8:22:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hal-4.inet.it (hal-4.inet.it [213.92.5.23]) by hub.freebsd.org (Postfix) with ESMTP id 849F437B417 for ; Wed, 12 Dec 2001 08:22:08 -0800 (PST) Received: (from root@localhost) by hal-4.inet.it (8.11.1/8.11.1) id fBCGM7o263130 for ; Wed, 12 Dec 2001 17:22:07 +0100 Received: from acampi.inet.it(213.92.1.165) by hal-4.inet.it via I-SMTP-4.0.3-100 id s-213.92.1.165-lDUXUD; Wed Dec 12 17:22:07 2001 Received: from webcom.it (brian.inet.it [213.92.1.190]) by acampi.inet.it (Postfix) with SMTP id 2B9EA15533 for ; Wed, 12 Dec 2001 17:22:06 +0100 (CET) Received: (qmail 14862 invoked by uid 1000); 12 Dec 2001 16:22:04 -0000 Date: Wed, 12 Dec 2001 17:22:03 +0100 From: Andrea Campi To: Bakul Shah Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... Message-ID: <20011212162203.GA9595@webcom.it> References: <200112092050.PAA26830@glatton.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112092050.PAA26830@glatton.cnchost.com> User-Agent: Mutt/1.3.24i X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG #include I was able to simple boot to single user and growfs my / without any magic. I *might* have changed it to read-only just for safety but I don't think so. After that of course I rebooted immediately... Bye, Andrea On Sun, Dec 09, 2001 at 12:50:49PM -0800, Bakul Shah wrote: > Changing sysinstall helps new installations but doesn't help > existing systems with a "tiny" root fs -- something I had to > fix recently. I was surprised to see how easy it was! > > Here is the procedure I used, in case anyone else needs to do > the same. Assume ad0s1a is the root filesystem and ad0s1b is > the swap partition and its size is atleast new root fs size + > old root fs size. Do this as single user on a freshly booted > system. > > 1. disklabel ad0s1 > label # save a copy of the disklabel > 2. disklabel -e ad0s1 > if the new root size is N, change the b partition to start at offset N. > make its size the same as partition a and make its type 4.2BSD type. > 3. dd /dev/ad0s1b bs=1m > 4. fsck /dev/ad0s1b > 5. echo 'boot_askname="YES"' >> /boot/loader.conf > 6. shutdown -r now > 7. boot in single user mode and when asked, choose the b partition as root. > 8. disklabel -e ad0s1 > change 'a' partition size to N. > 9. growfs -s N /dev/ad0s1a > 10. fsck /dev/ad0s1a # just to convince yourself everything is okay > 11. shutdown -r now > 12. boot in single user mode and when aske, choose the a partition as root. > 13. disklabel -e ad0s1 > restore the swap partition (to its new reduced size) > 14. remove the change to /boot/loader.conf made in step 5. > 15. reboot > > If there is an easier way, I'd like to hear about it. In > particular if / can be switched at runtime, all of this can > be done in one program without so many reboots. One can even > write a program to shuffle filesystems around to grow any fs > so long as there is some space somewhere! > > Disclaimer: use at your own risk. make backups and keep a > cleenex handy in case you screw up. make notes while doing > this to aid in debugging in case things go wrong. > > growfs should take an optional argument -A (for Auto :-) to > grow a fs to fill up the partition. growfs needs to be > renamed grow_ufs in case in future growfs is extended to grow > other fs types. Ditto for newfs, dumpfs, tunafish and so on. > > -- bakul > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Weird enough for government work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 8:42:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id 8F2DC37B417 for ; Wed, 12 Dec 2001 08:41:48 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id KAA00272 for ; Wed, 12 Dec 2001 10:42:04 -0600 (CST) Message-ID: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> From: "Jim Fleming" To: Subject: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 10:54:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This may help... http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Charlie Root" To: Sent: Wednesday, December 12, 2001 4:45 AM > diff -c -r /unir/sys/netinet/ip.h netinet/ip.h > *** /unir/sys/netinet/ip.h Wed Dec 22 19:13:20 1999 > --- netinet/ip.h Tue Dec 11 13:59:38 2001 > *************** > *** 43,48 **** > --- 43,53 ---- > */ > #define IPVERSION 4 > > + #define IPXX_V4 4 > + #define IPXX_V5 5 > + #define IPXX_V7 7 > + #define IPXX_V8 8 > + > /* > * Structure of an internet header, naked of options. > */ > *************** > *** 61,73 **** > #endif /* not _IP_VHL */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > ! u_short ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > #define IP_RF 0x8000 /* reserved fragment flag */ > #define IP_DF 0x4000 /* dont fragment flag */ > #define IP_MF 0x2000 /* more fragments flag */ > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > u_char ip_ttl; /* time to live */ > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > --- 66,89 ---- > #endif /* not _IP_VHL */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > ! #define IPXX_UNIRVERSE_DEFAULT 0 /* Default IPv8 UnirVerse Value */ > ! u_char ip_gate; /* UnirVerse/StarGate */ > ! u_char ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > + #define IPXX_FLAG 0x8000 /* IPvXX flag */ > #define IP_RF 0x8000 /* reserved fragment flag */ > #define IP_DF 0x4000 /* dont fragment flag */ > #define IP_MF 0x2000 /* more fragments flag */ > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > u_char ip_ttl; /* time to live */ > + #define IPXX_GALAXY 033 /* IPv8 Galaxy Value for 3:219 .INFO */ > + #define IPXX_P_MASK 0x3F > + #define IPXX_ICMP_VAL 1 > + #define IPXX_ICMP_FLAG 0x40 > + #define IPXX_TCP_VAL 6 > + #define IPXX_TCP_FLAG 0x80 > + #define IPXX_UDP_VAL 16 > + #define IPXX_UDP_FLAG 0xC0 > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > diff -c -r /unir/sys/netinet/ip_icmp.c netinet/ip_icmp.c > *** /unir/sys/netinet/ip_icmp.c Tue Jul 3 11:01:46 2001 > --- netinet/ip_icmp.c Tue Dec 11 14:00:00 2001 > *************** > *** 121,132 **** > #endif > > static void icmp_reflect __P((struct mbuf *)); > ! static void icmp_send __P((struct mbuf *, struct mbuf *)); > static int ip_next_mtu __P((int, int)); > > extern struct protosw inetsw[]; > > /* > * Generate an error packet of type error > * in response to bad packet ip. > */ > --- 121,396 ---- > #endif > > static void icmp_reflect __P((struct mbuf *)); > ! static void icmp_send __P((struct mbuf *, struct mbuf *, int)); > static int ip_next_mtu __P((int, int)); > > extern struct protosw inetsw[]; > > /* > + * Table used to reverse the 4-bit source and destination values > + * in the 8-bit TOS field. > + */ > + > + unsigned char reverse_nibbles[256] = { > + /*00*/ 0x00, > + /*01*/ 0x10, > + /*02*/ 0x20, > + /*03*/ 0x30, > + /*04*/ 0x40, > + /*05*/ 0x50, > + /*06*/ 0x60, > + /*07*/ 0x70, > + /*08*/ 0x80, > + /*09*/ 0x90, > + /*0a*/ 0xa0, > + /*0b*/ 0xb0, > + /*0c*/ 0xc0, > + /*0d*/ 0xd0, > + /*0e*/ 0xe0, > + /*0f*/ 0xf0, > + /*10*/ 0x01, > + /*11*/ 0x11, > + /*12*/ 0x21, > + /*13*/ 0x31, > + /*14*/ 0x41, > + /*15*/ 0x51, > + /*16*/ 0x61, > + /*17*/ 0x71, > + /*18*/ 0x81, > + /*19*/ 0x91, > + /*1a*/ 0xa1, > + /*1b*/ 0xb1, > + /*1c*/ 0xc1, > + /*1d*/ 0xd1, > + /*1e*/ 0xe1, > + /*1f*/ 0xf1, > + /*20*/ 0x02, > + /*21*/ 0x12, > + /*22*/ 0x22, > + /*23*/ 0x32, > + /*24*/ 0x42, > + /*25*/ 0x52, > + /*26*/ 0x62, > + /*27*/ 0x72, > + /*28*/ 0x82, > + /*29*/ 0x92, > + /*2a*/ 0xa2, > + /*2b*/ 0xb2, > + /*2c*/ 0xc2, > + /*2d*/ 0xd2, > + /*2e*/ 0xe2, > + /*2f*/ 0xf2, > + /*30*/ 0x03, > + /*31*/ 0x13, > + /*32*/ 0x23, > + /*33*/ 0x33, > + /*34*/ 0x43, > + /*35*/ 0x53, > + /*36*/ 0x63, > + /*37*/ 0x73, > + /*38*/ 0x83, > + /*39*/ 0x93, > + /*3a*/ 0xa3, > + /*3b*/ 0xb3, > + /*3c*/ 0xc3, > + /*3d*/ 0xd3, > + /*3e*/ 0xe3, > + /*3f*/ 0xf3, > + /*40*/ 0x04, > + /*41*/ 0x14, > + /*42*/ 0x24, > + /*43*/ 0x34, > + /*44*/ 0x44, > + /*45*/ 0x54, > + /*46*/ 0x64, > + /*47*/ 0x74, > + /*48*/ 0x84, > + /*49*/ 0x94, > + /*4a*/ 0xa4, > + /*4b*/ 0xb4, > + /*4c*/ 0xc4, > + /*4d*/ 0xd4, > + /*4e*/ 0xe4, > + /*4f*/ 0xf4, > + /*50*/ 0x05, > + /*51*/ 0x15, > + /*52*/ 0x25, > + /*53*/ 0x35, > + /*54*/ 0x45, > + /*55*/ 0x55, > + /*56*/ 0x65, > + /*57*/ 0x75, > + /*58*/ 0x85, > + /*59*/ 0x95, > + /*5a*/ 0xa5, > + /*5b*/ 0xb5, > + /*5c*/ 0xc5, > + /*5d*/ 0xd5, > + /*5e*/ 0xe5, > + /*5f*/ 0xf5, > + /*60*/ 0x06, > + /*61*/ 0x16, > + /*62*/ 0x26, > + /*63*/ 0x36, > + /*64*/ 0x46, > + /*65*/ 0x56, > + /*66*/ 0x66, > + /*67*/ 0x76, > + /*68*/ 0x86, > + /*69*/ 0x96, > + /*6a*/ 0xa6, > + /*6b*/ 0xb6, > + /*6c*/ 0xc6, > + /*6d*/ 0xd6, > + /*6e*/ 0xe6, > + /*6f*/ 0xf6, > + /*70*/ 0x07, > + /*71*/ 0x17, > + /*72*/ 0x27, > + /*73*/ 0x37, > + /*74*/ 0x47, > + /*75*/ 0x57, > + /*76*/ 0x67, > + /*77*/ 0x77, > + /*78*/ 0x87, > + /*79*/ 0x97, > + /*7a*/ 0xa7, > + /*7b*/ 0xb7, > + /*7c*/ 0xc7, > + /*7d*/ 0xd7, > + /*7e*/ 0xe7, > + /*7f*/ 0xf7, > + /*80*/ 0x08, > + /*81*/ 0x18, > + /*82*/ 0x28, > + /*83*/ 0x38, > + /*84*/ 0x48, > + /*85*/ 0x58, > + /*86*/ 0x68, > + /*87*/ 0x78, > + /*88*/ 0x88, > + /*89*/ 0x98, > + /*8a*/ 0xa8, > + /*8b*/ 0xb8, > + /*8c*/ 0xc8, > + /*8d*/ 0xd8, > + /*8e*/ 0xe8, > + /*8f*/ 0xf8, > + /*90*/ 0x09, > + /*91*/ 0x19, > + /*92*/ 0x29, > + /*93*/ 0x39, > + /*94*/ 0x49, > + /*95*/ 0x59, > + /*96*/ 0x69, > + /*97*/ 0x79, > + /*98*/ 0x89, > + /*99*/ 0x99, > + /*9a*/ 0xa9, > + /*9b*/ 0xb9, > + /*9c*/ 0xc9, > + /*9d*/ 0xd9, > + /*9e*/ 0xe9, > + /*9f*/ 0xf9, > + /*a0*/ 0x0a, > + /*a1*/ 0x1a, > + /*a2*/ 0x2a, > + /*a3*/ 0x3a, > + /*a4*/ 0x4a, > + /*a5*/ 0x5a, > + /*a6*/ 0x6a, > + /*a7*/ 0x7a, > + /*a8*/ 0x8a, > + /*a9*/ 0x9a, > + /*aa*/ 0xaa, > + /*ab*/ 0xba, > + /*ac*/ 0xca, > + /*ad*/ 0xda, > + /*ae*/ 0xea, > + /*af*/ 0xfa, > + /*b0*/ 0x0b, > + /*b1*/ 0x1b, > + /*b2*/ 0x2b, > + /*b3*/ 0x3b, > + /*b4*/ 0x4b, > + /*b5*/ 0x5b, > + /*b6*/ 0x6b, > + /*b7*/ 0x7b, > + /*b8*/ 0x8b, > + /*b9*/ 0x9b, > + /*ba*/ 0xab, > + /*bb*/ 0xbb, > + /*bc*/ 0xcb, > + /*bd*/ 0xdb, > + /*be*/ 0xeb, > + /*bf*/ 0xfb, > + /*c0*/ 0x0c, > + /*c1*/ 0x1c, > + /*c2*/ 0x2c, > + /*c3*/ 0x3c, > + /*c4*/ 0x4c, > + /*c5*/ 0x5c, > + /*c6*/ 0x6c, > + /*c7*/ 0x7c, > + /*c8*/ 0x8c, > + /*c9*/ 0x9c, > + /*ca*/ 0xac, > + /*cb*/ 0xbc, > + /*cc*/ 0xcc, > + /*cd*/ 0xdc, > + /*ce*/ 0xec, > + /*cf*/ 0xfc, > + /*d0*/ 0x0d, > + /*d1*/ 0x1d, > + /*d2*/ 0x2d, > + /*d3*/ 0x3d, > + /*d4*/ 0x4d, > + /*d5*/ 0x5d, > + /*d6*/ 0x6d, > + /*d7*/ 0x7d, > + /*d8*/ 0x8d, > + /*d9*/ 0x9d, > + /*da*/ 0xad, > + /*db*/ 0xbd, > + /*dc*/ 0xcd, > + /*dd*/ 0xdd, > + /*de*/ 0xed, > + /*df*/ 0xfd, > + /*e0*/ 0x0e, > + /*e1*/ 0x1e, > + /*e2*/ 0x2e, > + /*e3*/ 0x3e, > + /*e4*/ 0x4e, > + /*e5*/ 0x5e, > + /*e6*/ 0x6e, > + /*e7*/ 0x7e, > + /*e8*/ 0x8e, > + /*e9*/ 0x9e, > + /*ea*/ 0xae, > + /*eb*/ 0xbe, > + /*ec*/ 0xce, > + /*ed*/ 0xde, > + /*ee*/ 0xee, > + /*ef*/ 0xfe, > + /*f0*/ 0x0f, > + /*f1*/ 0x1f, > + /*f2*/ 0x2f, > + /*f3*/ 0x3f, > + /*f4*/ 0x4f, > + /*f5*/ 0x5f, > + /*f6*/ 0x6f, > + /*f7*/ 0x7f, > + /*f8*/ 0x8f, > + /*f9*/ 0x9f, > + /*fa*/ 0xaf, > + /*fb*/ 0xbf, > + /*fc*/ 0xcf, > + /*fd*/ 0xdf, > + /*fe*/ 0xef, > + /*ff*/ 0xff > + }; > + > + /* > * Generate an error packet of type error > * in response to bad packet ip. > */ > *************** > *** 226,232 **** > nip->ip_len = m->m_len; > nip->ip_vhl = IP_VHL_BORING; > nip->ip_p = IPPROTO_ICMP; > ! nip->ip_tos = 0; > icmp_reflect(m); > > freeit: > --- 490,496 ---- > nip->ip_len = m->m_len; > nip->ip_vhl = IP_VHL_BORING; > nip->ip_p = IPPROTO_ICMP; > ! nip->ip_tos = 0x44; /* Network Management Flow */ > icmp_reflect(m); > > freeit: > *************** > *** 610,615 **** > --- 874,880 ---- > struct in_addr t; > struct mbuf *opts = 0; > int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); > + int flags = 0; > > if (!in_canforward(ip->ip_src) && > ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) != > *************** > *** 617,622 **** > --- 882,895 ---- > m_freem(m); /* Bad return address */ > goto done; /* Ip_output() will check for broadcast */ > } > + /* Handle IPv8 TOS and UnirVerse fields */ > + if(((ip->ip_tos&0xF0)!=0) && ((ip->ip_tos&0x0F)!=0)){ > + ip->ip_tos = reverse_nibbles[ip->ip_tos]; > + if(ip->ip_gate != IPXX_UNIRVERSE_DEFAULT){ > + ip->ip_gate = reverse_nibbles[ip->ip_gate]; > + flags |= IP_UNIRVERSE_SET; > + } > + } > t = ip->ip_dst; > ip->ip_dst = ip->ip_src; > /* > *************** > *** 719,725 **** > (unsigned)(m->m_len - sizeof(struct ip))); > } > m->m_flags &= ~(M_BCAST|M_MCAST); > ! icmp_send(m, opts); > done: > if (opts) > (void)m_free(opts); > --- 992,998 ---- > (unsigned)(m->m_len - sizeof(struct ip))); > } > m->m_flags &= ~(M_BCAST|M_MCAST); > ! icmp_send(m,opts,flags); > done: > if (opts) > (void)m_free(opts); > *************** > *** 730,738 **** > * after supplying a checksum. > */ > static void > ! icmp_send(m, opts) > register struct mbuf *m; > struct mbuf *opts; > { > register struct ip *ip = mtod(m, struct ip *); > register int hlen; > --- 1003,1012 ---- > * after supplying a checksum. > */ > static void > ! icmp_send(m,opts,flags) > register struct mbuf *m; > struct mbuf *opts; > + int flags; > { > register struct ip *ip = mtod(m, struct ip *); > register int hlen; > *************** > *** 757,763 **** > } > #endif > bzero(&ro, sizeof ro); > ! (void) ip_output(m, opts, &ro, 0, NULL); > if (ro.ro_rt) > RTFREE(ro.ro_rt); > } > --- 1031,1037 ---- > } > #endif > bzero(&ro, sizeof ro); > ! (void) ip_output(m, opts, &ro, flags, NULL); > if (ro.ro_rt) > RTFREE(ro.ro_rt); > } > diff -c -r /unir/sys/netinet/ip_input.c netinet/ip_input.c > *** /unir/sys/netinet/ip_input.c Wed Aug 29 21:41:37 2001 > --- netinet/ip_input.c Wed Dec 12 09:57:20 2001 > *************** > *** 258,266 **** > maxnipq = nmbclusters / 4; > ip_maxfragpackets = nmbclusters / 4; > > - #ifndef RANDOM_IP_ID > ip_id = time_second & 0xffff; > ! #endif > ipintrq.ifq_maxlen = ipqmaxlen; > > register_netisr(NETISR_IP, ipintr); > --- 258,275 ---- > maxnipq = nmbclusters / 4; > ip_maxfragpackets = nmbclusters / 4; > > ip_id = time_second & 0xffff; > ! /* initialize all the StarGate id counters */ > ! for(i=0; i<256; i++){ > ! ip_id_[i] = time_second & 0xffff; > ! } > ! for(i=0; i<65536; i++){ > ! src_gate[i] = 0x00; > ! dst_gate[i] = 0x00; > ! } > ! galaxy_in=0; > ! galaxy_out=0; > ! > ipintrq.ifq_maxlen = ipqmaxlen; > > register_netisr(NETISR_IP, ipintr); > *************** > *** 269,274 **** > --- 278,285 ---- > static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; > static struct route ipforward_rt; > > + extern unsigned char reverse_nibbles[]; > + > /* > * Ip input routine. Checksum and byte swap header. If fragmented > * try to reassemble. Process options. Pass to next level. > *************** > *** 287,292 **** > --- 298,305 ---- > u_int32_t divert_info = 0; /* packet divert/tee info */ > #endif > struct ip_fw_chain *rule = NULL; > + u_int32_t src_addr; > + u_int32_t dst_addr; > > #ifdef IPDIVERT > /* Get and reset firewall cookie */ > *************** > *** 346,351 **** > --- 359,365 ---- > ip = mtod(m, struct ip *); > } > > + > /* 127/8 must not appear on wire - RFC1122 */ > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { > *************** > *** 402,407 **** > --- 416,483 ---- > if (ipsec_gethist(m, NULL)) > goto pass; > #endif > + > + /* Process IPvXX ICMP++ packets that are special QoS codes */ > + if((ip->ip_p==IPPROTO_ICMP) && (((ip->ip_tos&0xF0)==0)||((ip->ip_tos&0x0F)==0))){ > + src_addr = ntohl(ip->ip_src.s_addr); > + dst_addr = ntohl(ip->ip_dst.s_addr); > + /* QoS(4)=Network Management */ > + switch(ip->ip_tos){ > + case 0x04: > + /* Check for Galaxy PeaceKeeper */ > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > + if((src_addr&0x1F0F)==0){ > + dst_gate[src_addr>>16] >>= 4; > + dst_gate[src_addr>>16] |= src_addr&0xF0; > + /* Check for possible new Galaxy setting */ > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > + galaxy_out=(src_addr&0x0E00)>>8; > + log(LOG_WARNING,"Outbound Galactic Routing set to %d\n",galaxy_out); > + } > + else{ > + galaxy_out=0; > + } > + } > + break; > + case 0x40: > + /* Check for Galaxy PeaceKeeper */ > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > + if((src_addr&0x1F0F)==0){ > + src_gate[src_addr>>16] >>= 4; > + src_gate[src_addr>>16] |= src_addr&0xF0; > + /* Check for possible new Galaxy setting */ > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > + galaxy_in=(src_addr&0x0E00)>>8; > + log(LOG_WARNING,"Inbound Galactic Routing set to %d\n",galaxy_in); > + } > + else{ > + galaxy_in=0; > + } > + } > + break; > + default: > + log(LOG_WARNING,"Unknown ICMP+ QoS Code from %s\n", > + inet_ntoa(ip->ip_src)); > + } > + } > + /* Process IPvXX-style Packets */ > + if((ip->ip_off&0x8000)!=0){ > + /* Process non-Galaxy 0 Packets */ > + if(((ip->ip_p&0xC0) != 0)&& > + ((ip->ip_p&0x07) != galaxy_in)){ > + printf("Dropped packet not from our galaxy\n"); > + ipstat.ips_badaddr++; > + goto bad; > + } > + else{ > + /* Packet is Galaxy 0, are we ? */ > + if(galaxy_in != 0){ > + printf("Dropped packet not from our galaxy\n"); > + ipstat.ips_badaddr++; > + goto bad; > + } > + } > + } > > /* > * IpHack's section. > diff -c -r /unir/sys/netinet/ip_mroute.c netinet/ip_mroute.c > *** /unir/sys/netinet/ip_mroute.c Thu Jul 19 06:37:26 2001 > --- netinet/ip_mroute.c Tue Dec 11 14:00:20 2001 > *************** > *** 1581,1590 **** > */ > ip_copy = mtod(mb_copy, struct ip *); > *ip_copy = multicast_encap_iphdr; > #ifdef RANDOM_IP_ID > ip_copy->ip_id = ip_randomid(); > #else > ! ip_copy->ip_id = htons(ip_id++); > #endif > ip_copy->ip_len += len; > ip_copy->ip_src = vifp->v_lcl_addr; > --- 1581,1597 ---- > */ > ip_copy = mtod(mb_copy, struct ip *); > *ip_copy = multicast_encap_iphdr; > + ip_copy->ip_gate=0; > #ifdef RANDOM_IP_ID > ip_copy->ip_id = ip_randomid(); > #else > ! if(ip_copy->ip_tos != 0){ > ! ip_copy->ip_id = ip_id_[ip_copy->ip_gate]++; > ! } > ! else{ > ! ip_copy->ip_id = ip_id++; > ! ip_copy->ip_gate = ip_id>>8; > ! } > #endif > ip_copy->ip_len += len; > ip_copy->ip_src = vifp->v_lcl_addr; > diff -c -r /unir/sys/netinet/ip_output.c netinet/ip_output.c > *** /unir/sys/netinet/ip_output.c Thu Jul 19 06:37:26 2001 > --- netinet/ip_output.c Wed Dec 12 10:28:11 2001 > *************** > *** 52,57 **** > --- 52,58 ---- > #include > #include > #include > + #include > > #include > #include > *************** > *** 88,101 **** > #include > #endif > > ! #ifdef IPFIREWALL_FORWARD_DEBUG > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld",(ntohl(a.s_addr)>>24)&0xFF,\ > (ntohl(a.s_addr)>>16)&0xFF,\ > (ntohl(a.s_addr)>>8)&0xFF,\ > (ntohl(a.s_addr))&0xFF); > - #endif > > u_short ip_id; > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > --- 89,105 ---- > #include > #endif > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld ",(ntohl(a.s_addr)>>24)&0xFF,\ > (ntohl(a.s_addr)>>16)&0xFF,\ > (ntohl(a.s_addr)>>8)&0xFF,\ > (ntohl(a.s_addr))&0xFF); > > u_short ip_id; > + u_char ip_id_[256]; > + u_char src_gate[65536]; > + u_char dst_gate[65536]; > + u_char galaxy_out; > + u_char galaxy_in; > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > *************** > *** 127,132 **** > --- 131,137 ---- > int flags; > struct ip_moptions *imo; > { > + struct timeval random_time; > struct ip *ip, *mhip; > struct ifnet *ifp; > struct mbuf *m = m0; > *************** > *** 207,219 **** > /* > * Fill in IP header. > */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > ip->ip_off &= IP_DF; > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! ip->ip_id = htons(ip_id++); > #endif > ipstat.ips_localout++; > } else { > --- 212,252 ---- > /* > * Fill in IP header. > */ > + > + /* Set UnirVerse on QoS-agile Packets */ > + if(ip->ip_tos != 0){ > + /* Allow reflectors and forwarders to prevent setting */ > + if((flags & IP_UNIRVERSE_SET) == 0){ > + getmicrotime(&random_time); > + if(random_time.tv_usec&0x01){ > + ip->ip_gate = > + ((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])&0xF0) | > + (((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])>>4)&0x0F); > + } > + else{ > + ip->ip_gate = > + (((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])<<4)&0xF0) | > + ((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])&0x0F); > + } > + } > + } > + else{ > + ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > + } > + /* Set id based on UnirVerse */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > ip->ip_off &= IP_DF; > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! if(ip->ip_tos != 0){ > ! ip->ip_id = ip_id_[ip->ip_gate]++; > ! } > ! else{ > ! ip->ip_id = ip_id++; > ! ip->ip_gate = ip_id>>8; > ! } > #endif > ipstat.ips_localout++; > } else { > *************** > *** 431,436 **** > --- 464,470 ---- > } > > sendit: > + > #ifdef IPSEC > /* get SP for this packet */ > if (so == NULL) > diff -c -r /unir/sys/netinet/ip_var.h netinet/ip_var.h > *** /unir/sys/netinet/ip_var.h Thu Jul 19 06:37:26 2001 > --- netinet/ip_var.h Tue Dec 11 14:00:41 2001 > *************** > *** 133,138 **** > --- 133,140 ---- > /* flags passed to ip_output as last parameter */ > #define IP_FORWARDING 0x1 /* most of ip header exists */ > #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ > + #define IP_UNIRVERSE_SET 0x4 /* UnirVerse set in header */ > + > #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ > #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ > > *************** > *** 142,150 **** > struct sockopt; > > extern struct ipstat ipstat; > ! #ifndef RANDOM_IP_ID > ! extern u_short ip_id; /* ip packet ctr, for ids */ > ! #endif > extern int ip_defttl; /* default IP ttl */ > extern int ipforwarding; /* ip forwarding */ > extern u_char ip_protox[]; > --- 144,157 ---- > struct sockopt; > > extern struct ipstat ipstat; > ! > ! extern u_short ip_id; /* ip packet ctr, for ids */ > ! extern u_char ip_id_[]; /* id counters for each StarGate */ > ! extern u_char src_gate[]; > ! extern u_char dst_gate[]; > ! extern u_char galaxy_in; > ! extern u_char galaxy_out; > ! > extern int ip_defttl; /* default IP ttl */ > extern int ipforwarding; /* ip forwarding */ > extern u_char ip_protox[]; > diff -c -r /unir/sys/netinet/raw_ip.c netinet/raw_ip.c > *** /unir/sys/netinet/raw_ip.c Sun Jul 29 19:32:40 2001 > --- netinet/raw_ip.c Tue Dec 11 14:01:10 2001 > *************** > *** 239,249 **** > m_freem(m); > return EINVAL; > } > - if (ip->ip_id == 0) > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! ip->ip_id = htons(ip_id++); > #endif > /* XXX prevent ip_output from overwriting header fields */ > flags |= IP_RAWOUTPUT; > --- 239,259 ---- > m_freem(m); > return EINVAL; > } > #ifdef RANDOM_IP_ID > + if (ip->ip_id == 0){ > ip->ip_id = ip_randomid(); > + } > #else > ! if (ip->ip_id == 0){ > ! if(ip->ip_tos != 0){ > ! ip->ip_id = ip_id_[ip->ip_gate]++; > ! ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > ! } > ! else{ > ! ip->ip_id = ip_id++; > ! ip->ip_gate = ip_id>>8; > ! } > ! } > #endif > /* XXX prevent ip_output from overwriting header fields */ > flags |= IP_RAWOUTPUT; > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 8:47: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id B163637B417 for ; Wed, 12 Dec 2001 08:47:02 -0800 (PST) Received: (qmail 11588 invoked from network); 12 Dec 2001 16:46:48 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.63]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Dec 2001 16:46:48 -0000 Message-ID: <3C178964.9115B289@pipeline.ch> Date: Wed, 12 Dec 2001 17:44:20 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Fleming Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RIFRAF Routing Changes for FreeBSD References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG So? -- Andre Jim Fleming wrote: > > This may help... > http://www.dot-biz.com/IPv4/Tutorial/ > http://www.RepliGate.net > > The Netfilter Project: Packet Mangling for Linux 2.4 > http://netfilter.samba.org > > Jim Fleming > http://www.IPv8.info > IPv16....One Better !! > > ----- Original Message ----- > From: "Charlie Root" > To: > Sent: Wednesday, December 12, 2001 4:45 AM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 8:49: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id E0F7337B405 for ; Wed, 12 Dec 2001 08:49:00 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id KAA03733; Wed, 12 Dec 2001 10:49:13 -0600 (CST) Message-ID: <043b01c1832e$9d364b80$1000a8c0@Unir.com> From: "Jim Fleming" To: "Andre Oppermann" Cc: References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> <3C178964.9115B289@pipeline.ch> Subject: Re: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 11:01:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG RIFRAF Routing RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 Internet Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most 8-bits of the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows a PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. The 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are processed with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values to be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF can be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the packets pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained for the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" programs can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the real PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for use in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used on the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. ----- Original Message ----- From: "Andre Oppermann" To: "Jim Fleming" Cc: Sent: Wednesday, December 12, 2001 10:44 AM Subject: Re: RIFRAF Routing Changes for FreeBSD > > So? > > -- > Andre > > > Jim Fleming wrote: > > > > This may help... > > http://www.dot-biz.com/IPv4/Tutorial/ > > http://www.RepliGate.net > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > http://netfilter.samba.org > > > > Jim Fleming > > http://www.IPv8.info > > IPv16....One Better !! > > > > ----- Original Message ----- > > From: "Charlie Root" > > To: > > Sent: Wednesday, December 12, 2001 4:45 AM > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:12:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id D2D7237B41C for ; Wed, 12 Dec 2001 09:12:52 -0800 (PST) Received: (qmail 13185 invoked from network); 12 Dec 2001 17:12:38 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.63]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 12 Dec 2001 17:12:38 -0000 Message-ID: <3C178F72.1ECBE9D@pipeline.ch> Date: Wed, 12 Dec 2001 18:10:10 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Fleming Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RIFRAF Routing Changes for FreeBSD References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> <3C178964.9115B289@pipeline.ch> <043b01c1832e$9d364b80$1000a8c0@Unir.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 1. Learn how to articulate yourself 2. Read and understand the FreeBSD-arch list charter 3. Learn to state properly why you come here, what you'd like FreeBSD to and why it should do so 4. Learn how to insert line breaks after 72 chars -- Andre AO6-RIPE Jim Fleming wrote: > > RIFRAF Routing > RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 Internet > Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most 8-bits of > the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows a > PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. The > 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are processed > with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the > source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values to > be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF can > be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the packets > pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it > appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained for > the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" programs > can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing > connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the real > PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in > conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for use > in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used on > the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. > > ----- Original Message ----- > From: "Andre Oppermann" > To: "Jim Fleming" > Cc: > Sent: Wednesday, December 12, 2001 10:44 AM > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > So? > > > > -- > > Andre > > > > > > Jim Fleming wrote: > > > > > > This may help... > > > http://www.dot-biz.com/IPv4/Tutorial/ > > > http://www.RepliGate.net > > > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > > http://netfilter.samba.org > > > > > > Jim Fleming > > > http://www.IPv8.info > > > IPv16....One Better !! > > > > > > ----- Original Message ----- > > > From: "Charlie Root" > > > To: > > > Sent: Wednesday, December 12, 2001 4:45 AM > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:15:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id 8CF3437B419 for ; Wed, 12 Dec 2001 09:15:33 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id LAA16587; Wed, 12 Dec 2001 11:15:50 -0600 (CST) Message-ID: <049601c18332$513de9a0$1000a8c0@Unir.com> From: "Jim Fleming" To: "Andre Oppermann" Cc: References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> <3C178964.9115B289@pipeline.ch> <043b01c1832e$9d364b80$1000a8c0@Unir.com> <3C178F72.1ECBE9D@pipeline.ch> Subject: Re: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 11:27:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It all boils down to fairness. Which list do you think is more fair ? The "toy" IPv4 Internet Early Experimentation Allocations ? http://www.iana.org/assignments/ipv4-address-space or The Proof-of-Concept IPv8 Allocations ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Why would people pay for Address Space, when it is FREE ? Jim Fleming http://www.DOT-BIZ.com http://www.in-addr.info 3:219 INFO ----- Original Message ----- From: "Andre Oppermann" To: "Jim Fleming" Cc: Sent: Wednesday, December 12, 2001 11:10 AM Subject: Re: RIFRAF Routing Changes for FreeBSD > > 1. Learn how to articulate yourself > > 2. Read and understand the FreeBSD-arch list charter > > 3. Learn to state properly why you come here, what you'd like FreeBSD > to and why it should do so > > 4. Learn how to insert line breaks after 72 chars > > -- > Andre > > AO6-RIPE > > > Jim Fleming wrote: > > > > RIFRAF Routing > > RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 Internet > > Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most 8-bits of > > the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows a > > PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. The > > 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are processed > > with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the > > source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values to > > be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF can > > be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the packets > > pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it > > appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained for > > the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" programs > > can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing > > connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the real > > PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in > > conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for use > > in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used on > > the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. > > > > ----- Original Message ----- > > From: "Andre Oppermann" > > To: "Jim Fleming" > > Cc: > > Sent: Wednesday, December 12, 2001 10:44 AM > > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > > > So? > > > > > > -- > > > Andre > > > > > > > > > Jim Fleming wrote: > > > > > > > > This may help... > > > > http://www.dot-biz.com/IPv4/Tutorial/ > > > > http://www.RepliGate.net > > > > > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > > > http://netfilter.samba.org > > > > > > > > Jim Fleming > > > > http://www.IPv8.info > > > > IPv16....One Better !! > > > > > > > > ----- Original Message ----- > > > > From: "Charlie Root" > > > > To: > > > > Sent: Wednesday, December 12, 2001 4:45 AM > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:26:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 93FDA37B419 for ; Wed, 12 Dec 2001 09:26:12 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id fBCHQ9S45671; Wed, 12 Dec 2001 12:26:09 -0500 (EST) (envelope-from mwlucas) Date: Wed, 12 Dec 2001 12:26:09 -0500 From: Michael Lucas To: Jim Fleming Cc: Andre Oppermann , freebsd-arch@FreeBSD.ORG Subject: Re: RIFRAF Routing Changes for FreeBSD Message-ID: <20011212122609.A45600@blackhelicopters.org> References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> <3C178964.9115B289@pipeline.ch> <043b01c1832e$9d364b80$1000a8c0@Unir.com> <3C178F72.1ECBE9D@pipeline.ch> <049601c18332$513de9a0$1000a8c0@Unir.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <049601c18332$513de9a0$1000a8c0@Unir.com>; from jfleming@anet.com on Wed, Dec 12, 2001 at 11:27:46AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jim, If you're looking for opinions, you'll be much better served over in freebsd-chat. On Wed, Dec 12, 2001 at 11:27:46AM -0600, Jim Fleming wrote: > It all boils down to fairness. > Which list do you think is more fair ? > > The "toy" IPv4 Internet Early Experimentation Allocations ? > http://www.iana.org/assignments/ipv4-address-space > or > The Proof-of-Concept IPv8 Allocations ? > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > Why would people pay for Address Space, when it is FREE ? > > Jim Fleming > http://www.DOT-BIZ.com > http://www.in-addr.info > 3:219 INFO > > > ----- Original Message ----- > From: "Andre Oppermann" > To: "Jim Fleming" > Cc: > Sent: Wednesday, December 12, 2001 11:10 AM > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > 1. Learn how to articulate yourself > > > > 2. Read and understand the FreeBSD-arch list charter > > > > 3. Learn to state properly why you come here, what you'd like FreeBSD > > to and why it should do so > > > > 4. Learn how to insert line breaks after 72 chars > > > > -- > > Andre > > > > AO6-RIPE > > > > > > Jim Fleming wrote: > > > > > > RIFRAF Routing > > > RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 > Internet > > > Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most > 8-bits of > > > the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows > a > > > PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. > The > > > 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are > processed > > > with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the > > > source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values > to > > > be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF > can > > > be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the > packets > > > pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it > > > appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained > for > > > the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" > programs > > > can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing > > > connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the > real > > > PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in > > > conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for > use > > > in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used > on > > > the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. > > > > > > ----- Original Message ----- > > > From: "Andre Oppermann" > > > To: "Jim Fleming" > > > Cc: > > > Sent: Wednesday, December 12, 2001 10:44 AM > > > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > > > > > > So? > > > > > > > > -- > > > > Andre > > > > > > > > > > > > Jim Fleming wrote: > > > > > > > > > > This may help... > > > > > http://www.dot-biz.com/IPv4/Tutorial/ > > > > > http://www.RepliGate.net > > > > > > > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > > > > http://netfilter.samba.org > > > > > > > > > > Jim Fleming > > > > > http://www.IPv8.info > > > > > IPv16....One Better !! > > > > > > > > > > ----- Original Message ----- > > > > > From: "Charlie Root" > > > > > To: > > > > > Sent: Wednesday, December 12, 2001 4:45 AM > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org My FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:28:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id 5FA1037B405 for ; Wed, 12 Dec 2001 09:28:18 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id LAA22804; Wed, 12 Dec 2001 11:28:25 -0600 (CST) Message-ID: <04fd01c18334$116d5340$1000a8c0@Unir.com> From: "Jim Fleming" To: "Michael Lucas" Cc: "Andre Oppermann" , References: <041b01c1832d$9e1dbac0$1000a8c0@Unir.com> <3C178964.9115B289@pipeline.ch> <043b01c1832e$9d364b80$1000a8c0@Unir.com> <3C178F72.1ECBE9D@pipeline.ch> <049601c18332$513de9a0$1000a8c0@Unir.com> <20011212122609.A45600@blackhelicopters.org> Subject: Re: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 11:40:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Perhaps Theodore Geisel, Dr. Seuss' inventor, had the best advice, albeit not from The C@t in the Hat: "You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose." - Dr. Seuss Jim Fleming http://www.ddj.com/articles/search/search.cgi?q=fleming Oct93: The C+@ Programming Language ----- Original Message ----- From: "Michael Lucas" To: "Jim Fleming" Cc: "Andre Oppermann" ; Sent: Wednesday, December 12, 2001 11:26 AM Subject: Re: RIFRAF Routing Changes for FreeBSD > Jim, > > If you're looking for opinions, you'll be much better served over in > freebsd-chat. > > On Wed, Dec 12, 2001 at 11:27:46AM -0600, Jim Fleming wrote: > > It all boils down to fairness. > > Which list do you think is more fair ? > > > > The "toy" IPv4 Internet Early Experimentation Allocations ? > > http://www.iana.org/assignments/ipv4-address-space > > or > > The Proof-of-Concept IPv8 Allocations ? > > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > > Why would people pay for Address Space, when it is FREE ? > > > > Jim Fleming > > http://www.DOT-BIZ.com > > http://www.in-addr.info > > 3:219 INFO > > > > > > ----- Original Message ----- > > From: "Andre Oppermann" > > To: "Jim Fleming" > > Cc: > > Sent: Wednesday, December 12, 2001 11:10 AM > > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > > > > > 1. Learn how to articulate yourself > > > > > > 2. Read and understand the FreeBSD-arch list charter > > > > > > 3. Learn to state properly why you come here, what you'd like FreeBSD > > > to and why it should do so > > > > > > 4. Learn how to insert line breaks after 72 chars > > > > > > -- > > > Andre > > > > > > AO6-RIPE > > > > > > > > > Jim Fleming wrote: > > > > > > > > RIFRAF Routing > > > > RIFRAF (Remote Identification Field Random Action Filter) Routing is part of a phased approach to evolving from 32-bit IPv4 > > Internet > > > > Addressing to larger address spaces. The RIFRAF feature in an IP stack, allows for remote access control of the left-most > > 8-bits of > > > > the normally 16-bit IPv4 Identification Field. The feature is part of the IPv8 PeaceKeeper/GateKeeper series. The feature allows > > a > > > > PeaceKeeper for a /16 prefix to remotely set StarGate values in a marking engine via simple ICMP+ extensions via the TOS field. > > The > > > > 4-bit StarGate values are rotated through an 8-bit field which is used in a 50/50 coin-toss marking process as packets are > > processed > > > > with the /16 prefix. Source and Destination StarGate marking is distinct, and all 65,536 /16 prefixes have two choices for the > > > > source addresses and two choices for destination addresses. The random marking can be prevented by loading both StarGate values > > to > > > > be the same. The GateKeeper can be restored to legacy Identification Field marking by the PeaceKeeper. Packets marked via RIFRAF > > can > > > > be further routed or queued based on the marks which effectively add 4 bits to the 32-bit IPv4 legacy addresses. All of the > > packets > > > > pass transparently through legacy IPv4 equipment with no change. For legacy equipment not prepared to handle the markings, it > > > > appears as the left 8-bits of the Identification Field. For each of the 256 marking values, an independent counter is maintained > > for > > > > the right-most 8-bits of the Identification Field. There is no API required or other user-level tools. Most modern "ping" > > programs > > > > can be used to set the bits. RIFRAF can exist silently inside of the stack and be totally controlled remotely via existing > > > > connection(s) to the IPv4 private Intranets or the IPv4 Global Public Internet. Spoofing of the PeaceKeeper is possible and the > > real > > > > PeaceKeeper will receive the return reply, at which point the PeaceKeeper can restore the desired values. When RIFRAF is used in > > > > conjunction with other routing devices and on an IPv16 network, these problems can be minimized. RIFRAF is mostly intended for > > use > > > > in extending the addressing of leaf-nodes, which generally are protected behind fire-walls and NAT devices, but can also be used > > on > > > > the IPv4 Global Public Internet to increase the addressing used by edge devices on /16 networks. > > > > > > > > ----- Original Message ----- > > > > From: "Andre Oppermann" > > > > To: "Jim Fleming" > > > > Cc: > > > > Sent: Wednesday, December 12, 2001 10:44 AM > > > > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > > > > > > > > > So? > > > > > > > > > > -- > > > > > Andre > > > > > > > > > > > > > > > Jim Fleming wrote: > > > > > > > > > > > > This may help... > > > > > > http://www.dot-biz.com/IPv4/Tutorial/ > > > > > > http://www.RepliGate.net > > > > > > > > > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > > > > > http://netfilter.samba.org > > > > > > > > > > > > Jim Fleming > > > > > > http://www.IPv8.info > > > > > > IPv16....One Better !! > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Charlie Root" > > > > > > To: > > > > > > Sent: Wednesday, December 12, 2001 4:45 AM > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > > -- > Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org > My FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > http://www.blackhelicopters.org/~mwlucas/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:40:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id BD60537B41D for ; Wed, 12 Dec 2001 09:40:10 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fBCHdcq52834; Wed, 12 Dec 2001 09:39:38 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: "Jim Fleming" Cc: "Andre Oppermann" , freebsd-arch@FreeBSD.ORG Subject: Re: RIFRAF Routing Changes for FreeBSD In-Reply-To: Message from "Jim Fleming" of "Wed, 12 Dec 2001 11:27:46 CST." <049601c18332$513de9a0$1000a8c0@Unir.com> Date: Wed, 12 Dec 2001 09:39:38 -0800 Message-ID: <52830.1008178778@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > It all boils down to fairness. > Which list do you think is more fair ? I think it boils down to something simpler than that: What does this have to do with FreeBSD? The freebsd-arch list isn't for general discussion about things which _might_ be relevant to FreeBSD users, such as potentially interesting 3rd-party technologies or a great sale on hardware at Fred's PC Shack this week. This list is for discussing proposed changes to FreeBSD, ideally with sample code (which is applicable and ported to FreeBSD) attached. That's all there is to it. If you want to discuss more speculative or contraversial issues, freebsd-chat is the right mailing list for that kind of thing. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 9:43:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id 00F9D37B419 for ; Wed, 12 Dec 2001 09:42:42 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id LAA00717; Wed, 12 Dec 2001 11:42:52 -0600 (CST) Message-ID: <053301c18336$13f85900$1000a8c0@Unir.com> From: "Jim Fleming" To: "Jordan Hubbard" Cc: "Andre Oppermann" , References: <52830.1008178778@winston.freebsd.org> Subject: Re: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 11:54:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----- Original Message ----- From: "Jordan Hubbard" To: "Jim Fleming" Cc: "Andre Oppermann" ; Sent: Wednesday, December 12, 2001 11:39 AM Subject: Re: RIFRAF Routing Changes for FreeBSD > > It all boils down to fairness. > > Which list do you think is more fair ? > > I think it boils down to something simpler than that: What does this > have to do with FreeBSD? > > The freebsd-arch list isn't for general discussion about things which > _might_ be relevant to FreeBSD users, such as potentially interesting > 3rd-party technologies or a great sale on hardware at Fred's PC Shack > this week. This list is for discussing proposed changes to FreeBSD, > ideally with sample code (which is applicable and ported to FreeBSD) > attached. That's all there is to it. If you want to discuss more > speculative or contraversial issues, freebsd-chat is the right mailing > list for that kind of thing. > > - Jordan > This may help... http://www.dot-biz.com/IPv4/Tutorial/ http://www.RepliGate.net The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Charlie Root" To: Sent: Wednesday, December 12, 2001 4:45 AM > diff -c -r /unir/sys/netinet/ip.h netinet/ip.h > *** /unir/sys/netinet/ip.h Wed Dec 22 19:13:20 1999 > --- netinet/ip.h Tue Dec 11 13:59:38 2001 > *************** > *** 43,48 **** > --- 43,53 ---- > */ > #define IPVERSION 4 > > + #define IPXX_V4 4 > + #define IPXX_V5 5 > + #define IPXX_V7 7 > + #define IPXX_V8 8 > + > /* > * Structure of an internet header, naked of options. > */ > *************** > *** 61,73 **** > #endif /* not _IP_VHL */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > ! u_short ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > #define IP_RF 0x8000 /* reserved fragment flag */ > #define IP_DF 0x4000 /* dont fragment flag */ > #define IP_MF 0x2000 /* more fragments flag */ > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > u_char ip_ttl; /* time to live */ > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > --- 66,89 ---- > #endif /* not _IP_VHL */ > u_char ip_tos; /* type of service */ > u_short ip_len; /* total length */ > ! #define IPXX_UNIRVERSE_DEFAULT 0 /* Default IPv8 UnirVerse Value */ > ! u_char ip_gate; /* UnirVerse/StarGate */ > ! u_char ip_id; /* identification */ > u_short ip_off; /* fragment offset field */ > + #define IPXX_FLAG 0x8000 /* IPvXX flag */ > #define IP_RF 0x8000 /* reserved fragment flag */ > #define IP_DF 0x4000 /* dont fragment flag */ > #define IP_MF 0x2000 /* more fragments flag */ > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > u_char ip_ttl; /* time to live */ > + #define IPXX_GALAXY 033 /* IPv8 Galaxy Value for 3:219 .INFO */ > + #define IPXX_P_MASK 0x3F > + #define IPXX_ICMP_VAL 1 > + #define IPXX_ICMP_FLAG 0x40 > + #define IPXX_TCP_VAL 6 > + #define IPXX_TCP_FLAG 0x80 > + #define IPXX_UDP_VAL 16 > + #define IPXX_UDP_FLAG 0xC0 > u_char ip_p; /* protocol */ > u_short ip_sum; /* checksum */ > struct in_addr ip_src,ip_dst; /* source and dest address */ > diff -c -r /unir/sys/netinet/ip_icmp.c netinet/ip_icmp.c > *** /unir/sys/netinet/ip_icmp.c Tue Jul 3 11:01:46 2001 > --- netinet/ip_icmp.c Tue Dec 11 14:00:00 2001 > *************** > *** 121,132 **** > #endif > > static void icmp_reflect __P((struct mbuf *)); > ! static void icmp_send __P((struct mbuf *, struct mbuf *)); > static int ip_next_mtu __P((int, int)); > > extern struct protosw inetsw[]; > > /* > * Generate an error packet of type error > * in response to bad packet ip. > */ > --- 121,396 ---- > #endif > > static void icmp_reflect __P((struct mbuf *)); > ! static void icmp_send __P((struct mbuf *, struct mbuf *, int)); > static int ip_next_mtu __P((int, int)); > > extern struct protosw inetsw[]; > > /* > + * Table used to reverse the 4-bit source and destination values > + * in the 8-bit TOS field. > + */ > + > + unsigned char reverse_nibbles[256] = { > + /*00*/ 0x00, > + /*01*/ 0x10, > + /*02*/ 0x20, > + /*03*/ 0x30, > + /*04*/ 0x40, > + /*05*/ 0x50, > + /*06*/ 0x60, > + /*07*/ 0x70, > + /*08*/ 0x80, > + /*09*/ 0x90, > + /*0a*/ 0xa0, > + /*0b*/ 0xb0, > + /*0c*/ 0xc0, > + /*0d*/ 0xd0, > + /*0e*/ 0xe0, > + /*0f*/ 0xf0, > + /*10*/ 0x01, > + /*11*/ 0x11, > + /*12*/ 0x21, > + /*13*/ 0x31, > + /*14*/ 0x41, > + /*15*/ 0x51, > + /*16*/ 0x61, > + /*17*/ 0x71, > + /*18*/ 0x81, > + /*19*/ 0x91, > + /*1a*/ 0xa1, > + /*1b*/ 0xb1, > + /*1c*/ 0xc1, > + /*1d*/ 0xd1, > + /*1e*/ 0xe1, > + /*1f*/ 0xf1, > + /*20*/ 0x02, > + /*21*/ 0x12, > + /*22*/ 0x22, > + /*23*/ 0x32, > + /*24*/ 0x42, > + /*25*/ 0x52, > + /*26*/ 0x62, > + /*27*/ 0x72, > + /*28*/ 0x82, > + /*29*/ 0x92, > + /*2a*/ 0xa2, > + /*2b*/ 0xb2, > + /*2c*/ 0xc2, > + /*2d*/ 0xd2, > + /*2e*/ 0xe2, > + /*2f*/ 0xf2, > + /*30*/ 0x03, > + /*31*/ 0x13, > + /*32*/ 0x23, > + /*33*/ 0x33, > + /*34*/ 0x43, > + /*35*/ 0x53, > + /*36*/ 0x63, > + /*37*/ 0x73, > + /*38*/ 0x83, > + /*39*/ 0x93, > + /*3a*/ 0xa3, > + /*3b*/ 0xb3, > + /*3c*/ 0xc3, > + /*3d*/ 0xd3, > + /*3e*/ 0xe3, > + /*3f*/ 0xf3, > + /*40*/ 0x04, > + /*41*/ 0x14, > + /*42*/ 0x24, > + /*43*/ 0x34, > + /*44*/ 0x44, > + /*45*/ 0x54, > + /*46*/ 0x64, > + /*47*/ 0x74, > + /*48*/ 0x84, > + /*49*/ 0x94, > + /*4a*/ 0xa4, > + /*4b*/ 0xb4, > + /*4c*/ 0xc4, > + /*4d*/ 0xd4, > + /*4e*/ 0xe4, > + /*4f*/ 0xf4, > + /*50*/ 0x05, > + /*51*/ 0x15, > + /*52*/ 0x25, > + /*53*/ 0x35, > + /*54*/ 0x45, > + /*55*/ 0x55, > + /*56*/ 0x65, > + /*57*/ 0x75, > + /*58*/ 0x85, > + /*59*/ 0x95, > + /*5a*/ 0xa5, > + /*5b*/ 0xb5, > + /*5c*/ 0xc5, > + /*5d*/ 0xd5, > + /*5e*/ 0xe5, > + /*5f*/ 0xf5, > + /*60*/ 0x06, > + /*61*/ 0x16, > + /*62*/ 0x26, > + /*63*/ 0x36, > + /*64*/ 0x46, > + /*65*/ 0x56, > + /*66*/ 0x66, > + /*67*/ 0x76, > + /*68*/ 0x86, > + /*69*/ 0x96, > + /*6a*/ 0xa6, > + /*6b*/ 0xb6, > + /*6c*/ 0xc6, > + /*6d*/ 0xd6, > + /*6e*/ 0xe6, > + /*6f*/ 0xf6, > + /*70*/ 0x07, > + /*71*/ 0x17, > + /*72*/ 0x27, > + /*73*/ 0x37, > + /*74*/ 0x47, > + /*75*/ 0x57, > + /*76*/ 0x67, > + /*77*/ 0x77, > + /*78*/ 0x87, > + /*79*/ 0x97, > + /*7a*/ 0xa7, > + /*7b*/ 0xb7, > + /*7c*/ 0xc7, > + /*7d*/ 0xd7, > + /*7e*/ 0xe7, > + /*7f*/ 0xf7, > + /*80*/ 0x08, > + /*81*/ 0x18, > + /*82*/ 0x28, > + /*83*/ 0x38, > + /*84*/ 0x48, > + /*85*/ 0x58, > + /*86*/ 0x68, > + /*87*/ 0x78, > + /*88*/ 0x88, > + /*89*/ 0x98, > + /*8a*/ 0xa8, > + /*8b*/ 0xb8, > + /*8c*/ 0xc8, > + /*8d*/ 0xd8, > + /*8e*/ 0xe8, > + /*8f*/ 0xf8, > + /*90*/ 0x09, > + /*91*/ 0x19, > + /*92*/ 0x29, > + /*93*/ 0x39, > + /*94*/ 0x49, > + /*95*/ 0x59, > + /*96*/ 0x69, > + /*97*/ 0x79, > + /*98*/ 0x89, > + /*99*/ 0x99, > + /*9a*/ 0xa9, > + /*9b*/ 0xb9, > + /*9c*/ 0xc9, > + /*9d*/ 0xd9, > + /*9e*/ 0xe9, > + /*9f*/ 0xf9, > + /*a0*/ 0x0a, > + /*a1*/ 0x1a, > + /*a2*/ 0x2a, > + /*a3*/ 0x3a, > + /*a4*/ 0x4a, > + /*a5*/ 0x5a, > + /*a6*/ 0x6a, > + /*a7*/ 0x7a, > + /*a8*/ 0x8a, > + /*a9*/ 0x9a, > + /*aa*/ 0xaa, > + /*ab*/ 0xba, > + /*ac*/ 0xca, > + /*ad*/ 0xda, > + /*ae*/ 0xea, > + /*af*/ 0xfa, > + /*b0*/ 0x0b, > + /*b1*/ 0x1b, > + /*b2*/ 0x2b, > + /*b3*/ 0x3b, > + /*b4*/ 0x4b, > + /*b5*/ 0x5b, > + /*b6*/ 0x6b, > + /*b7*/ 0x7b, > + /*b8*/ 0x8b, > + /*b9*/ 0x9b, > + /*ba*/ 0xab, > + /*bb*/ 0xbb, > + /*bc*/ 0xcb, > + /*bd*/ 0xdb, > + /*be*/ 0xeb, > + /*bf*/ 0xfb, > + /*c0*/ 0x0c, > + /*c1*/ 0x1c, > + /*c2*/ 0x2c, > + /*c3*/ 0x3c, > + /*c4*/ 0x4c, > + /*c5*/ 0x5c, > + /*c6*/ 0x6c, > + /*c7*/ 0x7c, > + /*c8*/ 0x8c, > + /*c9*/ 0x9c, > + /*ca*/ 0xac, > + /*cb*/ 0xbc, > + /*cc*/ 0xcc, > + /*cd*/ 0xdc, > + /*ce*/ 0xec, > + /*cf*/ 0xfc, > + /*d0*/ 0x0d, > + /*d1*/ 0x1d, > + /*d2*/ 0x2d, > + /*d3*/ 0x3d, > + /*d4*/ 0x4d, > + /*d5*/ 0x5d, > + /*d6*/ 0x6d, > + /*d7*/ 0x7d, > + /*d8*/ 0x8d, > + /*d9*/ 0x9d, > + /*da*/ 0xad, > + /*db*/ 0xbd, > + /*dc*/ 0xcd, > + /*dd*/ 0xdd, > + /*de*/ 0xed, > + /*df*/ 0xfd, > + /*e0*/ 0x0e, > + /*e1*/ 0x1e, > + /*e2*/ 0x2e, > + /*e3*/ 0x3e, > + /*e4*/ 0x4e, > + /*e5*/ 0x5e, > + /*e6*/ 0x6e, > + /*e7*/ 0x7e, > + /*e8*/ 0x8e, > + /*e9*/ 0x9e, > + /*ea*/ 0xae, > + /*eb*/ 0xbe, > + /*ec*/ 0xce, > + /*ed*/ 0xde, > + /*ee*/ 0xee, > + /*ef*/ 0xfe, > + /*f0*/ 0x0f, > + /*f1*/ 0x1f, > + /*f2*/ 0x2f, > + /*f3*/ 0x3f, > + /*f4*/ 0x4f, > + /*f5*/ 0x5f, > + /*f6*/ 0x6f, > + /*f7*/ 0x7f, > + /*f8*/ 0x8f, > + /*f9*/ 0x9f, > + /*fa*/ 0xaf, > + /*fb*/ 0xbf, > + /*fc*/ 0xcf, > + /*fd*/ 0xdf, > + /*fe*/ 0xef, > + /*ff*/ 0xff > + }; > + > + /* > * Generate an error packet of type error > * in response to bad packet ip. > */ > *************** > *** 226,232 **** > nip->ip_len = m->m_len; > nip->ip_vhl = IP_VHL_BORING; > nip->ip_p = IPPROTO_ICMP; > ! nip->ip_tos = 0; > icmp_reflect(m); > > freeit: > --- 490,496 ---- > nip->ip_len = m->m_len; > nip->ip_vhl = IP_VHL_BORING; > nip->ip_p = IPPROTO_ICMP; > ! nip->ip_tos = 0x44; /* Network Management Flow */ > icmp_reflect(m); > > freeit: > *************** > *** 610,615 **** > --- 874,880 ---- > struct in_addr t; > struct mbuf *opts = 0; > int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); > + int flags = 0; > > if (!in_canforward(ip->ip_src) && > ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) != > *************** > *** 617,622 **** > --- 882,895 ---- > m_freem(m); /* Bad return address */ > goto done; /* Ip_output() will check for broadcast */ > } > + /* Handle IPv8 TOS and UnirVerse fields */ > + if(((ip->ip_tos&0xF0)!=0) && ((ip->ip_tos&0x0F)!=0)){ > + ip->ip_tos = reverse_nibbles[ip->ip_tos]; > + if(ip->ip_gate != IPXX_UNIRVERSE_DEFAULT){ > + ip->ip_gate = reverse_nibbles[ip->ip_gate]; > + flags |= IP_UNIRVERSE_SET; > + } > + } > t = ip->ip_dst; > ip->ip_dst = ip->ip_src; > /* > *************** > *** 719,725 **** > (unsigned)(m->m_len - sizeof(struct ip))); > } > m->m_flags &= ~(M_BCAST|M_MCAST); > ! icmp_send(m, opts); > done: > if (opts) > (void)m_free(opts); > --- 992,998 ---- > (unsigned)(m->m_len - sizeof(struct ip))); > } > m->m_flags &= ~(M_BCAST|M_MCAST); > ! icmp_send(m,opts,flags); > done: > if (opts) > (void)m_free(opts); > *************** > *** 730,738 **** > * after supplying a checksum. > */ > static void > ! icmp_send(m, opts) > register struct mbuf *m; > struct mbuf *opts; > { > register struct ip *ip = mtod(m, struct ip *); > register int hlen; > --- 1003,1012 ---- > * after supplying a checksum. > */ > static void > ! icmp_send(m,opts,flags) > register struct mbuf *m; > struct mbuf *opts; > + int flags; > { > register struct ip *ip = mtod(m, struct ip *); > register int hlen; > *************** > *** 757,763 **** > } > #endif > bzero(&ro, sizeof ro); > ! (void) ip_output(m, opts, &ro, 0, NULL); > if (ro.ro_rt) > RTFREE(ro.ro_rt); > } > --- 1031,1037 ---- > } > #endif > bzero(&ro, sizeof ro); > ! (void) ip_output(m, opts, &ro, flags, NULL); > if (ro.ro_rt) > RTFREE(ro.ro_rt); > } > diff -c -r /unir/sys/netinet/ip_input.c netinet/ip_input.c > *** /unir/sys/netinet/ip_input.c Wed Aug 29 21:41:37 2001 > --- netinet/ip_input.c Wed Dec 12 09:57:20 2001 > *************** > *** 258,266 **** > maxnipq = nmbclusters / 4; > ip_maxfragpackets = nmbclusters / 4; > > - #ifndef RANDOM_IP_ID > ip_id = time_second & 0xffff; > ! #endif > ipintrq.ifq_maxlen = ipqmaxlen; > > register_netisr(NETISR_IP, ipintr); > --- 258,275 ---- > maxnipq = nmbclusters / 4; > ip_maxfragpackets = nmbclusters / 4; > > ip_id = time_second & 0xffff; > ! /* initialize all the StarGate id counters */ > ! for(i=0; i<256; i++){ > ! ip_id_[i] = time_second & 0xffff; > ! } > ! for(i=0; i<65536; i++){ > ! src_gate[i] = 0x00; > ! dst_gate[i] = 0x00; > ! } > ! galaxy_in=0; > ! galaxy_out=0; > ! > ipintrq.ifq_maxlen = ipqmaxlen; > > register_netisr(NETISR_IP, ipintr); > *************** > *** 269,274 **** > --- 278,285 ---- > static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; > static struct route ipforward_rt; > > + extern unsigned char reverse_nibbles[]; > + > /* > * Ip input routine. Checksum and byte swap header. If fragmented > * try to reassemble. Process options. Pass to next level. > *************** > *** 287,292 **** > --- 298,305 ---- > u_int32_t divert_info = 0; /* packet divert/tee info */ > #endif > struct ip_fw_chain *rule = NULL; > + u_int32_t src_addr; > + u_int32_t dst_addr; > > #ifdef IPDIVERT > /* Get and reset firewall cookie */ > *************** > *** 346,351 **** > --- 359,365 ---- > ip = mtod(m, struct ip *); > } > > + > /* 127/8 must not appear on wire - RFC1122 */ > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { > *************** > *** 402,407 **** > --- 416,483 ---- > if (ipsec_gethist(m, NULL)) > goto pass; > #endif > + > + /* Process IPvXX ICMP++ packets that are special QoS codes */ > + if((ip->ip_p==IPPROTO_ICMP) && (((ip->ip_tos&0xF0)==0)||((ip->ip_tos&0x0F)==0))){ > + src_addr = ntohl(ip->ip_src.s_addr); > + dst_addr = ntohl(ip->ip_dst.s_addr); > + /* QoS(4)=Network Management */ > + switch(ip->ip_tos){ > + case 0x04: > + /* Check for Galaxy PeaceKeeper */ > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > + if((src_addr&0x1F0F)==0){ > + dst_gate[src_addr>>16] >>= 4; > + dst_gate[src_addr>>16] |= src_addr&0xF0; > + /* Check for possible new Galaxy setting */ > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > + galaxy_out=(src_addr&0x0E00)>>8; > + log(LOG_WARNING,"Outbound Galactic Routing set to %d\n",galaxy_out); > + } > + else{ > + galaxy_out=0; > + } > + } > + break; > + case 0x40: > + /* Check for Galaxy PeaceKeeper */ > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > + if((src_addr&0x1F0F)==0){ > + src_gate[src_addr>>16] >>= 4; > + src_gate[src_addr>>16] |= src_addr&0xF0; > + /* Check for possible new Galaxy setting */ > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > + galaxy_in=(src_addr&0x0E00)>>8; > + log(LOG_WARNING,"Inbound Galactic Routing set to %d\n",galaxy_in); > + } > + else{ > + galaxy_in=0; > + } > + } > + break; > + default: > + log(LOG_WARNING,"Unknown ICMP+ QoS Code from %s\n", > + inet_ntoa(ip->ip_src)); > + } > + } > + /* Process IPvXX-style Packets */ > + if((ip->ip_off&0x8000)!=0){ > + /* Process non-Galaxy 0 Packets */ > + if(((ip->ip_p&0xC0) != 0)&& > + ((ip->ip_p&0x07) != galaxy_in)){ > + printf("Dropped packet not from our galaxy\n"); > + ipstat.ips_badaddr++; > + goto bad; > + } > + else{ > + /* Packet is Galaxy 0, are we ? */ > + if(galaxy_in != 0){ > + printf("Dropped packet not from our galaxy\n"); > + ipstat.ips_badaddr++; > + goto bad; > + } > + } > + } > > /* > * IpHack's section. > diff -c -r /unir/sys/netinet/ip_mroute.c netinet/ip_mroute.c > *** /unir/sys/netinet/ip_mroute.c Thu Jul 19 06:37:26 2001 > --- netinet/ip_mroute.c Tue Dec 11 14:00:20 2001 > *************** > *** 1581,1590 **** > */ > ip_copy = mtod(mb_copy, struct ip *); > *ip_copy = multicast_encap_iphdr; > #ifdef RANDOM_IP_ID > ip_copy->ip_id = ip_randomid(); > #else > ! ip_copy->ip_id = htons(ip_id++); > #endif > ip_copy->ip_len += len; > ip_copy->ip_src = vifp->v_lcl_addr; > --- 1581,1597 ---- > */ > ip_copy = mtod(mb_copy, struct ip *); > *ip_copy = multicast_encap_iphdr; > + ip_copy->ip_gate=0; > #ifdef RANDOM_IP_ID > ip_copy->ip_id = ip_randomid(); > #else > ! if(ip_copy->ip_tos != 0){ > ! ip_copy->ip_id = ip_id_[ip_copy->ip_gate]++; > ! } > ! else{ > ! ip_copy->ip_id = ip_id++; > ! ip_copy->ip_gate = ip_id>>8; > ! } > #endif > ip_copy->ip_len += len; > ip_copy->ip_src = vifp->v_lcl_addr; > diff -c -r /unir/sys/netinet/ip_output.c netinet/ip_output.c > *** /unir/sys/netinet/ip_output.c Thu Jul 19 06:37:26 2001 > --- netinet/ip_output.c Wed Dec 12 10:28:11 2001 > *************** > *** 52,57 **** > --- 52,58 ---- > #include > #include > #include > + #include > > #include > #include > *************** > *** 88,101 **** > #include > #endif > > ! #ifdef IPFIREWALL_FORWARD_DEBUG > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld",(ntohl(a.s_addr)>>24)&0xFF,\ > (ntohl(a.s_addr)>>16)&0xFF,\ > (ntohl(a.s_addr)>>8)&0xFF,\ > (ntohl(a.s_addr))&0xFF); > - #endif > > u_short ip_id; > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > --- 89,105 ---- > #include > #endif > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld ",(ntohl(a.s_addr)>>24)&0xFF,\ > (ntohl(a.s_addr)>>16)&0xFF,\ > (ntohl(a.s_addr)>>8)&0xFF,\ > (ntohl(a.s_addr))&0xFF); > > u_short ip_id; > + u_char ip_id_[256]; > + u_char src_gate[65536]; > + u_char dst_gate[65536]; > + u_char galaxy_out; > + u_char galaxy_in; > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > *************** > *** 127,132 **** > --- 131,137 ---- > int flags; > struct ip_moptions *imo; > { > + struct timeval random_time; > struct ip *ip, *mhip; > struct ifnet *ifp; > struct mbuf *m = m0; > *************** > *** 207,219 **** > /* > * Fill in IP header. > */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > ip->ip_off &= IP_DF; > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! ip->ip_id = htons(ip_id++); > #endif > ipstat.ips_localout++; > } else { > --- 212,252 ---- > /* > * Fill in IP header. > */ > + > + /* Set UnirVerse on QoS-agile Packets */ > + if(ip->ip_tos != 0){ > + /* Allow reflectors and forwarders to prevent setting */ > + if((flags & IP_UNIRVERSE_SET) == 0){ > + getmicrotime(&random_time); > + if(random_time.tv_usec&0x01){ > + ip->ip_gate = > + ((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])&0xF0) | > + (((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])>>4)&0x0F); > + } > + else{ > + ip->ip_gate = > + (((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])<<4)&0xF0) | > + ((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])&0x0F); > + } > + } > + } > + else{ > + ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > + } > + /* Set id based on UnirVerse */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > ip->ip_off &= IP_DF; > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! if(ip->ip_tos != 0){ > ! ip->ip_id = ip_id_[ip->ip_gate]++; > ! } > ! else{ > ! ip->ip_id = ip_id++; > ! ip->ip_gate = ip_id>>8; > ! } > #endif > ipstat.ips_localout++; > } else { > *************** > *** 431,436 **** > --- 464,470 ---- > } > > sendit: > + > #ifdef IPSEC > /* get SP for this packet */ > if (so == NULL) > diff -c -r /unir/sys/netinet/ip_var.h netinet/ip_var.h > *** /unir/sys/netinet/ip_var.h Thu Jul 19 06:37:26 2001 > --- netinet/ip_var.h Tue Dec 11 14:00:41 2001 > *************** > *** 133,138 **** > --- 133,140 ---- > /* flags passed to ip_output as last parameter */ > #define IP_FORWARDING 0x1 /* most of ip header exists */ > #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ > + #define IP_UNIRVERSE_SET 0x4 /* UnirVerse set in header */ > + > #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ > #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ > > *************** > *** 142,150 **** > struct sockopt; > > extern struct ipstat ipstat; > ! #ifndef RANDOM_IP_ID > ! extern u_short ip_id; /* ip packet ctr, for ids */ > ! #endif > extern int ip_defttl; /* default IP ttl */ > extern int ipforwarding; /* ip forwarding */ > extern u_char ip_protox[]; > --- 144,157 ---- > struct sockopt; > > extern struct ipstat ipstat; > ! > ! extern u_short ip_id; /* ip packet ctr, for ids */ > ! extern u_char ip_id_[]; /* id counters for each StarGate */ > ! extern u_char src_gate[]; > ! extern u_char dst_gate[]; > ! extern u_char galaxy_in; > ! extern u_char galaxy_out; > ! > extern int ip_defttl; /* default IP ttl */ > extern int ipforwarding; /* ip forwarding */ > extern u_char ip_protox[]; > diff -c -r /unir/sys/netinet/raw_ip.c netinet/raw_ip.c > *** /unir/sys/netinet/raw_ip.c Sun Jul 29 19:32:40 2001 > --- netinet/raw_ip.c Tue Dec 11 14:01:10 2001 > *************** > *** 239,249 **** > m_freem(m); > return EINVAL; > } > - if (ip->ip_id == 0) > #ifdef RANDOM_IP_ID > ip->ip_id = ip_randomid(); > #else > ! ip->ip_id = htons(ip_id++); > #endif > /* XXX prevent ip_output from overwriting header fields */ > flags |= IP_RAWOUTPUT; > --- 239,259 ---- > m_freem(m); > return EINVAL; > } > #ifdef RANDOM_IP_ID > + if (ip->ip_id == 0){ > ip->ip_id = ip_randomid(); > + } > #else > ! if (ip->ip_id == 0){ > ! if(ip->ip_tos != 0){ > ! ip->ip_id = ip_id_[ip->ip_gate]++; > ! ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > ! } > ! else{ > ! ip->ip_id = ip_id++; > ! ip->ip_gate = ip_id>>8; > ! } > ! } > #endif > /* XXX prevent ip_output from overwriting header fields */ > flags |= IP_RAWOUTPUT; > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 10:36:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 102A737B41B for ; Wed, 12 Dec 2001 10:36:19 -0800 (PST) Received: from pool0253.cvx21-bradley.dialup.earthlink.net ([209.179.192.253] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EEEn-0006Dl-00; Wed, 12 Dec 2001 10:36:14 -0800 Message-ID: <3C17A3A3.A439BE21@mindspring.com> Date: Wed, 12 Dec 2001 10:36:19 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Campi Cc: Bakul Shah , freebsd-arch@FreeBSD.ORG Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... References: <200112092050.PAA26830@glatton.cnchost.com> <20011212162203.GA9595@webcom.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This comes up once in a while, so it's worth treating, once in a while... Andrea Campi wrote: > #include > > I was able to simple boot to single user and growfs my / without any magic. > I *might* have changed it to read-only just for safety but I don't think so. > After that of course I rebooted immediately... You either had spare space afterward, or you shrunk your swap to accommodate the increase (or your swap is writing to it now 8^(). Note that growing the FS doesn't entirely do what you think it does. If your FS was 90% full on average, then each of your cylinder groups was 90% full on average. Now say you had 99 cylinder groups, and you added one cylinder group. Your new cylinder group is 0% fiull, and the rest are 90% full. What is the probability that the new cylinder group will be selected for new writes? The answer is 1%. Ideally, you would want to weight the choice based on how full each cylinder group was, but that won't happen, since it defeats the seek optimization if you do that. So your disk fragmentation is still there... your disks start fragmenting at over 85% full, since the space selection function is feectively a hash, and, as we learned in CS 201 when we first read Knuth's book on Seminumerical Algorithms: Sorting and Searching, after 85% hash fill, you will start to get collisions, even with a perfect hash, given fullt random input data. I think that a 4M cylinder group would be reasonable; you could add cylinder groups as you deem fit, and run the system on top of virtual partitions made up of free disk space (what AIX calls "PP"'s -- Physical Partitions). But you will have fragmentation problems, because of the selection mechanism used by UFS. So lets try another less drastic one: my disk is 90% full, and so is 8% fragmented (on average, this is about what it will be). I double the disk size. Now it's 4% fragmented. Now as time goes on, I have a 50/50 chance of allocating in the new (free) area, or allocating in the old area. Allocations in the old area will continue to increase fragmentation. What went wrong? Really, as part of growing an FS, you need to defragment it, so that the average fill percentage of all cylinder groups is equal. That way, as you go forward, the allocation will be approximately equal across all cylinder groups (since that's how the allocation works), and you will maintain a uniform level of fragmentation going forward. You could imagine a brute force tool to do this: back up to tape, newfs, and restore from tape. A better tool would allow you to defragment an existing FS, or even run in the background at boot, and defragment only if necessary (some inequality threshold on per cylinder group fill amounts, perhaps). An even better tool might allow you to "defragment" a large disk, at the same time declaring the end of that disk "off limits". Doing that would let you actually free up cylinder groups at the end of a disk -- and shrink partitions, as well as expand them. So, to make this relevent to -arch: a good junior FS hacker project would be to write a defragmentation tool. Before you start, realize that if you use FFS partitions the way you are supposed to, no one will ever need your tool. But if you fill up and then clean out the unused files at very close to a full disk, or you grow, or (if your new tool is smart enough) shrink partitions, then people would find your tool useful. Bonus points: make the code general enough, and encapsulate state well enough, that someone could use the code in a third party tool, or could use it to resize two FFS partitions simultaneously. Bonus bonus points: send the source code to this tool to the "Power Quest" people for inclusion in the next release of "Partition Magic", so that FreeBSD is represented there, and not just Linux. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 11: 1: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 5653A37B419 for ; Wed, 12 Dec 2001 11:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011212190014.CLKN10701.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 12 Dec 2001 19:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA10857; Wed, 12 Dec 2001 10:45:09 -0800 (PST) Date: Wed, 12 Dec 2001 10:45:09 -0800 (PST) From: Julian Elischer To: Jim Fleming Cc: Jordan Hubbard , Andre Oppermann , freebsd-arch@FreeBSD.ORG Subject: Re: RIFRAF Routing Changes for FreeBSD In-Reply-To: <053301c18336$13f85900$1000a8c0@Unir.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Now it belongs in freebsd-net :-) On Wed, 12 Dec 2001, Jim Fleming wrote: > > ----- Original Message ----- > From: "Jordan Hubbard" > To: "Jim Fleming" > Cc: "Andre Oppermann" ; > Sent: Wednesday, December 12, 2001 11:39 AM > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > It all boils down to fairness. > > > Which list do you think is more fair ? > > > > I think it boils down to something simpler than that: What does this > > have to do with FreeBSD? > > > > The freebsd-arch list isn't for general discussion about things which > > _might_ be relevant to FreeBSD users, such as potentially interesting > > 3rd-party technologies or a great sale on hardware at Fred's PC Shack > > this week. This list is for discussing proposed changes to FreeBSD, > > ideally with sample code (which is applicable and ported to FreeBSD) > > attached. That's all there is to it. If you want to discuss more > > speculative or contraversial issues, freebsd-chat is the right mailing > > list for that kind of thing. > > > > - Jordan > > > This may help... > http://www.dot-biz.com/IPv4/Tutorial/ > http://www.RepliGate.net > > The Netfilter Project: Packet Mangling for Linux 2.4 > http://netfilter.samba.org > > Jim Fleming > http://www.IPv8.info > IPv16....One Better !! > > ----- Original Message ----- > From: "Charlie Root" > To: > Sent: Wednesday, December 12, 2001 4:45 AM > > > > diff -c -r /unir/sys/netinet/ip.h netinet/ip.h > > *** /unir/sys/netinet/ip.h Wed Dec 22 19:13:20 1999 > > --- netinet/ip.h Tue Dec 11 13:59:38 2001 > > *************** > > *** 43,48 **** > > --- 43,53 ---- > > */ > > #define IPVERSION 4 > > > > + #define IPXX_V4 4 > > + #define IPXX_V5 5 > > + #define IPXX_V7 7 > > + #define IPXX_V8 8 > > + > > /* > > * Structure of an internet header, naked of options. > > */ > > *************** > > *** 61,73 **** > > #endif /* not _IP_VHL */ > > u_char ip_tos; /* type of service */ > > u_short ip_len; /* total length */ > > ! u_short ip_id; /* identification */ > > u_short ip_off; /* fragment offset field */ > > #define IP_RF 0x8000 /* reserved fragment flag */ > > #define IP_DF 0x4000 /* dont fragment flag */ > > #define IP_MF 0x2000 /* more fragments flag */ > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > u_char ip_ttl; /* time to live */ > > u_char ip_p; /* protocol */ > > u_short ip_sum; /* checksum */ > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > --- 66,89 ---- > > #endif /* not _IP_VHL */ > > u_char ip_tos; /* type of service */ > > u_short ip_len; /* total length */ > > ! #define IPXX_UNIRVERSE_DEFAULT 0 /* Default IPv8 UnirVerse Value */ > > ! u_char ip_gate; /* UnirVerse/StarGate */ > > ! u_char ip_id; /* identification */ > > u_short ip_off; /* fragment offset field */ > > + #define IPXX_FLAG 0x8000 /* IPvXX flag */ > > #define IP_RF 0x8000 /* reserved fragment flag */ > > #define IP_DF 0x4000 /* dont fragment flag */ > > #define IP_MF 0x2000 /* more fragments flag */ > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > u_char ip_ttl; /* time to live */ > > + #define IPXX_GALAXY 033 /* IPv8 Galaxy Value for 3:219 .INFO */ > > + #define IPXX_P_MASK 0x3F > > + #define IPXX_ICMP_VAL 1 > > + #define IPXX_ICMP_FLAG 0x40 > > + #define IPXX_TCP_VAL 6 > > + #define IPXX_TCP_FLAG 0x80 > > + #define IPXX_UDP_VAL 16 > > + #define IPXX_UDP_FLAG 0xC0 > > u_char ip_p; /* protocol */ > > u_short ip_sum; /* checksum */ > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > diff -c -r /unir/sys/netinet/ip_icmp.c netinet/ip_icmp.c > > *** /unir/sys/netinet/ip_icmp.c Tue Jul 3 11:01:46 2001 > > --- netinet/ip_icmp.c Tue Dec 11 14:00:00 2001 > > *************** > > *** 121,132 **** > > #endif > > > > static void icmp_reflect __P((struct mbuf *)); > > ! static void icmp_send __P((struct mbuf *, struct mbuf *)); > > static int ip_next_mtu __P((int, int)); > > > > extern struct protosw inetsw[]; > > > > /* > > * Generate an error packet of type error > > * in response to bad packet ip. > > */ > > --- 121,396 ---- > > #endif > > > > static void icmp_reflect __P((struct mbuf *)); > > ! static void icmp_send __P((struct mbuf *, struct mbuf *, int)); > > static int ip_next_mtu __P((int, int)); > > > > extern struct protosw inetsw[]; > > > > /* > > + * Table used to reverse the 4-bit source and destination values > > + * in the 8-bit TOS field. > > + */ > > + > > + unsigned char reverse_nibbles[256] = { > > + /*00*/ 0x00, > > + /*01*/ 0x10, > > + /*02*/ 0x20, > > + /*03*/ 0x30, > > + /*04*/ 0x40, > > + /*05*/ 0x50, > > + /*06*/ 0x60, > > + /*07*/ 0x70, > > + /*08*/ 0x80, > > + /*09*/ 0x90, > > + /*0a*/ 0xa0, > > + /*0b*/ 0xb0, > > + /*0c*/ 0xc0, > > + /*0d*/ 0xd0, > > + /*0e*/ 0xe0, > > + /*0f*/ 0xf0, > > + /*10*/ 0x01, > > + /*11*/ 0x11, > > + /*12*/ 0x21, > > + /*13*/ 0x31, > > + /*14*/ 0x41, > > + /*15*/ 0x51, > > + /*16*/ 0x61, > > + /*17*/ 0x71, > > + /*18*/ 0x81, > > + /*19*/ 0x91, > > + /*1a*/ 0xa1, > > + /*1b*/ 0xb1, > > + /*1c*/ 0xc1, > > + /*1d*/ 0xd1, > > + /*1e*/ 0xe1, > > + /*1f*/ 0xf1, > > + /*20*/ 0x02, > > + /*21*/ 0x12, > > + /*22*/ 0x22, > > + /*23*/ 0x32, > > + /*24*/ 0x42, > > + /*25*/ 0x52, > > + /*26*/ 0x62, > > + /*27*/ 0x72, > > + /*28*/ 0x82, > > + /*29*/ 0x92, > > + /*2a*/ 0xa2, > > + /*2b*/ 0xb2, > > + /*2c*/ 0xc2, > > + /*2d*/ 0xd2, > > + /*2e*/ 0xe2, > > + /*2f*/ 0xf2, > > + /*30*/ 0x03, > > + /*31*/ 0x13, > > + /*32*/ 0x23, > > + /*33*/ 0x33, > > + /*34*/ 0x43, > > + /*35*/ 0x53, > > + /*36*/ 0x63, > > + /*37*/ 0x73, > > + /*38*/ 0x83, > > + /*39*/ 0x93, > > + /*3a*/ 0xa3, > > + /*3b*/ 0xb3, > > + /*3c*/ 0xc3, > > + /*3d*/ 0xd3, > > + /*3e*/ 0xe3, > > + /*3f*/ 0xf3, > > + /*40*/ 0x04, > > + /*41*/ 0x14, > > + /*42*/ 0x24, > > + /*43*/ 0x34, > > + /*44*/ 0x44, > > + /*45*/ 0x54, > > + /*46*/ 0x64, > > + /*47*/ 0x74, > > + /*48*/ 0x84, > > + /*49*/ 0x94, > > + /*4a*/ 0xa4, > > + /*4b*/ 0xb4, > > + /*4c*/ 0xc4, > > + /*4d*/ 0xd4, > > + /*4e*/ 0xe4, > > + /*4f*/ 0xf4, > > + /*50*/ 0x05, > > + /*51*/ 0x15, > > + /*52*/ 0x25, > > + /*53*/ 0x35, > > + /*54*/ 0x45, > > + /*55*/ 0x55, > > + /*56*/ 0x65, > > + /*57*/ 0x75, > > + /*58*/ 0x85, > > + /*59*/ 0x95, > > + /*5a*/ 0xa5, > > + /*5b*/ 0xb5, > > + /*5c*/ 0xc5, > > + /*5d*/ 0xd5, > > + /*5e*/ 0xe5, > > + /*5f*/ 0xf5, > > + /*60*/ 0x06, > > + /*61*/ 0x16, > > + /*62*/ 0x26, > > + /*63*/ 0x36, > > + /*64*/ 0x46, > > + /*65*/ 0x56, > > + /*66*/ 0x66, > > + /*67*/ 0x76, > > + /*68*/ 0x86, > > + /*69*/ 0x96, > > + /*6a*/ 0xa6, > > + /*6b*/ 0xb6, > > + /*6c*/ 0xc6, > > + /*6d*/ 0xd6, > > + /*6e*/ 0xe6, > > + /*6f*/ 0xf6, > > + /*70*/ 0x07, > > + /*71*/ 0x17, > > + /*72*/ 0x27, > > + /*73*/ 0x37, > > + /*74*/ 0x47, > > + /*75*/ 0x57, > > + /*76*/ 0x67, > > + /*77*/ 0x77, > > + /*78*/ 0x87, > > + /*79*/ 0x97, > > + /*7a*/ 0xa7, > > + /*7b*/ 0xb7, > > + /*7c*/ 0xc7, > > + /*7d*/ 0xd7, > > + /*7e*/ 0xe7, > > + /*7f*/ 0xf7, > > + /*80*/ 0x08, > > + /*81*/ 0x18, > > + /*82*/ 0x28, > > + /*83*/ 0x38, > > + /*84*/ 0x48, > > + /*85*/ 0x58, > > + /*86*/ 0x68, > > + /*87*/ 0x78, > > + /*88*/ 0x88, > > + /*89*/ 0x98, > > + /*8a*/ 0xa8, > > + /*8b*/ 0xb8, > > + /*8c*/ 0xc8, > > + /*8d*/ 0xd8, > > + /*8e*/ 0xe8, > > + /*8f*/ 0xf8, > > + /*90*/ 0x09, > > + /*91*/ 0x19, > > + /*92*/ 0x29, > > + /*93*/ 0x39, > > + /*94*/ 0x49, > > + /*95*/ 0x59, > > + /*96*/ 0x69, > > + /*97*/ 0x79, > > + /*98*/ 0x89, > > + /*99*/ 0x99, > > + /*9a*/ 0xa9, > > + /*9b*/ 0xb9, > > + /*9c*/ 0xc9, > > + /*9d*/ 0xd9, > > + /*9e*/ 0xe9, > > + /*9f*/ 0xf9, > > + /*a0*/ 0x0a, > > + /*a1*/ 0x1a, > > + /*a2*/ 0x2a, > > + /*a3*/ 0x3a, > > + /*a4*/ 0x4a, > > + /*a5*/ 0x5a, > > + /*a6*/ 0x6a, > > + /*a7*/ 0x7a, > > + /*a8*/ 0x8a, > > + /*a9*/ 0x9a, > > + /*aa*/ 0xaa, > > + /*ab*/ 0xba, > > + /*ac*/ 0xca, > > + /*ad*/ 0xda, > > + /*ae*/ 0xea, > > + /*af*/ 0xfa, > > + /*b0*/ 0x0b, > > + /*b1*/ 0x1b, > > + /*b2*/ 0x2b, > > + /*b3*/ 0x3b, > > + /*b4*/ 0x4b, > > + /*b5*/ 0x5b, > > + /*b6*/ 0x6b, > > + /*b7*/ 0x7b, > > + /*b8*/ 0x8b, > > + /*b9*/ 0x9b, > > + /*ba*/ 0xab, > > + /*bb*/ 0xbb, > > + /*bc*/ 0xcb, > > + /*bd*/ 0xdb, > > + /*be*/ 0xeb, > > + /*bf*/ 0xfb, > > + /*c0*/ 0x0c, > > + /*c1*/ 0x1c, > > + /*c2*/ 0x2c, > > + /*c3*/ 0x3c, > > + /*c4*/ 0x4c, > > + /*c5*/ 0x5c, > > + /*c6*/ 0x6c, > > + /*c7*/ 0x7c, > > + /*c8*/ 0x8c, > > + /*c9*/ 0x9c, > > + /*ca*/ 0xac, > > + /*cb*/ 0xbc, > > + /*cc*/ 0xcc, > > + /*cd*/ 0xdc, > > + /*ce*/ 0xec, > > + /*cf*/ 0xfc, > > + /*d0*/ 0x0d, > > + /*d1*/ 0x1d, > > + /*d2*/ 0x2d, > > + /*d3*/ 0x3d, > > + /*d4*/ 0x4d, > > + /*d5*/ 0x5d, > > + /*d6*/ 0x6d, > > + /*d7*/ 0x7d, > > + /*d8*/ 0x8d, > > + /*d9*/ 0x9d, > > + /*da*/ 0xad, > > + /*db*/ 0xbd, > > + /*dc*/ 0xcd, > > + /*dd*/ 0xdd, > > + /*de*/ 0xed, > > + /*df*/ 0xfd, > > + /*e0*/ 0x0e, > > + /*e1*/ 0x1e, > > + /*e2*/ 0x2e, > > + /*e3*/ 0x3e, > > + /*e4*/ 0x4e, > > + /*e5*/ 0x5e, > > + /*e6*/ 0x6e, > > + /*e7*/ 0x7e, > > + /*e8*/ 0x8e, > > + /*e9*/ 0x9e, > > + /*ea*/ 0xae, > > + /*eb*/ 0xbe, > > + /*ec*/ 0xce, > > + /*ed*/ 0xde, > > + /*ee*/ 0xee, > > + /*ef*/ 0xfe, > > + /*f0*/ 0x0f, > > + /*f1*/ 0x1f, > > + /*f2*/ 0x2f, > > + /*f3*/ 0x3f, > > + /*f4*/ 0x4f, > > + /*f5*/ 0x5f, > > + /*f6*/ 0x6f, > > + /*f7*/ 0x7f, > > + /*f8*/ 0x8f, > > + /*f9*/ 0x9f, > > + /*fa*/ 0xaf, > > + /*fb*/ 0xbf, > > + /*fc*/ 0xcf, > > + /*fd*/ 0xdf, > > + /*fe*/ 0xef, > > + /*ff*/ 0xff > > + }; > > + > > + /* > > * Generate an error packet of type error > > * in response to bad packet ip. > > */ > > *************** > > *** 226,232 **** > > nip->ip_len = m->m_len; > > nip->ip_vhl = IP_VHL_BORING; > > nip->ip_p = IPPROTO_ICMP; > > ! nip->ip_tos = 0; > > icmp_reflect(m); > > > > freeit: > > --- 490,496 ---- > > nip->ip_len = m->m_len; > > nip->ip_vhl = IP_VHL_BORING; > > nip->ip_p = IPPROTO_ICMP; > > ! nip->ip_tos = 0x44; /* Network Management Flow */ > > icmp_reflect(m); > > > > freeit: > > *************** > > *** 610,615 **** > > --- 874,880 ---- > > struct in_addr t; > > struct mbuf *opts = 0; > > int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); > > + int flags = 0; > > > > if (!in_canforward(ip->ip_src) && > > ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) != > > *************** > > *** 617,622 **** > > --- 882,895 ---- > > m_freem(m); /* Bad return address */ > > goto done; /* Ip_output() will check for broadcast */ > > } > > + /* Handle IPv8 TOS and UnirVerse fields */ > > + if(((ip->ip_tos&0xF0)!=0) && ((ip->ip_tos&0x0F)!=0)){ > > + ip->ip_tos = reverse_nibbles[ip->ip_tos]; > > + if(ip->ip_gate != IPXX_UNIRVERSE_DEFAULT){ > > + ip->ip_gate = reverse_nibbles[ip->ip_gate]; > > + flags |= IP_UNIRVERSE_SET; > > + } > > + } > > t = ip->ip_dst; > > ip->ip_dst = ip->ip_src; > > /* > > *************** > > *** 719,725 **** > > (unsigned)(m->m_len - sizeof(struct ip))); > > } > > m->m_flags &= ~(M_BCAST|M_MCAST); > > ! icmp_send(m, opts); > > done: > > if (opts) > > (void)m_free(opts); > > --- 992,998 ---- > > (unsigned)(m->m_len - sizeof(struct ip))); > > } > > m->m_flags &= ~(M_BCAST|M_MCAST); > > ! icmp_send(m,opts,flags); > > done: > > if (opts) > > (void)m_free(opts); > > *************** > > *** 730,738 **** > > * after supplying a checksum. > > */ > > static void > > ! icmp_send(m, opts) > > register struct mbuf *m; > > struct mbuf *opts; > > { > > register struct ip *ip = mtod(m, struct ip *); > > register int hlen; > > --- 1003,1012 ---- > > * after supplying a checksum. > > */ > > static void > > ! icmp_send(m,opts,flags) > > register struct mbuf *m; > > struct mbuf *opts; > > + int flags; > > { > > register struct ip *ip = mtod(m, struct ip *); > > register int hlen; > > *************** > > *** 757,763 **** > > } > > #endif > > bzero(&ro, sizeof ro); > > ! (void) ip_output(m, opts, &ro, 0, NULL); > > if (ro.ro_rt) > > RTFREE(ro.ro_rt); > > } > > --- 1031,1037 ---- > > } > > #endif > > bzero(&ro, sizeof ro); > > ! (void) ip_output(m, opts, &ro, flags, NULL); > > if (ro.ro_rt) > > RTFREE(ro.ro_rt); > > } > > diff -c -r /unir/sys/netinet/ip_input.c netinet/ip_input.c > > *** /unir/sys/netinet/ip_input.c Wed Aug 29 21:41:37 2001 > > --- netinet/ip_input.c Wed Dec 12 09:57:20 2001 > > *************** > > *** 258,266 **** > > maxnipq = nmbclusters / 4; > > ip_maxfragpackets = nmbclusters / 4; > > > > - #ifndef RANDOM_IP_ID > > ip_id = time_second & 0xffff; > > ! #endif > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > register_netisr(NETISR_IP, ipintr); > > --- 258,275 ---- > > maxnipq = nmbclusters / 4; > > ip_maxfragpackets = nmbclusters / 4; > > > > ip_id = time_second & 0xffff; > > ! /* initialize all the StarGate id counters */ > > ! for(i=0; i<256; i++){ > > ! ip_id_[i] = time_second & 0xffff; > > ! } > > ! for(i=0; i<65536; i++){ > > ! src_gate[i] = 0x00; > > ! dst_gate[i] = 0x00; > > ! } > > ! galaxy_in=0; > > ! galaxy_out=0; > > ! > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > register_netisr(NETISR_IP, ipintr); > > *************** > > *** 269,274 **** > > --- 278,285 ---- > > static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; > > static struct route ipforward_rt; > > > > + extern unsigned char reverse_nibbles[]; > > + > > /* > > * Ip input routine. Checksum and byte swap header. If fragmented > > * try to reassemble. Process options. Pass to next level. > > *************** > > *** 287,292 **** > > --- 298,305 ---- > > u_int32_t divert_info = 0; /* packet divert/tee info */ > > #endif > > struct ip_fw_chain *rule = NULL; > > + u_int32_t src_addr; > > + u_int32_t dst_addr; > > > > #ifdef IPDIVERT > > /* Get and reset firewall cookie */ > > *************** > > *** 346,351 **** > > --- 359,365 ---- > > ip = mtod(m, struct ip *); > > } > > > > + > > /* 127/8 must not appear on wire - RFC1122 */ > > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || > > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { > > *************** > > *** 402,407 **** > > --- 416,483 ---- > > if (ipsec_gethist(m, NULL)) > > goto pass; > > #endif > > + > > + /* Process IPvXX ICMP++ packets that are special QoS codes */ > > + if((ip->ip_p==IPPROTO_ICMP) && (((ip->ip_tos&0xF0)==0)||((ip->ip_tos&0x0F)==0))){ > > + src_addr = ntohl(ip->ip_src.s_addr); > > + dst_addr = ntohl(ip->ip_dst.s_addr); > > + /* QoS(4)=Network Management */ > > + switch(ip->ip_tos){ > > + case 0x04: > > + /* Check for Galaxy PeaceKeeper */ > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > + if((src_addr&0x1F0F)==0){ > > + dst_gate[src_addr>>16] >>= 4; > > + dst_gate[src_addr>>16] |= src_addr&0xF0; > > + /* Check for possible new Galaxy setting */ > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > + galaxy_out=(src_addr&0x0E00)>>8; > > + log(LOG_WARNING,"Outbound Galactic Routing set to %d\n",galaxy_out); > > + } > > + else{ > > + galaxy_out=0; > > + } > > + } > > + break; > > + case 0x40: > > + /* Check for Galaxy PeaceKeeper */ > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > + if((src_addr&0x1F0F)==0){ > > + src_gate[src_addr>>16] >>= 4; > > + src_gate[src_addr>>16] |= src_addr&0xF0; > > + /* Check for possible new Galaxy setting */ > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > + galaxy_in=(src_addr&0x0E00)>>8; > > + log(LOG_WARNING,"Inbound Galactic Routing set to %d\n",galaxy_in); > > + } > > + else{ > > + galaxy_in=0; > > + } > > + } > > + break; > > + default: > > + log(LOG_WARNING,"Unknown ICMP+ QoS Code from %s\n", > > + inet_ntoa(ip->ip_src)); > > + } > > + } > > + /* Process IPvXX-style Packets */ > > + if((ip->ip_off&0x8000)!=0){ > > + /* Process non-Galaxy 0 Packets */ > > + if(((ip->ip_p&0xC0) != 0)&& > > + ((ip->ip_p&0x07) != galaxy_in)){ > > + printf("Dropped packet not from our galaxy\n"); > > + ipstat.ips_badaddr++; > > + goto bad; > > + } > > + else{ > > + /* Packet is Galaxy 0, are we ? */ > > + if(galaxy_in != 0){ > > + printf("Dropped packet not from our galaxy\n"); > > + ipstat.ips_badaddr++; > > + goto bad; > > + } > > + } > > + } > > > > /* > > * IpHack's section. > > diff -c -r /unir/sys/netinet/ip_mroute.c netinet/ip_mroute.c > > *** /unir/sys/netinet/ip_mroute.c Thu Jul 19 06:37:26 2001 > > --- netinet/ip_mroute.c Tue Dec 11 14:00:20 2001 > > *************** > > *** 1581,1590 **** > > */ > > ip_copy = mtod(mb_copy, struct ip *); > > *ip_copy = multicast_encap_iphdr; > > #ifdef RANDOM_IP_ID > > ip_copy->ip_id = ip_randomid(); > > #else > > ! ip_copy->ip_id = htons(ip_id++); > > #endif > > ip_copy->ip_len += len; > > ip_copy->ip_src = vifp->v_lcl_addr; > > --- 1581,1597 ---- > > */ > > ip_copy = mtod(mb_copy, struct ip *); > > *ip_copy = multicast_encap_iphdr; > > + ip_copy->ip_gate=0; > > #ifdef RANDOM_IP_ID > > ip_copy->ip_id = ip_randomid(); > > #else > > ! if(ip_copy->ip_tos != 0){ > > ! ip_copy->ip_id = ip_id_[ip_copy->ip_gate]++; > > ! } > > ! else{ > > ! ip_copy->ip_id = ip_id++; > > ! ip_copy->ip_gate = ip_id>>8; > > ! } > > #endif > > ip_copy->ip_len += len; > > ip_copy->ip_src = vifp->v_lcl_addr; > > diff -c -r /unir/sys/netinet/ip_output.c netinet/ip_output.c > > *** /unir/sys/netinet/ip_output.c Thu Jul 19 06:37:26 2001 > > --- netinet/ip_output.c Wed Dec 12 10:28:11 2001 > > *************** > > *** 52,57 **** > > --- 52,58 ---- > > #include > > #include > > #include > > + #include > > > > #include > > #include > > *************** > > *** 88,101 **** > > #include > > #endif > > > > ! #ifdef IPFIREWALL_FORWARD_DEBUG > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld",(ntohl(a.s_addr)>>24)&0xFF,\ > > (ntohl(a.s_addr)>>16)&0xFF,\ > > (ntohl(a.s_addr)>>8)&0xFF,\ > > (ntohl(a.s_addr))&0xFF); > > - #endif > > > > u_short ip_id; > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > --- 89,105 ---- > > #include > > #endif > > > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld ",(ntohl(a.s_addr)>>24)&0xFF,\ > > (ntohl(a.s_addr)>>16)&0xFF,\ > > (ntohl(a.s_addr)>>8)&0xFF,\ > > (ntohl(a.s_addr))&0xFF); > > > > u_short ip_id; > > + u_char ip_id_[256]; > > + u_char src_gate[65536]; > > + u_char dst_gate[65536]; > > + u_char galaxy_out; > > + u_char galaxy_in; > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > *************** > > *** 127,132 **** > > --- 131,137 ---- > > int flags; > > struct ip_moptions *imo; > > { > > + struct timeval random_time; > > struct ip *ip, *mhip; > > struct ifnet *ifp; > > struct mbuf *m = m0; > > *************** > > *** 207,219 **** > > /* > > * Fill in IP header. > > */ > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > ip->ip_off &= IP_DF; > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! ip->ip_id = htons(ip_id++); > > #endif > > ipstat.ips_localout++; > > } else { > > --- 212,252 ---- > > /* > > * Fill in IP header. > > */ > > + > > + /* Set UnirVerse on QoS-agile Packets */ > > + if(ip->ip_tos != 0){ > > + /* Allow reflectors and forwarders to prevent setting */ > > + if((flags & IP_UNIRVERSE_SET) == 0){ > > + getmicrotime(&random_time); > > + if(random_time.tv_usec&0x01){ > > + ip->ip_gate = > > + ((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])&0xF0) | > > + (((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])>>4)&0x0F); > > + } > > + else{ > > + ip->ip_gate = > > + (((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])<<4)&0xF0) | > > + ((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])&0x0F); > > + } > > + } > > + } > > + else{ > > + ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > + } > > + /* Set id based on UnirVerse */ > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > ip->ip_off &= IP_DF; > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! if(ip->ip_tos != 0){ > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > ! } > > ! else{ > > ! ip->ip_id = ip_id++; > > ! ip->ip_gate = ip_id>>8; > > ! } > > #endif > > ipstat.ips_localout++; > > } else { > > *************** > > *** 431,436 **** > > --- 464,470 ---- > > } > > > > sendit: > > + > > #ifdef IPSEC > > /* get SP for this packet */ > > if (so == NULL) > > diff -c -r /unir/sys/netinet/ip_var.h netinet/ip_var.h > > *** /unir/sys/netinet/ip_var.h Thu Jul 19 06:37:26 2001 > > --- netinet/ip_var.h Tue Dec 11 14:00:41 2001 > > *************** > > *** 133,138 **** > > --- 133,140 ---- > > /* flags passed to ip_output as last parameter */ > > #define IP_FORWARDING 0x1 /* most of ip header exists */ > > #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ > > + #define IP_UNIRVERSE_SET 0x4 /* UnirVerse set in header */ > > + > > #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ > > #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ > > > > *************** > > *** 142,150 **** > > struct sockopt; > > > > extern struct ipstat ipstat; > > ! #ifndef RANDOM_IP_ID > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > ! #endif > > extern int ip_defttl; /* default IP ttl */ > > extern int ipforwarding; /* ip forwarding */ > > extern u_char ip_protox[]; > > --- 144,157 ---- > > struct sockopt; > > > > extern struct ipstat ipstat; > > ! > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > ! extern u_char ip_id_[]; /* id counters for each StarGate */ > > ! extern u_char src_gate[]; > > ! extern u_char dst_gate[]; > > ! extern u_char galaxy_in; > > ! extern u_char galaxy_out; > > ! > > extern int ip_defttl; /* default IP ttl */ > > extern int ipforwarding; /* ip forwarding */ > > extern u_char ip_protox[]; > > diff -c -r /unir/sys/netinet/raw_ip.c netinet/raw_ip.c > > *** /unir/sys/netinet/raw_ip.c Sun Jul 29 19:32:40 2001 > > --- netinet/raw_ip.c Tue Dec 11 14:01:10 2001 > > *************** > > *** 239,249 **** > > m_freem(m); > > return EINVAL; > > } > > - if (ip->ip_id == 0) > > #ifdef RANDOM_IP_ID > > ip->ip_id = ip_randomid(); > > #else > > ! ip->ip_id = htons(ip_id++); > > #endif > > /* XXX prevent ip_output from overwriting header fields */ > > flags |= IP_RAWOUTPUT; > > --- 239,259 ---- > > m_freem(m); > > return EINVAL; > > } > > #ifdef RANDOM_IP_ID > > + if (ip->ip_id == 0){ > > ip->ip_id = ip_randomid(); > > + } > > #else > > ! if (ip->ip_id == 0){ > > ! if(ip->ip_tos != 0){ > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > ! ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > ! } > > ! else{ > > ! ip->ip_id = ip_id++; > > ! ip->ip_gate = ip_id>>8; > > ! } > > ! } > > #endif > > /* XXX prevent ip_output from overwriting header fields */ > > flags |= IP_RAWOUTPUT; > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 11: 3:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by hub.freebsd.org (Postfix) with ESMTP id 082E937B41B for ; Wed, 12 Dec 2001 11:03:11 -0800 (PST) Received: from IPv16 (as1b-243.chi.il.dial.anet.com [198.92.157.243]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id NAA12673; Wed, 12 Dec 2001 13:03:20 -0600 (CST) Message-ID: <061501c18341$49f6aba0$1000a8c0@Unir.com> From: "Jim Fleming" To: "Julian Elischer" Cc: "Jordan Hubbard" , "Andre Oppermann" , References: Subject: Re: RIFRAF Routing Changes for FreeBSD Date: Wed, 12 Dec 2001 13:14:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > + /* Check for possible new Galaxy setting */ > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > + galaxy_in=(src_addr&0x0E00)>>8; E000 in both cases....not 0E00 ----- Original Message ----- From: "Julian Elischer" To: "Jim Fleming" Cc: "Jordan Hubbard" ; "Andre Oppermann" ; Sent: Wednesday, December 12, 2001 12:45 PM Subject: Re: RIFRAF Routing Changes for FreeBSD > Now it belongs in freebsd-net :-) > > > On Wed, 12 Dec 2001, Jim Fleming wrote: > > > > > ----- Original Message ----- > > From: "Jordan Hubbard" > > To: "Jim Fleming" > > Cc: "Andre Oppermann" ; > > Sent: Wednesday, December 12, 2001 11:39 AM > > Subject: Re: RIFRAF Routing Changes for FreeBSD > > > > > > > > It all boils down to fairness. > > > > Which list do you think is more fair ? > > > > > > I think it boils down to something simpler than that: What does this > > > have to do with FreeBSD? > > > > > > The freebsd-arch list isn't for general discussion about things which > > > _might_ be relevant to FreeBSD users, such as potentially interesting > > > 3rd-party technologies or a great sale on hardware at Fred's PC Shack > > > this week. This list is for discussing proposed changes to FreeBSD, > > > ideally with sample code (which is applicable and ported to FreeBSD) > > > attached. That's all there is to it. If you want to discuss more > > > speculative or contraversial issues, freebsd-chat is the right mailing > > > list for that kind of thing. > > > > > > - Jordan > > > > > This may help... > > http://www.dot-biz.com/IPv4/Tutorial/ > > http://www.RepliGate.net > > > > The Netfilter Project: Packet Mangling for Linux 2.4 > > http://netfilter.samba.org > > > > Jim Fleming > > http://www.IPv8.info > > IPv16....One Better !! > > > > ----- Original Message ----- > > From: "Charlie Root" > > To: > > Sent: Wednesday, December 12, 2001 4:45 AM > > > > > > > diff -c -r /unir/sys/netinet/ip.h netinet/ip.h > > > *** /unir/sys/netinet/ip.h Wed Dec 22 19:13:20 1999 > > > --- netinet/ip.h Tue Dec 11 13:59:38 2001 > > > *************** > > > *** 43,48 **** > > > --- 43,53 ---- > > > */ > > > #define IPVERSION 4 > > > > > > + #define IPXX_V4 4 > > > + #define IPXX_V5 5 > > > + #define IPXX_V7 7 > > > + #define IPXX_V8 8 > > > + > > > /* > > > * Structure of an internet header, naked of options. > > > */ > > > *************** > > > *** 61,73 **** > > > #endif /* not _IP_VHL */ > > > u_char ip_tos; /* type of service */ > > > u_short ip_len; /* total length */ > > > ! u_short ip_id; /* identification */ > > > u_short ip_off; /* fragment offset field */ > > > #define IP_RF 0x8000 /* reserved fragment flag */ > > > #define IP_DF 0x4000 /* dont fragment flag */ > > > #define IP_MF 0x2000 /* more fragments flag */ > > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > > u_char ip_ttl; /* time to live */ > > > u_char ip_p; /* protocol */ > > > u_short ip_sum; /* checksum */ > > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > > --- 66,89 ---- > > > #endif /* not _IP_VHL */ > > > u_char ip_tos; /* type of service */ > > > u_short ip_len; /* total length */ > > > ! #define IPXX_UNIRVERSE_DEFAULT 0 /* Default IPv8 UnirVerse Value */ > > > ! u_char ip_gate; /* UnirVerse/StarGate */ > > > ! u_char ip_id; /* identification */ > > > u_short ip_off; /* fragment offset field */ > > > + #define IPXX_FLAG 0x8000 /* IPvXX flag */ > > > #define IP_RF 0x8000 /* reserved fragment flag */ > > > #define IP_DF 0x4000 /* dont fragment flag */ > > > #define IP_MF 0x2000 /* more fragments flag */ > > > #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ > > > u_char ip_ttl; /* time to live */ > > > + #define IPXX_GALAXY 033 /* IPv8 Galaxy Value for 3:219 .INFO */ > > > + #define IPXX_P_MASK 0x3F > > > + #define IPXX_ICMP_VAL 1 > > > + #define IPXX_ICMP_FLAG 0x40 > > > + #define IPXX_TCP_VAL 6 > > > + #define IPXX_TCP_FLAG 0x80 > > > + #define IPXX_UDP_VAL 16 > > > + #define IPXX_UDP_FLAG 0xC0 > > > u_char ip_p; /* protocol */ > > > u_short ip_sum; /* checksum */ > > > struct in_addr ip_src,ip_dst; /* source and dest address */ > > > diff -c -r /unir/sys/netinet/ip_icmp.c netinet/ip_icmp.c > > > *** /unir/sys/netinet/ip_icmp.c Tue Jul 3 11:01:46 2001 > > > --- netinet/ip_icmp.c Tue Dec 11 14:00:00 2001 > > > *************** > > > *** 121,132 **** > > > #endif > > > > > > static void icmp_reflect __P((struct mbuf *)); > > > ! static void icmp_send __P((struct mbuf *, struct mbuf *)); > > > static int ip_next_mtu __P((int, int)); > > > > > > extern struct protosw inetsw[]; > > > > > > /* > > > * Generate an error packet of type error > > > * in response to bad packet ip. > > > */ > > > --- 121,396 ---- > > > #endif > > > > > > static void icmp_reflect __P((struct mbuf *)); > > > ! static void icmp_send __P((struct mbuf *, struct mbuf *, int)); > > > static int ip_next_mtu __P((int, int)); > > > > > > extern struct protosw inetsw[]; > > > > > > /* > > > + * Table used to reverse the 4-bit source and destination values > > > + * in the 8-bit TOS field. > > > + */ > > > + > > > + unsigned char reverse_nibbles[256] = { > > > + /*00*/ 0x00, > > > + /*01*/ 0x10, > > > + /*02*/ 0x20, > > > + /*03*/ 0x30, > > > + /*04*/ 0x40, > > > + /*05*/ 0x50, > > > + /*06*/ 0x60, > > > + /*07*/ 0x70, > > > + /*08*/ 0x80, > > > + /*09*/ 0x90, > > > + /*0a*/ 0xa0, > > > + /*0b*/ 0xb0, > > > + /*0c*/ 0xc0, > > > + /*0d*/ 0xd0, > > > + /*0e*/ 0xe0, > > > + /*0f*/ 0xf0, > > > + /*10*/ 0x01, > > > + /*11*/ 0x11, > > > + /*12*/ 0x21, > > > + /*13*/ 0x31, > > > + /*14*/ 0x41, > > > + /*15*/ 0x51, > > > + /*16*/ 0x61, > > > + /*17*/ 0x71, > > > + /*18*/ 0x81, > > > + /*19*/ 0x91, > > > + /*1a*/ 0xa1, > > > + /*1b*/ 0xb1, > > > + /*1c*/ 0xc1, > > > + /*1d*/ 0xd1, > > > + /*1e*/ 0xe1, > > > + /*1f*/ 0xf1, > > > + /*20*/ 0x02, > > > + /*21*/ 0x12, > > > + /*22*/ 0x22, > > > + /*23*/ 0x32, > > > + /*24*/ 0x42, > > > + /*25*/ 0x52, > > > + /*26*/ 0x62, > > > + /*27*/ 0x72, > > > + /*28*/ 0x82, > > > + /*29*/ 0x92, > > > + /*2a*/ 0xa2, > > > + /*2b*/ 0xb2, > > > + /*2c*/ 0xc2, > > > + /*2d*/ 0xd2, > > > + /*2e*/ 0xe2, > > > + /*2f*/ 0xf2, > > > + /*30*/ 0x03, > > > + /*31*/ 0x13, > > > + /*32*/ 0x23, > > > + /*33*/ 0x33, > > > + /*34*/ 0x43, > > > + /*35*/ 0x53, > > > + /*36*/ 0x63, > > > + /*37*/ 0x73, > > > + /*38*/ 0x83, > > > + /*39*/ 0x93, > > > + /*3a*/ 0xa3, > > > + /*3b*/ 0xb3, > > > + /*3c*/ 0xc3, > > > + /*3d*/ 0xd3, > > > + /*3e*/ 0xe3, > > > + /*3f*/ 0xf3, > > > + /*40*/ 0x04, > > > + /*41*/ 0x14, > > > + /*42*/ 0x24, > > > + /*43*/ 0x34, > > > + /*44*/ 0x44, > > > + /*45*/ 0x54, > > > + /*46*/ 0x64, > > > + /*47*/ 0x74, > > > + /*48*/ 0x84, > > > + /*49*/ 0x94, > > > + /*4a*/ 0xa4, > > > + /*4b*/ 0xb4, > > > + /*4c*/ 0xc4, > > > + /*4d*/ 0xd4, > > > + /*4e*/ 0xe4, > > > + /*4f*/ 0xf4, > > > + /*50*/ 0x05, > > > + /*51*/ 0x15, > > > + /*52*/ 0x25, > > > + /*53*/ 0x35, > > > + /*54*/ 0x45, > > > + /*55*/ 0x55, > > > + /*56*/ 0x65, > > > + /*57*/ 0x75, > > > + /*58*/ 0x85, > > > + /*59*/ 0x95, > > > + /*5a*/ 0xa5, > > > + /*5b*/ 0xb5, > > > + /*5c*/ 0xc5, > > > + /*5d*/ 0xd5, > > > + /*5e*/ 0xe5, > > > + /*5f*/ 0xf5, > > > + /*60*/ 0x06, > > > + /*61*/ 0x16, > > > + /*62*/ 0x26, > > > + /*63*/ 0x36, > > > + /*64*/ 0x46, > > > + /*65*/ 0x56, > > > + /*66*/ 0x66, > > > + /*67*/ 0x76, > > > + /*68*/ 0x86, > > > + /*69*/ 0x96, > > > + /*6a*/ 0xa6, > > > + /*6b*/ 0xb6, > > > + /*6c*/ 0xc6, > > > + /*6d*/ 0xd6, > > > + /*6e*/ 0xe6, > > > + /*6f*/ 0xf6, > > > + /*70*/ 0x07, > > > + /*71*/ 0x17, > > > + /*72*/ 0x27, > > > + /*73*/ 0x37, > > > + /*74*/ 0x47, > > > + /*75*/ 0x57, > > > + /*76*/ 0x67, > > > + /*77*/ 0x77, > > > + /*78*/ 0x87, > > > + /*79*/ 0x97, > > > + /*7a*/ 0xa7, > > > + /*7b*/ 0xb7, > > > + /*7c*/ 0xc7, > > > + /*7d*/ 0xd7, > > > + /*7e*/ 0xe7, > > > + /*7f*/ 0xf7, > > > + /*80*/ 0x08, > > > + /*81*/ 0x18, > > > + /*82*/ 0x28, > > > + /*83*/ 0x38, > > > + /*84*/ 0x48, > > > + /*85*/ 0x58, > > > + /*86*/ 0x68, > > > + /*87*/ 0x78, > > > + /*88*/ 0x88, > > > + /*89*/ 0x98, > > > + /*8a*/ 0xa8, > > > + /*8b*/ 0xb8, > > > + /*8c*/ 0xc8, > > > + /*8d*/ 0xd8, > > > + /*8e*/ 0xe8, > > > + /*8f*/ 0xf8, > > > + /*90*/ 0x09, > > > + /*91*/ 0x19, > > > + /*92*/ 0x29, > > > + /*93*/ 0x39, > > > + /*94*/ 0x49, > > > + /*95*/ 0x59, > > > + /*96*/ 0x69, > > > + /*97*/ 0x79, > > > + /*98*/ 0x89, > > > + /*99*/ 0x99, > > > + /*9a*/ 0xa9, > > > + /*9b*/ 0xb9, > > > + /*9c*/ 0xc9, > > > + /*9d*/ 0xd9, > > > + /*9e*/ 0xe9, > > > + /*9f*/ 0xf9, > > > + /*a0*/ 0x0a, > > > + /*a1*/ 0x1a, > > > + /*a2*/ 0x2a, > > > + /*a3*/ 0x3a, > > > + /*a4*/ 0x4a, > > > + /*a5*/ 0x5a, > > > + /*a6*/ 0x6a, > > > + /*a7*/ 0x7a, > > > + /*a8*/ 0x8a, > > > + /*a9*/ 0x9a, > > > + /*aa*/ 0xaa, > > > + /*ab*/ 0xba, > > > + /*ac*/ 0xca, > > > + /*ad*/ 0xda, > > > + /*ae*/ 0xea, > > > + /*af*/ 0xfa, > > > + /*b0*/ 0x0b, > > > + /*b1*/ 0x1b, > > > + /*b2*/ 0x2b, > > > + /*b3*/ 0x3b, > > > + /*b4*/ 0x4b, > > > + /*b5*/ 0x5b, > > > + /*b6*/ 0x6b, > > > + /*b7*/ 0x7b, > > > + /*b8*/ 0x8b, > > > + /*b9*/ 0x9b, > > > + /*ba*/ 0xab, > > > + /*bb*/ 0xbb, > > > + /*bc*/ 0xcb, > > > + /*bd*/ 0xdb, > > > + /*be*/ 0xeb, > > > + /*bf*/ 0xfb, > > > + /*c0*/ 0x0c, > > > + /*c1*/ 0x1c, > > > + /*c2*/ 0x2c, > > > + /*c3*/ 0x3c, > > > + /*c4*/ 0x4c, > > > + /*c5*/ 0x5c, > > > + /*c6*/ 0x6c, > > > + /*c7*/ 0x7c, > > > + /*c8*/ 0x8c, > > > + /*c9*/ 0x9c, > > > + /*ca*/ 0xac, > > > + /*cb*/ 0xbc, > > > + /*cc*/ 0xcc, > > > + /*cd*/ 0xdc, > > > + /*ce*/ 0xec, > > > + /*cf*/ 0xfc, > > > + /*d0*/ 0x0d, > > > + /*d1*/ 0x1d, > > > + /*d2*/ 0x2d, > > > + /*d3*/ 0x3d, > > > + /*d4*/ 0x4d, > > > + /*d5*/ 0x5d, > > > + /*d6*/ 0x6d, > > > + /*d7*/ 0x7d, > > > + /*d8*/ 0x8d, > > > + /*d9*/ 0x9d, > > > + /*da*/ 0xad, > > > + /*db*/ 0xbd, > > > + /*dc*/ 0xcd, > > > + /*dd*/ 0xdd, > > > + /*de*/ 0xed, > > > + /*df*/ 0xfd, > > > + /*e0*/ 0x0e, > > > + /*e1*/ 0x1e, > > > + /*e2*/ 0x2e, > > > + /*e3*/ 0x3e, > > > + /*e4*/ 0x4e, > > > + /*e5*/ 0x5e, > > > + /*e6*/ 0x6e, > > > + /*e7*/ 0x7e, > > > + /*e8*/ 0x8e, > > > + /*e9*/ 0x9e, > > > + /*ea*/ 0xae, > > > + /*eb*/ 0xbe, > > > + /*ec*/ 0xce, > > > + /*ed*/ 0xde, > > > + /*ee*/ 0xee, > > > + /*ef*/ 0xfe, > > > + /*f0*/ 0x0f, > > > + /*f1*/ 0x1f, > > > + /*f2*/ 0x2f, > > > + /*f3*/ 0x3f, > > > + /*f4*/ 0x4f, > > > + /*f5*/ 0x5f, > > > + /*f6*/ 0x6f, > > > + /*f7*/ 0x7f, > > > + /*f8*/ 0x8f, > > > + /*f9*/ 0x9f, > > > + /*fa*/ 0xaf, > > > + /*fb*/ 0xbf, > > > + /*fc*/ 0xcf, > > > + /*fd*/ 0xdf, > > > + /*fe*/ 0xef, > > > + /*ff*/ 0xff > > > + }; > > > + > > > + /* > > > * Generate an error packet of type error > > > * in response to bad packet ip. > > > */ > > > *************** > > > *** 226,232 **** > > > nip->ip_len = m->m_len; > > > nip->ip_vhl = IP_VHL_BORING; > > > nip->ip_p = IPPROTO_ICMP; > > > ! nip->ip_tos = 0; > > > icmp_reflect(m); > > > > > > freeit: > > > --- 490,496 ---- > > > nip->ip_len = m->m_len; > > > nip->ip_vhl = IP_VHL_BORING; > > > nip->ip_p = IPPROTO_ICMP; > > > ! nip->ip_tos = 0x44; /* Network Management Flow */ > > > icmp_reflect(m); > > > > > > freeit: > > > *************** > > > *** 610,615 **** > > > --- 874,880 ---- > > > struct in_addr t; > > > struct mbuf *opts = 0; > > > int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); > > > + int flags = 0; > > > > > > if (!in_canforward(ip->ip_src) && > > > ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) != > > > *************** > > > *** 617,622 **** > > > --- 882,895 ---- > > > m_freem(m); /* Bad return address */ > > > goto done; /* Ip_output() will check for broadcast */ > > > } > > > + /* Handle IPv8 TOS and UnirVerse fields */ > > > + if(((ip->ip_tos&0xF0)!=0) && ((ip->ip_tos&0x0F)!=0)){ > > > + ip->ip_tos = reverse_nibbles[ip->ip_tos]; > > > + if(ip->ip_gate != IPXX_UNIRVERSE_DEFAULT){ > > > + ip->ip_gate = reverse_nibbles[ip->ip_gate]; > > > + flags |= IP_UNIRVERSE_SET; > > > + } > > > + } > > > t = ip->ip_dst; > > > ip->ip_dst = ip->ip_src; > > > /* > > > *************** > > > *** 719,725 **** > > > (unsigned)(m->m_len - sizeof(struct ip))); > > > } > > > m->m_flags &= ~(M_BCAST|M_MCAST); > > > ! icmp_send(m, opts); > > > done: > > > if (opts) > > > (void)m_free(opts); > > > --- 992,998 ---- > > > (unsigned)(m->m_len - sizeof(struct ip))); > > > } > > > m->m_flags &= ~(M_BCAST|M_MCAST); > > > ! icmp_send(m,opts,flags); > > > done: > > > if (opts) > > > (void)m_free(opts); > > > *************** > > > *** 730,738 **** > > > * after supplying a checksum. > > > */ > > > static void > > > ! icmp_send(m, opts) > > > register struct mbuf *m; > > > struct mbuf *opts; > > > { > > > register struct ip *ip = mtod(m, struct ip *); > > > register int hlen; > > > --- 1003,1012 ---- > > > * after supplying a checksum. > > > */ > > > static void > > > ! icmp_send(m,opts,flags) > > > register struct mbuf *m; > > > struct mbuf *opts; > > > + int flags; > > > { > > > register struct ip *ip = mtod(m, struct ip *); > > > register int hlen; > > > *************** > > > *** 757,763 **** > > > } > > > #endif > > > bzero(&ro, sizeof ro); > > > ! (void) ip_output(m, opts, &ro, 0, NULL); > > > if (ro.ro_rt) > > > RTFREE(ro.ro_rt); > > > } > > > --- 1031,1037 ---- > > > } > > > #endif > > > bzero(&ro, sizeof ro); > > > ! (void) ip_output(m, opts, &ro, flags, NULL); > > > if (ro.ro_rt) > > > RTFREE(ro.ro_rt); > > > } > > > diff -c -r /unir/sys/netinet/ip_input.c netinet/ip_input.c > > > *** /unir/sys/netinet/ip_input.c Wed Aug 29 21:41:37 2001 > > > --- netinet/ip_input.c Wed Dec 12 09:57:20 2001 > > > *************** > > > *** 258,266 **** > > > maxnipq = nmbclusters / 4; > > > ip_maxfragpackets = nmbclusters / 4; > > > > > > - #ifndef RANDOM_IP_ID > > > ip_id = time_second & 0xffff; > > > ! #endif > > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > > > register_netisr(NETISR_IP, ipintr); > > > --- 258,275 ---- > > > maxnipq = nmbclusters / 4; > > > ip_maxfragpackets = nmbclusters / 4; > > > > > > ip_id = time_second & 0xffff; > > > ! /* initialize all the StarGate id counters */ > > > ! for(i=0; i<256; i++){ > > > ! ip_id_[i] = time_second & 0xffff; > > > ! } > > > ! for(i=0; i<65536; i++){ > > > ! src_gate[i] = 0x00; > > > ! dst_gate[i] = 0x00; > > > ! } > > > ! galaxy_in=0; > > > ! galaxy_out=0; > > > ! > > > ipintrq.ifq_maxlen = ipqmaxlen; > > > > > > register_netisr(NETISR_IP, ipintr); > > > *************** > > > *** 269,274 **** > > > --- 278,285 ---- > > > static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET }; > > > static struct route ipforward_rt; > > > > > > + extern unsigned char reverse_nibbles[]; > > > + > > > /* > > > * Ip input routine. Checksum and byte swap header. If fragmented > > > * try to reassemble. Process options. Pass to next level. > > > *************** > > > *** 287,292 **** > > > --- 298,305 ---- > > > u_int32_t divert_info = 0; /* packet divert/tee info */ > > > #endif > > > struct ip_fw_chain *rule = NULL; > > > + u_int32_t src_addr; > > > + u_int32_t dst_addr; > > > > > > #ifdef IPDIVERT > > > /* Get and reset firewall cookie */ > > > *************** > > > *** 346,351 **** > > > --- 359,365 ---- > > > ip = mtod(m, struct ip *); > > > } > > > > > > + > > > /* 127/8 must not appear on wire - RFC1122 */ > > > if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || > > > (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { > > > *************** > > > *** 402,407 **** > > > --- 416,483 ---- > > > if (ipsec_gethist(m, NULL)) > > > goto pass; > > > #endif > > > + > > > + /* Process IPvXX ICMP++ packets that are special QoS codes */ > > > + if((ip->ip_p==IPPROTO_ICMP) && (((ip->ip_tos&0xF0)==0)||((ip->ip_tos&0x0F)==0))){ > > > + src_addr = ntohl(ip->ip_src.s_addr); > > > + dst_addr = ntohl(ip->ip_dst.s_addr); > > > + /* QoS(4)=Network Management */ > > > + switch(ip->ip_tos){ > > > + case 0x04: > > > + /* Check for Galaxy PeaceKeeper */ > > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > > + if((src_addr&0x1F0F)==0){ > > > + dst_gate[src_addr>>16] >>= 4; > > > + dst_gate[src_addr>>16] |= src_addr&0xF0; > > > + /* Check for possible new Galaxy setting */ > > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > > + galaxy_out=(src_addr&0x0E00)>>8; > > > + log(LOG_WARNING,"Outbound Galactic Routing set to %d\n",galaxy_out); > > > + } > > > + else{ > > > + galaxy_out=0; > > > + } > > > + } > > > + break; > > > + case 0x40: > > > + /* Check for Galaxy PeaceKeeper */ > > > + /* PPPPPPPP.PPPPPPPP.GGG00000.XXXX0000 */ > > > + if((src_addr&0x1F0F)==0){ > > > + src_gate[src_addr>>16] >>= 4; > > > + src_gate[src_addr>>16] |= src_addr&0xF0; > > > + /* Check for possible new Galaxy setting */ > > > + if(((src_addr&0x0E00)!=0)&&((src_addr&0xFFFF0000)==(dst_addr&0xFFFF0000))){ > > > + galaxy_in=(src_addr&0x0E00)>>8; > > > + log(LOG_WARNING,"Inbound Galactic Routing set to %d\n",galaxy_in); > > > + } > > > + else{ > > > + galaxy_in=0; > > > + } > > > + } > > > + break; > > > + default: > > > + log(LOG_WARNING,"Unknown ICMP+ QoS Code from %s\n", > > > + inet_ntoa(ip->ip_src)); > > > + } > > > + } > > > + /* Process IPvXX-style Packets */ > > > + if((ip->ip_off&0x8000)!=0){ > > > + /* Process non-Galaxy 0 Packets */ > > > + if(((ip->ip_p&0xC0) != 0)&& > > > + ((ip->ip_p&0x07) != galaxy_in)){ > > > + printf("Dropped packet not from our galaxy\n"); > > > + ipstat.ips_badaddr++; > > > + goto bad; > > > + } > > > + else{ > > > + /* Packet is Galaxy 0, are we ? */ > > > + if(galaxy_in != 0){ > > > + printf("Dropped packet not from our galaxy\n"); > > > + ipstat.ips_badaddr++; > > > + goto bad; > > > + } > > > + } > > > + } > > > > > > /* > > > * IpHack's section. > > > diff -c -r /unir/sys/netinet/ip_mroute.c netinet/ip_mroute.c > > > *** /unir/sys/netinet/ip_mroute.c Thu Jul 19 06:37:26 2001 > > > --- netinet/ip_mroute.c Tue Dec 11 14:00:20 2001 > > > *************** > > > *** 1581,1590 **** > > > */ > > > ip_copy = mtod(mb_copy, struct ip *); > > > *ip_copy = multicast_encap_iphdr; > > > #ifdef RANDOM_IP_ID > > > ip_copy->ip_id = ip_randomid(); > > > #else > > > ! ip_copy->ip_id = htons(ip_id++); > > > #endif > > > ip_copy->ip_len += len; > > > ip_copy->ip_src = vifp->v_lcl_addr; > > > --- 1581,1597 ---- > > > */ > > > ip_copy = mtod(mb_copy, struct ip *); > > > *ip_copy = multicast_encap_iphdr; > > > + ip_copy->ip_gate=0; > > > #ifdef RANDOM_IP_ID > > > ip_copy->ip_id = ip_randomid(); > > > #else > > > ! if(ip_copy->ip_tos != 0){ > > > ! ip_copy->ip_id = ip_id_[ip_copy->ip_gate]++; > > > ! } > > > ! else{ > > > ! ip_copy->ip_id = ip_id++; > > > ! ip_copy->ip_gate = ip_id>>8; > > > ! } > > > #endif > > > ip_copy->ip_len += len; > > > ip_copy->ip_src = vifp->v_lcl_addr; > > > diff -c -r /unir/sys/netinet/ip_output.c netinet/ip_output.c > > > *** /unir/sys/netinet/ip_output.c Thu Jul 19 06:37:26 2001 > > > --- netinet/ip_output.c Wed Dec 12 10:28:11 2001 > > > *************** > > > *** 52,57 **** > > > --- 52,58 ---- > > > #include > > > #include > > > #include > > > + #include > > > > > > #include > > > #include > > > *************** > > > *** 88,101 **** > > > #include > > > #endif > > > > > > ! #ifdef IPFIREWALL_FORWARD_DEBUG > > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld",(ntohl(a.s_addr)>>24)&0xFF,\ > > > (ntohl(a.s_addr)>>16)&0xFF,\ > > > (ntohl(a.s_addr)>>8)&0xFF,\ > > > (ntohl(a.s_addr))&0xFF); > > > - #endif > > > > > > u_short ip_id; > > > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > > --- 89,105 ---- > > > #include > > > #endif > > > > > > ! #define print_ip(a) printf("%ld.%ld.%ld.%ld ",(ntohl(a.s_addr)>>24)&0xFF,\ > > > (ntohl(a.s_addr)>>16)&0xFF,\ > > > (ntohl(a.s_addr)>>8)&0xFF,\ > > > (ntohl(a.s_addr))&0xFF); > > > > > > u_short ip_id; > > > + u_char ip_id_[256]; > > > + u_char src_gate[65536]; > > > + u_char dst_gate[65536]; > > > + u_char galaxy_out; > > > + u_char galaxy_in; > > > > > > static struct mbuf *ip_insertoptions __P((struct mbuf *, struct mbuf *, int *)); > > > static struct ifnet *ip_multicast_if __P((struct in_addr *, int *)); > > > *************** > > > *** 127,132 **** > > > --- 131,137 ---- > > > int flags; > > > struct ip_moptions *imo; > > > { > > > + struct timeval random_time; > > > struct ip *ip, *mhip; > > > struct ifnet *ifp; > > > struct mbuf *m = m0; > > > *************** > > > *** 207,219 **** > > > /* > > > * Fill in IP header. > > > */ > > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > > ip->ip_off &= IP_DF; > > > #ifdef RANDOM_IP_ID > > > ip->ip_id = ip_randomid(); > > > #else > > > ! ip->ip_id = htons(ip_id++); > > > #endif > > > ipstat.ips_localout++; > > > } else { > > > --- 212,252 ---- > > > /* > > > * Fill in IP header. > > > */ > > > + > > > + /* Set UnirVerse on QoS-agile Packets */ > > > + if(ip->ip_tos != 0){ > > > + /* Allow reflectors and forwarders to prevent setting */ > > > + if((flags & IP_UNIRVERSE_SET) == 0){ > > > + getmicrotime(&random_time); > > > + if(random_time.tv_usec&0x01){ > > > + ip->ip_gate = > > > + ((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])&0xF0) | > > > + (((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])>>4)&0x0F); > > > + } > > > + else{ > > > + ip->ip_gate = > > > + (((src_gate[(ntohl(ip->ip_src.s_addr)>>16)&0xFFFF])<<4)&0xF0) | > > > + ((dst_gate[(ntohl(ip->ip_dst.s_addr)>>16)&0xFFFF])&0x0F); > > > + } > > > + } > > > + } > > > + else{ > > > + ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > > + } > > > + /* Set id based on UnirVerse */ > > > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > > > ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); > > > ip->ip_off &= IP_DF; > > > #ifdef RANDOM_IP_ID > > > ip->ip_id = ip_randomid(); > > > #else > > > ! if(ip->ip_tos != 0){ > > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > > ! } > > > ! else{ > > > ! ip->ip_id = ip_id++; > > > ! ip->ip_gate = ip_id>>8; > > > ! } > > > #endif > > > ipstat.ips_localout++; > > > } else { > > > *************** > > > *** 431,436 **** > > > --- 464,470 ---- > > > } > > > > > > sendit: > > > + > > > #ifdef IPSEC > > > /* get SP for this packet */ > > > if (so == NULL) > > > diff -c -r /unir/sys/netinet/ip_var.h netinet/ip_var.h > > > *** /unir/sys/netinet/ip_var.h Thu Jul 19 06:37:26 2001 > > > --- netinet/ip_var.h Tue Dec 11 14:00:41 2001 > > > *************** > > > *** 133,138 **** > > > --- 133,140 ---- > > > /* flags passed to ip_output as last parameter */ > > > #define IP_FORWARDING 0x1 /* most of ip header exists */ > > > #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ > > > + #define IP_UNIRVERSE_SET 0x4 /* UnirVerse set in header */ > > > + > > > #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ > > > #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ > > > > > > *************** > > > *** 142,150 **** > > > struct sockopt; > > > > > > extern struct ipstat ipstat; > > > ! #ifndef RANDOM_IP_ID > > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > > ! #endif > > > extern int ip_defttl; /* default IP ttl */ > > > extern int ipforwarding; /* ip forwarding */ > > > extern u_char ip_protox[]; > > > --- 144,157 ---- > > > struct sockopt; > > > > > > extern struct ipstat ipstat; > > > ! > > > ! extern u_short ip_id; /* ip packet ctr, for ids */ > > > ! extern u_char ip_id_[]; /* id counters for each StarGate */ > > > ! extern u_char src_gate[]; > > > ! extern u_char dst_gate[]; > > > ! extern u_char galaxy_in; > > > ! extern u_char galaxy_out; > > > ! > > > extern int ip_defttl; /* default IP ttl */ > > > extern int ipforwarding; /* ip forwarding */ > > > extern u_char ip_protox[]; > > > diff -c -r /unir/sys/netinet/raw_ip.c netinet/raw_ip.c > > > *** /unir/sys/netinet/raw_ip.c Sun Jul 29 19:32:40 2001 > > > --- netinet/raw_ip.c Tue Dec 11 14:01:10 2001 > > > *************** > > > *** 239,249 **** > > > m_freem(m); > > > return EINVAL; > > > } > > > - if (ip->ip_id == 0) > > > #ifdef RANDOM_IP_ID > > > ip->ip_id = ip_randomid(); > > > #else > > > ! ip->ip_id = htons(ip_id++); > > > #endif > > > /* XXX prevent ip_output from overwriting header fields */ > > > flags |= IP_RAWOUTPUT; > > > --- 239,259 ---- > > > m_freem(m); > > > return EINVAL; > > > } > > > #ifdef RANDOM_IP_ID > > > + if (ip->ip_id == 0){ > > > ip->ip_id = ip_randomid(); > > > + } > > > #else > > > ! if (ip->ip_id == 0){ > > > ! if(ip->ip_tos != 0){ > > > ! ip->ip_id = ip_id_[ip->ip_gate]++; > > > ! ip->ip_gate = IPXX_UNIRVERSE_DEFAULT; > > > ! } > > > ! else{ > > > ! ip->ip_id = ip_id++; > > > ! ip->ip_gate = ip_id>>8; > > > ! } > > > ! } > > > #endif > > > /* XXX prevent ip_output from overwriting header fields */ > > > flags |= IP_RAWOUTPUT; > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-arch" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 12:21:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 79A2837B416; Wed, 12 Dec 2001 12:21:50 -0800 (PST) Received: from user-33qtm6u.dialup.mindspring.com ([199.174.216.222] helo=gohan.cjclark.org) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EFsk-0002Fx-00; Wed, 12 Dec 2001 12:21:35 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.1) id fBC1USG04267; Tue, 11 Dec 2001 17:30:28 -0800 (PST) (envelope-from cjc) Date: Tue, 11 Dec 2001 17:30:28 -0800 From: "Crist J. Clark" To: Peter Wemm Cc: Nik Clayton , Garance A Drosihn , Greg Lehey , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011211173028.H232@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011211234433.B697@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011212001610.9AEA739EA@overcee.netplex.com.au>; from peter@wemm.org on Tue, Dec 11, 2001 at 04:16:10PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 11, 2001 at 04:16:10PM -0800, Peter Wemm wrote: > Nik Clayton wrote: > > > > --gj572EiMnwbLXET9 > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Tue, Dec 11, 2001 at 06:23:15PM -0500, Garance A Drosihn wrote: > > > In the land of weird suggestions, just how weird would it be to > > > suggest that we create some way for 'cat' versions of man pages > > > to land somewhere else? > > >=20 > > > Maybe /var/man/usr/share/cat* > > > for ones from /usr/share/man/man* > > > etc? > > > > Sounds like a good idea. > > I for one would like it a lot. Nothing in man(1) actually breaks if you just make /usr read-only. You won't get cached pages, but in this day of overpowered CPUs, who cares? OTOH, in these days of super-cheap HHD, who needs markup pages except for the developers? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 13: 2: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A1F3637B405 for ; Wed, 12 Dec 2001 13:02:04 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBCL21Q68587; Wed, 12 Dec 2001 16:02:01 -0500 (EST) (envelope-from wollman) Date: Wed, 12 Dec 2001 16:02:01 -0500 (EST) From: Garrett Wollman Message-Id: <200112122102.fBCL21Q68587@khavrinen.lcs.mit.edu> To: jkh@winston.freebsd.org Subject: Re: RIFRAF Routing Changes for FreeBSD In-Reply-To: <52830.1008178778@winston.freebsd.org> References: Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <52830.1008178778@winston.freebsd.org> you write: >The freebsd-arch list isn't for general discussion about things which >_might_ be relevant to FreeBSD users, such as potentially interesting >3rd-party technologies or a great sale on hardware at Fred's PC Shack >this week. It certainly isn't for the lunatic ravings of well-known net.kooks. There's a reason this particular character is known far as wide as Jim Flaming. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 13:17:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D73337B417 for ; Wed, 12 Dec 2001 13:17:45 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBCLHia87384; Wed, 12 Dec 2001 14:17:44 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBCLHhM38741; Wed, 12 Dec 2001 14:17:43 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112122117.fBCLHhM38741@harmony.village.org> To: cjclark@alum.mit.edu Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 11 Dec 2001 17:30:28 PST." <20011211173028.H232@gohan.cjclark.org> References: <20011211173028.H232@gohan.cjclark.org> <20011211234433.B697@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> Date: Wed, 12 Dec 2001 14:17:43 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: : Nothing in man(1) actually breaks if you just make /usr read-only. You : won't get cached pages, but in this day of overpowered CPUs, who : cares? OTOH, in these days of super-cheap HHD, who needs markup pages : except for the developers? Well, if installworld did a catman phase... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 13:22: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0FEE137B417 for ; Wed, 12 Dec 2001 13:22:05 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBCLM4a87400; Wed, 12 Dec 2001 14:22:04 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBCLM3M38772; Wed, 12 Dec 2001 14:22:03 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112122122.fBCLM3M38772@harmony.village.org> To: Thomas Zenker Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Wed, 12 Dec 2001 22:03:26 +0100." <20011212220325.A3251@peotl.homeip.net> References: <20011212220325.A3251@peotl.homeip.net> <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> <20011212090610.D67986@monorchid.lemis.com> <20011212131734.B82733@monorchid.lemis.com> Date: Wed, 12 Dec 2001 14:22:03 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011212220325.A3251@peotl.homeip.net> Thomas Zenker writes: : role and you haven't to do a lot of changes, this works optimal, no : fscks on / and /usr, very quick boot times. Yes. We fsck a 5-10M filesystem on boot. We then fsck -y it if it didn't work. We have though about newfs if that didn't work :-), but haven't done it yet. We get very fast boot times as well. If you are running an embedded system, combining / and /usr and building things NOSHARED=no will give you a space savings of several megabytes because then all of /bin and /sbin are linked dynamically. We've deployed about 100 systems like this and haven't had any problems with it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 13:22:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iscserv7.nepustil.net (NS.Nepustil.NET [193.96.243.22]) by hub.freebsd.org (Postfix) with ESMTP id 6153837B405; Wed, 12 Dec 2001 13:22:01 -0800 (PST) Received: from peotl.homeip.net (tuebpool-152.pm3.nepustil.net [212.71.200.152]) by iscserv7.nepustil.net (Sendmail) with ESMTP id 6D1C37A044; Wed, 12 Dec 2001 22:21:49 +0100 (CET) Received: (from thz@localhost) by peotl.homeip.net (8.11.6/8.11.6) id fBCL3Q703546; Wed, 12 Dec 2001 22:03:26 +0100 (MET) (envelope-from thz) Date: Wed, 12 Dec 2001 22:03:26 +0100 From: Thomas Zenker To: Greg Lehey Cc: Garance A Drosihn , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011212220325.A3251@peotl.homeip.net> References: <20011210124458.B63585@monorchid.lemis.com> <20011208102658.B11428@dragon.nuxi.com> <200112082050.fB8Ko1T01347@mass.dis.org> <20011209164606.C83634@monorchid.lemis.com> <20011209104437.A69671@clan.nothing-going-on.org> <3C141A26.9D8BC688@mindspring.com> <200112110946.fBB9kMM26143@harmony.village.org> <20011212090610.D67986@monorchid.lemis.com> <20011212131734.B82733@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20011212131734.B82733@monorchid.lemis.com>; from grog@FreeBSD.ORG on Wed, Dec 12, 2001 at 01:17:35PM +1030 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Dec 12, 2001 at 01:17:35PM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 18:23:15 -0500, Garance A Drosihn wrote: > > At 9:06 AM +1030 12/12/01, Greg Lehey wrote: > >> On Tuesday, 11 Dec 2001, Warner Losh wrote: > >>> I suspect, however, that we'll find that crash recovery really is a > >>> big factor since /usr does get written to on every man command that > >>> generates a new man page... > >> > >> That's pretty seldom. > >> > >> $ find /usr/share/man/cat* -type f | wc -l > >> 3277 > > > > In the land of weird suggestions, just how weird would it be to > > suggest that we create some way for 'cat' versions of man pages > > to land somewhere else? > > > > Maybe /var/man/usr/share/cat* > > for ones from /usr/share/man/man* > > This seems to make a lot of sense. If we could find a way to make a / > file system (including /usr) read only, this would be a great > advantage. > > Greg > we are using fbsd here in semi-embedded fashion in our equipment, with / and /usr mounted readonly, all our own stuff and its configs are on an extra partition /home which is rw. The man-pages are not a problem (really I had forgotten about it), the difference only is, that it lasts a bit longer to view the manpage allways, not only the first time - no errors. For a machine which has a dedicated role and you haven't to do a lot of changes, this works optimal, no fscks on / and /usr, very quick boot times. Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 13:22:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id B0CAB37B41C for ; Wed, 12 Dec 2001 13:22:22 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id fBCLMJ740804; Wed, 12 Dec 2001 16:22:19 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200112122122.fBCLMJ740804@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garrett Wollman Cc: jkh@winston.freebsd.org, arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: RIFRAF Routing Changes for FreeBSD References: <200112122102.fBCL21Q68587@khavrinen.lcs.mit.edu> In-reply-to: Your message of "Wed, 12 Dec 2001 16:02:01 EST." <200112122102.fBCL21Q68587@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Dec 2001 16:22:19 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In article <52830.1008178778@winston.freebsd.org> you write: > > >The freebsd-arch list isn't for general discussion about things which > >_might_ be relevant to FreeBSD users, such as potentially interesting > >3rd-party technologies or a great sale on hardware at Fred's PC Shack > >this week. > > It certainly isn't for the lunatic ravings of well-known net.kooks. > There's a reason this particular character is known far as wide as Jim > Flaming. Yes, please don't feed the net.kooks or the trolls. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 14:52:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 0656337B416 for ; Wed, 12 Dec 2001 14:52:11 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CBC691B219 for ; Wed, 12 Dec 2001 14:52:09 -0800 (PST) Message-ID: <3C17DF99.1DE9D1A1@vicor-nb.com> Date: Wed, 12 Dec 2001 14:52:09 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: arch@freebsd.org Subject: Threads, KSEs etc. during exit. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Here is an implimentation detail I've hit that I'd like to discuss because it has some ramifications for non KSE code too. During the life of a threaded process, (and even a non threaded process during exit) the kernel's thread structures are are created and freed whenever there is a change in the number of threads active in a process. (where userland counts as one activation, and each sleeping or active syscall counts as one). WHen a thread becomes surplus to requirements, the final acts it makes would be to call thread_free() (new call) and cpu_throw() (existing). thread_free would call the current pmap_dispose_thread(td); and zfree(thread_zone, td); This is all ok except that pmap_dispose_thread(td) will free the stack pages so are we safe in returning? No. In the current world, the stack is not freed until the wait() system call (maybe much) later in the context of another process. So the race is avoided because thread stacks are only freed as part of process teardown. This makes the ZOMBIE actually hold a lot more resources that one might imagine. (specifically several pages of kernel stack it will never use, and a full u-area). Ideally I'd like to discard the thread structure and it's stack when the last cpu_throw() is called to make the zombie smaller, (as above) (If I could think of a way around the race above), but even if I don't I still hit the same race whenever a kernel thread is declared surplus to requirements, and something else is to be run. One answer would be to make whatever thread is selected next actually do the freeing of the previously running (now zombie) thread, but this increases the complexity of the switch routine. Another would be to switch the context of the dying thread to a per processor dummy thread/stack before the cpu_throw() is called and let the dummy context free the original. Basically what I need is: come in with a context from a "doomed" thread. leave in the context of a thread from the run queue, with the doomed thread now in the free list (of threads) with its resources (e.g. stack) freed too. It's not impossible but I'd like to know what others who have been around that code think is the best answer. (I am working in the KSE kernel to make threads NOT a part of the proc structure.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 15:23:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 738DC37B416 for ; Wed, 12 Dec 2001 15:23:30 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 055DB81D01; Wed, 12 Dec 2001 17:23:25 -0600 (CST) Date: Wed, 12 Dec 2001 17:23:24 -0600 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads, KSEs etc. during exit. Message-ID: <20011212172324.V92148@elvis.mu.org> References: <3C17DF99.1DE9D1A1@vicor-nb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C17DF99.1DE9D1A1@vicor-nb.com>; from julian@vicor-nb.com on Wed, Dec 12, 2001 at 02:52:09PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011212 16:52] wrote: > > Here is an implimentation detail I've hit that I'd like to > discuss because it has some ramifications for non KSE code too. [snip] > > This is all ok except that pmap_dispose_thread(td) will free > the stack pages so are we safe in returning? No. I think it's less important to get bogged down in the details, what would make more sense is to perform the cleanup as part of the job of the next-to-run thread's work as it exits the scheduler. This could be done in a MI fashion most likely. The only problem is possibly recursing into one of those subsystems in the case of thread pre-emption within the kernel. Ok, so let's make it a bit simpler. 1) The exiting thread marks the structures as "in use". 2) It then queues them on the end of a "to be freed" list, this needs a mutex. 3) It then enters the scheduler which runs the next thread. 4) On the way out in the context of another thread it will atomically mark the structures as "freeable" then issue a wakeup/cv_signal on the queue. 5) A dedicated per-cpu thread "thread_reaper" will then wakeup and perform the cleanup. Let's not over optimize it for now, getting it done correctly then optimizing will probably get the job done for now. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 15:31:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id F227637B416 for ; Wed, 12 Dec 2001 15:31:47 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBCNbc103644; Wed, 12 Dec 2001 15:37:38 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112122337.fBCNbc103644@mass.dis.org> To: Terry Lambert Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... In-Reply-To: Message from Terry Lambert of "Wed, 12 Dec 2001 10:36:19 PST." <3C17A3A3.A439BE21@mindspring.com> Date: Wed, 12 Dec 2001 15:37:38 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Now say you had 99 cylinder groups, and you added one cylinder group. > Your new cylinder group is 0% fiull, and the rest are 90% full. What > is the probability that the new cylinder group will be selected for > new writes? > > The answer is 1%. Ideally, you would want to weight the choice based > on how full each cylinder group was, but that won't happen, since it > defeats the seek optimization if you do that. Actually, this isn't entirely true. The pre-dirpref code would in fact create all new directories in this new cylinder group at least until it was as full (of directories) as the other. And thus new files would also be created there. Dirpref changes this to some degree, and of course it doesn't help for files that already exist. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 15:56:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 158AD37B416 for ; Wed, 12 Dec 2001 15:56:06 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id C3B6A786E3; Thu, 13 Dec 2001 10:26:01 +1030 (CST) Date: Thu, 13 Dec 2001 10:26:01 +1030 From: Greg Lehey To: Warner Losh Cc: cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011213102601.D76019@monorchid.lemis.com> References: <20011211173028.H232@gohan.cjclark.org> <20011211234433.B697@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> <200112122117.fBCLHhM38741@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112122117.fBCLHhM38741@harmony.village.org> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday, 12 December 2001 at 14:17:43 -0700, Warner Losh wrote: > In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: >> Nothing in man(1) actually breaks if you just make /usr read-only. You >> won't get cached pages, but in this day of overpowered CPUs, who >> cares? OTOH, in these days of super-cheap HHD, who needs markup pages >> except for the developers? > > Well, if installworld did a catman phase... I've seen a system which does this. I think it was Inactive. It's certainly a reasonable option, maybe even worth being the default. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 16: 0:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id EDBBA37B419 for ; Wed, 12 Dec 2001 16:00:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011213000014.MKCY403.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 13 Dec 2001 00:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA12091; Wed, 12 Dec 2001 15:49:19 -0800 (PST) Date: Wed, 12 Dec 2001 15:49:17 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads, KSEs etc. during exit. In-Reply-To: <20011212172324.V92148@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 12 Dec 2001, Alfred Perlstein wrote: > * Julian Elischer [011212 16:52] wrote: > > > > Here is an implimentation detail I've hit that I'd like to > > discuss because it has some ramifications for non KSE code too. > [snip] > > > > This is all ok except that pmap_dispose_thread(td) will free > > the stack pages so are we safe in returning? No. > > I think it's less important to get bogged down in the details, > what would make more sense is to perform the cleanup as part > of the job of the next-to-run thread's work as it exits the > scheduler. > > This could be done in a MI fashion most likely. > > The only problem is possibly recursing into one of those subsystems > in the case of thread pre-emption within the kernel. > > Ok, so let's make it a bit simpler. > > 1) The exiting thread marks the structures as "in use". > 2) It then queues them on the end of a "to be freed" list, this needs > a mutex. > 3) It then enters the scheduler which runs the next thread. > 4) On the way out in the context of another thread it will atomically > mark the structures as "freeable" then issue a wakeup/cv_signal on > the queue. > 5) A dedicated per-cpu thread "thread_reaper" will then wakeup and > perform the cleanup. > > Let's not over optimize it for now, getting it done correctly then > optimizing will probably get the job done for now. That's one of the possibilities I am considering, but you don't want to put too much extra testing etc on outgoing path of swtch() as it is called a hell of a lot. It's also worth wondering if it's enough to store a single 'to be freed' thread in the pcpu area or whether we need an open ended scheme. The answer to that would depend on whether we could recurse before we had the chance to free what we alreay have there. The freeing requires some "relatively complicated" things, e.g. freeing stack pages back to the vm, possibly freeing the vm-object associated with it, and maybe placing the thread structure back in the thread-zone for re-allocation. It is a question as to whether we may ever want to free the memory back to the system after a process with massive threading exits. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 16:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 0A39637B447 for ; Wed, 12 Dec 2001 16:46:58 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 8348081D01; Wed, 12 Dec 2001 18:46:52 -0600 (CST) Date: Wed, 12 Dec 2001 18:46:52 -0600 From: Alfred Perlstein To: Julian Elischer Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads, KSEs etc. during exit. Message-ID: <20011212184652.C79896@elvis.mu.org> References: <20011212172324.V92148@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Dec 12, 2001 at 03:49:17PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Julian Elischer [011212 18:00] wrote: > > That's one of the possibilities I am considering, but you don't want to > put too much extra testing etc on outgoing path of swtch() as it is called > a hell of a lot. It's also worth wondering if it's enough to store a > single 'to be freed' thread in the pcpu area or whether we need an open > ended scheme. The answer to that would depend on whether we could recurse > before we had the chance to free what we alreay have there. As I've said, it's more important to get it right than to make it fast, we can make it fast later. Why not just implement my solution? it will be pleasantly simple. > The freeing requires some "relatively complicated" things, > e.g. freeing stack pages back to the vm, possibly freeing > the vm-object associated with it, and maybe placing the thread structure > back in the thread-zone for re-allocation. It is a question as to whether > we may ever want to free the memory back to the system after > a process with massive threading exits. Yes, all valid points, but they have no bearing(sp?) without a working implementation. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 18: 2:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (oe66.pav0.hotmail.com [64.4.33.208]) by hub.freebsd.org (Postfix) with ESMTP id 721A437B427 for ; Wed, 12 Dec 2001 18:02:33 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 Dec 2001 18:02:33 -0800 X-Originating-IP: [64.210.248.135] From: "jeremiah wenzel" To: Subject: question Date: Wed, 12 Dec 2001 20:02:14 -0500 MIME-Version: 1.0 X-Mailer: MSN Explorer 7.00.0021.1702 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0000_01C18347.E4F40AC0" Message-ID: X-OriginalArrivalTime: 13 Dec 2001 02:02:33.0272 (UTC) FILETIME=[3A6F8380:01C1837A] Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------=_NextPart_001_0000_01C18347.E4F40AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Will this run all of the windows software so I would know if i could get = this or not? I ask you this because I am currently using windows and i do= n't want to lose the ability to use my software. email me at jwenzel16@ms= n.com Jeremiah M. WenzelGet more from the Web. FREE MSN Explorer download : ht= tp://explorer.msn.com ------=_NextPart_001_0000_01C18347.E4F40AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Will this run = all of the windows software so I would know if i could get this or not? I= ask you this because I am currently using windows and i don't want to lo= se the ability to use my software. email me at jwenzel16@msn.com

J= eremiah M. Wenzel

Get more from th= e Web. FREE MSN Explorer download : = http://explorer.msn.com

------=_NextPart_001_0000_01C18347.E4F40AC0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 19:59:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 6274B37B417; Wed, 12 Dec 2001 19:59:04 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id AA8603E2F; Thu, 13 Dec 2001 03:59:03 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id A875C3C12E; Thu, 13 Dec 2001 03:59:03 +0000 (UTC) To: Robert Watson Cc: arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: ; from rwatson@freebsd.org on "Thu, 6 Dec 2001 16:29:04 -0500 (EST)" Date: Thu, 13 Dec 2001 03:58:58 +0000 From: Dima Dorfman Message-Id: <20011213035903.AA8603E2F@bazooka.trit.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > I've actually been thinking about modifying xucred in -CURRENT to export > additional information from a kernel ucred, such as real and saved ids, > now that we have that information in ucred. Some users of xucred wouldn't know what to do with these extra fields, since they just use xucred to pass a uid/gid to/from the kernel. The NFS export stuff is one of these, I think. > Before we MFC xucred, it > might make sense to make a few tweaks to xucred, including changing the > first _cr_unused0 into a version number, and teaching applications how to > understand the version number. I don't know what other tweaks you had in mind (perhaps making it larger?), but the version number seems like a good idea. I've attached a patch that makes the first field a version number, and teaches the existing applications about it (mostly, it teaches them set the version when writing an xucred, and return EINVAL if it doesn't match when reading an xucred). It compiles and seems to run, but I have not done extensive testing with it. Please review. (Note that this patch changes something inside lomac which looks like it was copied verbatim from uipc_usrreq.c. I don't know anything about lomac, but my guess is that this code should be kept somewhat in sync (although I haven't seen any posts/warnings to that effect). If anyone can shed any light on this, I'd appreciate it). Thanks. Index: lib/libc/gen/getpeereid.3 =================================================================== RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.3,v retrieving revision 1.3 diff -u -r1.3 getpeereid.3 --- lib/libc/gen/getpeereid.3 2001/12/02 23:50:40 1.3 +++ lib/libc/gen/getpeereid.3 2001/12/09 23:48:36 @@ -118,7 +118,8 @@ The argument .Fa s does not refer to a socket of type -.Dv SOCK_STREAM . +.Dv SOCK_STREAM , +or the kernel returned invalid data. .El .Sh SEE ALSO .Xr connect 2 , Index: lib/libc/gen/getpeereid.c =================================================================== RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.c,v retrieving revision 1.1 diff -u -r1.1 getpeereid.c --- lib/libc/gen/getpeereid.c 2001/08/17 22:09:15 1.1 +++ lib/libc/gen/getpeereid.c 2001/12/10 07:25:39 @@ -34,6 +34,7 @@ #include #include +#include #include int @@ -47,6 +48,8 @@ error = getsockopt(s, LOCAL_PEERCRED, 1, &xuc, &xuclen); if (error != 0) return (error); + if (xuc.cr_xversion != XUCRED_VERSION) + return (EINVAL); *euid = xuc.cr_uid; *egid = xuc.cr_gid; return (0); Index: sbin/mountd/mountd.c =================================================================== RCS file: /ref/cvsf/src/sbin/mountd/mountd.c,v retrieving revision 1.59 diff -u -r1.59 mountd.c --- sbin/mountd/mountd.c 2001/09/20 02:15:17 1.59 +++ sbin/mountd/mountd.c 2001/12/09 23:48:36 @@ -211,7 +211,7 @@ struct grouplist *grphead; char exname[MAXPATHLEN]; struct xucred def_anon = { - 0, + XUCRED_VERSION, (uid_t)-2, 1, { (gid_t)-2 }, @@ -2050,6 +2050,7 @@ struct group *gr; int ngroups, groups[NGROUPS + 1]; + cr->cr_xversion = XUCRED_VERSION; /* * Set up the unprivileged user. */ Index: sys/kern/uipc_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.77 diff -u -r1.77 uipc_usrreq.c --- sys/kern/uipc_usrreq.c 2001/11/17 03:07:07 1.77 +++ sys/kern/uipc_usrreq.c 2001/12/09 23:48:36 @@ -711,6 +711,7 @@ * (which is now). */ memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); + unp3->unp_peercred.cr_xversion = XUCRED_VERSION; unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroups; memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_groups, @@ -1397,6 +1398,7 @@ { bzero(&unp->unp_peercred, sizeof(unp->unp_peercred)); + unp->unp_peercred.cr_xversion = XUCRED_VERSION; unp->unp_peercred.cr_uid = p->p_ucred->cr_uid; unp->unp_peercred.cr_ngroups = p->p_ucred->cr_ngroups; bcopy(p->p_ucred->cr_groups, unp->unp_peercred.cr_groups, Index: sys/netinet/tcp_subr.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet/tcp_subr.c,v retrieving revision 1.118 diff -u -r1.118 tcp_subr.c --- sys/netinet/tcp_subr.c 2001/11/22 04:50:43 1.118 +++ sys/netinet/tcp_subr.c 2001/12/09 23:48:36 @@ -920,6 +920,7 @@ if (error) goto out; bzero(&xuc, sizeof(xuc)); + xuc.cr_xversion = XUCRED_VERSION; xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, @@ -976,6 +977,7 @@ if (error) goto out; bzero(&xuc, sizeof(xuc)); + xuc.cr_xversion = XUCRED_VERSION; xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, Index: sys/netinet/udp_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.100 diff -u -r1.100 udp_usrreq.c --- sys/netinet/udp_usrreq.c 2001/11/08 02:13:17 1.100 +++ sys/netinet/udp_usrreq.c 2001/12/09 23:48:36 @@ -652,6 +652,7 @@ if (error) goto out; bzero(&xuc, sizeof(xuc)); + xuc.cr_xversion = XUCRED_VERSION; xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, Index: sys/netinet6/udp6_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.19 diff -u -r1.19 udp6_usrreq.c --- sys/netinet6/udp6_usrreq.c 2001/11/08 02:13:18 1.19 +++ sys/netinet6/udp6_usrreq.c 2001/12/09 23:48:36 @@ -485,6 +485,7 @@ goto out; } bzero(&xuc, sizeof(xuc)); + xuc.cr_xversion = XUCRED_VERSION; xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, Index: sys/security/lomac/kernel_socket.c =================================================================== RCS file: /ref/cvsf/src/sys/security/lomac/kernel_socket.c,v retrieving revision 1.2 diff -u -r1.2 kernel_socket.c --- sys/security/lomac/kernel_socket.c 2001/12/03 00:21:18 1.2 +++ sys/security/lomac/kernel_socket.c 2001/12/09 23:48:36 @@ -266,6 +266,7 @@ * (which is now). */ memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); + unp3->unp_peercred.cr_xversion = XUCRED_VERSION; unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroups; memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_groups, Index: sys/sys/ucred.h =================================================================== RCS file: /ref/cvsf/src/sys/sys/ucred.h,v retrieving revision 1.26 diff -u -r1.26 ucred.h --- sys/sys/ucred.h 2001/10/11 23:38:17 1.26 +++ sys/sys/ucred.h 2001/12/09 23:48:36 @@ -73,12 +73,13 @@ * any need to change the size of this or layout of its used fields. */ struct xucred { - u_short _cr_unused0; /* compatibility with old ucred */ + u_short cr_xversion; /* structure layout version */ uid_t cr_uid; /* effective user id */ short cr_ngroups; /* number of groups */ gid_t cr_groups[NGROUPS]; /* groups */ void *_cr_unused1; /* compatibility with old ucred */ }; +#define XUCRED_VERSION 1 #ifdef _KERNEL Index: usr.sbin/inetd/builtins.c =================================================================== RCS file: /ref/cvsf/src/usr.sbin/inetd/builtins.c,v retrieving revision 1.36 diff -u -r1.36 builtins.c --- usr.sbin/inetd/builtins.c 2001/07/17 07:12:57 1.36 +++ usr.sbin/inetd/builtins.c 2001/12/09 23:48:36 @@ -569,7 +569,7 @@ getcredfail = EAFNOSUPPORT; break; } - if (getcredfail != 0) { + if (getcredfail != 0 || uc.cr_xversion != XUCRED_VERSION) { if (*idbuf == '\0') iderror(lport, fport, s, getcredfail == ENOENT ? ID_NOUSER : ID_UNKNOWN); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 21: 1:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id D919937B416; Wed, 12 Dec 2001 21:01:08 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBD516M125682; Thu, 13 Dec 2001 00:01:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011212001610.9AEA739EA@overcee.netplex.com.au> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> Date: Thu, 13 Dec 2001 00:01:03 -0500 To: Peter Wemm , Nik Clayton From: Garance A Drosihn Subject: Changing 'man' to check alternate destination for 'cat' pages Cc: Greg Lehey , Warner Losh , ru@FreeBSD.ORG, ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From the thread Re: Getting rid of /usr file system (was: Using a larger block size...) > > On Tue, Dec 11, 2001, Garance A Drosihn wrote: > > > In the land of weird suggestions, just how weird would it be to >> > suggest that we create some way for 'cat' versions of man pages >> > to land somewhere else? > > > > > > Maybe /var/man/usr/share/cat* >> > for ones from /usr/share/man/man* > > > etc? Given that Peter, Nik, and Greg expressed some interest, I thought it might be interesting to try my hand at doing it. I looked at it for about 15 minutes tonight, and noticed that 'man' is under gnu/usr.bin. Does that imply changes for it should go thru gnu, somehow? <> I noticed there are some changes to 'man' in release 5 which haven't been MFC'ed yet. Would there be any reason those should not be MFC'ed? Should I try my hand at implementing my idea, or is someone else already looking into it? While I haven't tried writing any code yet, my intent is that 'man ' would do something like: search for the requested man page (same as it does now) once it finds the location, then + look for a 'cat' page at //cat/thing.n, + if found, use it look for a 'cat' page at /var/man//cat/thing.n, if found, use it + see if /var/man//cat is an existing directory, + if so, then put the expanded 'man' page into that directory. otherwise put it in //cat (as happens now) Does this sound about how people would want it to work? Basically the idea is that it would work exactly the same as it does now, except for the steps with a '+' on them. So, to get this alternate behavior people would have to create the appropriate directories under /var/man (or perhaps some other name), such as: /var/man/usr/share/man/cat* /var/man/usr/local/man/cat* /var/man/usr/X11R6/man/cat* I haven't done any work on this yet, I'm just looking for feedback. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 12 23: 6:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 87CF937B405; Wed, 12 Dec 2001 23:06:46 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBD76jM144950; Thu, 13 Dec 2001 02:06:45 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200112021023.fB2ANMi91290@apollo.backplane.com> References: <200112021023.fB2ANMi91290@apollo.backplane.com> Date: Thu, 13 Dec 2001 02:06:42 -0500 To: arch@FreeBSD.ORG, Kirk McKusick From: Garance A Drosihn Subject: Making installkernel behave better with softupdates Cc: Matthew Dillon Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From the thread on: Re: Enabling Softupdates in default install on -CURRENT At 2:23 AM -0800 12/2/01, Matthew Dillon wrote: >Garance Drosihn wrote: >:I expect it would be best to have it default 'off' for /, because the >:user can get into strange-seeming failures when installing a new kernel. >:I do like the idea of it being on for most other filesystems. > > I agree. / is still a problem - I have softupdates enabled on > my 128M / partitions and if I 'make install' a kernel twice in > a row the filesystem runs out of space and the second install > fails. But that's the only time I've ever managed to run a > softupdates filesystem out of space. If we incorporated a couple > of 'sync's (like eight of them) at the beginning of a kernel or > world install target it would probably be safe enough. With my recent investigations into the size of /modules increasing in stable (discussed in freebsd-stable a few weeks ago), I noticed that the install process for modules goes (loosely-speaking) like this: for each fname in /modules/* cp /modules/fname /modules.old/fname for each fname in /usr/obj/.../modules/* cp /usr/obj/.../modules/fname /modules/fname This strikes me as a worst-case scenario for softupdates. Not only that, but doesn't seem like the safest way to make a backup of the current modules, or to copy new modules in. I changed that to: rm -rf /modules.old ; sync mv /modules /modules.old mkdir /modules for each fname in /usr/obj/.../modules/* cp /usr/obj/.../modules/fname /modules/fname I am assuming this would be faster, and better for softupdates, because you're only destroying one set of files (all in one nice clean 'rm'), instead of destroying both sets of files, one file at a time, by copying over the file. It also means the backup step is a relatively atomic operation (the 'mv'), and that you're starting out /modules with a clean slate. It'd probably be even better to remove /modules.old, copy new modules into /modules.new, and then do two 'mv's only if all of those succeeded. Anyway, I should have some free time over the next few weeks, and could revisit these ideas and probably come up with the even safer strategy (as well as the fancier handling for debug-versions of kernel+modules). Is this worth doing? Would changes like this make 'installkernel' behave better on a softupdates partition? -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 0:14:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id BA67937B417; Thu, 13 Dec 2001 00:14:44 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBD8E1D80472; Thu, 13 Dec 2001 10:14:01 +0200 (EET) (envelope-from ru) Date: Thu, 13 Dec 2001 10:14:01 +0200 From: Ruslan Ermilov To: Garance A Drosihn Cc: Peter Wemm , Nik Clayton , Greg Lehey , Warner Losh , ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011213101401.C77774@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 12:01:03AM -0500, Garance A Drosihn wrote: > From the thread > Re: Getting rid of /usr file system (was: Using a larger block size...) > > > > On Tue, Dec 11, 2001, Garance A Drosihn wrote: > > > > In the land of weird suggestions, just how weird would it be to > >> > suggest that we create some way for 'cat' versions of man pages > >> > to land somewhere else? > > > > > > > > Maybe /var/man/usr/share/cat* > >> > for ones from /usr/share/man/man* > > > > etc? > > Given that Peter, Nik, and Greg expressed some interest, I thought it might > be interesting to try my hand at doing it. I looked at it for about 15 > minutes tonight, and noticed that 'man' is under gnu/usr.bin. Does that > imply changes for it should go thru gnu, somehow? <> > No. > I noticed there are some changes to 'man' in release 5 which haven't been > MFC'ed yet. Would there be any reason those should not be MFC'ed? > Some of them can't be MFC'ed, some can be. Please be specific. :-) > Should I try my hand at implementing my idea, or is someone else already > looking into it? > Sorry, but I don't quite understand what are you looking at. We already have a manpath(1) facility, that could be used to configure alternate manual pathes. Is that not sufficient? > While I haven't tried writing any code yet, my intent is that > 'man ' would do something like: > > search for the requested man page (same as it does now) > once it finds the location, then > + look for a 'cat' page at //cat/thing.n, > + if found, use it > look for a 'cat' page at /var/man//cat/thing.n, > if found, use it > + see if /var/man//cat is an existing directory, > + if so, then put the expanded 'man' page into that directory. > otherwise put it in //cat (as happens now) > > Does this sound about how people would want it to work? Basically the > idea is that it would work exactly the same as it does now, except for > the steps with a '+' on them. So, to get this alternate behavior people > would have to create the appropriate directories under /var/man (or > perhaps some other name), such as: > /var/man/usr/share/man/cat* > /var/man/usr/local/man/cat* > /var/man/usr/X11R6/man/cat* > > I haven't done any work on this yet, I'm just looking for feedback. > What's the goal of doing this? I missed the original thread. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 0:21: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4998D37B417; Thu, 13 Dec 2001 00:21:02 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBD8L1a89587; Thu, 13 Dec 2001 01:21:01 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBD8L0M43025; Thu, 13 Dec 2001 01:21:00 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112130821.fBD8L0M43025@harmony.village.org> To: Ruslan Ermilov Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 13 Dec 2001 10:14:01 +0200." <20011213101401.C77774@sunbay.com> References: <20011213101401.C77774@sunbay.com> <20011212001610.9AEA739EA@overcee.netplex.com.au> Date: Thu, 13 Dec 2001 01:21:00 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011213101401.C77774@sunbay.com> Ruslan Ermilov writes: : Sorry, but I don't quite understand what are you looking at. : We already have a manpath(1) facility, that could be used : to configure alternate manual pathes. Is that not sufficient? I wondered this myself... I just assumed that man put the cached version in the same path it found the original, with the last man translated to cat. : What's the goal of doing this? I missed the original thread. Make it possible to have a read only /usr and still cache man pages. However, CPU time is so cheap that we should install the CAT versions or run catman at the end of installworld. I know that NetBSD and OpenBSD both build and install the cat pages. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 0:49:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C989337B419 for ; Thu, 13 Dec 2001 00:49:01 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBD8mgm84417; Thu, 13 Dec 2001 10:48:42 +0200 (EET) (envelope-from ru) Date: Thu, 13 Dec 2001 10:48:41 +0200 From: Ruslan Ermilov To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011213104841.E77774@sunbay.com> References: <20011213101401.C77774@sunbay.com> <20011212001610.9AEA739EA@overcee.netplex.com.au> <200112130821.fBD8L0M43025@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112130821.fBD8L0M43025@harmony.village.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 01:21:00AM -0700, Warner Losh wrote: > In message <20011213101401.C77774@sunbay.com> Ruslan Ermilov writes: > : Sorry, but I don't quite understand what are you looking at. > : We already have a manpath(1) facility, that could be used > : to configure alternate manual pathes. Is that not sufficient? > > I wondered this myself... I just assumed that man put the cached > version in the same path it found the original, with the last man > translated to cat. > Yes, exactly how it works. > : What's the goal of doing this? I missed the original thread. > > Make it possible to have a read only /usr and still cache man pages. > That sounds like a good idea to me. But: cat pages are optional, their appearence is an optimization only, and you can have them (already) installed during installworld, or not have them at all. An alternate solution would be to symlink cat? to somewhere else, but that's probably not a good idea, see PR bin/32791. > However, CPU time is so cheap that we should install the CAT versions > or run catman at the end of installworld. I know that NetBSD and > OpenBSD both build and install the cat pages. > Exactly my thoughs, and that's why I have MANBUILDCAT=YES in my /etc/make.conf. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 3:20:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 022B037B416 for ; Thu, 13 Dec 2001 03:20:20 -0800 (PST) Received: (qmail 31893 invoked from network); 13 Dec 2001 11:20:18 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Dec 2001 11:20:18 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011212172324.V92148@elvis.mu.org> Date: Thu, 13 Dec 2001 03:20:13 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Threads, KSEs etc. during exit. Cc: arch@freebsd.org, Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 12-Dec-01 Alfred Perlstein wrote: > * Julian Elischer [011212 16:52] wrote: >> >> Here is an implimentation detail I've hit that I'd like to >> discuss because it has some ramifications for non KSE code too. > [snip] >> >> This is all ok except that pmap_dispose_thread(td) will free >> the stack pages so are we safe in returning? No. > > I think it's less important to get bogged down in the details, > what would make more sense is to perform the cleanup as part > of the job of the next-to-run thread's work as it exits the > scheduler. > > This could be done in a MI fashion most likely. > > The only problem is possibly recursing into one of those subsystems > in the case of thread pre-emption within the kernel. > > Ok, so let's make it a bit simpler. > > 1) The exiting thread marks the structures as "in use". > 2) It then queues them on the end of a "to be freed" list, this needs > a mutex. > 3) It then enters the scheduler which runs the next thread. > 4) On the way out in the context of another thread it will atomically > mark the structures as "freeable" then issue a wakeup/cv_signal on > the queue. > 5) A dedicated per-cpu thread "thread_reaper" will then wakeup and > perform the cleanup. > > Let's not over optimize it for now, getting it done correctly then > optimizing will probably get the job done for now. Have one thread reaper kproc for now. Eventually I think we will want a generic mechanism for specifying that a given kproc should have per-cpu threads and we can worry about that later. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 5:41:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id C62D337BD7B for ; Thu, 13 Dec 2001 05:36:34 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id fBDDa9I51674; Thu, 13 Dec 2001 08:36:09 -0500 (EST) (envelope-from mwlucas) Date: Thu, 13 Dec 2001 08:36:09 -0500 From: Michael Lucas To: jeremiah wenzel Cc: freebsd-arch@FreeBSD.ORG Subject: Re: question Message-ID: <20011213083609.A51599@blackhelicopters.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jwenzel16@msn.com on Wed, Dec 12, 2001 at 08:02:14PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Your questions would be better answered over on FreeBSD-questions@FreeBSD.org. Thanks for your interest! On Wed, Dec 12, 2001 at 08:02:14PM -0500, jeremiah wenzel wrote: > Will this run all of the windows software so I would know if i could get this or not? I ask you this because I am currently using windows and i don't want to lose the ability to use my software. email me at jwenzel16@msn.com > > Jeremiah M. WenzelGet more from the Web. FREE MSN Explorer download : http://explorer.msn.com -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org My FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 6:35:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 91A6F37B41C for ; Thu, 13 Dec 2001 06:35:20 -0800 (PST) Received: (qmail 45087 invoked by uid 1000); 13 Dec 2001 14:35:20 -0000 Date: Thu, 13 Dec 2001 09:35:20 -0500 From: Joe Abley To: Greg Lehey Cc: Warner Losh , cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011213093519.G34121@buffoon.automagic.org> References: <20011211173028.H232@gohan.cjclark.org> <20011211234433.B697@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> <200112122117.fBCLHhM38741@harmony.village.org> <20011213102601.D76019@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011213102601.D76019@monorchid.lemis.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 10:26:01AM +1030, Greg Lehey wrote: > On Wednesday, 12 December 2001 at 14:17:43 -0700, Warner Losh wrote: > > In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: > >> Nothing in man(1) actually breaks if you just make /usr read-only. You > >> won't get cached pages, but in this day of overpowered CPUs, who > >> cares? OTOH, in these days of super-cheap HHD, who needs markup pages > >> except for the developers? > > > > Well, if installworld did a catman phase... > > I've seen a system which does this. I think it was Inactive. It's > certainly a reasonable option, maybe even worth being the default. OpenBSD does this. The only manual pages that are installed in /usr/share/man are pre-formatted catman pages. /usr/share/man/man* exist, but are empty. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 7:11:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id F2D6D37B405; Thu, 13 Dec 2001 07:11:25 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id fBDFBHE78634; Thu, 13 Dec 2001 10:11:24 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200112131511.fBDFBHE78634@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dima Dorfman Cc: Robert Watson , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: Message from Dima Dorfman of "Thu, 13 Dec 2001 03:58:58 GMT." <20011213035903.AA8603E2F@bazooka.trit.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 10:11:17 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman wrote: > Robert Watson wrote: > > I've actually been thinking about modifying xucred in -CURRENT to export > > additional information from a kernel ucred, such as real and saved ids, > > now that we have that information in ucred. > > Some users of xucred wouldn't know what to do with these extra fields, > since they just use xucred to pass a uid/gid to/from the kernel. The > NFS export stuff is one of these, I think. > > > Before we MFC xucred, it > > might make sense to make a few tweaks to xucred, including changing the > > first _cr_unused0 into a version number, and teaching applications how to > > understand the version number. > > I don't know what other tweaks you had in mind (perhaps making it > larger?), but the version number seems like a good idea. > > I've attached a patch that makes the first field a version number, and > teaches the existing applications about it (mostly, it teaches them > set the version when writing an xucred, and return EINVAL if it > doesn't match when reading an xucred). It compiles and seems to run, > but I have not done extensive testing with it. Please review. Yes, this looks like just what I intended we should do with xucred {} if we ever decided to want to export more fields. I like the changes, except for a few smaller things. In the interest of compatibility, XUCRED_VERSION should start at 0, or it will needlessly break several applications. The other is that I am curious why the new field is named cr_xversion and not just cr_version. I'd be much more comfortable with cr_version, which would coincide with the naming of the #define you chose of XUCRED_VERSION. > (Note that this patch changes something inside lomac which looks like > it was copied verbatim from uipc_usrreq.c. I don't know anything > about lomac, but my guess is that this code should be kept somewhat in > sync (although I haven't seen any posts/warnings to that effect). If > anyone can shed any light on this, I'd appreciate it). That is indeed the case. That bit of code would have to either have been copied for use there or modified wholesale (which would be somewhat evil). Anyway, all seems to be correct even if I'd rather those two small changes were made. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 7:17:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 213FB37B416; Thu, 13 Dec 2001 07:17:36 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id fBDFHZC78678; Thu, 13 Dec 2001 10:17:35 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200112131517.fBDFHZC78678@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Joe Abley Cc: Greg Lehey , Warner Losh , cjclark@alum.mit.edu, freebsd-arch@FreeBSD.org Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-Reply-To: Message from Joe Abley of "Thu, 13 Dec 2001 09:35:20 EST." <20011213093519.G34121@buffoon.automagic.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 10:17:35 -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Joe Abley wrote: > On Thu, Dec 13, 2001 at 10:26:01AM +1030, Greg Lehey wrote: > > On Wednesday, 12 December 2001 at 14:17:43 -0700, Warner Losh wrote: > > > In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: > > >> Nothing in man(1) actually breaks if you just make /usr read-only. You > > >> won't get cached pages, but in this day of overpowered CPUs, who > > >> cares? OTOH, in these days of super-cheap HHD, who needs markup pages > > >> except for the developers? > > > > > > Well, if installworld did a catman phase... > > > > I've seen a system which does this. I think it was Inactive. It's > > certainly a reasonable option, maybe even worth being the default. > > OpenBSD does this. The only manual pages that are installed in > /usr/share/man are pre-formatted catman pages. /usr/share/man/man* > exist, but are empty. So of course, when the end-user wants to zcat /usr/share/man/manx/y.x.gz | groff -Tps -mdoc | lpr, they happily install the source tree to be able to do this? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 7:45:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from buffoon.automagic.org (buffoon.automagic.org [208.185.30.208]) by hub.freebsd.org (Postfix) with SMTP id 62EF937B41F for ; Thu, 13 Dec 2001 07:45:12 -0800 (PST) Received: (qmail 45480 invoked by uid 1000); 13 Dec 2001 15:45:11 -0000 Date: Thu, 13 Dec 2001 10:45:11 -0500 From: Joe Abley To: "Brian F. Feldman" Cc: Greg Lehey , Warner Losh , cjclark@alum.mit.edu, freebsd-arch@FreeBSD.org Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011213104511.H34121@buffoon.automagic.org> References: <20011213093519.G34121@buffoon.automagic.org> <200112131517.fBDFHZC78678@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112131517.fBDFHZC78678@green.bikeshed.org> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 10:17:35AM -0500, Brian F. Feldman wrote: > Joe Abley wrote: > > On Thu, Dec 13, 2001 at 10:26:01AM +1030, Greg Lehey wrote: > > > On Wednesday, 12 December 2001 at 14:17:43 -0700, Warner Losh wrote: > > > > In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: > > > >> Nothing in man(1) actually breaks if you just make /usr read-only. You > > > >> won't get cached pages, but in this day of overpowered CPUs, who > > > >> cares? OTOH, in these days of super-cheap HHD, who needs markup pages > > > >> except for the developers? > > > > > > > > Well, if installworld did a catman phase... > > > > > > I've seen a system which does this. I think it was Inactive. It's > > > certainly a reasonable option, maybe even worth being the default. > > > > OpenBSD does this. The only manual pages that are installed in > > /usr/share/man are pre-formatted catman pages. /usr/share/man/man* > > exist, but are empty. > > So of course, when the end-user wants to zcat /usr/share/man/manx/y.x.gz | > groff -Tps -mdoc | lpr, they happily install the source tree to be able to > do this? Since it has been this way since OpenBSD 2.5, if not earlier, I think it is safe to say that that is not a high-demand function of the OS by OpenBSD users. Thinking about it, I don't think I have ever printed a manual page. It may be worth mentioning that OpenBSD's avoidance of pre- formatted nroff source isn't accompanied by some GNU-like deprecation and stagnation of manual pages in favour of something different; OpenBSD people seem to put a lot of effort into improving their manual pages, and they are typically very good. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 8:54: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id B8FE637B41B; Thu, 13 Dec 2001 08:54:03 -0800 (PST) Received: from Hermes10.corp.disney.com (hermes10.corp.disney.com [153.7.110.102]) by mail.disney.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBDGqSf09166; Thu, 13 Dec 2001 08:52:28 -0800 (PST) Received: from [172.30.50.1] by hermes.corp.disney.com with ESMTP; Thu, 13 Dec 2001 08:53:18 -0800 Received: from plio.fan.fa.disney.com (plio.fan.fa.disney.com [153.7.118.2]) by pecos.fa.disney.com (8.11.3/8.11.3) with ESMTP id fBDGrl312404; Thu, 13 Dec 2001 08:53:53 -0800 (PST) Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by plio.fan.fa.disney.com (8.9.2/8.9.2) with ESMTP id IAA22548; Thu, 13 Dec 2001 08:53:45 -0800 (PST) (envelope-from Jim.Pirzyk@disney.com) Received: from [172.30.5.103] by mercury.fan.fa.disney.com; Thu, 13 Dec 2001 08:53:45 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Pirzyk, Jim" Organization: Walt Disney Feature Animation To: Garance A Drosihn , arch@FreeBSD.ORG, Kirk McKusick Subject: Re: Making installkernel behave better with softupdates Date: Thu, 13 Dec 2001 08:53:46 -0800 X-Mailer: KMail [version 1.3] Cc: Matthew Dillon References: <200112021023.fB2ANMi91290@apollo.backplane.com> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 12 December 2001 11:06 pm, Garance A Drosihn wrote: > From the thread on: > Re: Enabling Softupdates in default install on -CURRENT > > At 2:23 AM -0800 12/2/01, Matthew Dillon wrote: > >Garance Drosihn wrote: > >:I expect it would be best to have it default 'off' for /, because the > >:user can get into strange-seeming failures when installing a new kernel. > >:I do like the idea of it being on for most other filesystems. > > > > I agree. / is still a problem - I have softupdates enabled on > > my 128M / partitions and if I 'make install' a kernel twice in > > a row the filesystem runs out of space and the second install > > fails. But that's the only time I've ever managed to run a > > softupdates filesystem out of space. If we incorporated a couple > > of 'sync's (like eight of them) at the beginning of a kernel or > > world install target it would probably be safe enough. > > With my recent investigations into the size of /modules increasing in > stable (discussed in freebsd-stable a few weeks ago), I noticed that the > install process for modules goes (loosely-speaking) like this: > > for each fname in /modules/* > cp /modules/fname /modules.old/fname > for each fname in /usr/obj/.../modules/* > cp /usr/obj/.../modules/fname /modules/fname The only problem I see with this is the case where you have modules in /modules that did not come from /usr/obj/.../modules/* (Like the DRI modules from XFree86). - JimP > > This strikes me as a worst-case scenario for softupdates. Not only > that, but doesn't seem like the safest way to make a backup of the > current modules, or to copy new modules in. I changed that to: > > rm -rf /modules.old ; sync > mv /modules /modules.old > mkdir /modules > for each fname in /usr/obj/.../modules/* > cp /usr/obj/.../modules/fname /modules/fname > > I am assuming this would be faster, and better for softupdates, because > you're only destroying one set of files (all in one nice clean 'rm'), > instead of destroying both sets of files, one file at a time, by > copying over the file. It also means the backup step is a relatively > atomic operation (the 'mv'), and that you're starting out /modules with > a clean slate. It'd probably be even better to remove /modules.old, > copy new modules into /modules.new, and then do two 'mv's only if all > of those succeeded. > > Anyway, I should have some free time over the next few weeks, and could > revisit these ideas and probably come up with the even safer strategy (as > well as the fancier handling for debug-versions of kernel+modules). Is > this worth doing? Would changes like this make 'installkernel' behave > better on a softupdates partition? -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 9: 6:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 5D45137B416 for ; Thu, 13 Dec 2001 09:06:53 -0800 (PST) Received: from user-33qtnoj.dialup.mindspring.com ([199.174.223.19] helo=gohan.cjclark.org) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EZJp-0000a9-00; Thu, 13 Dec 2001 09:06:52 -0800 Received: (from cjc@localhost) by gohan.cjclark.org (8.11.6/8.11.1) id fBDH65800575; Thu, 13 Dec 2001 09:06:05 -0800 (PST) (envelope-from cjc) Date: Thu, 13 Dec 2001 09:06:02 -0800 From: "Crist J. Clark" To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011213090601.A270@gohan.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20011211173028.H232@gohan.cjclark.org> <20011211234433.B697@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011211173028.H232@gohan.cjclark.org> <200112122117.fBCLHhM38741@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112122117.fBCLHhM38741@harmony.village.org>; from imp@harmony.village.org on Wed, Dec 12, 2001 at 02:17:43PM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Dec 12, 2001 at 02:17:43PM -0700, Warner Losh wrote: > In message <20011211173028.H232@gohan.cjclark.org> "Crist J. Clark" writes: > : Nothing in man(1) actually breaks if you just make /usr read-only. You > : won't get cached pages, but in this day of overpowered CPUs, who > : cares? OTOH, in these days of super-cheap HHD, who needs markup pages > : except for the developers? > > Well, if installworld did a catman phase... My sarcasm meter is not working. Are you subtly pointing out the MANBUILDCAT variable or unaware of it? $ cat "MANBUILDCAT=yes" >> /etc/make.conf To build the cat pages. But you still get the man pages too. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 9:20: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id D98CB37B416 for ; Thu, 13 Dec 2001 09:19:57 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBDHJvf40251; Thu, 13 Dec 2001 09:19:57 -0800 (PST) (envelope-from rizzo) Date: Thu, 13 Dec 2001 09:19:57 -0800 From: Luigi Rizzo To: arch@freebsd.org Subject: swi_net Message-ID: <20011213091957.B39991@iguana.aciri.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, we have 2 slightly different versions of swi_net in -current and -stable, listed below (STABLE/Alpha is approximately the same as CURRENT). I like a lot the semantics of the version in -stable, because it enforces a strict priority in the execution of soft handlers (remember they are not preemptable), even when schednetisr(FOO) is called within one of the handlers. I understand that in the SMP case it is not simple to achieve the same semantics without using a spinlock to implement an "atomic_ffs_and_clear()" type of function (which would still be cheap in the non-SMP case). However I was wondering if there are objections in changing the first line of the CURRENT version in for (; bits = atomic_readandclear_int(&netisr); ) so that we process all pending handlers without exiting from the function and have a closer approximation of what STABLE does. comments ? cheers luigi --------- u2/HEAD/src/sys/kern/kern_intr.c ----------------- static void swi_net(void *dummy) { u_int bits; int i; bits = atomic_readandclear_int(&netisr); while ((i = ffs(bits)) != 0) { i--; if (netisrs[i] != NULL) netisrs[i](); else printf("swi_net: unregistered isr number: %d.\n", i); bits &= ~(1 << i); } } ----- STABLE/src/sys/i386/isa/ipl.s ----- swi_net: MCOUNT bsfl _netisr,%eax je swi_net_done swi_net_more: btrl %eax,_netisr jnc swi_net_next call *_netisrs(,%eax,4) swi_net_next: bsfl _netisr,%eax jne swi_net_more swi_net_done: ret To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 10:20:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 0047637B417 for ; Thu, 13 Dec 2001 10:20:31 -0800 (PST) Received: (qmail 9642 invoked by uid 0); 13 Dec 2001 18:20:29 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp011-rz3) with SMTP; 13 Dec 2001 18:20:29 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EaTB-0000tk-00 for ; Thu, 13 Dec 2001 19:20:33 +0100 Date: Thu, 13 Dec 2001 19:20:33 +0100 From: Thomas Moestl To: arch@FreeBSD.org Subject: Please review: changes to MI bus code for sparc64 Message-ID: <20011213192033.A871@crow.dom2ip.de> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I've attached a patch with changes I had to make to MI bus-related code for the sparc64 port. I would like to commit soonish (around the 21st) if there are no objections. The changes are in detail: - pass the bus device to isa_init() - add a generic resource list printing function, and make use of it in the PCI and ISA code (this may change the order in which the resources are printed in the ISA case). - add a generic __BUS_ACCESSOR macro to generate ivar accessors like PCI_ACCESSOR did, and make use of it in the PCI code - add a 'PCI_BROKEN_INTPIN' option. It activates a workaround for a bug in some Sun PCI devices, which have the intpin register wired to 0 although they use this interrupt generation mechanism. - another new option, PCI_INTLINE_0_BAD, indicates that an intline register value of 0 is used to indicate an unrouted interrupt. It is required for some Sun boxes in conjunction with PCI_BROKEN_INTPIN to avoid the confusing detection of interrupts that are not actually present. - make most functions in pci_pci.c non-static and add a new header (pcib.h) and an extension pointer to the softc to allow drivers for non-standard PCI-PCI bridges to use this code instead of duplicating most of it. - add a variation of rman_reserve_resource(), rman_reserve_resource_bound(), that can additionally honor a boundary for the allocation. This way, the resource manager can be used to handle DVMA allocations, for example. - fix a few bugs in subr_bus.c and subr_rman.c related to the use of min()/max() when ulmin()/ulmax() should be used. It is tested on sparc64 and i386, and build-tested on alpha. It would be nice if somebody could try to build a kernel with it on ia64 (there is a one-line change to ia64-specific code). The patch is also available at http://people.FreeBSD.org/~tmm/sparc64-bus-mi.diff Comments? Thanks, - thomas --- freebsd/sys/isa/isa_common.c Sat Sep 8 19:46:52 2001 +++ sparc64/sys/isa/isa_common.c Wed Oct 10 00:59:24 2001 @@ -92,7 +92,7 @@ isa_probe(device_t dev) { device_set_desc(dev, "ISA bus"); - isa_init(); /* Allow machdep code to initialise */ + isa_init(dev); /* Allow machdep code to initialise */ return 0; } @@ -634,37 +634,6 @@ } static int -isa_print_resources(struct resource_list *rl, const char *name, int type, - int count, const char *format) -{ - struct resource_list_entry *rle; - int printed; - int i, retval = 0;; - - printed = 0; - for (i = 0; i < count; i++) { - rle = resource_list_find(rl, type, i); - if (rle) { - if (printed == 0) - retval += printf(" %s ", name); - else if (printed > 0) - retval += printf(","); - printed++; - retval += printf(format, rle->start); - if (rle->count > 1) { - retval += printf("-"); - retval += printf(format, - rle->start + rle->count - 1); - } - } else if (i > 3) { - /* check the first few regardless */ - break; - } - } - return retval; -} - -static int isa_print_all_resources(device_t dev) { struct isa_device *idev = DEVTOISA(dev); @@ -674,14 +643,10 @@ if (SLIST_FIRST(rl) || device_get_flags(dev)) retval += printf(" at"); - retval += isa_print_resources(rl, "port", SYS_RES_IOPORT, - ISA_NPORT, "%#lx"); - retval += isa_print_resources(rl, "iomem", SYS_RES_MEMORY, - ISA_NMEM, "%#lx"); - retval += isa_print_resources(rl, "irq", SYS_RES_IRQ, - ISA_NIRQ, "%ld"); - retval += isa_print_resources(rl, "drq", SYS_RES_DRQ, - ISA_NDRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); + retval += resource_list_print_type(rl, "iomem", SYS_RES_MEMORY, "%#lx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); + retval += resource_list_print_type(rl, "drq", SYS_RES_DRQ, "%ld"); if (device_get_flags(dev)) retval += printf(" flags %#x", device_get_flags(dev)); --- freebsd/sys/isa/isa_common.h Sat Sep 8 19:46:52 2001 +++ sparc64/sys/isa/isa_common.h Wed Oct 10 00:59:27 2001 @@ -65,7 +65,7 @@ /* * These functions are architecture dependant. */ -extern void isa_init(void); +extern void isa_init(device_t dev); extern struct resource *isa_alloc_resource(device_t bus, device_t child, int type, int *rid, u_long start, u_long end, --- freebsd/sys/dev/pci/pci.c Sun Nov 4 01:39:41 2001 +++ sparc64/sys/dev/pci/pci.c Fri Oct 26 20:03:58 2001 @@ -78,9 +78,6 @@ device_t dev); static void pci_add_children(device_t dev, int busno); static int pci_probe(device_t dev); -static int pci_print_resources(struct resource_list *rl, - const char *name, int type, - const char *format); static int pci_print_child(device_t dev, device_t child); static void pci_probe_nomatch(device_t dev, device_t child); static int pci_describe_parse_line(char **ptr, int *vendor, @@ -190,6 +187,12 @@ u_int32_t pci_numdevs = 0; +#ifdef PCI_INTLINE_0_BAD +#define PCI_INTLINE_ASSIGNED(l) ((l) != 255 && (l) != 0) +#else +#define PCI_INTLINE_ASSIGNED(l) ((l) != 255) +#endif + /* return base address of memory or port map */ static u_int32_t @@ -619,6 +622,10 @@ #endif /* PCI_DEBUG */ if (cfg->intpin > 0) printf("\tintpin=%c, irq=%d\n", cfg->intpin +'a' -1, cfg->intline); +#ifdef PCI_BROKEN_INTPIN + if (cfg->intpin == 0 && PCI_INTLINE_ASSIGNED(cfg->intline)) + printf("\tintpin=(broken), irq=%d\n", cfg->intline); +#endif if (cfg->pp_cap) { u_int16_t status; @@ -748,7 +755,11 @@ pci_add_map(pcib, b, s, f, q->arg1, rl); } - if (cfg->intpin > 0 && cfg->intline != 255) { +#ifdef PCI_BROKEN_INTPIN + if (PCI_INTLINE_ASSIGNED(cfg->intline)) { +#else + if (cfg->intpin > 0 && PCI_INTLINE_ASSIGNED(cfg->intline)) { +#endif #ifdef __ia64__ /* * Re-route interrupts on ia64 so that we can get the @@ -831,34 +842,6 @@ } static int -pci_print_resources(struct resource_list *rl, const char *name, int type, - const char *format) -{ - struct resource_list_entry *rle; - int printed, retval; - - printed = 0; - retval = 0; - /* Yes, this is kinda cheating */ - SLIST_FOREACH(rle, rl, link) { - if (rle->type == type) { - if (printed == 0) - retval += printf(" %s ", name); - else if (printed > 0) - retval += printf(","); - printed++; - retval += printf(format, rle->start); - if (rle->count > 1) { - retval += printf("-"); - retval += printf(format, rle->start + - rle->count - 1); - } - } - } - return retval; -} - -static int pci_print_child(device_t dev, device_t child) { struct pci_devinfo *dinfo; @@ -872,9 +855,9 @@ retval += bus_print_child_header(dev, child); - retval += pci_print_resources(rl, "port", SYS_RES_IOPORT, "%#lx"); - retval += pci_print_resources(rl, "mem", SYS_RES_MEMORY, "%#lx"); - retval += pci_print_resources(rl, "irq", SYS_RES_IRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); + retval += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#lx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); if (device_get_flags(dev)) retval += printf(" flags %#x", device_get_flags(dev)); @@ -1219,7 +1202,11 @@ * If device doesn't have an interrupt routed, and is deserving of * an interrupt, try to assign it one. */ - if ((type == SYS_RES_IRQ) && (cfg->intline == 255 || cfg->intline == 0) && (cfg->intpin != 0)) { +#ifdef PCI_BROKEN_INTPIN + if ((type == SYS_RES_IRQ) && !PCI_INTLINE_ASSIGNED(cfg->intline)) { +#else + if ((type == SYS_RES_IRQ) && !PCI_INTLINE_ASSIGNED(cfg->intline) && (cfg->intpin != 0)) { +#endif cfg->intline = PCIB_ROUTE_INTERRUPT(device_get_parent(dev), child, cfg->intpin); if (cfg->intline != 255) { --- freebsd/sys/dev/pci/pci_pci.c Mon Dec 10 20:43:24 2001 +++ sparc64/sys/dev/pci/pci_pci.c Thu Dec 13 04:06:09 2001 @@ -32,6 +32,8 @@ /* * PCI:PCI bridge support. + * Some functions are also used in drivers for incompatible PCI:PCI bridges, + * like sparc64/pci/apb.c. */ #include @@ -43,39 +45,12 @@ #include #include +#include #include "pcib_if.h" -/* - * Bridge-specific data. - */ -struct pcib_softc -{ - device_t dev; - u_int16_t command; /* command register */ - u_int8_t secbus; /* secondary bus number */ - u_int8_t subbus; /* subordinate bus number */ - pci_addr_t pmembase; /* base address of prefetchable memory */ - pci_addr_t pmemlimit; /* topmost address of prefetchable memory */ - pci_addr_t membase; /* base address of memory window */ - pci_addr_t memlimit; /* topmost address of memory window */ - u_int32_t iobase; /* base address of port window */ - u_int32_t iolimit; /* topmost address of port window */ - u_int16_t secstat; /* secondary bus status register */ - u_int16_t bridgectl; /* bridge control register */ - u_int8_t seclat; /* secondary bus latency timer */ -}; - static int pcib_probe(device_t dev); static int pcib_attach(device_t dev); -static int pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); -static int pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value); -static struct resource *pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, - u_long start, u_long end, u_long count, u_int flags); -static int pcib_maxslots(device_t dev); -static u_int32_t pcib_read_config(device_t dev, int b, int s, int f, int reg, int width); -static void pcib_write_config(device_t dev, int b, int s, int f, int reg, u_int32_t val, int width); -static int pcib_route_interrupt(device_t pcib, device_t dev, int pin); static device_method_t pcib_methods[] = { /* Device interface */ @@ -229,7 +204,7 @@ return(0); } -static int +int pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) { struct pcib_softc *sc = device_get_softc(dev); @@ -242,7 +217,7 @@ return(ENOENT); } -static int +int pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value) { struct pcib_softc *sc = device_get_softc(dev); @@ -259,7 +234,7 @@ * We have to trap resource allocation requests and ensure that the bridge * is set up to, or capable of handling them. */ -static struct resource * +struct resource * pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, u_long start, u_long end, u_long count, u_int flags) { @@ -335,7 +310,7 @@ /* * PCIB interface. */ -static int +int pcib_maxslots(device_t dev) { return(PCI_SLOTMAX); @@ -344,13 +319,13 @@ /* * Since we are a child of a PCI bus, its parent must support the pcib interface. */ -static u_int32_t +u_int32_t pcib_read_config(device_t dev, int b, int s, int f, int reg, int width) { return(PCIB_READ_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, width)); } -static void +void pcib_write_config(device_t dev, int b, int s, int f, int reg, u_int32_t val, int width) { PCIB_WRITE_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, val, width); @@ -359,7 +334,7 @@ /* * Route an interrupt across a PCI bridge. */ -static int +int pcib_route_interrupt(device_t pcib, device_t dev, int pin) { device_t bus; --- freebsd/sys/dev/pci/pcivar.h Sun Aug 5 19:55:43 2001 +++ sparc64/sys/dev/pci/pcivar.h Wed Oct 10 00:59:22 2001 @@ -182,20 +182,8 @@ /* * Simplified accessors for pci devices */ -#define PCI_ACCESSOR(A, B, T) \ - \ -static __inline T pci_get_ ## A(device_t dev) \ -{ \ - uintptr_t v; \ - BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_ ## B, &v); \ - return (T) v; \ -} \ - \ -static __inline void pci_set_ ## A(device_t dev, T t) \ -{ \ - uintptr_t v = (uintptr_t) t; \ - BUS_WRITE_IVAR(device_get_parent(dev), dev, PCI_IVAR_ ## B, v); \ -} +#define PCI_ACCESSOR(var, ivar, type) \ + __BUS_ACCESSOR(pci, var, PCI, ivar, type) PCI_ACCESSOR(subvendor, SUBVENDOR, u_int16_t) PCI_ACCESSOR(subdevice, SUBDEVICE, u_int16_t) --- /dev/null Thu Dec 13 16:44:55 2001 +++ sparc64/sys/dev/pci/pcib.h Wed Oct 10 00:59:22 2001 @@ -0,0 +1,68 @@ +/*- + * Copyright (c) 1994,1995 Stefan Esser, Wolfgang StanglMeier + * Copyright (c) 2000 Michael Smith + * Copyright (c) 2000 BSDi + * All rights reserved. + * + * 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. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * 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, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _PCIB_H_ +#define _PCIB_H_ + +/* + * Bridge-specific data. + */ +struct pcib_softc +{ + device_t dev; + u_int16_t command; /* command register */ + u_int8_t secbus; /* secondary bus number */ + u_int8_t subbus; /* subordinate bus number */ + pci_addr_t pmembase; /* base address of prefetchable memory */ + pci_addr_t pmemlimit; /* topmost address of prefetchable memory */ + pci_addr_t membase; /* base address of memory window */ + pci_addr_t memlimit; /* topmost address of memory window */ + u_int32_t iobase; /* base address of port window */ + u_int32_t iolimit; /* topmost address of port window */ + u_int16_t secstat; /* secondary bus status register */ + u_int16_t bridgectl; /* bridge control register */ + u_int8_t seclat; /* secondary bus latency timer */ + void *extptr; /* softc extension for derived drivers */ +}; + +int pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result); +int pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value); +struct resource *pcib_alloc_resource(device_t dev, device_t child, int type, int *rid, + u_long start, u_long end, u_long count, u_int flags); +int pcib_maxslots(device_t dev); +u_int32_t pcib_read_config(device_t dev, int b, int s, int f, int reg, int width); +void pcib_write_config(device_t dev, int b, int s, int f, int reg, u_int32_t val, int width); +int pcib_route_interrupt(device_t pcib, device_t dev, int pin); +int pcib_dev_iterate(device_t dev, uintptr_t *cookie, int flags, int *slot, int *func, + uintptr_t *data, uintptr_t *iterator); + +#endif /* _PCIB_H_ */ --- freebsd/sys/sys/bus.h Sun Nov 4 01:40:09 2001 +++ sparc64/sys/sys/bus.h Sun Nov 4 01:14:54 2001 @@ -180,6 +180,14 @@ int type, int rid, struct resource *res); /* + * Print all resources of a specified type, for use in bus_print_child. + * The name is printed if at least one resource of the given type is available. + * The format ist used to print resource start and end. + */ +int resource_list_print_type(struct resource_list *rl, + const char *name, int type, + const char *format); +/* * The root bus, to which all top-level busses are attached. */ extern device_t root_bus; @@ -410,6 +418,26 @@ }; \ DECLARE_MODULE(name##_##busname, name##_##busname##_mod, \ SI_SUB_DRIVERS, SI_ORDER_MIDDLE) + +/* + * Generic ivar accessor generation macros for bus drivers + */ +#define __BUS_ACCESSOR(varp, var, ivarp, ivar, type) \ + \ +static __inline type varp ## _get_ ## var(device_t dev) \ +{ \ + uintptr_t v; \ + BUS_READ_IVAR(device_get_parent(dev), dev, \ + ivarp ## _IVAR_ ## ivar, &v); \ + return ((type) v); \ +} \ + \ +static __inline void varp ## _set_ ## var(device_t dev, type t) \ +{ \ + uintptr_t v = (uintptr_t) t; \ + BUS_WRITE_IVAR(device_get_parent(dev), dev, \ + ivarp ## _IVAR_ ## ivar, v); \ +} #endif /* _KERNEL */ --- freebsd/sys/sys/rman.h Sat Sep 8 19:53:09 2001 +++ sparc64/sys/sys/rman.h Thu Nov 22 23:54:27 2001 @@ -126,6 +126,9 @@ struct resource *rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, u_int flags, struct device *dev); +struct resource *rman_reserve_resource_bound(struct rman *rm, u_long start, + u_long end, u_long count, u_long bound, + u_int flags, struct device *dev); uint32_t rman_make_alignment_flags(uint32_t size); #define rman_get_start(r) ((r)->r_start) --- freebsd/sys/kern/subr_bus.c Mon Dec 10 20:44:39 2001 +++ sparc64/sys/kern/subr_bus.c Thu Dec 13 04:06:25 2001 @@ -1207,8 +1207,8 @@ if (isdefault) { start = rle->start; - count = max(count, rle->count); - end = max(rle->end, start + count - 1); + count = ulmax(count, rle->count); + end = ulmax(rle->end, start + count - 1); } rle->res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, @@ -1253,6 +1253,34 @@ rle->res = NULL; return (0); +} + +int +resource_list_print_type(struct resource_list *rl, const char *name, int type, + const char *format) +{ + struct resource_list_entry *rle; + int printed, retval; + + printed = 0; + retval = 0; + /* Yes, this is kinda cheating */ + SLIST_FOREACH(rle, rl, link) { + if (rle->type == type) { + if (printed == 0) + retval += printf(" %s ", name); + else + retval += printf(","); + printed++; + retval += printf(format, rle->start); + if (rle->count > 1) { + retval += printf("-"); + retval += printf(format, rle->start + + rle->count - 1); + } + } + } + return retval; } /* --- freebsd/sys/kern/subr_rman.c Sun Nov 25 14:51:37 2001 +++ sparc64/sys/kern/subr_rman.c Thu Nov 22 23:54:25 2001 @@ -175,12 +175,13 @@ } struct resource * -rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, - u_int flags, struct device *dev) +rman_reserve_resource_bound(struct rman *rm, u_long start, u_long end, + u_long count, u_long bound, u_int flags, + struct device *dev) { u_int want_activate; struct resource *r, *s, *rv; - u_long rstart, rend; + u_long rstart, rend, amask, bmask; rv = 0; @@ -202,6 +203,9 @@ goto out; } + amask = (1ul << RF_ALIGNMENT(flags)) - 1; + /* If bound is 0, bmask will also be 0 */ + bmask = ~(bound - 1); /* * First try to find an acceptable totally-unshared region. */ @@ -215,10 +219,19 @@ DPRINTF(("region is allocated\n")); continue; } - rstart = max(s->r_start, start); - rstart = (rstart + ((1ul << RF_ALIGNMENT(flags))) - 1) & - ~((1ul << RF_ALIGNMENT(flags)) - 1); - rend = min(s->r_end, max(rstart + count, end)); + rstart = ulmax(s->r_start, start); + /* + * Try to find a region by adjusting to boundary and alignment + * until both conditions are satisfied. This is not an optimal + * algorithm, but in most cases it isn't really bad, either. + */ + do { + rstart = (rstart + amask) & ~amask; + if (((rstart ^ (rstart + count)) & bmask) != 0) + rstart += bound - (rstart & ~bmask); + } while ((rstart & amask) != 0 && rstart < end && + rstart < s->r_end); + rend = ulmin(s->r_end, ulmax(rstart + count, end)); DPRINTF(("truncated region: [%#lx, %#lx]; size %#lx (requested %#lx)\n", rstart, rend, (rend - rstart + 1), count)); @@ -313,10 +326,12 @@ break; if ((s->r_flags & flags) != flags) continue; - rstart = max(s->r_start, start); - rend = min(s->r_end, max(start + count, end)); + rstart = ulmax(s->r_start, start); + rend = ulmin(s->r_end, ulmax(start + count, end)); if (s->r_start >= start && s->r_end <= end - && (s->r_end - s->r_start + 1) == count) { + && (s->r_end - s->r_start + 1) == count && + (s->r_start & amask) == 0 && + ((s->r_start ^ s->r_end) & bmask) == 0) { rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); if (rv == 0) goto out; @@ -368,6 +383,15 @@ return (rv); } +struct resource * +rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, + u_int flags, struct device *dev) +{ + + return (rman_reserve_resource_bound(rm, start, end, count, 0, flags, + dev)); +} + static int int_rman_activate_resource(struct rman *rm, struct resource *r, struct resource **whohas) @@ -575,7 +599,7 @@ * Find the hightest bit set, and add one if more than one bit * set. We're effectively computing the ceil(log2(size)) here. */ - for (i = 32; i > 0; i--) + for (i = 31; i > 0; i--) if ((1 << i) & size) break; if (~(1 << i) & size) --- freebsd/sys/i386/isa/isa.c Fri Oct 12 16:18:20 2001 +++ sparc64/sys/i386/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -68,7 +68,7 @@ #include void -isa_init(void) +isa_init(device_t dev) { } --- freebsd/sys/alpha/isa/isa.c Sun Aug 5 19:43:26 2001 +++ sparc64/sys/alpha/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -94,7 +94,7 @@ } void -isa_init(void) +isa_init(device_t dev) { isa_init_intr(); } --- freebsd/sys/ia64/isa/isa.c Sun Aug 5 20:05:14 2001 +++ sparc64/sys/ia64/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -69,7 +69,7 @@ #include void -isa_init(void) +isa_init(device_t dev) { } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 10:32:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 9CABA37B417; Thu, 13 Dec 2001 10:32:30 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fBDIWOt13396; Thu, 13 Dec 2001 10:32:24 -0800 Date: Thu, 13 Dec 2001 10:32:24 -0800 From: Brooks Davis To: "Pirzyk, Jim" Cc: Garance A Drosihn , arch@FreeBSD.ORG, Kirk McKusick , Matthew Dillon Subject: Re: Making installkernel behave better with softupdates Message-ID: <20011213103224.A4987@Odin.AC.HMC.Edu> References: <200112021023.fB2ANMi91290@apollo.backplane.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Jim.Pirzyk@disney.com on Thu, Dec 13, 2001 at 08:53:46AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2001 at 08:53:46AM -0800, Pirzyk, Jim wrote: > The only problem I see with this is the case where you have > modules in /modules that did not come from /usr/obj/.../modules/* > (Like the DRI modules from XFree86). This is fixed in -current by placing external modules in /boot/modules and the kernel along with it's locally compiled modules in /boot/kernel. My suggestion would be to insure that the loader knows about /boot/modules and start advertising it now for things like DRI since that moves us closer to current without a hugh POLA violation. The fact that modules stays in /modules is counter intutitive for all that it's a nice behavior. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8GPQ3XY6L6fI4GtQRAggZAJ97kpl82GsqeqhfHRI/zhsGJL7gEACg0c3p shDcBFAzl4KwsChaGwCiCzM= =29VR -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 10:46:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 96B0D37B405 for ; Thu, 13 Dec 2001 10:46:34 -0800 (PST) Received: from pool0215.cvx22-bradley.dialup.earthlink.net ([209.179.198.215] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EasK-0001Ub-00; Thu, 13 Dec 2001 10:46:32 -0800 Message-ID: <3C18F78D.C537D487@mindspring.com> Date: Thu, 13 Dec 2001 10:46:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Moestl Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 References: <20011213192033.A871@crow.dom2ip.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thomas Moestl wrote: [ ... ] > Comments? [ ... ] I don't understand the, isa_init() parameter change, as the post-patch code does not appear to use "dev"? The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; they should be protected by a single name (probably PCI_BROKEN_INTPIN) in the #ifdef in pci.c; it should be "all or nothing" on a single value. As it is, you must define one if you define the other, but not vice versa, and the effect seems to be linked, anyway, so you might as well use a single protection mechanism. I don't think I fully understand why the "non-standard PCI-PCI bridge drivers" are non-standard, and won't fit into the general framework; if you are going to do this, doesn't it make more sense to have a registration function that gets back a struct containing entrypoint vectors, rather than making the vectors global? As "non-standard", the additional overhead from the function pointer dereferences should be an acceptable loss, to keep the code compartmentalized. I would be tempted to protect the registration function with an #ifdef, as well. I think that doing this would discourage casual use, since then the symbols would be effectively protected by an option. In subr_rman.c, I think it would be better to name "amask"/"bmask" as "align_mask"/"bound_mask", so that it was more obvious that you were not just using alphabetically inspired scratch variables. Also in subr_rman.c, in int_rman_activate_resource(), the change from 32 to 31 is not obvious... should you also change "> 0" to ">= 0"? It's not clear to me what this change fixes. I'm probably just missing something... Other than that, the other changes look useful, even if one does change the ISA print order, since they don't seem to impair functionality in any way by doing that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 10:55:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 049F437B405 for ; Thu, 13 Dec 2001 10:55:50 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBDJ1hl02003; Thu, 13 Dec 2001 11:01:43 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112131901.fBDJ1hl02003@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Moestl Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 In-reply-to: Your message of "Thu, 13 Dec 2001 19:20:33 +0100." <20011213192033.A871@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 11:01:43 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I've attached a patch with changes I had to make to MI bus-related > code for the sparc64 port. I would like to commit soonish (around the > 21st) if there are no objections. > > The changes are in detail: > - pass the bus device to isa_init() > - add a generic resource list printing function, and make use of it in > the PCI and ISA code (this may change the order in which the > resources are printed in the ISA case). > - add a generic __BUS_ACCESSOR macro to generate ivar accessors like > PCI_ACCESSOR did, and make use of it in the PCI code These are OK. > - add a 'PCI_BROKEN_INTPIN' option. It activates a workaround for a > bug in some Sun PCI devices, which have the intpin register wired to > 0 although they use this interrupt generation mechanism. This is the wrong way to do it. Fake the intpin access in the MD PCI config space handler, and don't make it optional; if you know the device is broken, fake it. If it's not, don't. > - another new option, PCI_INTLINE_0_BAD, indicates that an intline > register value of 0 is used to indicate an unrouted interrupt. It is > required for some Sun boxes in conjunction with PCI_BROKEN_INTPIN to > avoid the confusing detection of interrupts that are not actually > present. Again, fake this at the MD level. > - make most functions in pci_pci.c non-static and add a new header > (pcib.h) and an extension pointer to the softc to allow drivers for > non-standard PCI-PCI bridges to use this code instead of duplicating > most of it. I'm not sure that non-staticising this is the correct way to go; we need a better way of subclassing things. Without knowing what you mean by "non-standard", it's hard to see how calling these functions is useful. > - add a variation of rman_reserve_resource(), > rman_reserve_resource_bound(), that can additionally honor a > boundary for the allocation. This way, the resource manager can be > used to handle DVMA allocations, for example. Resource alignment should be handled above the resource manager, not in it. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 10:57:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 9350637B41A; Thu, 13 Dec 2001 10:57:20 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id fBDIvJ718139; Thu, 13 Dec 2001 10:57:19 -0800 Date: Thu, 13 Dec 2001 10:57:19 -0800 From: Brooks Davis To: Joe Abley Cc: "Brian F. Feldman" , Greg Lehey , Warner Losh , cjclark@alum.mit.edu, freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011213105719.B4987@Odin.AC.HMC.Edu> References: <20011213093519.G34121@buffoon.automagic.org> <200112131517.fBDFHZC78678@green.bikeshed.org> <20011213104511.H34121@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011213104511.H34121@buffoon.automagic.org>; from jabley@automagic.org on Thu, Dec 13, 2001 at 10:45:11AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 13, 2001 at 10:45:11AM -0500, Joe Abley wrote: > Since it has been this way since OpenBSD 2.5, if not earlier, I > think it is safe to say that that is not a high-demand function > of the OS by OpenBSD users. Thinking about it, I don't think I > have ever printed a manual page. Well, count me on the list of people who would be pissed if someone decided to do this. I'm all for installed the cat pages by default, but nobody is going to take away "man -t" support without a fight. I print manpages all the time when I want to read through them and I'll need them for more then a few minutes. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8GPoOXY6L6fI4GtQRAtYbAJ4v2eH1Hx5aWpVQAzYANjMPDxdPjQCeOlbq q/xLcsupGOnVbVnCl/K92oM= =4l2e -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 11: 2:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 19E5837B41B for ; Thu, 13 Dec 2001 11:02:43 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBDJ8el02057; Thu, 13 Dec 2001 11:08:41 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112131908.fBDJ8el02057@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brooks Davis Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) In-reply-to: Your message of "Thu, 13 Dec 2001 10:57:19 PST." <20011213105719.B4987@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Dec 2001 11:08:40 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Thu, Dec 13, 2001 at 10:45:11AM -0500, Joe Abley wrote: > > Since it has been this way since OpenBSD 2.5, if not earlier, I > > think it is safe to say that that is not a high-demand function > > of the OS by OpenBSD users. Thinking about it, I don't think I > > have ever printed a manual page. > > Well, count me on the list of people who would be pissed if someone > decided to do this. I'm all for installed the cat pages by default, but > nobody is going to take away "man -t" support without a fight. I print > manpages all the time when I want to read through them and I'll need > them for more then a few minutes. I'd have to agree; I'd much rather dump the whole catpages thing (it's a bad tradeoff, IMO; CPU speed is cheaper than disk space) but certainly dropping the ability to print manpages would just be stupid. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 11: 4:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 129C037B417; Thu, 13 Dec 2001 11:04:50 -0800 (PST) Received: from pool0215.cvx22-bradley.dialup.earthlink.net ([209.179.198.215] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EbA0-0004YZ-00; Thu, 13 Dec 2001 11:04:48 -0800 Message-ID: <3C18FBD5.598CDC28@mindspring.com> Date: Thu, 13 Dec 2001 11:04:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: Thomas Moestl , arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 References: <200112131901.fBDJ1hl02003@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith wrote: [ ... ] > > - add a 'PCI_BROKEN_INTPIN' option. It activates a workaround for a > > bug in some Sun PCI devices, which have the intpin register wired to > > 0 although they use this interrupt generation mechanism. > > This is the wrong way to do it. Fake the intpin access in the MD PCI > config space handler, and don't make it optional; if you know the device > is broken, fake it. If it's not, don't. I like Mike's answer better than mine, for this item. 8^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 11:12:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 4BDA137B417 for ; Thu, 13 Dec 2001 11:12:09 -0800 (PST) Received: (qmail 3923 invoked by uid 0); 13 Dec 2001 19:12:08 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp008-rz3) with SMTP; 13 Dec 2001 19:12:08 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EbHB-00013b-00; Thu, 13 Dec 2001 20:12:13 +0100 Date: Thu, 13 Dec 2001 20:12:13 +0100 From: Thomas Moestl To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011213201213.B871@crow.dom2ip.de> Mail-Followup-To: Terry Lambert , arch@FreeBSD.org References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C18F78D.C537D487@mindspring.com>; from tlambert2@mindspring.com on Thu, Dec 13, 2001 at 10:46:37AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 10:46:37 -0800, Terry Lambert wrote: > Thomas Moestl wrote: > [ ... ] > > Comments? > [ ... ] > > I don't understand the, isa_init() parameter change, as the post-patch > code does not appear to use "dev"? The sparc64 one does. > The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; > they should be protected by a single name (probably PCI_BROKEN_INTPIN) > in the #ifdef in pci.c; it should be "all or nothing" on a single > value. As it is, you must define one if you define the other, but > not vice versa, and the effect seems to be linked, anyway, so you > might as well use a single protection mechanism. It is not uncommon that i386 BIOSes to set the intline register to 0 when it should really be 0xff (to indicate an unrouted interrupt). So, I figured that it might be useful to make this an extra option. 0 as an intline value (which on sparc64 corresponds to an interrupt number offset (INO), which is added to an interrupt group number (IGN) to get the actual interrupt) can also be valid on sparc64, so there might be machines which need PCI_BROKEN_INTPIN activated, but PCI_INTLINE_0_BAD turned off to work correctly. > I don't think I fully understand why the "non-standard PCI-PCI bridge > drivers" are non-standard, and won't fit into the general framework; > if you are going to do this, doesn't it make more sense to have a > registration function that gets back a struct containing entrypoint > vectors, rather than making the vectors global? As "non-standard", > the additional overhead from the function pointer dereferences should > be an acceptable loss, to keep the code compartmentalized. I would > be tempted to protect the registration function with an #ifdef, as > well. I think that doing this would discourage casual use, since then > the symbols would be effectively protected by an option. I did this change to support the Sun APB bridge, which does not have base and limit registers, but uses a different mechanism to set the decoded ranges. So, to check resource allocations correctly, the apb driver needs to implement it's own alloc_resource method. The pcib functions which need not be 'overridden' can be directly used in the method table. > In subr_rman.c, I think it would be better to name "amask"/"bmask" as > "align_mask"/"bound_mask", so that it was more obvious that you were > not just using alphabetically inspired scratch variables. > > Also in subr_rman.c, in int_rman_activate_resource(), the change from > 32 to 31 is not obvious... should you also change "> 0" to ">= 0"? It's > not clear to me what this change fixes. I'm probably just missing > something... 1 << 32 is out of u_int32_t range, so it just would make no sense. In addition, it will overflow i (which is an int) on most architectures. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 11:18:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 80AAA37B417 for ; Thu, 13 Dec 2001 11:18:28 -0800 (PST) Received: (qmail 26018 invoked by uid 0); 13 Dec 2001 19:18:27 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp015-rz3) with SMTP; 13 Dec 2001 19:18:27 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EbNI-00014f-00; Thu, 13 Dec 2001 20:18:32 +0100 Date: Thu, 13 Dec 2001 20:18:32 +0100 From: Thomas Moestl To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011213201832.C871@crow.dom2ip.de> Mail-Followup-To: Terry Lambert , arch@FreeBSD.org References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011213201213.B871@crow.dom2ip.de>; from tmoestl@gmx.net on Thu, Dec 13, 2001 at 08:12:13PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 20:12:13 +0100, Thomas Moestl wrote: > 1 << 32 is out of u_int32_t range, so it just would make no sense. In > addition, it will overflow i (which is an int) on most architectures. Uh, scratch that i ;) (1 << i) would of course overflow because of the type of 1, sorry. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 12:15:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 0F4AA37B417 for ; Thu, 13 Dec 2001 12:15:36 -0800 (PST) Received: (qmail 27627 invoked by uid 0); 13 Dec 2001 20:15:34 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp002-rz3) with SMTP; 13 Dec 2001 20:15:34 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EcGe-0001G9-00 for ; Thu, 13 Dec 2001 21:15:44 +0100 Date: Thu, 13 Dec 2001 21:15:44 +0100 From: Thomas Moestl To: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011213211544.A4747@crow.dom2ip.de> Mail-Followup-To: arch@FreeBSD.org References: <20011213192033.A871@crow.dom2ip.de> <200112131901.fBDJ1hl02003@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 11:01:43 -0800, Mike Smith wrote: > > - add a 'PCI_BROKEN_INTPIN' option. It activates a workaround for a > > bug in some Sun PCI devices, which have the intpin register wired to > > 0 although they use this interrupt generation mechanism. > > This is the wrong way to do it. Fake the intpin access in the MD PCI > config space handler, and don't make it optional; if you know the device > is broken, fake it. If it's not, don't. I did this in the PCI code since it is a flake of the device, so I think it does not really belong into the MD code (I know that the particular device I am seeing this with is also used in PowerPC in a different version; maybe this version is broken there in a similar way). In any case, it is better to identify these devices and add a quirk table for them than using an option, as you say. I will change that. > > - another new option, PCI_INTLINE_0_BAD, indicates that an intline > > register value of 0 is used to indicate an unrouted interrupt. It is > > required for some Sun boxes in conjunction with PCI_BROKEN_INTPIN to > > avoid the confusing detection of interrupts that are not actually > > present. > > Again, fake this at the MD level. I did do it in the MI code because this breakage seems to exist on many architectures, but you are right, I will change that. > > - make most functions in pci_pci.c non-static and add a new header > > (pcib.h) and an extension pointer to the softc to allow drivers for > > non-standard PCI-PCI bridges to use this code instead of duplicating > > most of it. > > I'm not sure that non-staticising this is the correct way to go; we need > a better way of subclassing things. Without knowing what you mean by > "non-standard", it's hard to see how calling these functions is useful. It does not have base and limit registers, the decoded range is set differently. To be able to check allocations for in-rangeness, I need to override the alloc_resource method, and of course the probe and attach methods. I can however use pcib_read_ivar, pcib_write_ivar, pcib_maxslots, pcib_read_config and pcib_write_config. This could for example also be handled by introducing a common bridge layer with the common methods and making all bridge drivers children of it and passing the other method calls through, but I don't really like that. When the next non-standard bridge comes along, the common layer would probably need to be reduced, and so on, until it maybe is not existent any more. It could of course also be done by duplicating the code in question, which I also don't really like to do. > > - add a variation of rman_reserve_resource(), > > rman_reserve_resource_bound(), that can additionally honor a > > boundary for the allocation. This way, the resource manager can be > > used to handle DVMA allocations, for example. > > Resource alignment should be handled above the resource manager, not in > it. I'm not sure how this is meant. As I wrote, I am using it to manage virtual DVMA memory, so I need to be able to allocate resources with given alignment and boundary (to implement the busdma interface). Specifying an alignment is already supported. The only method to enforce a boundary at a higher level I could think of would be to try to adjust the allocation, which would be a gross hack. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 14:32:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id BF43D37B416 for ; Thu, 13 Dec 2001 14:32:13 -0800 (PST) Received: from pool0211.cvx21-bradley.dialup.earthlink.net ([209.179.192.211] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EeOh-000241-00; Thu, 13 Dec 2001 14:32:11 -0800 Message-ID: <3C192C70.9A79B3C5@mindspring.com> Date: Thu, 13 Dec 2001 14:32:16 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Moestl Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thomas Moestl wrote: > > I don't understand the, isa_init() parameter change, as the post-patch > > code does not appear to use "dev"? > > The sparc64 one does. OK; explains why it's not int he patches. > > The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; Still agree with Mike. [ ... PCI routines becoming global ... ] > I did this change to support the Sun APB bridge, which does not have > base and limit registers, but uses a different mechanism to set the > decoded ranges. So, to check resource allocations correctly, the apb > driver needs to implement it's own alloc_resource method. The pcib > functions which need not be 'overridden' can be directly used in the > method table. I still think that the proper way is to call a function to get the addresses of the static functions. Ideally, you would pass and/or break out the alloc_resource method, which would make the Sun APB brige "standard". > > Also in subr_rman.c, in int_rman_activate_resource(), the change from > > 32 to 31 is not obvious... should you also change "> 0" to ">= 0"? It's > > not clear to me what this change fixes. I'm probably just missing > > something... > > 1 << 32 is out of u_int32_t range, so it just would make no sense. In > addition, it will overflow i (which is an int) on most architectures. I was more concerned with the 1 << 0 not being hit at all. I agree on the overflow fix; I was just curious why the entire range was not shifted down 1, instead of just avoiding the overflow. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 15:50:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 2C78D37B41A for ; Thu, 13 Dec 2001 15:50:25 -0800 (PST) Received: (qmail 8896 invoked by uid 0); 13 Dec 2001 23:50:23 -0000 Received: from p5086f9a0.dip.t-dialin.net (HELO forge.local) (80.134.249.160) by mail.gmx.net (mp004-rz3) with SMTP; 13 Dec 2001 23:50:23 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16EfcV-0001lI-00; Fri, 14 Dec 2001 00:50:31 +0100 Date: Fri, 14 Dec 2001 00:50:31 +0100 From: Thomas Moestl To: Terry Lambert Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011214005031.B4747@crow.dom2ip.de> Mail-Followup-To: Terry Lambert , arch@FreeBSD.org References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> <3C192C70.9A79B3C5@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C192C70.9A79B3C5@mindspring.com>; from tlambert2@mindspring.com on Thu, Dec 13, 2001 at 02:32:16PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 14:32:16 -0800, Terry Lambert wrote: > > I did this change to support the Sun APB bridge, which does not have > > base and limit registers, but uses a different mechanism to set the > > decoded ranges. So, to check resource allocations correctly, the apb > > driver needs to implement it's own alloc_resource method. The pcib > > functions which need not be 'overridden' can be directly used in the > > method table. > > I still think that the proper way is to call a function to get the > addresses of the static functions. Ideally, you would pass and/or > break out the alloc_resource method, which would make the Sun APB > brige "standard". I'll think about doing that. > > > Also in subr_rman.c, in int_rman_activate_resource(), the change from > > > 32 to 31 is not obvious... should you also change "> 0" to ">= 0"? It's > > > not clear to me what this change fixes. I'm probably just missing > > > something... > > > > 1 << 32 is out of u_int32_t range, so it just would make no sense. In > > addition, it will overflow i (which is an int) on most architectures. > > I was more concerned with the 1 << 0 not being hit at all. I agree > on the overflow fix; I was just curious why the entire range was not > shifted down 1, instead of just avoiding the overflow. If no bit from 31 to 1 was found set, an alignment of 1 (i.e. any address is valid) is assumed. This corresponds to bit 0, so both 1 and zero mean that no alignment needs to be maintained. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 16:23:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 74B4537B405 for ; Thu, 13 Dec 2001 16:23:06 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id fBE0Sol04630; Thu, 13 Dec 2001 16:28:50 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200112140028.fBE0Sol04630@mass.dis.org> To: Thomas Moestl Cc: Terry Lambert , arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 In-Reply-To: Message from Thomas Moestl of "Thu, 13 Dec 2001 20:12:13 +0100." <20011213201213.B871@crow.dom2ip.de> Date: Thu, 13 Dec 2001 16:28:50 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; > > they should be protected by a single name (probably PCI_BROKEN_INTPIN) > > in the #ifdef in pci.c; it should be "all or nothing" on a single > > value. As it is, you must define one if you define the other, but > > not vice versa, and the effect seems to be linked, anyway, so you > > might as well use a single protection mechanism. > > It is not uncommon that i386 BIOSes to set the intline register to 0 > when it should really be 0xff (to indicate an unrouted interrupt). So, > I figured that it might be useful to make this an extra option. No. Fix the i386-specific config space accessor to convert 0 to 255. If you haven't seen the theme here yet; here it is. The MD layers should correct for platform-specific aberrations in the PCI implementation where possible. Adding compile-time options to MI code which indirectly relate exclusively to MD PCI issues is just the Wrong Thing to Do. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 16:53: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id A0E3C37B416; Thu, 13 Dec 2001 16:52:59 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id EBBFC786E3; Fri, 14 Dec 2001 11:22:55 +1030 (CST) Date: Fri, 14 Dec 2001 11:22:55 +1030 From: Greg Lehey To: Garance A Drosihn Cc: Peter Wemm , Nik Clayton , Warner Losh , ru@FreeBSD.ORG, ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011214112255.L3448@monorchid.lemis.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 13 December 2001 at 0:01:03 -0500, Garance A Drosihn wrote: > From the thread > Re: Getting rid of /usr file system (was: Using a larger block size...) > >>> On Tue, Dec 11, 2001, Garance A Drosihn wrote: >>>> In the land of weird suggestions, just how weird would it be to >>>> suggest that we create some way for 'cat' versions of man pages >>>> to land somewhere else? >>>> >>>> Maybe /var/man/usr/share/cat* >>>> for ones from /usr/share/man/man* >>>> etc? > > Given that Peter, Nik, and Greg expressed some interest, I thought it might > be interesting to try my hand at doing it. I looked at it for about 15 > minutes tonight, and noticed that 'man' is under gnu/usr.bin. Does that > imply changes for it should go thru gnu, somehow? <> No, there's no obligation to submit changes to the GNU project. If you think it would be worthwhile for them, you can do so, however. > I noticed there are some changes to 'man' in release 5 which haven't > been MFC'ed yet. Would there be any reason those should not be > MFC'ed? Your call. I'd guess that nobody felt motivated enough. > Should I try my hand at implementing my idea, or is someone else > already looking into it? > > While I haven't tried writing any code yet, my intent is that > 'man ' would do something like: > > search for the requested man page (same as it does now) > once it finds the location, then > + look for a 'cat' page at //cat/thing.n, > + if found, use it > look for a 'cat' page at /var/man//cat/thing.n, > if found, use it > + see if /var/man//cat is an existing directory, > + if so, then put the expanded 'man' page into that directory. > otherwise put it in //cat (as happens now) > > Does this sound about how people would want it to work? Basically the > idea is that it would work exactly the same as it does now, except for > the steps with a '+' on them. So, to get this alternate behavior people > would have to create the appropriate directories under /var/man (or > perhaps some other name), such as: > /var/man/usr/share/man/cat* > /var/man/usr/local/man/cat* > /var/man/usr/X11R6/man/cat* > > I haven't done any work on this yet, I'm just looking for feedback. If you're going to overhaul man, there's probably quite a bit you could do beyond the paths. I had a man years ago which would list which man pages were present (note that my MANPATH is: MANPATH=/usr/local/man:/usr/share/man:/usr/X11R6/man:/usr/share/man/BSDI-5:/usr/share/man/4.4BSD:/usr/share/man/BSDI:/usr/share/man/V6:/usr/share/man/V7:/usr/share/man/3bsd:/usr/share/man/2.11BSD:/usr/share/man/IRIX-5.3/u_man:/usr/share/man/IRIX-5.3/p_man:/usr/share/man/IRIX-5.3/a_man:/usr/share/man/IRIX-5.3/g_man:/usr/share/man/ISC-3.2/p_man:/usr/share/man/ISC-3.2/u_man:/usr/share/man/NonStop-UX-B23:/usr/share/man/NonStop-UX-C10:/usr/share/man/SCO-3.2.2:/usr/share/man/SCO-3.5.0:/usr/share/man/SVR4.2:/usr/share/man/Solaris-2.5:/usr/share/man/SunOS-4.1.3:/usr/share/man/Xenix-2.3.2 Under these circumstances it's interesting to know which man pages you have, and where they are. It also had a 'query' option: $ man -q ls -r--r--r-- 1 root wheel 5361 Sat Sep 30 17:13:47 2000 /usr/share/man/man1/ls.1.gz? n -rw-r--r-- 1 root wheel 3062 Thu Aug 18 21:45:13 1994 /usr/share/man/4.4BSD/cat1/ls.1.gz? n -r--r--r-- 1 bin bin 9435 Tue Jan 21 00:17:30 1997 /usr/share/man/BSDI/man1/ls.1? n -rw-r--r-- 1 root wheel 2271 Fri Aug 25 23:54:06 2000 /usr/share/man/linux/man1/ls.1.gz? n -rw-r--r-- 1 root wheel 4903 Fri Dec 10 09:30:51 1999 /usr/share/man/linux/man1/ls.1? n -rw-r--r-- 1 bin sys 3354 Fri Jun 27 10:05:42 1975 /usr/share/man/V6/man1/ls.1? As regards the cat files, it seems to me that an obvious solution would be to add a CATMAN environment variable which would specify the location of the catman pages, and default to /usr/share/man/cat. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 16:54:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 4E12137B417; Thu, 13 Dec 2001 16:54:51 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 90FB1786E3; Fri, 14 Dec 2001 11:24:49 +1030 (CST) Date: Fri, 14 Dec 2001 11:24:49 +1030 From: Greg Lehey To: Ruslan Ermilov Cc: Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011214112449.M3448@monorchid.lemis.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011213101401.C77774@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011213101401.C77774@sunbay.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 13 December 2001 at 10:14:01 +0200, Ruslan Ermilov wrote: > On Thu, Dec 13, 2001 at 12:01:03AM -0500, Garance A Drosihn wrote: >> Should I try my hand at implementing my idea, or is someone else already >> looking into it? >> > Sorry, but I don't quite understand what are you looking at. > We already have a manpath(1) facility, that could be used > to configure alternate manual pathes. Is that not sufficient? The idea here is to have the catman pages in a different place. For example, the man pages may stay in /usr/share/man, while the catman pages may move to /var/share/catman or some such. The motivation here is that this would help make /usr read-only. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 18:35:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 8EAA337B417 for ; Thu, 13 Dec 2001 18:35:14 -0800 (PST) Received: from pool0149.cvx22-bradley.dialup.earthlink.net ([209.179.198.149] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EiBs-0002cM-00; Thu, 13 Dec 2001 18:35:13 -0800 Message-ID: <3C196566.FCE0CAC3@mindspring.com> Date: Thu, 13 Dec 2001 18:35:18 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Moestl Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 References: <20011213192033.A871@crow.dom2ip.de> <3C18F78D.C537D487@mindspring.com> <20011213201213.B871@crow.dom2ip.de> <3C192C70.9A79B3C5@mindspring.com> <20011214005031.B4747@crow.dom2ip.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thomas Moestl wrote: > > I was more concerned with the 1 << 0 not being hit at all. I agree > > on the overflow fix; I was just curious why the entire range was not > > shifted down 1, instead of just avoiding the overflow. > > If no bit from 31 to 1 was found set, an alignment of 1 (i.e. any > address is valid) is assumed. This corresponds to bit 0, so both 1 and > zero mean that no alignment needs to be maintained. Got it, thanks. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 18:48:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 75AA237B417; Thu, 13 Dec 2001 18:48:30 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id D2A6F3E35; Fri, 14 Dec 2001 02:48:29 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id D12E73C12E; Fri, 14 Dec 2001 02:48:29 +0000 (UTC) To: "Brian F. Feldman" Cc: Robert Watson , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: <200112131511.fBDFBHE78634@green.bikeshed.org>; from green@freebsd.org on "Thu, 13 Dec 2001 10:11:17 -0500" Date: Fri, 14 Dec 2001 02:48:24 +0000 From: Dima Dorfman Message-Id: <20011214024829.D2A6F3E35@bazooka.trit.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: > Dima Dorfman wrote: > > Robert Watson wrote: > > > I've actually been thinking about modifying xucred in -CURRENT to export > > > additional information from a kernel ucred, such as real and saved ids, > > > now that we have that information in ucred. > > > > I've attached a patch that makes the first field a version number, and > > teaches the existing applications about it (mostly, it teaches them > > set the version when writing an xucred, and return EINVAL if it > > doesn't match when reading an xucred). It compiles and seems to run, > > but I have not done extensive testing with it. Please review. > > Yes, this looks like just what I intended we should do with xucred {} if we > ever decided to want to export more fields. I like the changes, except for > a few smaller things. In the interest of compatibility, XUCRED_VERSION > should start at 0, or it will needlessly break several applications. The > other is that I am curious why the new field is named cr_xversion and not > just cr_version. I'd be much more comfortable with cr_version, which would > coincide with the naming of the #define you chose of XUCRED_VERSION. I'm sure there was a reason I named it cr_xversion, but I can't remember it now :-/. I've made both of these changes; you can find the new patch at http://www.trit.org/~dima/home/a/crxver.diff (I'm not posting it since there's nothing terribly interesting in it compared to the old one). Barring any objections, I plan to commit it this weekend, and MFC the xucred definition, along with my LOCAL_PEERCRED changes, some time before the 4.5 freeze. > > (Note that this patch changes something inside lomac which looks like > > it was copied verbatim from uipc_usrreq.c. I don't know anything > > about lomac, but my guess is that this code should be kept somewhat in > > sync (although I haven't seen any posts/warnings to that effect). If > > anyone can shed any light on this, I'd appreciate it). > > That is indeed the case. That bit of code would have to either have been > copied for use there or modified wholesale (which would be somewhat evil). So am I right in saying it should be kept mostly in sync with kern/? In that case, it might be worth sticking some notices to that effect in the affected files, since people will probably miss the duplicates. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 19: 2:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6241537B417; Thu, 13 Dec 2001 19:02:45 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBE32gi77530; Thu, 13 Dec 2001 22:02:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 13 Dec 2001 22:02:42 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: "Brian F. Feldman" , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: <20011214024829.D2A6F3E35@bazooka.trit.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001, Dima Dorfman wrote: > I'm sure there was a reason I named it cr_xversion, but I can't remember > it now :-/. I've made both of these changes; you can find the new patch > at http://www.trit.org/~dima/home/a/crxver.diff (I'm not posting it > since there's nothing terribly interesting in it compared to the old > one). > > Barring any objections, I plan to commit it this weekend, and MFC the > xucred definition, along with my LOCAL_PEERCRED changes, some time > before the 4.5 freeze. Actually, the one thing I'd like to see before we move forward is a standard routine that accepts a ucred, and a *xucred, and fills out the xucred using the ucred (preferably, in kern_prot.c). Right now, xucred is filled out in various places manually (netinet, socket code, et al). As we begin to broaden the scope of xucred (for example, I'd like to push in the ruid and rgid), it will make things a lot easier, and also prevent more code from knowing much about the innards of ucred. That way, also, the version number can be kept in one place. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 19:13:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id BE69237B419; Thu, 13 Dec 2001 19:13:51 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 6D1203E2F; Fri, 14 Dec 2001 03:13:51 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 6900C3C12E; Fri, 14 Dec 2001 03:13:51 +0000 (UTC) To: Robert Watson Cc: "Brian F. Feldman" , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: ; from rwatson@freebsd.org on "Thu, 13 Dec 2001 22:02:42 -0500 (EST)" Date: Fri, 14 Dec 2001 03:13:46 +0000 From: Dima Dorfman Message-Id: <20011214031351.6D1203E2F@bazooka.trit.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > > On Fri, 14 Dec 2001, Dima Dorfman wrote: > > > I'm sure there was a reason I named it cr_xversion, but I can't remember > > it now :-/. I've made both of these changes; you can find the new patch > > at http://www.trit.org/~dima/home/a/crxver.diff (I'm not posting it > > since there's nothing terribly interesting in it compared to the old > > one). > > > > Barring any objections, I plan to commit it this weekend, and MFC the > > xucred definition, along with my LOCAL_PEERCRED changes, some time > > before the 4.5 freeze. > > Actually, the one thing I'd like to see before we move forward is a > standard routine that accepts a ucred, and a *xucred, and fills out the > xucred using the ucred (preferably, in kern_prot.c). Right now, xucred is > filled out in various places manually (netinet, socket code, et al). As > we begin to broaden the scope of xucred (for example, I'd like to push in > the ruid and rgid), it will make things a lot easier, and also prevent > more code from knowing much about the innards of ucred. That way, also, > the version number can be kept in one place. I had patches to add this routine (and vice versa, xucred->ucred) before you added the extra fields to ucred, at which point I dropped it since it didn't make much sense: Which fields do you copy? Effective, real, or saved {u,g}ids? It would again make sense if xucred had the same set of fields as ucred, however. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 19:17:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3160937B417; Thu, 13 Dec 2001 19:17:52 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBE3Hoi77716; Thu, 13 Dec 2001 22:17:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 13 Dec 2001 22:17:50 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dima Dorfman Cc: "Brian F. Feldman" , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: <20011214031351.6D1203E2F@bazooka.trit.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001, Dima Dorfman wrote: > > Actually, the one thing I'd like to see before we move forward is a > > standard routine that accepts a ucred, and a *xucred, and fills out the > > xucred using the ucred (preferably, in kern_prot.c). Right now, xucred is > > filled out in various places manually (netinet, socket code, et al). As > > we begin to broaden the scope of xucred (for example, I'd like to push in > > the ruid and rgid), it will make things a lot easier, and also prevent > > more code from knowing much about the innards of ucred. That way, also, > > the version number can be kept in one place. > > I had patches to add this routine (and vice versa, xucred->ucred) > before you added the extra fields to ucred, at which point I dropped it > since it didn't make much sense: Which fields do you copy? Effective, > real, or saved {u,g}ids? It would again make sense if xucred had the > same set of fields as ucred, however. It's always been euid in ucred previously, so I assumed that for version 0 of xucred, only euid and egid (plus additional groups) would be exported. Future versions of xucred (probably version 1, only in -CURRENT) would also be able to export ruid, svuid, rgid, and svgid. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 21:21:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 37A3A37B405; Thu, 13 Dec 2001 21:21:31 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBE5LTO37440; Fri, 14 Dec 2001 00:21:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011213101401.C77774@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011213101401.C77774@sunbay.com> Date: Fri, 14 Dec 2001 00:21:25 -0500 To: Ruslan Ermilov From: Garance A Drosihn Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Cc: freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:14 AM +0200 12/13/01, Ruslan Ermilov wrote: >On Thu, Dec 13, 2001 at 12:01:03AM -0500, Garance A Drosihn wrote: > > I noticed there are some changes to 'man' in release 5 which haven't been > > MFC'ed yet. Would there be any reason those should not be MFC'ed? > >Some of them can't be MFC'ed, some can be. Please be specific. :-) "Being specific" would require that I actually know what I'm talking about. I can be much quicker if I stick to being vague! :-) I was just noticing the changes to man/man.c and man/Makefile. Seems to be something about Avoid using setre[ug]id() calls. Removed the setgid stuff we don't need. (a few) about locale handling I only mentioned them because man/man.c is probably the source file I'd have to change if I were to implement the changes I am talking about, and if I did do these changes then I would like to MFC my own changes. That's easier (IMO) if I can MFC the changes which came before them. > > Should I try my hand at implementing my idea, or is someone else > > already looking into it? > >Sorry, but I don't quite understand what are you looking at. >We already have a manpath(1) facility, that could be used >to configure alternate manual pathes. Is that not sufficient? > > I haven't done any work on this yet, I'm just looking for feedback. >> >What's the goal of doing this? I missed the original thread. It started in the thread about getting rid of the need to have /usr as a separate partition. If we could get /usr so it was very close to "read-only" in standard operation (*), then we could do away with creating a separate partition for it in the default partition-choices. We would just roll it into the partition for '/', and create '/' at a larger size to match. I kinda like this idea. When I have a 20-gig disk, it seems a shame to burn up a limited-resource like "available partition letters" on a 50 or 100-meg partition. (just my opinion) (* - by "standard operation" here, I mean in normal day-to-day usage. Obviously it would be written to when installing ports into /usr/local, and things like that). Someone else then mentioned that if /usr *is* a part of '/', then we don't have to statically-build all the binaries in /bin or /sbin. It was noted that this saves several megabytes in the size of the system, and that such savings are welcome in some situations (embedded systems, older machines, etc). So, as one way to make /usr more "read-only" for all users, without adversely effecting anyone, I thought it would be nice if 'man' knew how to save the 'cat' pages for (say) /usr/share/man/man* into some place under /var. My thought was /var/man/usr/share/man/cat* While I have thought of doing this on my own machines with symlinks, I think that gets pretty messy pretty fast. So, I thought the least disruptive change would be if 'man' used such directories *if* they had been created by the administrator (or install-process), but if those new directories did not exist then 'man' would behave exactly as it does now. Another way to get the effect of a "more read-only" /usr would be to do a catman step every time one does an installworld. Me, I hate the idea of using catman to address this specific issue (although it may be fine to do for other reasons). For one, I do a lot of installworlds, and I am not looking for ways for installworld to take MORE time! Second, if one of my hopes is that we can *shrink* the executables in /bin or /sbin (because we will not have to statically-link them), then it seems counter-productive to reduce that disk space by chewing up a whole lot of disk space by storing all the cat pages. Given that background, my previous message should make a bit more sense. At least, I hope it does... :-) I guess one argument against my idea is that it means that the files in /var/log will be in the same partition as the arbitrary-amount of files from 'cat' pages. Perhaps this is not a good idea. I'm sure I could think of other objections if I really tried, but I hate arguing against my own ideas so I'm seeing what other developers think. I know that this one change will not turn /usr into a read-only directory, but it would be one step towards that goal. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 23: 9:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 2807537B419; Thu, 13 Dec 2001 23:09:16 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 91CB13E2F; Fri, 14 Dec 2001 07:09:15 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 8CDBD3C12E; Fri, 14 Dec 2001 07:09:15 +0000 (UTC) To: Robert Watson Cc: "Brian F. Feldman" , arch@freebsd.org Subject: Re: MFC'ing xucred definition In-Reply-To: ; from rwatson@freebsd.org on "Thu, 13 Dec 2001 22:17:50 -0500 (EST)" Date: Fri, 14 Dec 2001 07:09:10 +0000 From: Dima Dorfman Message-Id: <20011214070915.91CB13E2F@bazooka.trit.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: > > On Fri, 14 Dec 2001, Dima Dorfman wrote: > > > > Actually, the one thing I'd like to see before we move forward is a > > > standard routine that accepts a ucred, and a *xucred, and fills out the > > > xucred using the ucred (preferably, in kern_prot.c). Right now, xucred i > s > > > filled out in various places manually (netinet, socket code, et al). As > > > we begin to broaden the scope of xucred (for example, I'd like to push in > > > the ruid and rgid), it will make things a lot easier, and also prevent > > > more code from knowing much about the innards of ucred. That way, also, > > > the version number can be kept in one place. > > > > I had patches to add this routine (and vice versa, xucred->ucred) > > before you added the extra fields to ucred, at which point I dropped it > > since it didn't make much sense: Which fields do you copy? Effective, > > real, or saved {u,g}ids? It would again make sense if xucred had the > > same set of fields as ucred, however. > > It's always been euid in ucred previously, so I assumed that for version 0 > of xucred, only euid and egid (plus additional groups) would be exported. > Future versions of xucred (probably version 1, only in -CURRENT) would > also be able to export ruid, svuid, rgid, and svgid. Very well. The attached patch adds two routines, cru2x() and crx2u() which convert from a ucred to xucred and vice versa, respectively. cru2x() sets the version number, and crx2u() checks it. If the check fails, it returns EINVAL. I'm not sure if there's a better way to do this error passing, since it seems that none of the other cr*() routines return an error code. The userland parts remain unchanged from my previous patches. Index: lib/libc/gen/getpeereid.3 =================================================================== RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.3,v retrieving revision 1.3 diff -u -r1.3 getpeereid.3 --- lib/libc/gen/getpeereid.3 2001/12/02 23:50:40 1.3 +++ lib/libc/gen/getpeereid.3 2001/12/14 01:20:17 @@ -118,7 +118,8 @@ The argument .Fa s does not refer to a socket of type -.Dv SOCK_STREAM . +.Dv SOCK_STREAM , +or the kernel returned invalid data. .El .Sh SEE ALSO .Xr connect 2 , Index: lib/libc/gen/getpeereid.c =================================================================== RCS file: /ref/cvsf/src/lib/libc/gen/getpeereid.c,v retrieving revision 1.1 diff -u -r1.1 getpeereid.c --- lib/libc/gen/getpeereid.c 2001/08/17 22:09:15 1.1 +++ lib/libc/gen/getpeereid.c 2001/12/14 01:20:17 @@ -34,6 +34,7 @@ #include #include +#include #include int @@ -47,6 +48,8 @@ error = getsockopt(s, LOCAL_PEERCRED, 1, &xuc, &xuclen); if (error != 0) return (error); + if (xuc.cr_version != XUCRED_VERSION) + return (EINVAL); *euid = xuc.cr_uid; *egid = xuc.cr_gid; return (0); Index: sbin/mountd/mountd.c =================================================================== RCS file: /ref/cvsf/src/sbin/mountd/mountd.c,v retrieving revision 1.59 diff -u -r1.59 mountd.c --- sbin/mountd/mountd.c 2001/09/20 02:15:17 1.59 +++ sbin/mountd/mountd.c 2001/12/14 01:20:17 @@ -211,7 +211,7 @@ struct grouplist *grphead; char exname[MAXPATHLEN]; struct xucred def_anon = { - 0, + XUCRED_VERSION, (uid_t)-2, 1, { (gid_t)-2 }, @@ -2050,6 +2050,7 @@ struct group *gr; int ngroups, groups[NGROUPS + 1]; + cr->cr_version = XUCRED_VERSION; /* * Set up the unprivileged user. */ Index: sys/kern/kern_prot.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/kern_prot.c,v retrieving revision 1.131 diff -u -r1.131 kern_prot.c --- sys/kern/kern_prot.c 2001/12/06 21:58:47 1.131 +++ sys/kern/kern_prot.c 2001/12/14 03:30:55 @@ -1670,6 +1670,41 @@ } /* + * Fill in a struct xucred based on a struct ucred. + */ +void +cru2x(cr, xcr) + struct ucred *cr; + struct xucred *xcr; +{ + + bzero(xcr, sizeof(*xcr)); + xcr->cr_version = XUCRED_VERSION; + xcr->cr_uid = cr->cr_uid; + xcr->cr_ngroups = cr->cr_ngroups; + bcopy(cr->cr_groups, xcr->cr_groups, sizeof(cr->cr_groups)); +} + +/* + * Copy information out of a struct xucred into a struct ucred. This + * routine does *not* initialize (zero) the output structure (cr) + * because that's the job of crget() or crdup(). + */ +int +crx2u(xcr, cr) + struct xucred *xcr; + struct ucred *cr; +{ + + if (xcr->cr_version != XUCRED_VERSION) + return (EINVAL); + cr->cr_uid = xcr->cr_uid; + cr->cr_ngroups = xcr->cr_ngroups; + bcopy(xcr->cr_groups, cr->cr_groups, sizeof(xcr->cr_groups)); + return (0); +} + +/* * Get login name, if available. */ #ifndef _SYS_SYSPROTO_H_ Index: sys/kern/uipc_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.78 diff -u -r1.78 uipc_usrreq.c --- sys/kern/uipc_usrreq.c 2001/12/13 22:09:37 1.78 +++ sys/kern/uipc_usrreq.c 2001/12/14 03:33:12 @@ -710,11 +710,7 @@ * from its process structure at the time of connect() * (which is now). */ - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroups; - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_groups, - sizeof(unp3->unp_peercred.cr_groups)); + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); unp3->unp_flags |= UNP_HAVEPC; /* * The receiver's (server's) credentials are copied @@ -1396,11 +1392,7 @@ struct proc *p; { - bzero(&unp->unp_peercred, sizeof(unp->unp_peercred)); - unp->unp_peercred.cr_uid = p->p_ucred->cr_uid; - unp->unp_peercred.cr_ngroups = p->p_ucred->cr_ngroups; - bcopy(p->p_ucred->cr_groups, unp->unp_peercred.cr_groups, - sizeof(unp->unp_peercred.cr_groups)); + cru2x(p->p_ucred, &unp->unp_peercred); unp->unp_flags |= UNP_HAVEPCCACHED; return (0); } Index: sys/kern/vfs_export.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/vfs_export.c,v retrieving revision 1.312 diff -u -r1.312 vfs_export.c --- sys/kern/vfs_export.c 2001/09/10 11:28:05 1.312 +++ sys/kern/vfs_export.c 2001/12/14 03:40:24 @@ -98,11 +98,9 @@ return (EPERM); np = &nep->ne_defexported; np->netc_exflags = argp->ex_flags; - bzero(&np->netc_anon, sizeof(np->netc_anon)); - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, - sizeof(np->netc_anon.cr_groups)); + error = crx2u(&argp->ex_anon, &np->netc_anon); + if (error != 0) + return (error); np->netc_anon.cr_ref = 1; mp->mnt_flag |= MNT_DEFEXPORTED; return (0); @@ -150,11 +148,9 @@ goto out; } np->netc_exflags = argp->ex_flags; - bzero(&np->netc_anon, sizeof(np->netc_anon)); - np->netc_anon.cr_uid = argp->ex_anon.cr_uid; - np->netc_anon.cr_ngroups = argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon.cr_groups, - sizeof(np->netc_anon.cr_groups)); + error = crx2u(&argp->ex_anon, &np->netc_anon); + if (error != 0) + goto out; np->netc_anon.cr_ref = 1; return (0); out: Index: sys/netinet/tcp_subr.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet/tcp_subr.c,v retrieving revision 1.118 diff -u -r1.118 tcp_subr.c --- sys/netinet/tcp_subr.c 2001/11/22 04:50:43 1.118 +++ sys/netinet/tcp_subr.c 2001/12/14 03:34:19 @@ -919,11 +919,7 @@ error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); if (error) goto out; - bzero(&xuc, sizeof(xuc)); - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, - sizeof(xuc.cr_groups)); + cru2x(inp->inp_socket->so_cred, &xuc); error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); @@ -975,11 +971,7 @@ error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); if (error) goto out; - bzero(&xuc, sizeof(xuc)); - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, - sizeof(xuc.cr_groups)); + cru2x(inp->inp_socket->so_cred, &xuc); error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); Index: sys/netinet/udp_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.100 diff -u -r1.100 udp_usrreq.c --- sys/netinet/udp_usrreq.c 2001/11/08 02:13:17 1.100 +++ sys/netinet/udp_usrreq.c 2001/12/14 03:34:36 @@ -651,11 +651,7 @@ error = cr_cansee(req->td->td_proc->p_ucred, inp->inp_socket->so_cred); if (error) goto out; - bzero(&xuc, sizeof(xuc)); - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, - sizeof(xuc.cr_groups)); + cru2x(inp->inp_socket->so_cred, &xuc); error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); Index: sys/netinet6/udp6_usrreq.c =================================================================== RCS file: /ref/cvsf/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.19 diff -u -r1.19 udp6_usrreq.c --- sys/netinet6/udp6_usrreq.c 2001/11/08 02:13:18 1.19 +++ sys/netinet6/udp6_usrreq.c 2001/12/14 03:35:00 @@ -484,11 +484,7 @@ error = ENOENT; goto out; } - bzero(&xuc, sizeof(xuc)); - xuc.cr_uid = inp->inp_socket->so_cred->cr_uid; - xuc.cr_ngroups = inp->inp_socket->so_cred->cr_ngroups; - bcopy(inp->inp_socket->so_cred->cr_groups, xuc.cr_groups, - sizeof(xuc.cr_groups)); + cru2x(inp->inp_socket->so_cred, &xuc); error = SYSCTL_OUT(req, &xuc, sizeof(struct xucred)); out: splx(s); Index: sys/security/lomac/kernel_socket.c =================================================================== RCS file: /ref/cvsf/src/sys/security/lomac/kernel_socket.c,v retrieving revision 1.2 diff -u -r1.2 kernel_socket.c --- sys/security/lomac/kernel_socket.c 2001/12/03 00:21:18 1.2 +++ sys/security/lomac/kernel_socket.c 2001/12/14 03:35:23 @@ -265,11 +265,7 @@ * from its process structure at the time of connect() * (which is now). */ - memset(&unp3->unp_peercred, '\0', sizeof(unp3->unp_peercred)); - unp3->unp_peercred.cr_uid = td->td_proc->p_ucred->cr_uid; - unp3->unp_peercred.cr_ngroups = td->td_proc->p_ucred->cr_ngroups; - memcpy(unp3->unp_peercred.cr_groups, td->td_proc->p_ucred->cr_groups, - sizeof(unp3->unp_peercred.cr_groups)); + cru2x(td->td_proc->p_ucred, &unp3->unp_peercred); unp3->unp_flags |= UNP_HAVEPC; /* * The receiver's (server's) credentials are copied Index: sys/sys/ucred.h =================================================================== RCS file: /ref/cvsf/src/sys/sys/ucred.h,v retrieving revision 1.26 diff -u -r1.26 ucred.h --- sys/sys/ucred.h 2001/10/11 23:38:17 1.26 +++ sys/sys/ucred.h 2001/12/14 03:30:26 @@ -73,12 +73,13 @@ * any need to change the size of this or layout of its used fields. */ struct xucred { - u_short _cr_unused0; /* compatibility with old ucred */ + u_short cr_version; /* structure layout version */ uid_t cr_uid; /* effective user id */ short cr_ngroups; /* number of groups */ gid_t cr_groups[NGROUPS]; /* groups */ void *_cr_unused1; /* compatibility with old ucred */ }; +#define XUCRED_VERSION 0 #ifdef _KERNEL @@ -95,6 +96,8 @@ struct ucred *crget __P((void)); struct ucred *crhold __P((struct ucred *cr)); int crshared __P((struct ucred *cr)); +void cru2x __P((struct ucred *cr, struct xucred *xcr)); +int crx2u __P((struct xucred *xcr, struct ucred *cr)); int groupmember __P((gid_t gid, struct ucred *cred)); #endif /* _KERNEL */ Index: usr.sbin/inetd/builtins.c =================================================================== RCS file: /ref/cvsf/src/usr.sbin/inetd/builtins.c,v retrieving revision 1.36 diff -u -r1.36 builtins.c --- usr.sbin/inetd/builtins.c 2001/07/17 07:12:57 1.36 +++ usr.sbin/inetd/builtins.c 2001/12/14 01:20:18 @@ -569,7 +569,7 @@ getcredfail = EAFNOSUPPORT; break; } - if (getcredfail != 0) { + if (getcredfail != 0 || uc.cr_version != XUCRED_VERSION) { if (*idbuf == '\0') iderror(lport, fport, s, getcredfail == ENOENT ? ID_NOUSER : ID_UNKNOWN); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 23:27:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (pc-62-31-42-140-hy.blueyonder.co.uk [62.31.42.140]) by hub.freebsd.org (Postfix) with ESMTP id 25DEC37B405; Thu, 13 Dec 2001 23:27:28 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.6/8.11.6) id fBE78gj15274; Fri, 14 Dec 2001 07:08:42 GMT (envelope-from nik) Date: Fri, 14 Dec 2001 07:08:42 +0000 From: Nik Clayton To: Greg Lehey Cc: Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ru@FreeBSD.ORG, ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011214070842.C31192@clan.nothing-going-on.org> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011214112255.L3448@monorchid.lemis.com>; from grog@FreeBSD.org on Fri, Dec 14, 2001 at 11:22:55AM +1030 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 14, 2001 at 11:22:55AM +1030, Greg Lehey wrote: > If you're going to overhaul man, there's probably quite a bit you > could do beyond the paths. =20 Making % man _path_/foo.1 work (e.g., "man ./foo.1") would probably be beneficial. I've lost count of the number of times I've had to explain how to use "nroff -man =2E.." (or -mdoc) to people. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwZpXoACgkQk6gHZCw343UrCACbB2L2957oOyP8FUFy59Xv4x4z aaIAn0p4fCFfG7v8gK0qfMq4kOYYwaU3 =lR6n -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 13 23:50:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EFF6337B417; Thu, 13 Dec 2001 23:50:35 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fBE7oYa94512; Fri, 14 Dec 2001 00:50:34 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fBE7oYM50906; Fri, 14 Dec 2001 00:50:34 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112140750.fBE7oYM50906@harmony.village.org> To: Nik Clayton Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "Fri, 14 Dec 2001 07:08:42 GMT." <20011214070842.C31192@clan.nothing-going-on.org> References: <20011214070842.C31192@clan.nothing-going-on.org> <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> Date: Fri, 14 Dec 2001 00:50:34 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011214070842.C31192@clan.nothing-going-on.org> Nik Clayton writes: : Making : : % man _path_/foo.1 : : work (e.g., "man ./foo.1") would probably be beneficial. I've lost : count of the number of times I've had to explain how to use "nroff -man : =2E.." (or -mdoc) to people. This was the first thing I wanted from man, back in 1986 or so... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 0:19:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 413BF37B416; Fri, 14 Dec 2001 00:19:03 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBE8IwE38382; Fri, 14 Dec 2001 10:18:58 +0200 (EET) (envelope-from ru) Date: Fri, 14 Dec 2001 10:18:58 +0200 From: Ruslan Ermilov To: Greg Lehey Cc: Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011214101857.C35094@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214112255.L3448@monorchid.lemis.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 11:22:55AM +1030, Greg Lehey wrote: > On Thursday, 13 December 2001 at 0:01:03 -0500, Garance A Drosihn wrote: > > From the thread > > Re: Getting rid of /usr file system (was: Using a larger block size...) > > > >>> On Tue, Dec 11, 2001, Garance A Drosihn wrote: > >>>> In the land of weird suggestions, just how weird would it be to > >>>> suggest that we create some way for 'cat' versions of man pages > >>>> to land somewhere else? > >>>> > >>>> Maybe /var/man/usr/share/cat* > >>>> for ones from /usr/share/man/man* > >>>> etc? > > > > Given that Peter, Nik, and Greg expressed some interest, I thought it might > > be interesting to try my hand at doing it. I looked at it for about 15 > > minutes tonight, and noticed that 'man' is under gnu/usr.bin. Does that > > imply changes for it should go thru gnu, somehow? <> > > No, there's no obligation to submit changes to the GNU project. If > you think it would be worthwhile for them, you can do so, however. > > > I noticed there are some changes to 'man' in release 5 which haven't > > been MFC'ed yet. Would there be any reason those should not be > > MFC'ed? > > Your call. I'd guess that nobody felt motivated enough. > > > Should I try my hand at implementing my idea, or is someone else > > already looking into it? > > > > While I haven't tried writing any code yet, my intent is that > > 'man ' would do something like: > > > > search for the requested man page (same as it does now) > > once it finds the location, then > > + look for a 'cat' page at //cat/thing.n, > > + if found, use it > > look for a 'cat' page at /var/man//cat/thing.n, > > if found, use it > > + see if /var/man//cat is an existing directory, > > + if so, then put the expanded 'man' page into that directory. > > otherwise put it in //cat (as happens now) > > > > Does this sound about how people would want it to work? Basically the > > idea is that it would work exactly the same as it does now, except for > > the steps with a '+' on them. So, to get this alternate behavior people > > would have to create the appropriate directories under /var/man (or > > perhaps some other name), such as: > > /var/man/usr/share/man/cat* > > /var/man/usr/local/man/cat* > > /var/man/usr/X11R6/man/cat* > > > > I haven't done any work on this yet, I'm just looking for feedback. > > If you're going to overhaul man, there's probably quite a bit you > could do beyond the paths. I had a man years ago which would list which > man pages were present (note that my MANPATH is: > > MANPATH=/usr/local/man:/usr/share/man:/usr/X11R6/man:/usr/share/man/BSDI-5:/usr/share/man/4.4BSD:/usr/share/man/BSDI:/usr/share/man/V6:/usr/share/man/V7:/usr/share/man/3bsd:/usr/share/man/2.11BSD:/usr/share/man/IRIX-5.3/u_man:/usr/share/man/IRIX-5.3/p_man:/usr/share/man/IRIX-5.3/a_man:/usr/share/man/IRIX-5.3/g_man:/usr/share/man/ISC-3.2/p_man:/usr/share/man/ISC-3.2/u_man:/usr/share/man/NonStop-UX-B23:/usr/share/man/NonStop-UX-C10:/usr/share/man/SCO-3.2.2:/usr/share/man/SCO-3.5.0:/usr/share/man/SVR4.2:/usr/share/man/Solaris-2.5:/usr/share/man/SunOS-4.1.3:/usr/share/man/Xenix-2.3.2 > > Under these circumstances it's interesting to know which man pages you > have, and where they are. It also had a 'query' option: > > $ man -q ls > -r--r--r-- 1 root wheel 5361 Sat Sep 30 17:13:47 2000 /usr/share/man/man1/ls.1.gz? n > -rw-r--r-- 1 root wheel 3062 Thu Aug 18 21:45:13 1994 /usr/share/man/4.4BSD/cat1/ls.1.gz? n > -r--r--r-- 1 bin bin 9435 Tue Jan 21 00:17:30 1997 /usr/share/man/BSDI/man1/ls.1? n > -rw-r--r-- 1 root wheel 2271 Fri Aug 25 23:54:06 2000 /usr/share/man/linux/man1/ls.1.gz? n > -rw-r--r-- 1 root wheel 4903 Fri Dec 10 09:30:51 1999 /usr/share/man/linux/man1/ls.1? n > -rw-r--r-- 1 bin sys 3354 Fri Jun 27 10:05:42 1975 /usr/share/man/V6/man1/ls.1? > What are you looking for is already available as: $ MANPATH=/home/ru/mann:/usr/share/man man -a -w ls /home/ru/mann/man1/ls.1 /usr/share/man/cat1/ls.1.gz (source: /usr/share/man/man1/ls.1.gz) $ man -a -w dirname /usr/share/man/cat1/dirname.1.gz (source: /usr/share/man/man1/dirname.1.gz) /usr/share/man/cat3/dirname.3.gz (source: /usr/share/man/man3/dirname.3.gz) > As regards the cat files, it seems to me that an obvious solution > would be to add a CATMAN environment variable which would specify the > location of the catman pages, and default to /usr/share/man/cat. > Just having a CATMAN envariable is not enough, this would break many things. There are hosts on which people use different locales simultaneously. Look at how the usr/share/man/en.ISO8859-1 is organized nowadays, and realize why, while sharing the man? directories with the .., it has its own cat? directories. The "cat" feature of man(1) is insecure, and is probably going to be nuked after a release of 4.5. Having catpages: - is optional - can be configured at ``make world'' time - in different place can be achieved by using symlinks to cat?. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 2:27:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0A6B537B419; Fri, 14 Dec 2001 02:27:51 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fBEARoi82395; Fri, 14 Dec 2001 05:27:50 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 14 Dec 2001 05:27:49 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ruslan Ermilov Cc: Greg Lehey , Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages In-Reply-To: <20011214101857.C35094@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001, Ruslan Ermilov wrote: > Just having a CATMAN envariable is not enough, this would break many > things. There are hosts on which people use different locales > simultaneously. Look at how the usr/share/man/en.ISO8859-1 is organized > nowadays, and realize why, while sharing the man? directories with the > .., it has its own cat? directories. Not to mention the security issues -- the one nice thing about the hard-coded catman right now is that it greatly limits the scope for damage from a setuid man. I'm not entirely opposed to the notion of configuring its location in /etc/man.conf or something, but agree that a run-time user-tunable version of the same would be worrying. Even leaving aside the more serious attacks, imagine for a moment what would happen if arbitrary users could tweak the contents of arbitrary .8 man pages :-). > The "cat" feature of man(1) is insecure, and is probably going to be > nuked after a release of 4.5. Great! I've been hoping for that for years. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 3:45:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id DBC6B37B419; Fri, 14 Dec 2001 03:45:34 -0800 (PST) Received: from dialup-209.245.140.14.dial1.sanjose1.level3.net ([209.245.140.14] helo=blossom.cjclark.org) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16EqmT-0002Jj-00; Fri, 14 Dec 2001 03:45:34 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fBEBjUK02855; Fri, 14 Dec 2001 03:45:30 -0800 (PST) (envelope-from cjc) Date: Fri, 14 Dec 2001 03:45:30 -0800 From: "Crist J . Clark" To: Mike Smith Cc: Brooks Davis , freebsd-arch@FreeBSD.ORG Subject: Re: Getting rid of /usr file system (was: Using a larger block size on large filesystems) Message-ID: <20011214034530.A822@blossom.cjclark.org> References: <20011213105719.B4987@Odin.AC.HMC.Edu> <200112131908.fBDJ8el02057@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112131908.fBDJ8el02057@mass.dis.org>; from msmith@FreeBSD.ORG on Thu, Dec 13, 2001 at 11:08:40AM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 11:08:40AM -0800, Mike Smith wrote: > > On Thu, Dec 13, 2001 at 10:45:11AM -0500, Joe Abley wrote: > > > Since it has been this way since OpenBSD 2.5, if not earlier, I > > > think it is safe to say that that is not a high-demand function > > > of the OS by OpenBSD users. Thinking about it, I don't think I > > > have ever printed a manual page. > > > > Well, count me on the list of people who would be pissed if someone > > decided to do this. I'm all for installed the cat pages by default, but > > nobody is going to take away "man -t" support without a fight. I print > > manpages all the time when I want to read through them and I'll need > > them for more then a few minutes. > > I'd have to agree; I'd much rather dump the whole catpages thing (it's a > bad tradeoff, IMO; CPU speed is cheaper than disk space) but certainly > dropping the ability to print manpages would just be stupid. "CPU is cheaper than disk space?" Disk space is jaw-droppingly cheap. We're talking single-digit dollars per GB. And I think there are a lot more legacy (386, 486, Pentiums) with a big new hard drive, than fast CPUs with old, tiny (<1 GB) HDDs. It's not like the catpages take up lots of space. They are smaller than the manpages, $ echo /usr/bin/catman | su -m man $ du -ck /usr/share/man/man* | fgrep total 7189 total $ du -ck /usr/share/man/cat* | fgrep total 5974 total On a "small" modern HDD, 2 GB, the catpages would occupy 0.3% of the drive. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 4:44:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 226BF37B416; Fri, 14 Dec 2001 04:44:10 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBEChqA72499; Fri, 14 Dec 2001 14:43:52 +0200 (EET) (envelope-from ru) Date: Fri, 14 Dec 2001 14:43:52 +0200 From: Ruslan Ermilov To: Robert Watson Cc: Greg Lehey , Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011214144352.A71966@sunbay.com> References: <20011214101857.C35094@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Dec 14, 2001 at 05:27:49AM -0500, Robert Watson wrote: > > On Fri, 14 Dec 2001, Ruslan Ermilov wrote: > > > Just having a CATMAN envariable is not enough, this would break many > > things. There are hosts on which people use different locales > > simultaneously. Look at how the usr/share/man/en.ISO8859-1 is organized > > nowadays, and realize why, while sharing the man? directories with the > > .., it has its own cat? directories. > > Not to mention the security issues -- the one nice thing about the > hard-coded catman right now is that it greatly limits the scope for damage > from a setuid man. I'm not entirely opposed to the notion of configuring > its location in /etc/man.conf or something, but agree that a run-time > user-tunable version of the same would be worrying. Even leaving aside > the more serious attacks, imagine for a moment what would happen if > arbitrary users could tweak the contents of arbitrary .8 man pages :-). > > > The "cat" feature of man(1) is insecure, and is probably going to be > > nuked after a release of 4.5. > > Great! I've been hoping for that for years. :-) > Can I take it as an approval from core@ or security-officer@ team, both of which you are a member of? :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 7:10: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gateg.kw.bbc.co.uk (gateg.kw.bbc.co.uk [132.185.132.16]) by hub.freebsd.org (Postfix) with ESMTP id 0ABB737B416 for ; Fri, 14 Dec 2001 07:10:01 -0800 (PST) Received: from sunf0.rd.bbc.co.uk (ddmailgate.rd.bbc.co.uk [132.185.128.104]) by gateg.kw.bbc.co.uk (8.11.2/8.11.2) with SMTP id fBEF9rh17374; Fri, 14 Dec 2001 15:09:53 GMT Received: from inet34.rd.bbc.co.uk by sunf0.rd.bbc.co.uk; Fri, 14 Dec 01 15:09:52 GMT Date: Fri, 14 Dec 2001 15:09:50 +0000 From: Jonathan Perkin To: Garance A Drosihn Cc: freebsd-arch@freebsd.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-Id: <20011214150950.A12728@inet34.rd.bbc.co.uk> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011213101401.C77774@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Fri, Dec 14, 2001 at 12:21:25AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri Dec 14, 2001 at 12:21:25AM -0500, Garance A Drosihn wrote: > Someone else then mentioned that if /usr *is* a part of '/', then we > don't have to statically-build all the binaries in /bin or /sbin. It > was noted that this saves several megabytes in the size of the system, > and that such savings are welcome in some situations (embedded systems, > older machines, etc). As long as this isn't made the default. It's lovely to be free to be able to rm -rf /usr/{bin|sbin|lib*} etc and still have all the tools in /bin and /sbin available for recovery purposes. -- Jonathan Perkin - BBC Internet Services - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 7:31:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A62B637B417; Fri, 14 Dec 2001 07:31:11 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fBEFUup95933; Fri, 14 Dec 2001 17:30:56 +0200 (EET) (envelope-from ru) Date: Fri, 14 Dec 2001 17:30:56 +0200 From: Ruslan Ermilov To: Takahashi Yoshihiro Cc: arch@FreeBSD.org Subject: hw.machine on PC98 Message-ID: <20011214173056.A94075@sunbay.com> References: <200112141527.fBEFRF594757@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112141527.fBEFRF594757@freefall.freebsd.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear Takahashi, What do you think about making hw.machine display "pc98" on PC98's? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 13:21:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 51D9237B431 for ; Fri, 14 Dec 2001 13:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011214212008.LIL10701.rwcrmhc53.attbi.com@InterJet.elischer.org> for ; Fri, 14 Dec 2001 21:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA22211 for ; Fri, 14 Dec 2001 13:17:20 -0800 (PST) Date: Fri, 14 Dec 2001 13:17:18 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: KSEs and PTRACE/PROCFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there someone who really understands these, and who feels that they have a good idea of what the behaviour of a multi-threaded process should be when ptraced? The question is: WHat does it mean to "single step" a process with several threads? WHen you suspend a process, what happens? If there is someone with feelings on these topics I whuold welcome your input. Here's a brief example: case PT_STEP: case PT_CONTINUE: case PT_DETACH: if ((uap->req != PT_STEP) && ((unsigned)uap->data >= NSIG)) return (EINVAL); PHOLD(p); if (uap->req == PT_STEP) { if ((error = ptrace_single_step(FIRST_THREAD_IN_PROC(p))) { PRELE(p); return (error); } } if (uap->addr != (caddr_t)1) { fill_kinfo_proc(p, &p->p_uarea->u_kproc); if ((error = ptrace_set_pc( FIRST_THREAD_IN_PROC(p), (u_long)(uintfptr_t)uap->addr))) { PRELE(p); return (error); } } PRELE(p); In this code in the "ptrace" function, we use FIRST_THREAD_IN_PROC() which returns tgeh only thread in a normal system but if there are many threads active in the process, what should we do? Should we set asside one thread and KSE to run all work, thus serialising everything? if so where do we store it, and how do we separate it from all the other threads? Should we pick threads at random? If you are a debugger afficionado, I'd lov eto hear your ideas on this, julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 14:12:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id DD70E37B405 for ; Fri, 14 Dec 2001 14:12:34 -0800 (PST) Received: (qmail 2587 invoked from network); 14 Dec 2001 22:12:34 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Dec 2001 22:12:34 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 14 Dec 2001 14:12:25 -0800 (PST) From: John Baldwin To: Julian Elischer Subject: RE: KSEs and PTRACE/PROCFS Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 14-Dec-01 Julian Elischer wrote: > Is there someone who really understands these, and > who feels that they have a good idea of what the behaviour of a > multi-threaded process should be when ptraced? I would focus on getting multithreaded kprocs working with the scheduler first and worry about userland issues later. ptrace qualifies as a userland issue in this case. :) Not that this isn't a question that will have to be answered, but there are several things that can be done before we get to the point of needing to answer this question. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 15:20:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id DE12637B416; Fri, 14 Dec 2001 15:20:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011214232011.CSBJ5010.rwcrmhc51.attbi.com@InterJet.elischer.org>; Fri, 14 Dec 2001 23:20:11 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA22659; Fri, 14 Dec 2001 15:19:33 -0800 (PST) Date: Fri, 14 Dec 2001 15:19:31 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: arch@freebsd.org Subject: RE: KSEs and PTRACE/PROCFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For now I'm doing that.. but when going through the code sometimes it helps to have an idea where you are heading.. :-) On Fri, 14 Dec 2001, John Baldwin wrote: > > On 14-Dec-01 Julian Elischer wrote: > > Is there someone who really understands these, and > > who feels that they have a good idea of what the behaviour of a > > multi-threaded process should be when ptraced? > > I would focus on getting multithreaded kprocs working with the scheduler first > and worry about userland issues later. ptrace qualifies as a userland issue in > this case. :) > > Not that this isn't a question that will have to be answered, but there are > several things that can be done before we get to the point of needing to answer > this question. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 15:23:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 86D2F37B41A for ; Fri, 14 Dec 2001 15:23:24 -0800 (PST) Received: from rac1.wam.umd.edu (IDENT:root@rac1.wam.umd.edu [128.8.10.141]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id SAA06706; Fri, 14 Dec 2001 18:23:20 -0500 (EST) Received: from rac1.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id SAA04482; Fri, 14 Dec 2001 18:23:18 -0500 (EST) Received: from localhost (culverk@localhost) by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id SAA04478; Fri, 14 Dec 2001 18:23:18 -0500 (EST) X-Authentication-Warning: rac1.wam.umd.edu: culverk owned process doing -bs Date: Fri, 14 Dec 2001 18:23:18 -0500 (EST) From: Kenneth Wayne Culver To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSEs and PTRACE/PROCFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I don't know how to do this, but would it be possible to allow a user to somehow pick a thread if he/she wanted to? That would be most useful... Ken On Fri, 14 Dec 2001, Julian Elischer wrote: > Is there someone who really understands these, and > who feels that they have a good idea of what the behaviour of a > multi-threaded process should be when ptraced? > > The question is: > > WHat does it mean to "single step" a process with several threads? > WHen you suspend a process, what happens? > > If there is someone with feelings on these topics I whuold welcome > your input. > > Here's a brief example: > case PT_STEP: > case PT_CONTINUE: > case PT_DETACH: > if ((uap->req != PT_STEP) && ((unsigned)uap->data >= > NSIG)) > return (EINVAL); > > PHOLD(p); > > if (uap->req == PT_STEP) { > if ((error = > ptrace_single_step(FIRST_THREAD_IN_PROC(p))) { > PRELE(p); > return (error); > } > } > > if (uap->addr != (caddr_t)1) { > fill_kinfo_proc(p, &p->p_uarea->u_kproc); > if ((error = ptrace_set_pc( > FIRST_THREAD_IN_PROC(p), > (u_long)(uintfptr_t)uap->addr))) { > PRELE(p); > return (error); > } > } > PRELE(p); > > In this code in the "ptrace" function, we use > FIRST_THREAD_IN_PROC() which returns tgeh only thread in a normal > system but if there are many threads active in the process, > what should we do? > Should we set asside one thread and KSE to run all work, thus > serialising everything? if so where do we store it, and how do > we separate it from all the other threads? > Should we pick threads at random? > > If you are a debugger afficionado, I'd lov eto hear your ideas on this, > > julian > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 16:35:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id EC60337B41A; Fri, 14 Dec 2001 16:35:06 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 4460E786E6; Sat, 15 Dec 2001 11:05:05 +1030 (CST) Date: Sat, 15 Dec 2001 11:05:05 +1030 From: Greg Lehey To: Ruslan Ermilov Cc: Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011215110505.H85108@monorchid.lemis.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> <20011214101857.C35094@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214101857.C35094@sunbay.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, 14 December 2001 at 10:18:58 +0200, Ruslan Ermilov wrote: > On Fri, Dec 14, 2001 at 11:22:55AM +1030, Greg Lehey wrote: >> On Thursday, 13 December 2001 at 0:01:03 -0500, Garance A Drosihn wrote: >> Under these circumstances it's interesting to know which man pages you >> have, and where they are. It also had a 'query' option: >> >> $ man -q ls >> -r--r--r-- 1 root wheel 5361 Sat Sep 30 17:13:47 2000 /usr/share/man/man1/ls.1.gz? n >> -rw-r--r-- 1 root wheel 3062 Thu Aug 18 21:45:13 1994 /usr/share/man/4.4BSD/cat1/ls.1.gz? n >> -r--r--r-- 1 bin bin 9435 Tue Jan 21 00:17:30 1997 /usr/share/man/BSDI/man1/ls.1? n >> -rw-r--r-- 1 root wheel 2271 Fri Aug 25 23:54:06 2000 /usr/share/man/linux/man1/ls.1.gz? n >> -rw-r--r-- 1 root wheel 4903 Fri Dec 10 09:30:51 1999 /usr/share/man/linux/man1/ls.1? n >> -rw-r--r-- 1 bin sys 3354 Fri Jun 27 10:05:42 1975 /usr/share/man/V6/man1/ls.1? >> > What are you looking for is already available as: > > $ MANPATH=/home/ru/mann:/usr/share/man man -a -w ls > /home/ru/mann/man1/ls.1 > /usr/share/man/cat1/ls.1.gz (source: /usr/share/man/man1/ls.1.gz) Not quite. That corresponds to my man -l command: it just lists them, it doesn't give you the choice to select them or not. See the '? n' at the end of most lines; you can also answer 'y' or 'q'. >> As regards the cat files, it seems to me that an obvious solution >> would be to add a CATMAN environment variable which would specify the >> location of the catman pages, and default to /usr/share/man/cat. > > Just having a CATMAN envariable is not enough, this would break many > things. Yes, I was leaving that as an exercise for the implementor :-) > The "cat" feature of man(1) is insecure, and is probably going to be > nuked after a release of 4.5. I think this is a pity. What's the rationale? > Having catpages: > > - is optional > - can be configured at ``make world'' time Agreed. > - in different place can be achieved by using symlinks to cat?. Yes, but I'd consider this a workaround. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 16:35:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id 6E4C037B405; Fri, 14 Dec 2001 16:35:41 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id BE81F786E4; Sat, 15 Dec 2001 11:05:39 +1030 (CST) Date: Sat, 15 Dec 2001 11:05:39 +1030 From: Greg Lehey To: Ruslan Ermilov Cc: Robert Watson , Garance A Drosihn , Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Message-ID: <20011215110539.I85108@monorchid.lemis.com> References: <20011214101857.C35094@sunbay.com> <20011214144352.A71966@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214144352.A71966@sunbay.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, 14 December 2001 at 14:43:52 +0200, Ruslan Ermilov wrote: > On Fri, Dec 14, 2001 at 05:27:49AM -0500, Robert Watson wrote: >> >> On Fri, 14 Dec 2001, Ruslan Ermilov wrote: >> >>> Just having a CATMAN envariable is not enough, this would break many >>> things. There are hosts on which people use different locales >>> simultaneously. Look at how the usr/share/man/en.ISO8859-1 is organized >>> nowadays, and realize why, while sharing the man? directories with the >>> .., it has its own cat? directories. >> >> Not to mention the security issues -- the one nice thing about the >> hard-coded catman right now is that it greatly limits the scope for damage >> from a setuid man. I'm not entirely opposed to the notion of configuring >> its location in /etc/man.conf or something, but agree that a run-time >> user-tunable version of the same would be worrying. Even leaving aside >> the more serious attacks, imagine for a moment what would happen if >> arbitrary users could tweak the contents of arbitrary .8 man pages :-). >> >>> The "cat" feature of man(1) is insecure, and is probably going to be >>> nuked after a release of 4.5. >> >> Great! I've been hoping for that for years. :-) > > Can I take it as an approval from core@ or security-officer@ team, > both of which you are a member of? :-) It's certainly not (yet) an approval from core@. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 16:36:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from monorchid.lemis.com (monorchid.lemis.com [192.109.197.75]) by hub.freebsd.org (Postfix) with ESMTP id F130637B416 for ; Fri, 14 Dec 2001 16:36:50 -0800 (PST) Received: by monorchid.lemis.com (Postfix, from userid 1004) id 4A90F786E3; Sat, 15 Dec 2001 11:06:49 +1030 (CST) Date: Sat, 15 Dec 2001 11:06:49 +1030 From: Greg Lehey To: Jonathan Perkin Cc: Garance A Drosihn , freebsd-arch@freebsd.org Subject: Merging / and /usr (was: Changing 'man' to check alternate destination for 'cat' pages) Message-ID: <20011215110649.J85108@monorchid.lemis.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011213101401.C77774@sunbay.com> <20011214150950.A12728@inet34.rd.bbc.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011214150950.A12728@inet34.rd.bbc.co.uk> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, 14 December 2001 at 15:09:50 +0000, Jonathan Perkin wrote: > On Fri Dec 14, 2001 at 12:21:25AM -0500, Garance A Drosihn wrote: > >> Someone else then mentioned that if /usr *is* a part of '/', then we >> don't have to statically-build all the binaries in /bin or /sbin. It >> was noted that this saves several megabytes in the size of the system, >> and that such savings are welcome in some situations (embedded systems, >> older machines, etc). > > As long as this isn't made the default. It's lovely to be free to be > able to rm -rf /usr/{bin|sbin|lib*} etc and still have all the tools > in /bin and /sbin available for recovery purposes. That's an interesting consideration, but it's not directly related to having /usr and / on the same file system. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 17:20:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 95D7637B419 for ; Fri, 14 Dec 2001 17:20:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011215012013.HEYO403.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 15 Dec 2001 01:20:13 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA23107; Fri, 14 Dec 2001 17:14:32 -0800 (PST) Date: Fri, 14 Dec 2001 17:14:31 -0800 (PST) From: Julian Elischer To: Kenneth Wayne Culver Cc: arch@FreeBSD.ORG Subject: Re: KSEs and PTRACE/PROCFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 14 Dec 2001, Kenneth Wayne Culver wrote: > I don't know how to do this, but would it be possible to allow a user to > somehow pick a thread if he/she wanted to? That would be most useful... > > Ken A Not very easily, but let's examine.... A user would want to trace a single thread in the program, but threads inside the userland part of the program are invisible to the kernel. It supplies some contexts to allow the userland scheduler to run things in parallel, but it doesn;t know which userland thread is being multiplexed onto which kernel thread. The kernel threads are 'created' when the program enters the kernel, and 'destroyed' when the system call completes. (not really, they are cached) so one thread in userland will hop from one kernel thread to another at great speed. The kernel actually has ACCESS to a key that might indicate the user thread running (this just occured to me) (the syscall return status block shuld be 'per user thread'), but even using that, it doesn't know how to associate that number with a given thread. Now assuming we got past this, what would be the desired behaviour? One thread single steps and all others proceed at normal speed? all other threads suspended? what of threads in another KSE group? (different scheduler class) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 19:15: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 0822737B416; Fri, 14 Dec 2001 19:14:58 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 7D1011D169; Sat, 15 Dec 2001 03:14:55 +0000 (GMT) Date: Sat, 15 Dec 2001 03:14:55 -0000 From: Paul Richards To: Mike Smith , arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <12520000.1008386095@lobster.originative.co.uk> In-Reply-To: <200111272301.fARN1nj04294@mass.dis.org> References: <200111272301.fARN1nj04294@mass.dis.org> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Tuesday, November 27, 2001 15:01:49 -0800 Mike Smith wrote: >> I'd also point out that devfsd, in my world view, dealt with dev_t, >> while devd dealt with device_t. > > I think the problem here is that the line is being drawn in the wrong > place. > > Yes, there are a group of different things which need to be considered; > responses to new devices, new device nodes, new media, etc. > > However, all of these group under the single heading of "dynamic > changes in system configuration". And it would be highly desirable to > group the policies that react to these changes in a single place, and > manage them with a single tool. > > The alternative is a confusing mess. > > So, yes, we want a generic event-responsive architecture. And yes, we > need to be able to script the responses to these events accordingly. And > whether we call this facility "devd" or "devfsd" or "theamazingmancinid" > is IMO immaterial. I wanted to call it eventd :-) > There are a couple of well-understood sets of event-response sets already: > > - new dev_t > - new device_t > - new media / media ejection request > > and probably several more that I've left out. Let's quite the If eventd is a generic handler for all kernel events then all sorts of things can be hooked into it. What would be needed is an api call in the kernel to signal an event and then any part of the kernel would have a mechanism to cause an userland action to occur. I think focussing the design around device type events would be a big mistake in the long run. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 14 19:51:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id A37FF37B41A for ; Fri, 14 Dec 2001 19:51:54 -0800 (PST) Received: (qmail 3985 invoked from network); 15 Dec 2001 03:51:43 -0000 Received: from ken.yumyumyum.org (HELO there) (192.168.0.2) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 15 Dec 2001 03:51:43 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Kenneth Culver To: Julian Elischer Subject: Re: KSEs and PTRACE/PROCFS Date: Fri, 14 Dec 2001 22:51:56 -0500 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: Cc: arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011215035154.A37FF37B41A@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday 14 December 2001 08:14 pm, you wrote: > On Fri, 14 Dec 2001, Kenneth Wayne Culver wrote: > > I don't know how to do this, but would it be possible to allow a user to > > somehow pick a thread if he/she wanted to? That would be most useful... > > > > Ken > > A Not very easily, but let's examine.... > > A user would want to trace a single thread in the program, but threads > inside the userland part of the program are invisible to the kernel. It > supplies some contexts to allow the userland scheduler to run things in > parallel, but it doesn;t know which userland thread is being multiplexed > onto which kernel thread. The kernel threads are 'created' when the > program enters the kernel, and 'destroyed' when the system call completes. > (not really, they are cached) so one thread in userland will hop from one > kernel thread to another at great speed. > > The kernel actually has ACCESS to a key that might indicate the > user thread running (this just occured to me) (the syscall return status > block shuld be 'per user thread'), but even using that, it doesn't know > how to associate that number with a given thread. > > Now assuming we got past this, what would be the desired behaviour? > > One thread single steps and all others proceed at normal speed? > all other threads suspended? > what of threads in another KSE group? (different scheduler class) well, I would think that the threads that don't rely on data from the currently stopped thread should stop, just the thread that I want to stop should stop, along with any threads that rely on data from that thread... is that possible? I would also think that threads in a different KSE group could keep running given the same conditions.... as long as no threads there rely on data from the thread you stopped, I guess they could keep going... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 15 7:36:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ms51.hinet.net (ms51.hinet.net [168.95.4.51]) by hub.freebsd.org (Postfix) with ESMTP id 9CEAD37B419; Sat, 15 Dec 2001 07:35:34 -0800 (PST) Received: from u6o9v0 (61-216-40-84.HINET-IP.hinet.net [61.216.40.84]) by ms51.hinet.net (8.8.8/8.8.8) with SMTP id XAA09762; Sat, 15 Dec 2001 23:22:52 +0800 (CST) Message-Id: <200112151522.XAA09762@ms51.hinet.net> From: "dream" To: Subject: 行愛的真諦--敲天堂的門 Mime-Version: 1.0 Content-Type: text/html; charset="big5" Date: Sat, 15 Dec 2001 23:25:02 +0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

  • English

      

            

      行愛的真諦  敲天堂的門

     

     

    愛是恆久忍耐，又有恩慈，愛是不嫉妒。愛是不自誇，不張狂，不做害羞的事。不求自己的益處，不輕易發怒，不計算人家的惡，不喜歡不義，只喜歡真理。凡事包容，凡事相信，凡事盼望，凡事忍耐，凡事要忍耐，愛是永不止息。

     

      

       「愛的真諦」是聖經中的一段話，經人整理後，譜成一曲舒緩動聽的人間之歌。這首歌從小至今深獲我喜愛，印象中是在小學合唱團學的。她那優美柔和的旋律、內涵豐富的歌詞不但靜默地滋養著我童年的心靈，也陪我度過了無數個人生的挫折與考驗，當我遭逢苦惱或面對讚揚時，我的心底時常響起這首聖潔無比的歌。

        我常暗自佩服身旁的基督教朋友，因為神要她們做的不只是普通的好人，而是言行俱美、品德高潔的好人中的好人！前一陣子，一位基督教同學的談話，卻給了我一些思考的空間，我突然對她信仰上帝的方式感到有些疑惑。

        她經常熱心地與周圍的人分享神如何愛護他們整個家庭、如何悉心安排她的人生遭遇，真心地訴說著神的無私、偉大與包容。那天聽到她說：「…無論你以前做了什麼不好的事，只要你信祂，祂就會帶領你走向天國。」對方問她：「就這麼簡單嗎？只要我相信祂，就可以上天國嗎？」她回答：「是啊！就是這麼簡單！你看上帝多麼偉大呀！」

         我生長在一個沒有神佛信仰、甚少宗教儀式的家庭裡。儘管在成長過程中，與宗教的接觸非常有限，但是我一直深信，人總該要有屬於自己的信仰，也因此，我便不斷尋找亙古不變的真理。

        因著同學的談話，我再一次思考人們對於宗教的認知。人真的了解神的旨意嗎？我想，不管是耶穌或是釋迦牟尼，為了救渡世人而傳道講法時，應該沒有說過自己是基督教或是佛教吧！當我認識到宗教是後人所自創的名詞，儀式也是因著時空背景所自行建立的人類行為，而非神的旨意，人們信奉、護衛的是宗教形式，而非其中所闡揚的真理，祈求的是自己在世間的各種現實利益時，對於現今諸多宗教亂象也就不那麼摸不著頭緒了。也難怪我的同學會如此天真的以為只在表面上、形式上「信耶穌就得永生」了。

        我認為信不只是精神上的堅守，更是行動上的落實。就如同我們在學校學習一樣，如果我相信只要考進一流高中，就可以包中諸多學子夢寐以求的大學名校，而不在三年的高中生涯中認真聽講，盡力做好一個學生的本分，又怎能實現成為大學新鮮人的美麗夢想呢？正確的思考伴隨積極的行動，不正是成就諸多美事的先決要件嗎？

        我想不管我們來自何方，過著什麼樣的生活，是否擁有宗教信仰，我期盼人們都能將「愛的真諦」的精深內涵與美好德行融入生活點滴之中，做個真正心靈潔淨、道德高尚的好人。

                                    (摘錄自大紀元周報)

     

     

     

    ◎我覺得這是一篇好文章，所以想和更多的人分享，希望沒有打擾到你。若你還喜歡這文章歡迎寫信與我分享， 若你不想再收到類似文章也請回信給我。謝謝你！
                                                                     Fa-yin

      ◎上回電腦當機，有些信不見了，可否請你再寄一次給我。

          ※  This is internet sharing, hope not bothering you. If you can't understand Chinese, please click here reply me, and there will be no  more e-mail from us.  Thank you!

    To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 15 13:32: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 6C74637B405; Sat, 15 Dec 2001 13:32:03 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBFLVP8101742; Sat, 15 Dec 2001 16:31:25 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011214101857.C35094@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011214112255.L3448@monorchid.lemis.com> <20011214101857.C35094@sunbay.com> Date: Sat, 15 Dec 2001 16:31:23 -0500 To: Ruslan Ermilov , Greg Lehey From: Garance A Drosihn Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Cc: Peter Wemm , Nik Clayton , Warner Losh , ache@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:18 AM +0200 12/14/01, Ruslan Ermilov wrote: > > As regards the cat files, it seems to me that an obvious solution >> would be to add a CATMAN environment variable which would specify the > > location of the catman pages, and default to /usr/share/man/cat. > >Just having a CATMAN envariable is not enough, this would break many >things. There are hosts on which people use different locales >simultaneously. Look at how the usr/share/man/en.ISO8859-1 is >organized nowadays, and realize why, while sharing the man? >directories with the .., it has its own cat? directories. Note that my suggestion does not use an environment variable. What I wanted was something that the system administrator could decide to use, and if the sysadmin did want this, then the decision would effect all users on the system. I do not consider environment variables a good way to set system-wide policies. My thought was that if the administrator did create these new directories under /var/man, then 'man' would always prefer to use those for cat pages. >The "cat" feature of man(1) is insecure, and is probably going to >be nuked after a release of 4.5. Well, if this expected to disappear soon, then that certainly reduces my eagerness to make any changes to it! :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 15 17:33:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 6BB0E37B417 for ; Sat, 15 Dec 2001 17:33:15 -0800 (PST) Received: (qmail 10863 invoked by uid 0); 16 Dec 2001 01:33:13 -0000 Received: from p5086edec.dip.t-dialin.net (HELO forge.local) (80.134.237.236) by mail.gmx.net (mp020-rz3) with SMTP; 16 Dec 2001 01:33:13 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16FQB8-0001yQ-00; Sun, 16 Dec 2001 02:33:22 +0100 Date: Sun, 16 Dec 2001 02:33:21 +0100 From: Thomas Moestl To: Mike Smith Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011216023321.C458@crow.dom2ip.de> Mail-Followup-To: Mike Smith , arch@FreeBSD.org References: <200112140028.fBE0Sol04630@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112140028.fBE0Sol04630@mass.dis.org>; from msmith@freebsd.org on Thu, Dec 13, 2001 at 04:28:50PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2001/12/13 at 16:28:50 -0800, Mike Smith wrote: > > > The PCI_BROKEN_INTPIN/PCI_INTLINE_0_BAD seem to be the same thing; > > > they should be protected by a single name (probably PCI_BROKEN_INTPIN) > > > in the #ifdef in pci.c; it should be "all or nothing" on a single > > > value. As it is, you must define one if you define the other, but > > > not vice versa, and the effect seems to be linked, anyway, so you > > > might as well use a single protection mechanism. > > > > It is not uncommon that i386 BIOSes to set the intline register to 0 > > when it should really be 0xff (to indicate an unrouted interrupt). So, > > I figured that it might be useful to make this an extra option. > > No. Fix the i386-specific config space accessor to convert 0 to 255. > > If you haven't seen the theme here yet; here it is. The MD layers should > correct for platform-specific aberrations in the PCI implementation where > possible. > > Adding compile-time options to MI code which indirectly relate exclusively > to MD PCI issues is just the Wrong Thing to Do. OK, I've attached a new diff. Changes are: - remove PCI_INTLINE_0_BAD - move the code for PCI_BROKEN_INTPIN to MD code, and use a quirk table to identify the devices that need this fixup (I don't really like this change, as I think it is not totally unlikely that the device in question may also be used for other architectures; it is not really specific to sparc64) - revert the changes associated to pci_pci.c, at the cost of duplicating some of the device hierarchy assumptions in the apb driver code - add a diff I had previously forgotten: move the PCI_ENABLE_IO_MODES from conf/options.i386 to conf/options This should remove all the changes you did not like, except the addition to the resource manager. I do not see a good alternative to this last change, and I think I did not fully understand what you did not like about it (taking into consideration the task I am using it for); I'm of course open for further discussion. I would still like to commit this new diff around the 21st, if there are no further objections and I can make it. - thomas --- freebsd/sys/isa/isa_common.c Sat Sep 8 19:46:52 2001 +++ sparc64/sys/isa/isa_common.c Wed Oct 10 00:59:24 2001 @@ -92,7 +92,7 @@ isa_probe(device_t dev) { device_set_desc(dev, "ISA bus"); - isa_init(); /* Allow machdep code to initialise */ + isa_init(dev); /* Allow machdep code to initialise */ return 0; } @@ -634,37 +634,6 @@ } static int -isa_print_resources(struct resource_list *rl, const char *name, int type, - int count, const char *format) -{ - struct resource_list_entry *rle; - int printed; - int i, retval = 0;; - - printed = 0; - for (i = 0; i < count; i++) { - rle = resource_list_find(rl, type, i); - if (rle) { - if (printed == 0) - retval += printf(" %s ", name); - else if (printed > 0) - retval += printf(","); - printed++; - retval += printf(format, rle->start); - if (rle->count > 1) { - retval += printf("-"); - retval += printf(format, - rle->start + rle->count - 1); - } - } else if (i > 3) { - /* check the first few regardless */ - break; - } - } - return retval; -} - -static int isa_print_all_resources(device_t dev) { struct isa_device *idev = DEVTOISA(dev); @@ -674,14 +643,10 @@ if (SLIST_FIRST(rl) || device_get_flags(dev)) retval += printf(" at"); - retval += isa_print_resources(rl, "port", SYS_RES_IOPORT, - ISA_NPORT, "%#lx"); - retval += isa_print_resources(rl, "iomem", SYS_RES_MEMORY, - ISA_NMEM, "%#lx"); - retval += isa_print_resources(rl, "irq", SYS_RES_IRQ, - ISA_NIRQ, "%ld"); - retval += isa_print_resources(rl, "drq", SYS_RES_DRQ, - ISA_NDRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); + retval += resource_list_print_type(rl, "iomem", SYS_RES_MEMORY, "%#lx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); + retval += resource_list_print_type(rl, "drq", SYS_RES_DRQ, "%ld"); if (device_get_flags(dev)) retval += printf(" flags %#x", device_get_flags(dev)); --- freebsd/sys/isa/isa_common.h Sat Sep 8 19:46:52 2001 +++ sparc64/sys/isa/isa_common.h Wed Oct 10 00:59:27 2001 @@ -65,7 +65,7 @@ /* * These functions are architecture dependant. */ -extern void isa_init(void); +extern void isa_init(device_t dev); extern struct resource *isa_alloc_resource(device_t bus, device_t child, int type, int *rid, u_long start, u_long end, --- freebsd/sys/dev/pci/pci.c Sun Nov 4 01:39:41 2001 +++ sparc64/sys/dev/pci/pci.c Sat Dec 15 18:14:45 2001 @@ -78,9 +78,6 @@ device_t dev); static void pci_add_children(device_t dev, int busno); static int pci_probe(device_t dev); -static int pci_print_resources(struct resource_list *rl, - const char *name, int type, - const char *format); static int pci_print_child(device_t dev, device_t child); static void pci_probe_nomatch(device_t dev, device_t child); static int pci_describe_parse_line(char **ptr, int *vendor, @@ -831,34 +828,6 @@ } static int -pci_print_resources(struct resource_list *rl, const char *name, int type, - const char *format) -{ - struct resource_list_entry *rle; - int printed, retval; - - printed = 0; - retval = 0; - /* Yes, this is kinda cheating */ - SLIST_FOREACH(rle, rl, link) { - if (rle->type == type) { - if (printed == 0) - retval += printf(" %s ", name); - else if (printed > 0) - retval += printf(","); - printed++; - retval += printf(format, rle->start); - if (rle->count > 1) { - retval += printf("-"); - retval += printf(format, rle->start + - rle->count - 1); - } - } - } - return retval; -} - -static int pci_print_child(device_t dev, device_t child) { struct pci_devinfo *dinfo; @@ -872,9 +841,9 @@ retval += bus_print_child_header(dev, child); - retval += pci_print_resources(rl, "port", SYS_RES_IOPORT, "%#lx"); - retval += pci_print_resources(rl, "mem", SYS_RES_MEMORY, "%#lx"); - retval += pci_print_resources(rl, "irq", SYS_RES_IRQ, "%ld"); + retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx"); + retval += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#lx"); + retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld"); if (device_get_flags(dev)) retval += printf(" flags %#x", device_get_flags(dev)); --- freebsd/sys/dev/pci/pcivar.h Sun Aug 5 19:55:43 2001 +++ sparc64/sys/dev/pci/pcivar.h Wed Oct 10 00:59:22 2001 @@ -182,20 +182,8 @@ /* * Simplified accessors for pci devices */ -#define PCI_ACCESSOR(A, B, T) \ - \ -static __inline T pci_get_ ## A(device_t dev) \ -{ \ - uintptr_t v; \ - BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_ ## B, &v); \ - return (T) v; \ -} \ - \ -static __inline void pci_set_ ## A(device_t dev, T t) \ -{ \ - uintptr_t v = (uintptr_t) t; \ - BUS_WRITE_IVAR(device_get_parent(dev), dev, PCI_IVAR_ ## B, v); \ -} +#define PCI_ACCESSOR(var, ivar, type) \ + __BUS_ACCESSOR(pci, var, PCI, ivar, type) PCI_ACCESSOR(subvendor, SUBVENDOR, u_int16_t) PCI_ACCESSOR(subdevice, SUBDEVICE, u_int16_t) --- freebsd/sys/sys/bus.h Sun Nov 4 01:40:09 2001 +++ sparc64/sys/sys/bus.h Sun Nov 4 01:14:54 2001 @@ -180,6 +180,14 @@ int type, int rid, struct resource *res); /* + * Print all resources of a specified type, for use in bus_print_child. + * The name is printed if at least one resource of the given type is available. + * The format ist used to print resource start and end. + */ +int resource_list_print_type(struct resource_list *rl, + const char *name, int type, + const char *format); +/* * The root bus, to which all top-level busses are attached. */ extern device_t root_bus; @@ -410,6 +418,26 @@ }; \ DECLARE_MODULE(name##_##busname, name##_##busname##_mod, \ SI_SUB_DRIVERS, SI_ORDER_MIDDLE) + +/* + * Generic ivar accessor generation macros for bus drivers + */ +#define __BUS_ACCESSOR(varp, var, ivarp, ivar, type) \ + \ +static __inline type varp ## _get_ ## var(device_t dev) \ +{ \ + uintptr_t v; \ + BUS_READ_IVAR(device_get_parent(dev), dev, \ + ivarp ## _IVAR_ ## ivar, &v); \ + return ((type) v); \ +} \ + \ +static __inline void varp ## _set_ ## var(device_t dev, type t) \ +{ \ + uintptr_t v = (uintptr_t) t; \ + BUS_WRITE_IVAR(device_get_parent(dev), dev, \ + ivarp ## _IVAR_ ## ivar, v); \ +} #endif /* _KERNEL */ --- freebsd/sys/sys/rman.h Sat Sep 8 19:53:09 2001 +++ sparc64/sys/sys/rman.h Thu Nov 22 23:54:27 2001 @@ -126,6 +126,9 @@ struct resource *rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, u_int flags, struct device *dev); +struct resource *rman_reserve_resource_bound(struct rman *rm, u_long start, + u_long end, u_long count, u_long bound, + u_int flags, struct device *dev); uint32_t rman_make_alignment_flags(uint32_t size); #define rman_get_start(r) ((r)->r_start) --- freebsd/sys/kern/subr_bus.c Mon Dec 10 20:44:39 2001 +++ sparc64/sys/kern/subr_bus.c Thu Dec 13 04:06:25 2001 @@ -1207,8 +1207,8 @@ if (isdefault) { start = rle->start; - count = max(count, rle->count); - end = max(rle->end, start + count - 1); + count = ulmax(count, rle->count); + end = ulmax(rle->end, start + count - 1); } rle->res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, @@ -1253,6 +1253,34 @@ rle->res = NULL; return (0); +} + +int +resource_list_print_type(struct resource_list *rl, const char *name, int type, + const char *format) +{ + struct resource_list_entry *rle; + int printed, retval; + + printed = 0; + retval = 0; + /* Yes, this is kinda cheating */ + SLIST_FOREACH(rle, rl, link) { + if (rle->type == type) { + if (printed == 0) + retval += printf(" %s ", name); + else + retval += printf(","); + printed++; + retval += printf(format, rle->start); + if (rle->count > 1) { + retval += printf("-"); + retval += printf(format, rle->start + + rle->count - 1); + } + } + } + return retval; } /* --- freebsd/sys/kern/subr_rman.c Sun Nov 25 14:51:37 2001 +++ sparc64/sys/kern/subr_rman.c Thu Nov 22 23:54:25 2001 @@ -175,12 +175,13 @@ } struct resource * -rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, - u_int flags, struct device *dev) +rman_reserve_resource_bound(struct rman *rm, u_long start, u_long end, + u_long count, u_long bound, u_int flags, + struct device *dev) { u_int want_activate; struct resource *r, *s, *rv; - u_long rstart, rend; + u_long rstart, rend, amask, bmask; rv = 0; @@ -202,6 +203,9 @@ goto out; } + amask = (1ul << RF_ALIGNMENT(flags)) - 1; + /* If bound is 0, bmask will also be 0 */ + bmask = ~(bound - 1); /* * First try to find an acceptable totally-unshared region. */ @@ -215,10 +219,19 @@ DPRINTF(("region is allocated\n")); continue; } - rstart = max(s->r_start, start); - rstart = (rstart + ((1ul << RF_ALIGNMENT(flags))) - 1) & - ~((1ul << RF_ALIGNMENT(flags)) - 1); - rend = min(s->r_end, max(rstart + count, end)); + rstart = ulmax(s->r_start, start); + /* + * Try to find a region by adjusting to boundary and alignment + * until both conditions are satisfied. This is not an optimal + * algorithm, but in most cases it isn't really bad, either. + */ + do { + rstart = (rstart + amask) & ~amask; + if (((rstart ^ (rstart + count)) & bmask) != 0) + rstart += bound - (rstart & ~bmask); + } while ((rstart & amask) != 0 && rstart < end && + rstart < s->r_end); + rend = ulmin(s->r_end, ulmax(rstart + count, end)); DPRINTF(("truncated region: [%#lx, %#lx]; size %#lx (requested %#lx)\n", rstart, rend, (rend - rstart + 1), count)); @@ -313,10 +326,12 @@ break; if ((s->r_flags & flags) != flags) continue; - rstart = max(s->r_start, start); - rend = min(s->r_end, max(start + count, end)); + rstart = ulmax(s->r_start, start); + rend = ulmin(s->r_end, ulmax(start + count, end)); if (s->r_start >= start && s->r_end <= end - && (s->r_end - s->r_start + 1) == count) { + && (s->r_end - s->r_start + 1) == count && + (s->r_start & amask) == 0 && + ((s->r_start ^ s->r_end) & bmask) == 0) { rv = malloc(sizeof *rv, M_RMAN, M_NOWAIT | M_ZERO); if (rv == 0) goto out; @@ -368,6 +383,15 @@ return (rv); } +struct resource * +rman_reserve_resource(struct rman *rm, u_long start, u_long end, u_long count, + u_int flags, struct device *dev) +{ + + return (rman_reserve_resource_bound(rm, start, end, count, 0, flags, + dev)); +} + static int int_rman_activate_resource(struct rman *rm, struct resource *r, struct resource **whohas) @@ -575,7 +599,7 @@ * Find the hightest bit set, and add one if more than one bit * set. We're effectively computing the ceil(log2(size)) here. */ - for (i = 32; i > 0; i--) + for (i = 31; i > 0; i--) if ((1 << i) & size) break; if (~(1 << i) & size) --- freebsd/sys/i386/isa/isa.c Fri Oct 12 16:18:20 2001 +++ sparc64/sys/i386/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -68,7 +68,7 @@ #include void -isa_init(void) +isa_init(device_t dev) { } --- freebsd/sys/ia64/isa/isa.c Sun Aug 5 20:05:14 2001 +++ sparc64/sys/ia64/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -69,7 +69,7 @@ #include void -isa_init(void) +isa_init(device_t dev) { } --- freebsd/sys/alpha/isa/isa.c Sun Aug 5 19:43:26 2001 +++ sparc64/sys/alpha/isa/isa.c Thu Dec 13 17:53:29 2001 @@ -94,7 +94,7 @@ } void -isa_init(void) +isa_init(device_t dev) { isa_init_intr(); } --- freebsd/sys/conf/options.i386 Fri Dec 14 23:26:25 2001 +++ sparc64/sys/conf/options.i386 Sat Dec 15 18:14:45 2001 @@ -107,8 +107,6 @@ PSM_RESETAFTERSUSPEND opt_psm.h PSM_DEBUG opt_psm.h -PCI_ENABLE_IO_MODES opt_pci.h - PCIC_RESUME_RESET opt_pcic.h ATKBD_DFLT_KEYMAP opt_atkbd.h --- freebsd/sys/conf/options Sun Nov 25 14:51:22 2001 +++ sparc64/sys/conf/options Sat Dec 15 18:14:45 2001 @@ -416,6 +419,7 @@ # PCI related options PCI_QUIET opt_pci.h +PCI_ENABLE_IO_MODES opt_pci.h # NFS options NFS_MINATTRTIMO opt_nfs.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 15 18:22: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C04E837B41A for ; Sat, 15 Dec 2001 18:22:04 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fBG2M1b15584; Sat, 15 Dec 2001 21:22:01 -0500 (EST) (envelope-from wollman) Date: Sat, 15 Dec 2001 21:22:01 -0500 (EST) From: Garrett Wollman Message-Id: <200112160222.fBG2M1b15584@khavrinen.lcs.mit.edu> To: tmoestl@gmx.net Subject: Re: Please review: changes to MI bus code for sparc64 In-Reply-To: <20011216023321.C458@crow.dom2ip.de> References: <200112140028.fBE0Sol04630@mass.dis.org> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20011216023321.C458@crow.dom2ip.de>, Thomas Moestl wrote: >This should remove all the changes you did not like, except the >addition to the resource manager. I do not see a good alternative to >this last change, and I think I did not fully understand what you did >not like about it (taking into consideration the task I am using it >for); I'm of course open for further discussion. It was always my intent that the resource manager be able to deal with alignment and boundary constraints -- or indeed, entirely arbitrary constraints. I dropped that support early on in the process of implementation because it made things more complex than I absolutely needed in order to get things working on the i386. (The resource manager should be able to represent any resource that the busdma API needs.) Probably there should be a separate interface, rman_alloc_resource_callback(), which uses its callback parameter to validate potential allocations. (The callback can return an integer suggesting how far ahead to skip before trying the next allocation -- hopefully most architectures which need this will be making mostly conveniently-aligned requests.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message