From owner-freebsd-arch Sun Oct 10 0:21:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2DE6F14BCA for ; Sun, 10 Oct 1999 00:20:22 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id JAA15235 for ; Sun, 10 Oct 1999 09:20:20 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA56738 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 09:20:19 +0200 (MET DST) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133]) by hub.freebsd.org (Postfix) with ESMTP id 70483154DC; Sun, 10 Oct 1999 00:19:37 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA45890; Sun, 10 Oct 1999 09:19:29 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199910100719.JAA45890@gratis.grondar.za> To: Nik Clayton Cc: Chuck Robey , Eivind Eklund , "Daniel C. Sobral" , Bruce Evans , committers@freebsd.org, arch@freebsd.org Subject: Re: /etc/make.conf abuse Date: Sun, 10 Oct 1999 09:19:28 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One snag with that. Sometimes a remedy for fixing a build problem is > > # rm -rf /usr/src > > and start again. I know that's probably ingrained in a lot of people's > fingers, and they treat /usr/src as an expendable file system. Suddenly > we'll be putting a config file there. Well, doing that will also blow awayt your carefully crafted KERNEL file. That's why I put my kernel file into /usr//KERNEL and set a symlink so that blow-aways dont burn me. Perhaps the //make.conf could use something similar? > Perhaps /usr/local/etc/make.conf would be better? Or at least a variable > (which can be defined in /etc/make.conf) which points to the file, so that > the admin can easily set local policy. I dont like the use of /usr/local for this; that is ports' property. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 3:13:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F402D15937 for ; Sun, 10 Oct 1999 03:12:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA16098 for ; Sun, 10 Oct 1999 12:12:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA57184 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 12:12:43 +0200 (MET DST) Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id 718E71507B; Sun, 10 Oct 1999 03:12:28 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.197.156]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA37D6; Sun, 10 Oct 1999 12:12:26 +0200 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id MAA41256; Sun, 10 Oct 1999 12:11:03 +0200 (CEST) (envelope-from asmodai) Date: Sun, 10 Oct 1999 12:11:03 +0200 From: Jeroen Ruigrok/Asmodai To: Mark Murray Cc: Nik Clayton , Chuck Robey , Eivind Eklund , "Daniel C. Sobral" , Bruce Evans , committers@freebsd.org, arch@freebsd.org Subject: Re: /etc/make.conf abuse Message-ID: <19991010121103.B41010@daemon.ninth-circle.org> References: <199910100719.JAA45890@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <199910100719.JAA45890@gratis.grondar.za> Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On [19991010 12:00], Mark Murray (mark@grondar.za) wrote: >> One snag with that. Sometimes a remedy for fixing a build problem is >> >> # rm -rf /usr/src >> >> and start again. I know that's probably ingrained in a lot of people's >> fingers, and they treat /usr/src as an expendable file system. Suddenly >> we'll be putting a config file there. > >Well, doing that will also blow awayt your carefully crafted >KERNEL file. That's why I put my kernel file into /usr//KERNEL >and set a symlink so that blow-aways dont burn me. Perhaps the >//make.conf could use something similar? Reasoning behind this: if you don't want sources [/usr/src] you also do not need a kernel configuration file, a make configuration script which tunes make world to your tastes and what not else. IMHO, should we split make.conf out into other files for /usr/src I think we truely need to move it in /usr/src itself. >> Perhaps /usr/local/etc/make.conf would be better? Or at least a variable >> (which can be defined in /etc/make.conf) which points to the file, so that >> the admin can easily set local policy. > >I dont like the use of /usr/local for this; that is ports' property. Agreed. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Is this all there is of me..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 9:30:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 432DF15784 for ; Sun, 10 Oct 1999 09:28:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA18566 for ; Sun, 10 Oct 1999 18:28:14 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA00265 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 18:27:31 +0200 (MET DST) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9B03214C8E for ; Sun, 10 Oct 1999 08:56:39 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p06-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.135]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id AAA16468; Mon, 11 Oct 1999 00:56:15 +0900 (JST) Message-ID: <38007A78.4388F2B7@newsguy.com> Date: Sun, 10 Oct 1999 20:37:28 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: John Birrell Cc: Chuck Robey , Garrett Wollman , arch@freebsd.org Subject: Re: /etc/make.conf abuse References: <19991010115346.A374@freebsd1.cimlogic.com.au> <19991010142207.B374@freebsd1.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > Since sys.mk is the _only_ file that `make' knows about, you shouldn't > have anything FreeBSD-specific in there. That includes /etc/make.conf > IMO. The first time that `make' sees something that is part of a FreeBSD > build is when it reads the Makefile that you ask it to parse. Any > FreeBSD-specific gunk should be included only as a result of parsing > a FreeBSD Makefile. It doesn't matter what you call the file in which > you do your FreeBSD build adjustments, or where you put it, just don't > include it from sys.mk. [ I think this means that you end up having to > include some FreeBSD specific at the beginning of every Makefile, which > is probably why the "abuse" lives on. ] The abuse, in this case, is not pollution of make rules with FreeBSD-specific stuff. It's pollution of everything with world-specific stuff. > As far as "global make adjustments" that are not part of a FreeBSD build > are concerned -- I don't think there are any. After all, what is there to > configure about `make' itself? CC? CFLAGS? Just examples. /etc/make.conf is not even an intuitive place for things like NOPERL5_SUID (sp?) & cia. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 9:30:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D961D158BE for ; Sun, 10 Oct 1999 09:28:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA18580 for ; Sun, 10 Oct 1999 18:28:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA00498 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 18:27:50 +0200 (MET DST) Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id AA992154C9; Sun, 10 Oct 1999 06:52:41 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id NAA58486; Sun, 10 Oct 1999 13:00:53 +0100 (BST) (envelope-from nik) Date: Sun, 10 Oct 1999 13:00:53 +0100 From: Nik Clayton To: Chuck Robey Cc: Nik Clayton , Eivind Eklund , "Daniel C. Sobral" , Bruce Evans , committers@freebsd.org, arch@freebsd.org Subject: Re: /etc/make.conf abuse Message-ID: <19991010130052.A58116@catkin.nothing-going-on.org> References: <19991009175403.A54620@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Chuck Robey on Sat, Oct 09, 1999 at 04:53:24PM -0400 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc'd to the list, the moderator can decide whether or not it's still appropriate] On Sat, Oct 09, 1999 at 04:53:24PM -0400, Chuck Robey wrote: > > One snag with that. Sometimes a remedy for fixing a build problem is > > > > # rm -rf /usr/src > > > > and start again. > Where do you stick your kernel config files? I have mine in sys/i386/conf > (for my i386 machine), I used to. And then I fumbled once too often, and now they're in /root/kernels, with symlinks out of sys/i386/conf pointing back to them. It's one less thing I have to worry about when upgrading my system. N To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 9:30:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0372215915 for ; Sun, 10 Oct 1999 09:28:46 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA18585 for ; Sun, 10 Oct 1999 18:28:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA00622 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 18:28:05 +0200 (MET DST) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id AFADC1520E for ; Sun, 10 Oct 1999 04:32:58 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p09-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.138]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA08674; Sun, 10 Oct 1999 20:32:52 +0900 (JST) Message-ID: <380078FD.206F755A@newsguy.com> Date: Sun, 10 Oct 1999 20:31:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Garrett Wollman Cc: arch@freebsd.org Subject: Re: /etc/make.conf abuse References: <37FEDD1B.24FDF38E@newsguy.com> <199910100123.VAA75785@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > < said: > > > I'm inclined to have a /usr/src/make.conf (world.conf? :), included > > by the mk files, with path and name overridable by environment > > variables. > > Compromise: /etc/bsd.conf.mk and (logically or) $(SRCTOP)/conf.mk. I'd rather just have ${SRCTOP}/${SRCCONF}. If people prefer /etc/make.conf, they can leave it as it is right now, and it will continue to work. If they prefer the file in /etc instead of /usr/src, they can set SRCTOP in make.conf. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 9:30:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 09476157AA for ; Sun, 10 Oct 1999 09:28:22 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA18570 for ; Sun, 10 Oct 1999 18:28:22 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA00349 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 18:27:41 +0200 (MET DST) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 03D9E155DE; Sun, 10 Oct 1999 08:25:00 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id LAA20443; Sun, 10 Oct 1999 11:15:33 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sun, 10 Oct 1999 11:14:08 -0400 (EDT) From: Chuck Robey To: Mark Murray Cc: Nik Clayton , Eivind Eklund , "Daniel C. Sobral" , Bruce Evans , committers@freebsd.org, arch@freebsd.org Subject: Re: /etc/make.conf abuse In-Reply-To: <199910100719.JAA45890@gratis.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 10 Oct 1999, Mark Murray wrote: > Well, doing that will also blow awayt your carefully crafted > KERNEL file. That's why I put my kernel file into /usr//KERNEL > and set a symlink so that blow-aways dont burn me. Perhaps the > //make.conf could use something similar? > > > Perhaps /usr/local/etc/make.conf would be better? Or at least a variable > > (which can be defined in /etc/make.conf) which points to the file, so that > > the admin can easily set local policy. > > I dont like the use of /usr/local for this; that is ports' property. Arguing over where it should go is useless, because you'll never get agreement (just look at us) and it's such an easy thing to make moot, by letting the user, in their environment, have a $(MAKE_CONFIG_DIR). I agree with Mark's feelings, but we have to realize that some will think Mark's wrong, and there isn't any good reason to force the issue. Just allow the idea that someone may want to have a config file for their tree builds. The only question is whether that callout ought to be in /usr/src/Makefile or in /usr/share/mk/sys.mk. Since we want to restrict it's application to the tree, I would stick it into src/Makefile. I'd set a .if exists(), and set a default for MAKE_CONFIG_DIR to /usr/src, so that the file wouldn't exist, and the initial effect of the change would be nil. You want some local control, define MAKE_CONFIG_DIR in your environment (heck, you could set that in /etc/make.conf!), and establish the make.conf. If you don't like that name, fine, it's pretty unimportant, so take your choice. *I* get to choose where it goes, and so I get to choose whether I have one or not. ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 13:31:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BD0E914CEA for ; Sun, 10 Oct 1999 13:31:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA20672 for ; Sun, 10 Oct 1999 22:31:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA01818 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 22:31:37 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 26A7714F32; Sun, 10 Oct 1999 13:30:10 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA73061; Sun, 10 Oct 1999 13:26:57 -0700 (PDT) Date: Sun, 10 Oct 1999 13:26:56 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: freebsd-arch@freebsd.org, mckusick@mckusick.com, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I Can't believe this email only produced TWO responses! I would have thought that this wouldhav brought out the chainsaws! Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't work? (the only responders got it via 'core') julian On Sat, 9 Oct 1999, Bruce Evans wrote: > > PHK has been moving steadily in this direction to remove as many > > dependencies within the kernel on block devices as possible. > > The question is, When did the decision to do so become official? > > Never. > > > I don't believe it has been a stated official decision yet and so in order > > to put some clarity into the air over this I'd like to launch a PURELY > > TECHNICAL discussion on the topic. > > > > Here are some starters. > > > > 1/ block device writes have to be synchrnous or the user doesn't get > > write errors. > > Block devices should be implmented properly or the user doesn't get write > errors. > > A proper implementation is quite close. Write errors should be reported > on last-close and on fsync(). They already are as far as I can see, modulo > the bugs that (in -current) VOP_FSYNC() = ffs_fsync() sometimes hangs > instead of returning a write error and vinvalbuf() sometimes panics instead > of returning a write error. The bugs are different and worse in RELENG_3. > The bugs are different and more benign in RELENG_2_2 (write errors are > ignored). Note that the bugs have very little to do with specfs. All > specfs can reasonably do is kill the endless retries at a suitable time, > probably after calling vinvalbuf() in last-close. > > > 1A/ if they are not synchronous, errors need to be coped with in some > > other manner. > > Normal error handling suffices, modulo bugs. > > > 2/ People with old UNIX experience expect to be able to do unalligned > > transfers on block devices. > > 3/ DEVFS can cope just fine with block and char devices > > (I include this because DEVFS has been used as an argument for > > removing them) > > Correct. > > > 4/ Most of the block buffering code in the kernel will remain due to > > the VM and VFS systems. > > Well, if the Nth rewrite of vm wants to drop support for buffers in vfs, > then use of buffers for block devices shouldn't stop it. > > > 5/ New users don't tend to understand the rather strange distinctions > > between BLK and CHR devices. Some people consider having both POLA and > > This is an argument for removing character (disk) devices, since most > new users will be from Linux where block (disk) devices were the only > ones available until recently. Block devices have always worked better > in Linux. E.g., media change is detected for floppies, and buffers > remain valid across last-close, until media change. The latter behaviour > can be not what is wanted (extra ioctls are needed to discard the buffers), > but it is often useful. > > > others consider having only one POLA. Linux had til just recently, > > only BLK disk devices. They just aded CHR disk devices but I don't > > know if they created a whole second calss of device to do so. (I doubt it) > > 6/ It should be possible to make an overlay device (similar to the way > > ccd works), that supplies buffered characteristics to a disk. This may > > be a different minor number or a differnt major number.. but be a CHR > > type device. > > This would involve needless duplicatication of half of the buffer cache > implementation (maybe the simple half) unless the buffer cache goes away. > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 13:59:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C15F215646 for ; Sun, 10 Oct 1999 13:59:31 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA20888 for ; Sun, 10 Oct 1999 22:59:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA02013 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 22:59:30 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id E92A815657; Sun, 10 Oct 1999 13:58:38 -0700 (PDT) From: "Jonathan M. Bresler" To: julian@whistle.com Cc: bde@zeta.org.au, freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org In-reply-to: (message from Julian Elischer on Sun, 10 Oct 1999 13:26:56 -0700 (PDT)) Subject: Re: The eventual fate of BLOCK devices. Message-Id: <19991010205838.E92A815657@hub.freebsd.org> Date: Sun, 10 Oct 1999 13:58:38 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I Can't believe this email only produced TWO responses! > I would have thought that this wouldhav brought out the chainsaws! > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > work? (the only responders got it via 'core') > > > julian headers say that -arch works. yes, it is supposed to go thru eivind@bitbox.follo.net. jmb Return-Path: Received: by hub.freebsd.org (Postfix, from userid 538) id B3E3814FE2; Sun, 10 Oct 1999 13:31:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 9B0D31CD47B; Sun, 10 Oct 1999 13:31:57 -0700 (PDT) (envelope-from owner-freebsd-arch) Received: by hub.freebsd.org (bulk_mailer v1.12); Sun, 10 Oct 1999 13:31:57 -07\ 00 Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BD0E914CEA for ; Sun, 10 Oct 1999 13:31:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA20672 for ; Sun, 10 Oct 1999 22:31:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA01818 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 22:31:37 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 26A7714F32; Sun, 10 Oct 1999 13:30:10 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA73061; Sun, 10 Oct 1999 13:26:57 -0700 (PDT) Date: Sun, 10 Oct 1999 13:26:56 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: freebsd-arch@freebsd.org, mckusick@mckusick.com, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG X-Loop: FreeBSD.ORG Precedence: bulk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 13:59:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 87E4115333 for ; Sun, 10 Oct 1999 13:59:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA20883 for ; Sun, 10 Oct 1999 22:59:30 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA01999 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 22:59:29 +0200 (MET DST) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1900915036; Sun, 10 Oct 1999 13:58:05 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id OAA06730; Sun, 10 Oct 1999 14:57:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA11530; Sun, 10 Oct 1999 14:57:55 -0600 Date: Sun, 10 Oct 1999 14:57:55 -0600 Message-Id: <199910102057.OAA11530@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Bruce Evans , freebsd-arch@freebsd.org, mckusick@mckusick.com, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I Can't believe this email only produced TWO responses! > I would have thought that this wouldhav brought out the chainsaws! > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > work? (the only responders got it via 'core') Interesting. It appears that somehow I got 'unsubscribed' from arch. Not sure why, but in May I was subscribed, but I'm no longer subscribed. Did everyone get unsubscribed when it went idle? (I'm not commenting on the content as I haven't done enough research to agree/disagree with anything yet.) Nate > > julian > > On Sat, 9 Oct 1999, Bruce Evans wrote: > > > > PHK has been moving steadily in this direction to remove as many > > > dependencies within the kernel on block devices as possible. > > > The question is, When did the decision to do so become official? > > > > Never. > > > > > I don't believe it has been a stated official decision yet and so in order > > > to put some clarity into the air over this I'd like to launch a PURELY > > > TECHNICAL discussion on the topic. > > > > > > Here are some starters. > > > > > > 1/ block device writes have to be synchrnous or the user doesn't get > > > write errors. > > > > Block devices should be implmented properly or the user doesn't get write > > errors. > > > > A proper implementation is quite close. Write errors should be reported > > on last-close and on fsync(). They already are as far as I can see, modulo > > the bugs that (in -current) VOP_FSYNC() = ffs_fsync() sometimes hangs > > instead of returning a write error and vinvalbuf() sometimes panics instead > > of returning a write error. The bugs are different and worse in RELENG_3. > > The bugs are different and more benign in RELENG_2_2 (write errors are > > ignored). Note that the bugs have very little to do with specfs. All > > specfs can reasonably do is kill the endless retries at a suitable time, > > probably after calling vinvalbuf() in last-close. > > > > > 1A/ if they are not synchronous, errors need to be coped with in some > > > other manner. > > > > Normal error handling suffices, modulo bugs. > > > > > 2/ People with old UNIX experience expect to be able to do unalligned > > > transfers on block devices. > > > 3/ DEVFS can cope just fine with block and char devices > > > (I include this because DEVFS has been used as an argument for > > > removing them) > > > > Correct. > > > > > 4/ Most of the block buffering code in the kernel will remain due to > > > the VM and VFS systems. > > > > Well, if the Nth rewrite of vm wants to drop support for buffers in vfs, > > then use of buffers for block devices shouldn't stop it. > > > > > 5/ New users don't tend to understand the rather strange distinctions > > > between BLK and CHR devices. Some people consider having both POLA and > > > > This is an argument for removing character (disk) devices, since most > > new users will be from Linux where block (disk) devices were the only > > ones available until recently. Block devices have always worked better > > in Linux. E.g., media change is detected for floppies, and buffers > > remain valid across last-close, until media change. The latter behaviour > > can be not what is wanted (extra ioctls are needed to discard the buffers), > > but it is often useful. > > > > > others consider having only one POLA. Linux had til just recently, > > > only BLK disk devices. They just aded CHR disk devices but I don't > > > know if they created a whole second calss of device to do so. (I doubt it) > > > 6/ It should be possible to make an overlay device (similar to the way > > > ccd works), that supplies buffered characteristics to a disk. This may > > > be a different minor number or a differnt major number.. but be a CHR > > > type device. > > > > This would involve needless duplicatication of half of the buffer cache > > implementation (maybe the simple half) unless the buffer cache goes away. > > > > Bruce > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 14:31: 4 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D1092150C8 for ; Sun, 10 Oct 1999 14:30:59 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA21141 for ; Sun, 10 Oct 1999 23:30:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA02290 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 23:30:58 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id EAEC114C0A; Sun, 10 Oct 1999 14:30:01 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA74227; Sun, 10 Oct 1999 14:27:59 -0700 (PDT) Date: Sun, 10 Oct 1999 14:27:59 -0700 (PDT) From: Julian Elischer To: "Jonathan M. Bresler" Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <19991010205838.E92A815657@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I sent that one via freebsd-arch instead of 'arch'. did you get the original? On Sun, 10 Oct 1999, Jonathan M. Bresler wrote: > > > > I Can't believe this email only produced TWO responses! > > I would have thought that this wouldhav brought out the chainsaws! > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > > work? (the only responders got it via 'core') > > > > > > julian > > headers say that -arch works. yes, it is supposed to go thru > eivind@bitbox.follo.net. > > jmb > > Return-Path: > Delivered-To: jmb@freebsd.org > Received: by hub.freebsd.org (Postfix, from userid 538) > id B3E3814FE2; Sun, 10 Oct 1999 13:31:57 -0700 (PDT) > Received: from localhost (localhost [127.0.0.1]) > by hub.freebsd.org (Postfix) with SMTP > id 9B0D31CD47B; Sun, 10 Oct 1999 13:31:57 -0700 (PDT) > (envelope-from owner-freebsd-arch) > Received: by hub.freebsd.org (bulk_mailer v1.12); Sun, 10 Oct 1999 > 13:31:57 -07\ > 00 > Delivered-To: freebsd-arch@freebsd.org > Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) > by hub.freebsd.org (Postfix) with ESMTP id BD0E914CEA > for ; Sun, 10 Oct 1999 13:31:54 > -0700 (PDT) > (envelope-from eivind@bitbox.follo.net) > Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) > by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA20672 > for ; Sun, 10 Oct 1999 22:31:53 > +0200 (CEST) > Received: (from eivind@localhost) > by bitbox.follo.net (8.8.8/8.8.6) id WAA01818 > for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 22:31:37 +0200 > (MET DST) > Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) > by hub.freebsd.org (Postfix) with ESMTP > id 26A7714F32; Sun, 10 Oct 1999 13:30:10 -0700 (PDT) > (envelope-from julian@whistle.com) > Received: from current1.whiste.com (current1.whistle.com > [207.76.205.22]) > by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA73061; > Sun, 10 Oct 1999 13:26:57 -0700 (PDT) > Date: Sun, 10 Oct 1999 13:26:56 -0700 (PDT) > From: Julian Elischer > To: Bruce Evans > Cc: freebsd-arch@freebsd.org, mckusick@mckusick.com, > committers@freebsd.org, current@freebsd.org > Subject: Re: The eventual fate of BLOCK devices. > In-Reply-To: > > Message-ID: > > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-freebsd-arch@FreeBSD.ORG > X-Loop: FreeBSD.ORG > Precedence: bulk > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 14:51:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E70AB14EC7 for ; Sun, 10 Oct 1999 14:51:29 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA21323 for ; Sun, 10 Oct 1999 23:51:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA02456 for freebsd-arch@freebsd.org; Sun, 10 Oct 1999 23:51:27 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id AA02D14E2C; Sun, 10 Oct 1999 14:51:15 -0700 (PDT) From: "Jonathan M. Bresler" To: julian@whistle.com Cc: freebsd-arch@freebsd.org In-reply-to: (message from Julian Elischer on Sun, 10 Oct 1999 14:27:59 -0700 (PDT)) Subject: Re: The eventual fate of BLOCK devices. Message-Id: <19991010215115.AA02D14E2C@hub.freebsd.org> Date: Sun, 10 Oct 1999 14:51:15 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG arch and freebsd-arch are the same. yes i got your email. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 16:58:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5B5C514F09 for ; Sun, 10 Oct 1999 16:58:56 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA22405 for ; Mon, 11 Oct 1999 01:58:55 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA03450 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 01:58:54 +0200 (MET DST) Received: from dt011n66.san.rr.com (dt011n66.san.rr.com [204.210.13.102]) by hub.freebsd.org (Postfix) with ESMTP id 2559E14C43 for ; Sun, 10 Oct 1999 16:58:22 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n66.san.rr.com (8.9.3/8.8.8) with ESMTP id QAA08523; Sun, 10 Oct 1999 16:57:47 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <380127FB.FD9BCD36@gorean.org> Date: Sun, 10 Oct 1999 16:57:47 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT-0927 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. References: <199910102057.OAA11530@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > I Can't believe this email only produced TWO responses! > > I would have thought that this wouldhav brought out the chainsaws! > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > > work? (the only responders got it via 'core') > > Interesting. It appears that somehow I got 'unsubscribed' from arch. > Not sure why, but in May I was subscribed, but I'm no longer subscribed. Looks like the same happened to me, although it's hard to tell because even after I subscribed (and majordomo confirmed this by not letting me subscribe again) my address does not show up with a 'which' command. Same for freebsd-security-notifications, which I'm probably on from several different addresses now. :) Not a major deal in my book, but it may explain why the list has been so quiet.... Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 17:19:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B2EB151F2 for ; Sun, 10 Oct 1999 17:19:52 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA24543 for ; Mon, 11 Oct 1999 02:19:51 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA05977 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 02:19:51 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id 57DC214A2A; Sun, 10 Oct 1999 17:19:39 -0700 (PDT) From: "Jonathan M. Bresler" To: Doug@gorean.org Cc: nate@mt.sri.com, julian@whistle.com, freebsd-arch@freebsd.org In-reply-to: <380127FB.FD9BCD36@gorean.org> (message from Doug on Sun, 10 Oct 1999 16:57:47 -0700) Subject: Re: The eventual fate of BLOCK devices. Message-Id: <19991011001939.57DC214A2A@hub.freebsd.org> Date: Sun, 10 Oct 1999 17:19:39 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG the which command is disabled for freebsd-arch and security-notifications. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 18:21:36 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6C630156A3 for ; Sun, 10 Oct 1999 18:21:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA26287 for ; Mon, 11 Oct 1999 03:21:16 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA08036 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 03:21:16 +0200 (MET DST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4FD8614BD3; Sun, 10 Oct 1999 18:21:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA18665; Sun, 10 Oct 1999 18:21:04 -0700 (PDT) (envelope-from dillon) Date: Sun, 10 Oct 1999 18:21:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199910110121.SAA18665@apollo.backplane.com> To: Julian Elischer Cc: Bruce Evans , freebsd-arch@freebsd.org, mckusick@mckusick.com, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > 6/ It should be possible to make an overlay device (similar to the way :> > ccd works), that supplies buffered characteristics to a disk. This may :> > be a different minor number or a differnt major number.. but be a CHR :> > type device. :> :> This would involve needless duplicatication of half of the buffer cache :> implementation (maybe the simple half) unless the buffer cache goes away. :> :> Bruce It should be noted that the current implementation of block devices is fairly trivial, only a few dozen lines of code. I agree with Bruce: it would be silly to throw that away and spend days rewriting it. There is nothing wrong with block device's that can't be trivially fixed other then the fact that Poul seems rabidly intent on destroying them, and there isn't anything wrong with using filesystem buffers either. It should also be noted that in order to maintain cache coherency between read/write and mmap() on a block device, you either have to go through the buffer cache or you have to rewrite considerably more then just specfs. There are several trivial ways to solve the write-error problem. First, implement writes as write-through so a synchronous error can be returned. Second, implement an error code on close. There are other possibilities as well, such as implementing a single buffer pipeline and returning a delayed error, which preserves some of the write pipelining performance, or implementing an intermediate backing layer (such as swap) to buffer errored blocks for later retrieval. There are also situations where errors can be assumed to not occur, such as when using buffered VN partition which is backed by a file or swap. It isn't inconceivable that the methodology could be selected with an ioctl(), with the write-through-synchronous-return for writes made the default. This is all of a dozen lines of code. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 10 19:44:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D622F14EB5 for ; Sun, 10 Oct 1999 19:44:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA26863 for ; Mon, 11 Oct 1999 04:44:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA08421 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 04:44:49 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 9123114EB5 for ; Sun, 10 Oct 1999 19:44:42 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40329>; Mon, 11 Oct 1999 12:40:46 +1000 Content-return: prohibited Date: Mon, 11 Oct 1999 12:44:30 +1000 From: Peter Jeremy Subject: Re: The eventual fate of BLOCK devices. In-reply-to: <199910110121.SAA18665@apollo.backplane.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct11.124046est.40329@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199910110121.SAA18665@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-11 11:21:04 +1000, Matthew Dillon wrote: > There are several trivial ways to solve the write-error problem. Unless I've missed something along the way, it's not that simple. Traditionally, a write to a block device sits in the buffer cache until the sync daemon flushes it to disk. I thought that unifying VM and the buffer cache, together with softupdates, would have relatively little impact on this - there's still a write-back cache with the cache flushing occurring asynchronously and independent of the writer. > First, > implement writes as write-through so a synchronous error can be returned. I would have thought that switching from the current write-back to a write-through policy would, in general, entail a significant performance hit. Even if filesystem I/O is excluded (which I believe is the intent), you still lose the I/O clustering benefits. > Second, implement an error code on close. This would seem to be preferable (and even POLA for direct I/O to block devices). The problem I can see is firstly, the delays in syncer and secondly, getting I/O errors from syncer to to process (or processes, since several different processes could have written to the block(s) in question) issuing the close. > There are also situations where > errors can be assumed to not occur, such as when using buffered VN > partition which is backed by a file or swap. The device underlying the filesystem or swap could still suffer errors. At some point, a decision needs to be made that the error is not reported back to the caller, but notified to `the operator' as a `system' error. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 11 1: 5:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D3B54152DE for ; Mon, 11 Oct 1999 01:05:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA12966 for ; Mon, 11 Oct 1999 10:05:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA13944 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 10:05:33 +0200 (MET DST) Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id D79251504C; Mon, 11 Oct 1999 01:05:08 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id JAA92847; Mon, 11 Oct 1999 09:05:03 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id IAA00710; Mon, 11 Oct 1999 08:30:14 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <199910110730.IAA00710@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: nate@mt.sri.com (Nate Williams) Cc: Julian Elischer , Bruce Evans , freebsd-arch@freebsd.org, mckusick@mckusick.com, committers@freebsd.org, current@freebsd.org Subject: People getting automatically unsub'ed from -arch In-reply-to: Your message of "Sun, 10 Oct 1999 14:57:55 MDT." <199910102057.OAA11530@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Oct 1999 08:30:14 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I Can't believe this email only produced TWO responses! > > I would have thought that this wouldhav brought out the chainsaws! > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > > work? (the only responders got it via 'core') > > Interesting. It appears that somehow I got 'unsubscribed' from arch. > Not sure why, but in May I was subscribed, but I'm no longer subscribed. > > Did everyone get unsubscribed when it went idle? I believe I did more than once. I've re-subscribed several times and got a ``you'll have to be approved manually'' message back. When I tried again a few days ago, it seemed to stick. Like you, I was subscribed at one point.... > Nate -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 11 13:55:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6D73C1573B for ; Mon, 11 Oct 1999 13:55:02 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA19128 for ; Mon, 11 Oct 1999 22:54:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA26062 for freebsd-arch@freebsd.org; Mon, 11 Oct 1999 22:54:43 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id BCCBF14C92 for ; Mon, 11 Oct 1999 13:52:11 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id NAA12655; Mon, 11 Oct 1999 13:52:03 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpdAAA5HaWuy; Mon Oct 11 13:51:41 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA03111; Mon, 11 Oct 1999 13:51:27 -0700 (MST) From: Terry Lambert Message-Id: <199910112051.NAA03111@usr09.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: peter.jeremy@alcatel.com.au Date: Mon, 11 Oct 1999 20:51:27 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <99Oct11.124046est.40329@border.alcanet.com.au> from "Peter Jeremy" at Oct 11, 99 12:44:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > There are several trivial ways to solve the write-error problem. > > Unless I've missed something along the way, it's not that simple. > Traditionally, a write to a block device sits in the buffer cache > until the sync daemon flushes it to disk. I thought that unifying VM > and the buffer cache, together with softupdates, would have relatively > little impact on this - there's still a write-back cache with the > cache flushing occurring asynchronously and independent of the writer. Not to butt in, but O_FSYNC and IO_SYNC should handle this, and if they don't they need to be fixed, rather than glossed over by sweeping block devices under the rug. More generally, it'd be nice to adhere to standards, if only because of ABI compatability concerns for "emulation" modules. Standard UNIX (Single UNIX Specification) defines open(2) arguments: O_DSYNC Write operations to the descriptor are are synchronized data I/O completion. O_RSYNC Read I/O operations on the descriptor complete at the same level of integrity as specified by the O_DSYNC and O_SYNC flags. If both O_DSYNC and O_RSYNC are set in _oflag_ all I/O operations on the descriptor complete as defined by synchronized I/O data integrity completion. If both O_SYNC and O_RSYNC are set in _oflags_, all I/O operations on the descriptor complete as defined by synchronized I/O file integrity completion. O_SYNC Write I/O operations on the descriptor complete as defined by synchronized I/O file integrity completion. Note that the suggested ioctl(2) meshanism is inherently bogus, since the specification states that ioctl(2) can not operate on files. It would be nice to have a non-device-centric solution for this problem, instead of inventing new things (concerning this, I don't believe the idea that the future BSD installed base will be coming from a Linux background in any way justifies the repetition of the mistakes Linux has made). > > First, > > implement writes as write-through so a synchronous error can be returned. > > I would have thought that switching from the current write-back to a > write-through policy would, in general, entail a significant > performance hit. Even if filesystem I/O is excluded (which I believe > is the intent), you still lose the I/O clustering benefits. You are correct. However, I believe that it is the only way to do a correct implementation of the control flags. My take on this is that, in the absence of O_DSYNC and O_SYNC being specified in the open flags, that the policy should be write-back, and that it should require a user override (by specification of these flags at time of open(2) call) to invoke the performance hit (and the synchronous error reporting that appears to be desired by some parties). > > Second, implement an error code on close. > > This would seem to be preferable (and even POLA for direct I/O to > block devices). The problem I can see is firstly, the delays in > syncer and secondly, getting I/O errors from syncer to to process (or > processes, since several different processes could have written to the > block(s) in question) issuing the close. I believe the biggest issue here is actually "last close" vs. "any close" hooks into the device drivers. Both PHK and Bruce have noted this issue in the past. Perhaps it is time to deal with it, rather than talking about it. So far as assigning responsibility for the error, an error on close is only an issue in the non-O_DSYNC, non-O_SYNC case, i.e. when the user has elected ambiguity in the face of the performance hit that they would otherwise suffer. I think this can be ameliorated by implementing an error code on fsync(2), rather than one on close(2) (or in addition to; however it strikes me that the error on close is much less useful, in general, since it is very hard to take corrective action by the time you are calling close in the user space program). > > There are also situations where > > errors can be assumed to not occur, such as when using buffered VN > > partition which is backed by a file or swap. > > The device underlying the filesystem or swap could still suffer > errors. At some point, a decision needs to be made that the error is > not reported back to the caller, but notified to `the operator' as > a `system' error. In particular, the reason it is difficult for the soft updates code to enable or disable soft updates on the fly is that there are buffers off the device vnode, and there are buffers off the vnodes of the FS mounted on the device. This two-stage caching has three negative effects: (1) hard errors are not signalled until the underlying device vnode flush fails; a writethrough to the device buffers will never fail, and therefore never signal a user process, (2) uncommitted writes are, and remain, ambiguous, at least until the underlying vnode commit, and (3) there is an implicit limitation of the size of a device that can be accomodated through the interface, equal to the normal limit on the size of a file within a filesystem. I think that this is a more general problem, and is similar in scope and effect to the VM object coherency issues underlying VFS stacking. I think that a more general solution should be sought, with this in mind; the problem is going to have to be resolved eventaully, one way or the other, so ducking it now by eliminating block devices doesn't save any work in the long run: better to not procrastinate. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 14:49:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B259215129 for ; Tue, 12 Oct 1999 14:49:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA07951 for ; Tue, 12 Oct 1999 23:48:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA33120 for freebsd-arch@freebsd.org; Tue, 12 Oct 1999 23:48:43 +0200 (MET DST) Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160]) by hub.freebsd.org (Postfix) with ESMTP id 0842714DE9; Tue, 12 Oct 1999 14:48:07 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id OAA02290; Tue, 12 Oct 1999 14:48:04 -0700 (PDT) Received: from flamingo.McKusick.COM (mckusick@localhost.concentric.net [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id NAA15822; Tue, 12 Oct 1999 13:14:41 -0700 (PDT) Message-Id: <199910122014.NAA15822@flamingo.McKusick.COM> To: Julian Elischer Subject: Re: The eventual fate of BLOCK devices. Cc: Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org In-reply-to: Your message of "Sun, 10 Oct 1999 18:21:04 PDT." <199910110121.SAA18665@apollo.backplane.com> Date: Tue, 12 Oct 1999 13:14:40 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would like to take a step back from the debate for a moment and ask the bigger question: How many real-world applications actually use the block device interface? I know of none whatsoever. All the filesystem utilities go out of their way to avoid the block device and use the raw interface. Does anyone on this list know of any programs that need/want the block interface? If there are none, or only very obscure ones, then it seems pointless to waste any kernel code supporting them. Indeed it will clean up a good deal of code to get rid of them. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 14:59:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 488A2158CC for ; Tue, 12 Oct 1999 14:59:35 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA08087 for ; Tue, 12 Oct 1999 23:59:34 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA33192 for freebsd-arch@freebsd.org; Tue, 12 Oct 1999 23:59:33 +0200 (MET DST) Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 10D1C151D5; Tue, 12 Oct 1999 14:58:12 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id QAA18360; Tue, 12 Oct 1999 16:57:49 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Tue, 12 Oct 1999 16:57:49 -0500 (CDT) From: David Scheidt To: Kirk McKusick Cc: Julian Elischer , Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910122014.NAA15822@flamingo.McKusick.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 12 Oct 1999, Kirk McKusick wrote: > I would like to take a step back from the debate for a moment and > ask the bigger question: How many real-world applications actually > use the block device interface? I know of none whatsoever. All the > filesystem utilities go out of their way to avoid the block device > and use the raw interface. Does anyone on this list know of any > programs that need/want the block interface? If there are none, or It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated disk devices. There may be other RDBMSes that do this. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 15:14: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9067F14C1B for ; Tue, 12 Oct 1999 15:13:55 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA08269 for ; Wed, 13 Oct 1999 00:13:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA33319 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 00:13:52 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F3C4D15387; Tue, 12 Oct 1999 15:10:49 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA39209; Tue, 12 Oct 1999 16:10:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA99359; Tue, 12 Oct 1999 16:11:30 -0600 (MDT) Message-Id: <199910122211.QAA99359@harmony.village.org> To: David Scheidt Subject: Re: The eventual fate of BLOCK devices. Cc: Kirk McKusick , Julian Elischer , Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org In-reply-to: Your message of "Tue, 12 Oct 1999 16:57:49 CDT." References: Date: Tue, 12 Oct 1999 16:11:30 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message David Scheidt writes: : It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated : disk devices. There may be other RDBMSes that do this. EVERY RDBMS that I've ever seen or had to make work with my drivers has been on the raw partition. This is because the database writers DO NOT LIKE OR TRUST the buffer cache due to its non-deterministic nature of disk writing. Are you sure that Sybase uses BLOCK devices and not CHAR devices? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 15:34:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D0FC614C8D for ; Tue, 12 Oct 1999 15:34:13 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA08636 for ; Wed, 13 Oct 1999 00:34:11 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA33464 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 00:34:11 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8D7FD155E1 for ; Tue, 12 Oct 1999 15:30:39 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA58769; Tue, 12 Oct 1999 15:27:55 -0700 (PDT) Date: Tue, 12 Oct 1999 15:27:54 -0700 (PDT) From: Julian Elischer To: Kirk McKusick Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910122014.NAA15822@flamingo.McKusick.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (CC list trimmed to 'freebsd-arch') On Tue, 12 Oct 1999, Kirk McKusick wrote: > I would like to take a step back from the debate for a moment and > ask the bigger question: How many real-world applications actually > use the block device interface? I know of none whatsoever. All the > filesystem utilities go out of their way to avoid the block device > and use the raw interface. Does anyone on this list know of any > programs that need/want the block interface? If there are none, or > only very obscure ones, then it seems pointless to waste any kernel > code supporting them. Indeed it will clean up a good deal of code > to get rid of them. The question is, "How much code will it clear up?" The opinions differ. and, just because we can't point out one at the moment doesn't mean that there aren't any. There is also the issue of Posix standards etc. is a 'Unix' supposed to have two kinds of devices? the standards certainly define block and character devices. might a process use block devices as a mething of allowing caching between multiple co-operating processes? > > Kirk McKusick > Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 15:38:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 616AA152DF for ; Tue, 12 Oct 1999 15:38:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA08710 for ; Wed, 13 Oct 1999 00:38:14 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA33502 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 00:38:14 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CD8515489 for ; Tue, 12 Oct 1999 15:35:17 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA58953; Tue, 12 Oct 1999 15:31:43 -0700 (PDT) Date: Tue, 12 Oct 1999 15:31:42 -0700 (PDT) From: Julian Elischer To: David Scheidt Cc: Kirk McKusick , freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (this should be on 'freebsd-arch' only...) I BELIEVE sybase uses raw devices, right? On Tue, 12 Oct 1999, David Scheidt wrote: > On Tue, 12 Oct 1999, Kirk McKusick wrote: > > > I would like to take a step back from the debate for a moment and > > ask the bigger question: How many real-world applications actually > > use the block device interface? I know of none whatsoever. All the > > filesystem utilities go out of their way to avoid the block device > > and use the raw interface. Does anyone on this list know of any > > programs that need/want the block interface? If there are none, or > > It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated > disk devices. There may be other RDBMSes that do this. > > David Scheidt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 16: 0:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5A99915326 for ; Tue, 12 Oct 1999 16:00:01 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA08927 for ; Wed, 13 Oct 1999 00:59:56 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA33591 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 00:59:54 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id E1DBB152BA; Tue, 12 Oct 1999 15:54:56 -0700 (PDT) From: "Jonathan M. Bresler" To: dscheidt@enteract.com Cc: mckusick@flamingo.McKusick.COM, julian@whistle.com, bde@zeta.org.au, dillon@apollo.backplane.com, freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org In-reply-to: (message from David Scheidt on Tue, 12 Oct 1999 16:57:49 -0500 (CDT)) Subject: Re: The eventual fate of BLOCK devices. Message-Id: <19991012225456.E1DBB152BA@hub.freebsd.org> Date: Tue, 12 Oct 1999 15:54:56 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sybase can use either block devices or raw disk. We run all our databases, Sybase, Oracle, etc. on raw disk. the database engineers here would kill me if i were to ask them to use a block device rather than raw disk. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 16: 4:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8621314C16 for ; Tue, 12 Oct 1999 16:04:09 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA09043 for ; Wed, 13 Oct 1999 01:04:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA33668 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 01:04:03 +0200 (MET DST) Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 66869152DF for ; Tue, 12 Oct 1999 15:59:05 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: from shell-1.enteract.com (dscheidt@shell-1.enteract.com [207.229.143.40]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id RAA26230; Tue, 12 Oct 1999 17:58:58 -0500 (CDT) (envelope-from dscheidt@enteract.com) Date: Tue, 12 Oct 1999 17:58:58 -0500 (CDT) From: David Scheidt To: Julian Elischer Cc: Kirk McKusick , freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 12 Oct 1999, Julian Elischer wrote: > > (this should be on 'freebsd-arch' only...) > > I BELIEVE sybase uses raw devices, right? > We certainly use the block devices -- I just made several dozen today, but it appears that it is OS dependent. On HP-UX, older versions required the use of the block devices. Current versions appear to use either. I didn't know this, so I have no idea what the possible performance impacts are. I will talk to our DBAs. HP-UX does a number of things oddly, I am not shocked about this. (See http://www.sybase.com/partners/hp/hp_ux_tunning.html ) David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 12 17:44:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9561B14A0D for ; Tue, 12 Oct 1999 17:44:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA10033 for ; Wed, 13 Oct 1999 02:44:31 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA34353 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 02:44:31 +0200 (MET DST) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4145B14E79; Tue, 12 Oct 1999 17:41:00 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CA0C41C6D; Wed, 13 Oct 1999 08:40:59 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: David Scheidt , Kirk McKusick , Julian Elischer , Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Tue, 12 Oct 1999 16:11:30 CST." <199910122211.QAA99359@harmony.village.org> Date: Wed, 13 Oct 1999 08:40:59 +0800 From: Peter Wemm Message-Id: <19991013004059.CA0C41C6D@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message Da vid Scheidt writes: > : It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated > : disk devices. There may be other RDBMSes that do this. > > EVERY RDBMS that I've ever seen or had to make work with my drivers > has been on the raw partition. This is because the database writers > DO NOT LIKE OR TRUST the buffer cache due to its non-deterministic > nature of disk writing. Are you sure that Sybase uses BLOCK devices > and not CHAR devices? Sybase is supposed to be run on char devices. The Linux sybase release notes refer to "Unfortunately Linux does not have raw (char) disk devices so we have to make do". Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 12:31:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AB77014BED for ; Wed, 13 Oct 1999 12:31:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA24458 for ; Wed, 13 Oct 1999 21:31:18 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA38253 for freebsd-arch@freebsd.org; Wed, 13 Oct 1999 21:31:13 +0200 (MET DST) Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160]) by hub.freebsd.org (Postfix) with ESMTP id 2E4DD153F7 for ; Wed, 13 Oct 1999 12:30:08 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id MAA06327; Wed, 13 Oct 1999 12:30:07 -0700 (PDT) Received: from flamingo.McKusick.COM (mckusick@localhost.concentric.net [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id KAA18428; Wed, 13 Oct 1999 10:38:36 -0700 (PDT) Message-Id: <199910131738.KAA18428@flamingo.McKusick.COM> To: Julian Elischer Subject: Re: The eventual fate of BLOCK devices. Cc: freebsd-arch@freebsd.org In-reply-to: Your message of "Tue, 12 Oct 1999 15:27:54 PDT." Date: Wed, 13 Oct 1999 10:38:35 -0700 From: Kirk McKusick Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 12 Oct 1999 15:27:54 -0700 (PDT) From: Julian Elischer To: Kirk McKusick cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910122014.NAA15822@flamingo.McKusick.COM> (CC list trimmed to 'freebsd-arch') On Tue, 12 Oct 1999, Kirk McKusick wrote: > I would like to take a step back from the debate for a moment and > ask the bigger question: How many real-world applications actually > use the block device interface? I know of none whatsoever. All the > filesystem utilities go out of their way to avoid the block device > and use the raw interface. Does anyone on this list know of any > programs that need/want the block interface? If there are none, or > only very obscure ones, then it seems pointless to waste any kernel > code supporting them. Indeed it will clean up a good deal of code > to get rid of them. The question is, "How much code will it clear up?" The opinions differ. And, just because we can't point out one at the moment doesn't mean that there aren't any. If no one on the list can think of any use, I doubt that there is one. Just because there might some day be a use is not enough reason to have an interface. BSD has stayed lean and mean (relative to the commercial Unix varients) by actively throwing out decrepit interfaces. If we revert to the vendor `keep every interface that we ever put in the kernel for fear of upsetting some legacy application' we will end up with a bloated, hard to maintain, hard to evolve system. We have pitched far more heavily used interfaces than block devices and been better for it. There is also the issue of Posix standards etc. is a 'Unix' supposed to have two kinds of devices? the standards certainly define block and character devices. might a process use block devices as a mething of allowing caching between multiple co-operating processes? > > Kirk McKusick > Julian Posix defines that there are two types. It says absolutely nothing about the semantics of the two types. It does not require that you have both types, merely that you be able to report them if they are there. As for maintaining caching between processes, we already have two ways of doing that. FIFO's (a descriptor I/O based method) and shared memory (obtained via mmap). We do not need another descriptor based method. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 16:46:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CCAEE14ED4 for ; Wed, 13 Oct 1999 16:46:02 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA26860 for ; Thu, 14 Oct 1999 01:46:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA39270 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 01:45:45 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id E51D814FEE for ; Wed, 13 Oct 1999 16:45:29 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id QAA22274; Wed, 13 Oct 1999 16:45:25 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAAzZaaaR; Wed Oct 13 16:45:00 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA24624; Wed, 13 Oct 1999 16:44:53 -0700 (MST) From: Terry Lambert Message-Id: <199910132344.QAA24624@usr01.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Date: Wed, 13 Oct 1999 23:44:52 +0000 (GMT) Cc: julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <199910131738.KAA18428@flamingo.McKusick.COM> from "Kirk McKusick" at Oct 13, 99 10:38:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The question is, "How much code will it clear up?" > The opinions differ. > And, just because we can't point out one at the moment doesn't > mean that there aren't any. > > If no one on the list can think of any use, I doubt that there is one. > Just because there might some day be a use is not enough reason to have > an interface. BSD has stayed lean and mean (relative to the commercial > Unix varients) by actively throwing out decrepit interfaces. If we revert > to the vendor `keep every interface that we ever put in the kernel for > fear of upsetting some legacy application' we will end up with a bloated, > hard to maintain, hard to evolve system. We have pitched far more heavily > used interfaces than block devices and been better for it. I agree with this sentiment. However, this seems to argue for pitching character devices, since character devices have the restriction that they must be accessed on block boundaries in block size increments, whereas block devices have no such restriction. When choosing between interfaces, it seems to me that keeping the one with the least restrictions, and pitching the one with the most, would be the more correct approach. I really object to having to modify user space code to know about having to access things on block boundaries, and having to cache a blocks worth of data (dependant on whatever the native block size of the underlying device happens to be) in order to update regions. It makes little sense to do this in many user space programs, as opposed to making the opacity of the blocking a kernel function. With regard to unnecessary block buffering occorruing in the kernel, two candidates ripe for a bullet in the head are directory entry blocks, and the inode hash. The inode hash could be easily eliminated by not breaking the vnode/inode association arbitrarily (perhaps by yielding ownership of vnodes which incorporate inodes at the end of their structure to the FS containing the inodes). The directory entry block code is a historical wart, which has the effect of preventing us from going forward with things like btree based directories, native Unicode support for 256 character filenames (_NOT_ UTF-8 encoded: that would require up to 1280 octets for a worst-case encoding, whereas 16 bit fixed characters require only a maximum of 512 bytes -- but leave no room for directory metadata other than the file name, if limited to 512 byte blocks), multiple namespaces (needed to optimize Samba), ACL's, extended attributes, etc.. Both of these issues are roadblocks to progress... unlike block devices, which may be ugly in some people's eyes. > There is also the issue of Posix standards etc. > is a 'Unix' supposed to have two kinds of devices? > the standards certainly define block and character devices. > might a process use block devices as a mething of allowing > caching between multiple co-operating processes? > > Julian > > Posix defines that there are two types. It says absolutely nothing > about the semantics of the two types. It does not require that you > have both types, merely that you be able to report them if they are > there. As for maintaining caching between processes, we already have > two ways of doing that. FIFO's (a descriptor I/O based method) and > shared memory (obtained via mmap). We do not need another descriptor > based method. > > Kirk McKusick Julian's example of cooperating processes is flawed, since that is an issue for the coherency model to deal with, but his reasoning is not; POSIX states (from the "Go Solo 2" CDROM): character special file A file that refers to a device. One specific type of character special file is a terminal device file, whose access is defined in "General Terminal Interface" in (XBD). ... block special file A file that refers to a device. A block special file is normally distinguished from a character special file by providing access to the device in a manner such that the hardware characteristics of the device are not visible. The standards (POSIX, et. al.) _do_ require both types of special files. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 17:59:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 167F11513C for ; Wed, 13 Oct 1999 17:59:11 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA29620 for ; Thu, 14 Oct 1999 02:59:10 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA39737 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 02:59:09 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 901B31513C for ; Wed, 13 Oct 1999 17:59:00 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40349>; Thu, 14 Oct 1999 10:54:55 +1000 Content-return: prohibited Date: Thu, 14 Oct 1999 10:58:50 +1000 From: Peter Jeremy Subject: Re: The eventual fate of BLOCK devices. In-reply-to: <199910132344.QAA24624@usr01.primenet.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct14.105455est.40349@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199910131738.KAA18428@flamingo.McKusick.COM> <199910132344.QAA24624@usr01.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-14 09:44:52 +1000, Terry Lambert wrote: >However, this seems to argue for pitching character devices, since >character devices have the restriction that they must be accessed >on block boundaries in block size increments, whereas block devices >have no such restriction. I'd suggest the opposite. Anything that needs to access a physical device needs to know _something_ about the device. Requiring it to understand blocksizes and blocking factors does not seem unreasonable. Providing a stream interface to a naturally block device (eg a raw disk) means that the kernel has to appropriately buffer the data and write it at suitable times. Whilst the kernel knows the blocksize, it cannot know the application behaviour. This means that the performance is likely to be sub-optimal. The other disadvantage is that read/write to a block device implies an extra memory-memory copy, compared to a raw device. (A partially compensating advantage is that mmap(2) may be able to be used instead). >When choosing between interfaces, it seems to me that keeping the >one with the least restrictions, and pitching the one with the most, >would be the more correct approach. You gain the ability to use naive applications with the device. You reduce the ability of `smart' applications to optimise their performance. It's unclear that either approach is clearly better. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 18:14:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C434114E53 for ; Wed, 13 Oct 1999 18:14:12 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA29711 for ; Thu, 14 Oct 1999 03:14:12 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA39796 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 03:14:11 +0200 (MET DST) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 89D3B14E6C; Wed, 13 Oct 1999 18:13:04 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id VAA64179; Wed, 13 Oct 1999 21:12:36 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Wed, 13 Oct 1999 21:12:36 -0400 (EDT) From: Chuck Robey To: David Scheidt Cc: Kirk McKusick , Julian Elischer , Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 12 Oct 1999, David Scheidt wrote: > On Tue, 12 Oct 1999, Kirk McKusick wrote: > > > I would like to take a step back from the debate for a moment and > > ask the bigger question: How many real-world applications actually > > use the block device interface? I know of none whatsoever. All the > > filesystem utilities go out of their way to avoid the block device > > and use the raw interface. Does anyone on this list know of any > > programs that need/want the block interface? If there are none, or > > It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated > disk devices. There may be other RDBMSes that do this. Informix, should a miracle occur and they decide to suport FreeBSD, definitely want the same. ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 18:15:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 18DC214E53 for ; Wed, 13 Oct 1999 18:15:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA29734 for ; Thu, 14 Oct 1999 03:15:33 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA39834 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 03:15:33 +0200 (MET DST) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id B7E471528A; Wed, 13 Oct 1999 18:14:30 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id VAA64183; Wed, 13 Oct 1999 21:14:10 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Wed, 13 Oct 1999 21:14:10 -0400 (EDT) From: Chuck Robey To: Warner Losh Cc: David Scheidt , Kirk McKusick , Julian Elischer , Bruce Evans , Matthew Dillon , freebsd-arch@freebsd.org, committers@freebsd.org, current@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910122211.QAA99359@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 12 Oct 1999, Warner Losh wrote: > In message David Scheidt writes: > : It doesn't run on FreeBSD, but Sybase uses block devices for its dedicated > : disk devices. There may be other RDBMSes that do this. > > EVERY RDBMS that I've ever seen or had to make work with my drivers > has been on the raw partition. This is because the database writers > DO NOT LIKE OR TRUST the buffer cache due to its non-deterministic > nature of disk writing. Are you sure that Sybase uses BLOCK devices > and not CHAR devices? Gawd, now that I think of it, about my Informix post, you're right, they use a raw partition, and their own buffering. > > Warner > > ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 13 20:16:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7D8FE14F07 for ; Wed, 13 Oct 1999 20:16:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA00685 for ; Thu, 14 Oct 1999 05:16:18 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA40178 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 05:16:18 +0200 (MET DST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 90F4014F07 for ; Wed, 13 Oct 1999 20:16:07 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from d154.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA29042; Thu, 14 Oct 1999 13:18:11 +1000 Date: Thu, 14 Oct 1999 13:15:25 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Kirk McKusick Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910131738.KAA18428@flamingo.McKusick.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 13 Oct 1999, Kirk McKusick wrote: > If no one on the list can think of any use, I doubt that there is one. I routinely use Linux fsck.ext2 and mkfs.ext2 to develop ext2fs under FreeBSD. These (at least the May 1997 versions) depend on the system for sub-block i/o's. savecore depended on the system for sub-block i/o's until recently. It needs to read the dumpmag word and related things, and doing its own blocking just for this is unnecessarily difficult. > Just because there might some day be a use is not enough reason to have > an interface. BSD has stayed lean and mean (relative to the commercial > Unix varients) by actively throwing out decrepit interfaces. If we revert FreeBSD hasn't been so successful in avoiding bloat. The text size of a (sub) minimal kernel with no options or devices has increased from 275K in FreeBSD-1.1.5 to 500K in FreeBSD-3.3 and 550K in FreeBSD-current. The size of sys/kern has increased from 822 blocks in FreeBSD-1.1.5 to 780 blocks in Lite2, 1719 blocks in FreeBSD-3.3 and 1812 blocks in FreeBSD-current. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 14 4:13:11 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 832E414C27 for ; Thu, 14 Oct 1999 04:13:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA07380 for ; Thu, 14 Oct 1999 13:13:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA42008 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 13:13:07 +0200 (MET DST) Received: from critter.freebsd.dk (wandering-wizard.cybercity.dk [212.242.43.150]) by hub.freebsd.org (Postfix) with ESMTP id A5A0214C27 for ; Thu, 14 Oct 1999 04:12:55 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id MAA00449 for ; Thu, 14 Oct 1999 12:43:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Thu, 14 Oct 1999 13:15:25 +1000." Date: Thu, 14 Oct 1999 12:43:40 +0200 Message-ID: <447.939897820@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I know it was Julian who threw this ball in the air, but I take the liberty of doing the final round: I have been the primus motor on this issue from the beginning and it is part of the dev_t cleanup project.] SUMMARY: So far we have identified the following two classes of software which access disk-like devices through cdev and bdev: 1) Database software. 2) Filesystem maintenance tools 3) savecore(8) Database software prefer cdev semantics if at all possible, if running on anything but a cdev database software call fsync(2) a lot to make sure the writes have hit the media. Terry argues for retaining the bdev semantics rather than the cdev semantics, but I think we can dismiss that idea based on the above observation: it would penalize software which know better. Retaining the bdev would in essence be emulating the mistake Linux made, and which they are now unmaking. The filesystem maintenance applications mentioned so far which rely on bdev semantics, the EXT2FS tools, can be trivially converted to operate on cdev semantics. The majority of such tools already correctly operate on cdevs. Savecore(8) has already been converted to operate on cdevs. Using mmap(2) to provide a new type of buffered semantics for disk-like devices is insteresting, but its applicability will be limited by the virtual address space of a process: you can't map a 20GB database into a 32bit address space, so a lot of mmap(2) calls will be needed for serious sized data. The need for, and actual use of such a facility seemes uncertain. There is general disagreement about how much code we save, but nobody disputes that we will be able to remove some amount of complexity from the kernel. Most people seem to overlook the needlessly replicated code in a number of xxx(8) tools to DTRT with /dev/foo vs /dev/rfoo. Implementing an ioctl(2) to switch a disk-like device into bdev mode is relatively trivial, but there currently seems to be no point in doing so. There is a significant majority supporting the removal of bdev semantics. CONCLUSION: ----------- Unless we have significant new information to the contrary, I will commence the bdev removal after November 1st 1999. In order to try to trigger any such information, I will change the default value of the vfs.bdev_buffered sysctl to zero this weekend, this will make bdevs react like cdevs. An ioctl(2) based mode-switch will only be implemented if a very good reason for doing so materializes. Thanks for participating. Poul-Henning -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 14 8:15:30 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 737CC14BD4 for ; Thu, 14 Oct 1999 08:15:27 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA11730 for ; Thu, 14 Oct 1999 17:15:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA43230 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 17:15:26 +0200 (MET DST) Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id A801A14BD4 for ; Thu, 14 Oct 1999 08:15:04 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA35743 for freebsd-arch@FreeBSD.ORG; Thu, 14 Oct 1999 08:15:04 -0700 (PDT) Date: Thu, 14 Oct 1999 08:15:04 -0700 (PDT) From: David Wolfskill Message-Id: <199910141515.IAA35743@pau-amma.whistle.com> To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <447.939897820@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Thu, 14 Oct 1999 12:43:40 +0200 >From: Poul-Henning Kamp [I probably should have changed the Subject:.... dhw] >Using mmap(2) to provide a new type of buffered semantics for >disk-like devices is insteresting, but its applicability will be >limited by the virtual address space of a process: you can't map >a 20GB database into a 32bit address space, so a lot of mmap(2) >calls will be needed for serious sized data. The need for, and >actual use of such a facility seemes uncertain. For whatever it might possibly be worth, re: the issue of addressing more storage than the address space, I'll briefly sketch what I recall of what IBM (the mainframe side of the house) did in the transition from MVS/XA -> MVS/ESA. The purpose is illustration, not advocacy (either pro or con). :-) The hardware in question uses 32-bit words, but in MVS/XA, they used 31-bit addresses. (High-order bit was reserved. I don't *even* want to think about that....) System architecture tended to reserve a very large chunk of address space for system (common to each AS) information. Over time, this tended to grow, decreasing the private area of the AS. Meanwhile, applications such as databases needed to access more data, and their architects wanted to keep the data resident... and if you do that, it really helps if it's addressable. :-) So IBM came up with an "interesting" concept... "data only" address spaces: A program would run in one address space, and request that the OS create a new address space for it to play in. The (first -- don't recall the official term) AS would then denote a range within this new AS, and cause data to be placed into it. This (data-only AS creation & access) could happen for up to some architectural limit of data-only ASs per "normal" AS. A database engine could, for example, place separate tables in separate data-only ASs. It should be noted that paging I/O was measurably faster than normal I/O, generally. And it was possible (with sufficient chilled water) to put a *lot* of memory on these beasts. So if, at some point, accessing more VM than one AS becomes an issue, that's the basics of one approach that has been used. Should we get to that point, I'd hope we can learn from others' experiences. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 14 12:29:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4E26C14BDE for ; Thu, 14 Oct 1999 12:29:37 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA14629 for ; Thu, 14 Oct 1999 21:29:36 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA44673 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 21:29:36 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4C05D14BDE for ; Thu, 14 Oct 1999 12:29:16 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA32173 for ; Thu, 14 Oct 1999 15:29:16 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 14 Oct 1999 15:29:16 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org Subject: Re: Low Watermark MAC (LOMAC) implementation for Linux (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of the topics that comes up quite a bit on the posix1e mailing list is how to fit security extension data into the file system of operating systems needing security extensions. Right now, we're discussing MAC labels but ACLs are also relevant. In BSD-land, we usually say things like "use a filesystem layer" in response to the suggestion that additional metadata should be added. However, I'm concerned about the transactional properties of security attributes--it's important that a coerced system failure (kernel panic, power outage, whatever) not leave a file unprotected because the inode was updated but the ACL was left behind, or the like. Currently, permissions are in the inode, so that works ok, but if the ACLs were pulled from another layer of the FS, that wouldn't be the case. XFS appears to support generic attribute extensions, although I don't know anything about it and am trying to get documents to find out more about it. NT supports named file forks, etc. The big sticking point for the Linux ACL and Capability people has been where to put their data. The other question is how aware should the VFS/vnode calls be of ACLs and security labels. There's a decent argument that ACLs are like other attributes (file permissions, etc) and it is ok to expose them at all levels -- add a Posix-style ACL descriptor struct, have it passed around in the same way as the other attributes via get/setacl vnode calls. Alternatively, it could be integrated into the attribut structure (not good because, for example, the IRIX ACL struct is 308 bytes, dramatically increasing the size of an inode if it ends up there, and also breaking a binary interface to both the kernel and the fs). Since the fs is reponsible for enforcing ACLs, it wouldn't require too may sweeping changes--most file systems could leave it unimplemented, but fs's that support ACLs (such as NTfs, Coda, AFS, etc) might be able to expose some of that via the Posix interface. Would the general FreeBSD community be opposed to addition of two new vnode calls of this type, and the appropriate structs to describe their interface, as well as syscalls to match? This might facilitate the development of ACL support, and not prohibit the layer implementation, as it could still be handled by an ACLfs layer that spoke ACLs. Anyhow, opinions and comments would be greatly appreciated. Cross-platform comments on implementation could be CC'd to posix1e@cyrus.watson.org, but FreeBSD-specific stuff should probably stay on -arch or elsewhere. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services ---------- Forwarded message ---------- Date: Thu, 14 Oct 1999 15:18:49 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: "Ilmar S. Habibulin" Cc: Casey Schaufler , posix1e@cyrus.watson.org Subject: Re: Low Watermark MAC (LOMAC) implementation for Linux On Thu, 14 Oct 1999, Ilmar S. Habibulin wrote: > On Thu, 14 Oct 1999, Casey Schaufler wrote: > > > We've got a little bit of a dilemma here. On one hand, we'd > > love to say that the extended attribuites of XFS are the way > > to go. On the other hand, we recognize that XFS may never be the > > default file system for Linux. For file systems other than XFS > > another mechanism may be required. > Can you point some url, describing this fs or somehow describe it by > yourself? > > > So, until XFS is available, a file system independent scheme may > > be the most appropriate. I have attached (PostScript - sorry) a > > description of what we did before we had XFS. It's not actually > As i understand it is something like quotas in ffs, am i right? This > approach was proposed by Robert. I don't understand why my thoughts were > not supported? Is an idea of some improvements in ffs so terrible? ;-) Well, the idea of updating FFS I think is a good one--perhaps to have some generic attributes support of the type XFS appears to have. Please forgive my ignorance as to the design of XFS--I've mostly lived in Linux-, Solaris-, and BSD-land in the past few years, so am not familiar with it's particular quirks/features. Anyone have a good reference for the design/implementation of XFS online, or in a journal or the like? I'm also interested in how the Solaris folk fit ACLs (and presumably other things) into their FFS. One of the things that I think is important is to give ACL/other security-relevant tags the same atomic update properties that attribute information in traditional inode structures has--i.e., in the event of an untimely power loss, it's not possible to end up with the inode but not the associated ACL or MAC data. Fitting the data into the inode directly might be one way to do this, but it's probably desirable to have a general extension mechanism (such as XFS-style attributes, possibly?) so we don't have to keep modifying the file system. This can result in painful upgrade procedures, divergences in mainstream and secure code, etc. I'm out of town this weekend, but I think the next step in BSD support for ACLs/MAC support in the FS is to add support in the VFS/vnode layer for requesting and modifying these attributes. How that interface looks depends a bit on whether we have a general-purpose extension mechanism or not. Given the proliferation of various file systems at this point, it might make sense to add kernel-level VFS interfaces such as getacl, setacl, getmaclabel, setmaclabel, and let the file system decide how to store this data. This might allow the hiding of AFS or Coda ACLs behind a POSIX.1e ACL interface, which would probably be quite desirable, if feasible. There are downsides to this, of course, including that the vnode/vfs layer is now aware of a particular kind of ACL interface or MAC interface--of course, it already knows about permissions, and in a sense it's just passing back and forth binary blobs most of the time for ACLs as the FS layer itself enforces the limits, I believe. For the MAC data, however, that's a different question,.. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@cyrus.watson.org with "unsubscribe posix1e" 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 Thu Oct 14 13:57:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A9CDF150C4 for ; Thu, 14 Oct 1999 13:57:20 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA15434 for ; Thu, 14 Oct 1999 22:57:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA45035 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 22:57:02 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 68DA7150C4 for ; Thu, 14 Oct 1999 13:56:43 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id NAA24351; Thu, 14 Oct 1999 13:56:33 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAG8aWsV; Thu Oct 14 13:56:28 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id NAA29867; Thu, 14 Oct 1999 13:56:11 -0700 (MST) From: Terry Lambert Message-Id: <199910142056.NAA29867@usr08.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Oct 1999 20:56:11 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <447.939897820@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 14, 99 12:43:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First of all, thanks to everyone for such a focussed discussion. I have some comments on Poul's comments, and would at least like to argue for a "legacy mode", even if it is not enabled by default, so long as it can be enabled (and implied) without a kernel recompile (but perhaps requiring a kernel module), for standards compliance reasons, if no other. > SUMMARY: > > So far we have identified the following two classes of software > which access disk-like devices through cdev and bdev: > > 1) Database software. > > 2) Filesystem maintenance tools > > 3) savecore(8) I would add: 4) Programs which want to treat object in the filespace as if they were byte streams. In other words, it shouldn't matter, and I should not have to give special arguments to programs such as "tar" and "dd" and "team" to do I/O in variable media blocking factors. I think I would also add: 5) Programs that have to deal with CDROM's containing multiple sessions. This is an issues, since not all data is 2048 byte blocks, but can in fact be 2352, or a physical sector size of 2048, 2336, or 2340 bytes. This will only get more complicated as DVD and other standards evolve and come online. In addition, many WORM, mageneto-optical, and Japanese hard drives (such as those by default in the NEC PC-98) are 1024 bytes. I would have that complexity hidden from the user, who is most interested in a linear array of bytes of arbitrary length, and in seeking to non-block aligned offsets in the linear array. > Database software prefer cdev semantics if at all possible, if > running on anything but a cdev database software call fsync(2) a > lot to make sure the writes have hit the media. I would argue that such database software is either broken, or it is expecting a broken kernel (one which does not do the correct thing on block device descriptors marked O_SYNC -- such as FreeBSD's existing block device semantics). > Terry argues for retaining the bdev semantics rather than the cdev > semantics, but I think we can dismiss that idea based on the above > observation: it would penalize software which know better. Retaining > the bdev would in essence be emulating the mistake Linux made, and > which they are now unmaking. I think that for "software that knows better", i.e. software that has called fstat(2) to get st_blksize, and intentionally performs aligned writes, that it would be trivial to determine if a write was on a block boundary, and spanned an integer number of blocks, and therefore not penalize the smarter software. This is really an implementation issue, not a performance issue. > The filesystem maintenance applications mentioned so far which rely > on bdev semantics, the EXT2FS tools, can be trivially converted to > operate on cdev semantics. The majority of such tools already > correctly operate on cdevs. I believe the tools should be implemented via a different API, since the kernel already knows about slices, partitions, etc., and has to have that knowledge embedded in it. So either way, the tools promiscuous knowledge of stuff that they really have no right knowing in the first place isn't an argument for getting rid of block devices -- nor an argument in favor of keeping them. > Savecore(8) has already been converted to operate on cdevs. Irrelevent, I think, as well. Clearly, we could convert the entirety of all FTP'able software on the Internet to do its own block size determination, and do buffering in user space thereafter. I think this would be wasteful. As Julian didn't point out, but probably meant to with his example, Multiple fromas operating at a granularity of sizeof(struct foo), where sizeof(struct foo) is not an integer multiple of the underlying device block size, will havve to have some form of promiscuous IPC mechanism to communicate with each other. As has been pointed out before, advisory locking does not work on specfs or other vnodes not accessed through the VFS interface's struct vfsops. Although this could be corrected by moving the advisory lock list to the vnode, and removing all advisory locking code from every VFS (except the NFS client VFS), this work has not yet been done. Without buffering, a supra-record offset granularity would need to be maintained and communicated between multiple programs that are accessing the character device on non-block boundaries. This is a can of worms. > Using mmap(2) to provide a new type of buffered semantics for > disk-like devices is insteresting, but its applicability will be > limited by the virtual address space of a process: you can't map > a 20GB database into a 32bit address space, so a lot of mmap(2) > calls will be needed for serious sized data. The need for, and > actual use of such a facility seemes uncertain. Agreed. > There is general disagreement about how much code we save, but > nobody disputes that we will be able to remove some amount of > complexity from the kernel. Most people seem to overlook the > needlessly replicated code in a number of xxx(8) tools to DTRT with > /dev/foo vs /dev/rfoo. I think if these tools are written to operate on the less limited block device, they should simply refuse to operate on the more limited character device. This is an elegant soloution, and some message morally equivalent to "use the block device, dummy" would be adequate to get the user to do the right thing, rather than making up for the inadequacies of the user. (down that road lies ruin and "undelete" and "unnewfs"). > Implementing an ioctl(2) to switch a disk-like device into bdev > mode is relatively trivial, but there currently seems to be no > point in doing so. I think the point in doing this would be to ensure that code would not be broken by the OS, and could be forced to work. I would not object to removal of the block devices (except on standards conformance based grounds), if it were guaranteed that such an ioctl() would be implemented before their removal, and that a user desiring to do so could override the "MAKEDEV" to create "block" devices, on which this ioctl() call was implicitly called on open. This would certainly satisfy the "legacy/standards crowd", I think, while still allowing the surgery you want to perform. > There is a significant majority supporting the removal of bdev > semantics. Majority is not a measure of technical merit. I think a character device that allowed block semantics, but would discard cache buffers if accessed on block boundaries would equally suffice to address the issue of unification of the block and character device namespace, which I think is the real issue here. However, an ioctl() based soloution, with a compatability mode which is not enabled by default (but must be capable of being soft-enabled) would suffice. > An ioctl(2) based mode-switch will only be implemented if a > very good reason for doing so materializes. I think that the fact that we can't know about all software, and that the standards specify block devices, argues for some form of legacy support mechanism, even ifit isn't enabled by default for FreeBSD systems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 14 14:41:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5B73914BDC for ; Thu, 14 Oct 1999 14:41:22 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA16005 for ; Thu, 14 Oct 1999 23:41:22 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA45371 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 23:41:21 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 859E014BDC for ; Thu, 14 Oct 1999 14:41:11 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40324>; Fri, 15 Oct 1999 07:37:01 +1000 Content-return: prohibited Date: Fri, 15 Oct 1999 07:41:01 +1000 From: Peter Jeremy Subject: Multiple VAS [Re: The eventual fate of BLOCK devices.] In-reply-to: <199910141515.IAA35743@pau-amma.whistle.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct15.073701est.40324@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <447.939897820@critter.freebsd.dk> <199910141515.IAA35743@pau-amma.whistle.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-15 01:15:04 +1000, David Wolfskill wrote: >So IBM came up with an "interesting" concept... "data only" address >spaces: A program would run in one address space, and request that the >OS create a new address space for it to play in. The (first -- don't >recall the official term) AS would then denote a range within this new >AS, and cause data to be placed into it. It's not clear to me how a process using 32-bit (or 31-bit) pointers can access multiple 31-bit address spaces. However I look at it, you appear to need to issue a system call to get the kernel to change the page table mappings. And once you have to go into the kernel, you've lost a lot of the advantage. This is actually one area where the segmented IA32 architecture could have been useful. Unfortunately, Intel (IMHO) got it backwards (again) and segmented the single 32-bit VAS, instead of allowing each segment to describe an independent 32-bit VAS. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 14 17: 0:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7133414F2B for ; Thu, 14 Oct 1999 17:00:42 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA17187 for ; Fri, 15 Oct 1999 02:00:41 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA46097 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 02:00:40 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6496D14F2B for ; Thu, 14 Oct 1999 17:00:31 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id QAA45490; Thu, 14 Oct 1999 16:56:26 -0700 (PDT) Date: Thu, 14 Oct 1999 16:56:25 -0700 (PDT) From: Julian Elischer To: freebsd-arch@freebsd.org Cc: mckusick@mckusick.com Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910142056.NAA29867@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 14 Oct 1999, Terry Lambert wrote: > First of all, thanks to everyone for such a focussed discussion. > > I have some comments on Poul's comments, and would at least like > to argue for a "legacy mode", even if it is not enabled by default, > so long as it can be enabled (and implied) without a kernel recompile > (but perhaps requiring a kernel module), for standards compliance > reasons, if no other. I have mentionned before, and I will mention again, that if a standard disk layer is implemented, then it would be quite easy to implement a block buffered interface to the raw disks, purely within the disk layer. I could imagine simply taking the highest bit in the minor number to indicate raw or blocked access. I could even ahppily see the next highest bit being used to indicate write-through or write-back behaviour. (there are 24 bits and if we probably don't need them all.) This would remove all bdevs from the system and still give us 'buffered disk devices if they were needed. > > > > > I would add: > > 4) Programs which want to treat object in the filespace as if > they were byte streams. e.g. I have quite often used dd to extract the MBR table from the disk with the command: dd if=/dev/wd0 of=/tmp/table bs=1 skip=446 count=64 I could of course do this in 2 steps, first reading the block and then extracting the bytes, but it's an example of something 'breaking'. > > In other words, it shouldn't matter, and I should not have to > give special arguments to programs such as "tar" and "dd" and "team" > to do I/O in variable media blocking factors. > > I think I would also add: > > 5) Programs that have to deal with CDROM's containing multiple > sessions. > > This is an issues, since not all data is 2048 byte blocks, but > can in fact be 2352, or a physical sector size of 2048, 2336, or > 2340 bytes. This will only get more complicated as DVD and other > standards evolve and come online. I'm not sure this would work anyhow ans I think our bufferring code may explode with non binary blocksizes. You also don't want to flush your vm buffers with some top-40 song.. :-) > > In addition, many WORM, mageneto-optical, and Japanese hard > drives (such as those by default in the NEC PC-98) are 1024 bytes. > > I would have that complexity hidden from the user, who is most > interested in a linear array of bytes of arbitrary length, and > in seeking to non-block aligned offsets in the linear array. true, it would be nice.. > > > > Database software prefer cdev semantics if at all possible, if > > running on anything but a cdev database software call fsync(2) a > > lot to make sure the writes have hit the media. > > I would argue that such database software is either broken, or > it is expecting a broken kernel (one which does not do the correct > thing on block device descriptors marked O_SYNC -- such as FreeBSD's > existing block device semantics). I think this was the reason for John Dyson's async IO stuff. Does it work as expected on raw devices? I presume so. > > > > Terry argues for retaining the bdev semantics rather than the cdev > > semantics, but I think we can dismiss that idea based on the above > > observation: it would penalize software which know better. Retaining > > the bdev would in essence be emulating the mistake Linux made, and > > which they are now unmaking. > > I think that for "software that knows better", i.e. software that > has called fstat(2) to get st_blksize, and intentionally performs > aligned writes, that it would be trivial to determine if a write > was on a block boundary, and spanned an integer number of blocks, > and therefore not penalize the smarter software. This is really > an implementation issue, not a performance issue. It doesn't help if what you are trying to do is use the buffer cache to cache.. especially if you are doing so , so that different processes can benefit from each other's cach filling activities. > > > > The filesystem maintenance applications mentioned so far which rely > > on bdev semantics, the EXT2FS tools, can be trivially converted to > > operate on cdev semantics. The majority of such tools already > > correctly operate on cdevs. > > I believe the tools should be implemented via a different API, > since the kernel already knows about slices, partitions, etc., > and has to have that knowledge embedded in it. So either way, > the tools promiscuous knowledge of stuff that they really have no > right knowing in the first place isn't an argument for getting > rid of block devices -- nor an argument in favor of keeping them. That's a whole different question, and having tried to implement it I know it has its own pitfalls. You end up having to know some insestuous information no matter what you do. > > > > Savecore(8) has already been converted to operate on cdevs. > > Irrelevent, I think, as well. > > Clearly, we could convert the entirety of all FTP'able software > on the Internet to do its own block size determination, and > do buffering in user space thereafter. I think this would be > wasteful. > > As Julian didn't point out, but probably meant to with his example, > Multiple fromas operating at a granularity of sizeof(struct foo), > where sizeof(struct foo) is not an integer multiple of the underlying > device block size, will havve to have some form of promiscuous IPC > mechanism to communicate with each other. > "fromas"? I assume that was a neural spasm attacking while the fingers were being ordered to type "processes". Well they wouldn't need it if htey were working through a coherent cache system (and most of them were readers). > > Without buffering, a supra-record offset granularity would need > to be maintained and communicated between multiple programs that > are accessing the character device on non-block boundaries. > > This is a can of worms. > > > > Using mmap(2) to provide a new type of buffered semantics for > > disk-like devices is insteresting, but its applicability will be > > limited by the virtual address space of a process: you can't map > > a 20GB database into a 32bit address space, so a lot of mmap(2) > > calls will be needed for serious sized data. The need for, and > > actual use of such a facility seemes uncertain. > > Agreed. Also Mmap has disadvantages which plain old read/write get around. you need to 'touch' a mmapped page to actually initiate the transfer which may be aslightly more complicated operation than one expects. > > > > There is general disagreement about how much code we save, but > > nobody disputes that we will be able to remove some amount of > > complexity from the kernel. Most people seem to overlook the > > needlessly replicated code in a number of xxx(8) tools to DTRT with > > /dev/foo vs /dev/rfoo. > > I think if these tools are written to operate on the less limited > block device, they should simply refuse to operate on the more > limited character device. This is an elegant soloution, and some > message morally equivalent to "use the block device, dummy" would > be adequate to get the user to do the right thing, rather than > making up for the inadequacies of the user. (down that road lies > ruin and "undelete" and "unnewfs"). I doubt that we would save much (already written) code froem the tools. Some, but not an amount that would influence this decision. > > > > Implementing an ioctl(2) to switch a disk-like device into bdev > > mode is relatively trivial, but there currently seems to be no > > point in doing so. that's no real good from my perspective as you need to add extra code to do the ioctl.. where did the 'simplification of code' go? > > I think the point in doing this would be to ensure that code > would not be broken by the OS, and could be forced to work. Not without modification. > > I would not object to removal of the block devices (except on > standards conformance based grounds), if it were guaranteed > that such an ioctl() would be implemented before their removal, > and that a user desiring to do so could override the "MAKEDEV" > to create "block" devices, on which this ioctl() call was implicitly > called on open. We are adding more and more complexity back.. > > This would certainly satisfy the "legacy/standards crowd", I > think, while still allowing the surgery you want to perform. > > > > There is a significant majority supporting the removal of bdev > > semantics. Actually I see it as "A few detirmined people (I count 3) for it, a few (I also count 3) against it, and a whole pile of people who, judging by their total lack of activity, couldn't care less". > Majority is not a measure of technical merit. Win95? > > I think a character device that allowed block semantics, but would > discard cache buffers if accessed on block boundaries would equally > suffice to address the issue of unification of the block and character > device namespace, which I think is the real issue here. Unless you were looking for it to KEEP the information to speed up the next access. > > However, an ioctl() based soloution, with a compatability mode which > is not enabled by default (but must be capable of being soft-enabled) > would suffice. Once again. it would solve a subset of the needs. > > > > An ioctl(2) based mode-switch will only be implemented if a > > very good reason for doing so materializes. > > I think that the fact that we can't know about all software, and > that the standards specify block devices, argues for some form > of legacy support mechanism, even if it isn't enabled by default > for FreeBSD systems. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > > > > 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 Thu Oct 14 17: 5:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 132E214F2B for ; Thu, 14 Oct 1999 17:05:18 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA17265 for ; Fri, 15 Oct 1999 02:05:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA46170 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 02:05:16 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 61F2E14F2B for ; Thu, 14 Oct 1999 17:05:09 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA45884; Thu, 14 Oct 1999 17:04:58 -0700 (PDT) Date: Thu, 14 Oct 1999 17:04:58 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <447.939897820@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 14 Oct 1999, Poul-Henning Kamp wrote: > > [I know it was Julian who threw this ball in the air, but I take > the liberty of doing the final round: I have been the primus > motor on this issue from the beginning and it is part of the > dev_t cleanup project.] [see my other response to Terry] > > SUMMARY: [...] > Unless we have significant new information to the contrary, I will > commence the bdev removal after November 1st 1999. This is I think a bit "pushy" for such an important step. How about: "We will ask for a declaration of the right thing to do from Core, specifically, DG as Arbiter, (not as DG) on Novenber 1. So all arguments either way should be completed by that time." All sides involved should agree to let the matter rest after the decision has been reached. > > In order to try to trigger any such information, I will change > the default value of the vfs.bdev_buffered sysctl to zero this > weekend, this will make bdevs react like cdevs. I would suggest instead turning off Matt's sysctl which will make the bdevs completely fail. (hmm oh yeah fsck / would fail.... hmmm) Using your ioctl may act more to simply corrupt data than to make people notice the change. > > An ioctl(2) based mode-switch will only be implemented if a > very good reason for doing so materializes. > > Thanks for participating. > > Poul-Henning > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > > > 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 Thu Oct 14 18:22:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9E98114E09 for ; Thu, 14 Oct 1999 18:22:01 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA19502 for ; Fri, 15 Oct 1999 03:21:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA46441 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 03:21:56 +0200 (MET DST) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 52D9314E09 for ; Thu, 14 Oct 1999 18:21:18 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id SAA20382; Thu, 14 Oct 1999 18:21:07 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpdAAAbpaaVN; Thu Oct 14 18:21:01 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA20401; Thu, 14 Oct 1999 18:21:04 -0700 (MST) From: Terry Lambert Message-Id: <199910150121.SAA20401@usr01.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: julian@whistle.com (Julian Elischer) Date: Fri, 15 Oct 1999 01:21:04 +0000 (GMT) Cc: freebsd-arch@freebsd.org, mckusick@mckusick.com In-Reply-To: from "Julian Elischer" at Oct 14, 99 04:56:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's an argument I haven't heard before, and then a response to Julian: Question 1: How will I netboot my non-FreeBSD OS that requires block devices using an NFS mounted / containing that OS's /dev, if FreeBSD can not support block devices in its FS? Question 2: If block device nodes are still allowed in the FS on a FreeBSD box, what's the point of not allowing variant behaviour based on an implied ioctl in the open routine for 'b' vs. 'c' nodes? Question 3: If a single if test based on the 'b'-ness of a device is allowed at open time (no real performance penalty for operations against already open 'c' devices), why should I not be able to call variant code (e.g. ioctl)? Question 4: If the arguemnt is simply against the variant code being in the kernel by default, then why not permit it in a kernel module, which need not be loaded by default (or could be loaded by default, except on people who hate block devices systems)? It seem logical to me to allow legacy systems to netboot, and therefore block device nodes to be created, and therefore, since it can't hurt to have code variant on 'b'-ness, if 'b'-ness is never used by people who don't like it, check if a function pointer is null, and fail as if block devices are not supported, and have a kernel module that sets the pointer non-null when it is loaded. [ ... in response to Julian ... ] > > This is an issues, since not all data is 2048 byte blocks, but > > can in fact be 2352, or a physical sector size of 2048, 2336, or > > 2340 bytes. This will only get more complicated as DVD and other > > standards evolve and come online. > > I'm not sure this would work anyhow ans I think our bufferring code may > explode with non binary blocksizes. You also don't want to flush your vm > buffers with some top-40 song.. :-) That depends. I might, if I were mastering a CD on a read/write device before burning it. Not to say that the FS that can do this currently exists, but the change suggested would certainly preclude it ever existing. > > I would argue that such database software is either broken, or > > it is expecting a broken kernel (one which does not do the correct > > thing on block device descriptors marked O_SYNC -- such as FreeBSD's > > existing block device semantics). > > I think this was the reason for John Dyson's async IO stuff. > Does it work as expected on raw devices? I presume so. My point was that it can be made to report errors correctly by using the correct open mode, and by fixing FreeBSD to honor that open mode, not that the concept was broken, but that the applications use of the devices without the concept in force was broken. > > > Terry argues for retaining the bdev semantics rather than the cdev > > > semantics, but I think we can dismiss that idea based on the above > > > observation: it would penalize software which know better. Retaining > > > the bdev would in essence be emulating the mistake Linux made, and > > > which they are now unmaking. > > > > I think that for "software that knows better", i.e. software that > > has called fstat(2) to get st_blksize, and intentionally performs > > aligned writes, that it would be trivial to determine if a write > > was on a block boundary, and spanned an integer number of blocks, > > and therefore not penalize the smarter software. This is really > > an implementation issue, not a performance issue. > > It doesn't help if what you are trying to do is use the buffer cache to > cache.. especially if you are doing so , so that different processes can > benefit from each other's cach filling activities. The data will still be in buffer cache; it will just be hung off the device vnode. > > I believe the tools should be implemented via a different API, > > since the kernel already knows about slices, partitions, etc., > > and has to have that knowledge embedded in it. So either way, > > the tools promiscuous knowledge of stuff that they really have no > > right knowing in the first place isn't an argument for getting > > rid of block devices -- nor an argument in favor of keeping them. > > That's a whole different question, and having tried to implement it I know > it has its own pitfalls. You end up having to know some insestuous > information no matter what you do. Having implemented precisely this on SVR4, I don't see the pitfalls to which you are referring. A single ioctl() to ask about the available partitioning methods, including the one preferred by the device, another to get available space & size & allowable count, etc., and another to instantiate or deinstatiate an instance based on a variable length array, based on the actual count. The idea of slicing things up into subregions, region contiguity and overlap rules, etc., can all be made abstract via an API; it's quite trivial. It only gets complicated if you try and write the information on raw partitions from user space, and under an API based scheme, that's not an allowable operation. > > As Julian didn't point out, but probably meant to with his example, > > Multiple fromas operating at a granularity of sizeof(struct foo), > > where sizeof(struct foo) is not an integer multiple of the underlying > > device block size, will havve to have some form of promiscuous IPC > > mechanism to communicate with each other. > > > > "fromas"? I assume that was a neural spasm attacking while the fingers > were being ordered to type "processes". No, it was an editor esacpe character timeout glitch over a slow link, and yes, it was supposed to be "processes". > Well they wouldn't need it if htey were working through a coherent > cache system (and most of them were readers). For files, this is true, for character devices, this is not true. Say I have a structure of 32 bytes in length, and I want to write the third one in the file. The unavailability of the block device means that I must find out the block size, get a buffer of that size, read in the first block, modify the data starting 64 bytes into the buffer for 32 bytes, and then write out the whole block. This means that even if I have a locking mechanism (e.g. Sybase's) that lets me lock the third block, someone may race me to another structure in the block, and then I will overwrite their data with the previous contents. User buffering for sub-block boundaries is unacceptable in a multiprocess environment. Additionally, this seems to be counter-intuitive, if only from first principles: I am supposed to be able to treat devices as I can any other object in the filesystem for which I have read or write permission, when I am reading or writing. I believe there is a seperate limitation, as well, which was stated in the orginal design goals (and may be in POSIX), which is to say that block devices are seekable. [ ... an ioctl() to turn on block buffering ... ] > > I would not object to removal of the block devices (except on > > standards conformance based grounds), if it were guaranteed > > that such an ioctl() would be implemented before their removal, > > and that a user desiring to do so could override the "MAKEDEV" > > to create "block" devices, on which this ioctl() call was implicitly > > called on open. > > We are adding more and more complexity back.. Not really. The complexity argument is (supposedly) based on the coherency arguemnt, not the amount of code argument. As I satated before, you could mute the "amount of code" argument simply by placing the implementation code into a kernel module. As for complexity in bdevsw[] vs. cdevsw[], apart from the fact that both are long due for pasture based on a devfs or similar soloution, it would be easy to declare that, on a system where the module was loaded, access to a block device inode was the same as access to a character device inode + the ioctl(), and there is a 1:1 correspondance between block and character devices in this world (much of the complexity argument appears to depend on the desynchronization of these tables, and the idea that both tables must, for some unknown reason, be somehow maintained in any implementation). > > I think a character device that allowed block semantics, but would > > discard cache buffers if accessed on block boundaries would equally > > suffice to address the issue of unification of the block and character > > device namespace, which I think is the real issue here. > > Unless you were looking for it to KEEP the information to speed up the > next access. The blocks *won't* be cached off the vnode for a character device? This flies in the face of reason... not to mention file system performance. I don't believe it. > > However, an ioctl() based soloution, with a compatability mode which > > is not enabled by default (but must be capable of being soft-enabled) > > would suffice. > > Once again. it would solve a subset of the needs. With a compatability mode, you would not know the difference, so long as the module was loaded, and the devices created. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 5:24: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 14BE314CDE for ; Fri, 15 Oct 1999 05:24:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA00316 for ; Fri, 15 Oct 1999 14:23:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA48726 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 14:23:57 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 8558B14CDE for ; Fri, 15 Oct 1999 05:23:46 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id NAA00353 for arch@FreeBSD.org; Fri, 15 Oct 1999 13:57:32 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 15 Oct 1999 13:57:24 +0200 From: Marcel Moolenaar Message-ID: <380716A4.20961526@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Some flaws in the "make world" became apparent when the sigset_t datatype changed. One of the biggest problems right now is that we don't have an upgrade path from -stable to -current. Especially with 4.0 being released early next year. I want to start a discussion here on how to properly implement make world. I start of with known issues/problems and some points that are not necessarily problems. Following that I give an indication of what I'm thinking about by summing a number of design "points" that I have in mind. I finish with the notion that you can help :-) Known issues/problems: P1. the upgrade path is broken. P2. aout to elf seems to be broken too. P3. no cross compilation. P4. buildworld must be performed as root. P5. sys.mk pollution. Questionable issues: P6. no kernel is made as part of world. P7. installworld may fail for -j>0. P8. makefile complexity. P9. dumb make process. ad P7: it is possible for a task to want to run install while another task is installing it. ad P9: a buildworld starts by clearing /usr/obj by default and then generating everything. This can be controlled by NOCLEAN and NOTOOLS, by which you enter the twilight zone :-) Make world design points: D1. redesign the make world process from scratch. This should prevent P8 from becoming worse and also may help solve P5. D2. introduce TARGET_ARCH and TARGET_OBJ to specify for which architecture and object format we are building (resp.). MACHINE_ARCH and MACHINE_OBJ will be set to reflect the current (ie running) environment. This should help fix P3. D3. assume 3 "roots" in the build-process: SRCROOT, OBJROOT and INSTROOT. These point to the root of the source tree, the root of the object tree and the root of the install tree (resp). SRCROOT is assumed to be read-only. OBJROOT is assumed to be writable by priviledged users and INSTROOT is assumed to be writable by root only. This should help fix P4. D4. allow concurrent cross-builds by defining a TRGTROOT under OBJROOT using TARGET_ARCH and TARGET_OBJ. If, for example, OBJROOT=/usr/obj, TARGET_ARCH=i386 and TARGET_OBJ=elf, then TGTROOT can be defined as cross-build for the Alpha can be performed at the same time (TRGTROOT=/usr/obj/alpha/elf). This may help in fixing P9 and may be advanteous in making snapshots and releases on build-machines. D5. build tools that are necessary for cross-building only if necessary. If possible use the installed tools. If tools need to be made, make them as machine native binaries and install them under TRGTROOT. This implies that includes are taken from /usr/include and that libraries are sought from /usr/lib. This helps P3 and P9. D6. do not use chown, chgrp and chflags for anything created and installed under TRGTROOT. This fixes P4. D7. make a kernel as part of the build process. Use GENERIC if KERNEL has not been befined, otherwise make ${KERNEL}. This helps P1 and P2 and solves P6. More vague points: D8. the build-process starts with creating a minimal hierarchy under TRGTROOT, after which all necessary tools are checked and created if necessary. The build should start with includes and libraries, followed by everything else according to dependencies. D9. allow a "smart" build by taking modifications to makefiles into account. If for example /usr/src/usr.bin/Makefile has been updated after /usr/obj/.../usr.bin has been created, remove /usr/obj/.../usr.bin completely. This also holds for programs/libraries. This should minimize unnecessary rebuilding, but with the proper conservatism. A second builworld should therefore don't have to do anything when it is started immediately after the first has completed. D10. it should be possible to build a single program just as it can be done now. There are probably more points, but this is what comes to mind first. If you have suggestions, criticism, additions or time, let me (us) know! thanks, -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Oct 15 6: 2:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5524D14D71 for ; Fri, 15 Oct 1999 06:02:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA01314 for ; Fri, 15 Oct 1999 15:02:16 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA48884 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 15:02:16 +0200 (MET DST) Received: by hub.freebsd.org (Postfix, from userid 608) id 7CF6414D71; Fri, 15 Oct 1999 06:02:06 -0700 (PDT) From: "Jonathan M. Bresler" To: marcel@scc.nl Cc: arch@freebsd.org In-reply-to: <380716A4.20961526@scc.nl> (message from Marcel Moolenaar on Fri, 15 Oct 1999 13:57:24 +0200) Subject: Re: make world issues Message-Id: <19991015130206.7CF6414D71@hub.freebsd.org> Date: Fri, 15 Oct 1999 06:02:06 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Some flaws in the "make world" became apparent when the sigset_t > datatype changed. One of the biggest problems right now is that we don't > have an upgrade path from -stable to -current. Especially with 4.0 being Marcel, I have successfully upgraded a box from stable to current, using a CVS tree. the method is to use a CVS tree to build current as of 19990927 first. then update the source tree to current, build and install a new kernel, then make world jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 6:25:31 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3BE3514CA3 for ; Fri, 15 Oct 1999 06:25:19 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA01714 for ; Fri, 15 Oct 1999 15:25:17 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA49001 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 15:25:02 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 563F215269 for ; Fri, 15 Oct 1999 06:23:47 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id PAA20879 for arch@FreeBSD.org; Fri, 15 Oct 1999 15:20:05 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 15 Oct 1999 15:19:57 +0200 From: Marcel Moolenaar Message-ID: <380729FD.629C2C5F@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991015130206.7CF6414D71@hub.freebsd.org> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jonathan M. Bresler" wrote: > > Some flaws in the "make world" became apparent when the sigset_t > > datatype changed. One of the biggest problems right now is that we don't > > have an upgrade path from -stable to -current. Especially with 4.0 being > > I have successfully upgraded a box from stable to current, > using a CVS tree. the method is to use a CVS tree to build current > as of 19990927 first. then update the source tree to current, > build and install a new kernel, then make world Thanks, that's good to know. I don't think we can expect joe user to do the same thing though and it's not exactly an upgrade path I like to present to our users... What I'm aiming for is that you can slap a current FreeBSD source tree on any runnable version of FreeBSD and perform a cross-build for the machine you want it to run on, whether that has the same architecture or the same object format as the machine you are using to build it or not. With such a capability more complex upgrade problems may be more easily solved (assuming I can't get what I'm aiming for of course :-). I certainly hope to make upgrading from 2.2.x to -current possible without more than a single "make world". -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Oct 15 8:53:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C40D315405 for ; Fri, 15 Oct 1999 08:53:25 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA03980 for ; Fri, 15 Oct 1999 17:53:24 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA49815 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 17:53:22 +0200 (MET DST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id EE53715405 for ; Fri, 15 Oct 1999 08:20:59 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id IAA39079 for ; Fri, 15 Oct 1999 08:20:59 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id IAA60135 for arch@freebsd.org; Fri, 15 Oct 1999 08:20:59 -0700 (PDT) (envelope-from obrien) Date: Fri, 15 Oct 1999 08:20:59 -0700 From: "David O'Brien" To: arch@freebsd.org Subject: Re: make world issues Message-ID: <19991015082059.C9753@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <380716A4.20961526@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <380716A4.20961526@scc.nl> X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Known issues/problems: > P1. the upgrade path is broken. > P2. aout to elf seems to be broken too. > P3. no cross compilation. > P4. buildworld must be performed as root. > P5. sys.mk pollution. P10. the compiler isn't built properly. The intergral libgcc needs half of it build buy the compiler you are compiling the new compiler with, and the second half by the compiler you just built. It is very hard to get proper access to both compilers at the right places. IFAIK, this would also affect cross compliation. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 10:25:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BF9891515C for ; Fri, 15 Oct 1999 10:25:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA05135 for ; Fri, 15 Oct 1999 19:25:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA50256 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 19:25:49 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 365D21519A for ; Fri, 15 Oct 1999 10:23:47 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id SAA74416 for arch@FreeBSD.org; Fri, 15 Oct 1999 18:54:56 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 15 Oct 1999 18:54:49 +0200 From: Marcel Moolenaar Message-ID: <38075C59.7E2670D1@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991015082059.C9753@dragon.nuxi.com> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > > Known issues/problems: > > P1. the upgrade path is broken. > > P2. aout to elf seems to be broken too. > > P3. no cross compilation. > > P4. buildworld must be performed as root. > > P5. sys.mk pollution. > > P10. the compiler isn't built properly. The intergral libgcc needs half > of it build buy the compiler you are compiling the new compiler with, and > the second half by the compiler you just built. It is very hard to get > proper access to both compilers at the right places. IFAIK, this would > also affect cross compliation. Hmmm... I always thought that gcc was bootstrapping: with the current compiler, build the bootstrap compiler. Use the bootstrap compiler to build the actual compiler. I have to dig into this again... -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Oct 15 11:13:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9ABA4151A1 for ; Fri, 15 Oct 1999 11:13:43 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA05589 for ; Fri, 15 Oct 1999 20:13:42 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA50502 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 20:13:40 +0200 (MET DST) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id EC1BF151A1 for ; Fri, 15 Oct 1999 11:13:31 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA40274 for ; Fri, 15 Oct 1999 11:13:31 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA64810 for arch@freebsd.org; Fri, 15 Oct 1999 11:13:30 -0700 (PDT) (envelope-from obrien) Date: Fri, 15 Oct 1999 11:13:30 -0700 From: "David O'Brien" To: arch@freebsd.org Subject: Re: make world issues Message-ID: <19991015111330.E9753@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <380716A4.20961526@scc.nl>, <19991015082059.C9753@dragon.nuxi.com> <38075C59.7E2670D1@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <38075C59.7E2670D1@scc.nl> X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 15, 1999 at 06:54:49PM +0200, Marcel Moolenaar wrote: > compiler, build the bootstrap compiler. Use the bootstrap compiler to > build the actual compiler. I have to dig into this again... If you have access to a 3.x box, look at src/contrib/gnu/usr.bin/cc/libgcc/Makefile. BDE removed the something that Peter was depending on to get the definition of XCC and XCXX (they are now set to just CC and CXX). The issues here lead to me having to move libgcc from src/contrib/gnu/usr.bin/cc/ to src/contrib/gnu/lib/ -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 14:43: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 699B214A26 for ; Fri, 15 Oct 1999 14:43:04 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA07431 for ; Fri, 15 Oct 1999 23:43:02 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA51226 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 23:43:01 +0200 (MET DST) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 34FFD14A26 for ; Fri, 15 Oct 1999 14:42:49 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id HAA78075; Sat, 16 Oct 1999 07:46:07 +1000 (EST) (envelope-from jb) Date: Sat, 16 Oct 1999 07:46:06 +1000 From: John Birrell To: "David O'Brien" Cc: arch@freebsd.org Subject: Re: make world issues Message-ID: <19991016074606.C67481@freebsd1.cimlogic.com.au> References: <380716A4.20961526@scc.nl> <19991015082059.C9753@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <19991015082059.C9753@dragon.nuxi.com>; from David O'Brien on Fri, Oct 15, 1999 at 08:20:59AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 15, 1999 at 08:20:59AM -0700, David O'Brien wrote: > > Known issues/problems: > > P1. the upgrade path is broken. > > P2. aout to elf seems to be broken too. > > P3. no cross compilation. > > P4. buildworld must be performed as root. > > P5. sys.mk pollution. > > P10. the compiler isn't built properly. The intergral libgcc needs half > of it build buy the compiler you are compiling the new compiler with, and > the second half by the compiler you just built. It is very hard to get > proper access to both compilers at the right places. IFAIK, this would > also affect cross compliation. I've found that cross-compiling is the easy bit. I build the cross-compilers as part of a host make world during which they never get executed. To build a cross-world, I just set MACHINE and MACHINE_ARCH and let sys.mk (more pollution 8-) check to see if these differ from what the kernel knows. If they differ, sys.mk sets CC etc to my cross-compiler and HOST_CC to cc. Then the make world uses NOTOOLS and DESTDIR. The few places in our tree where we build host tools in the obj tree during make world and execute them from there need simple makefile changes to use HOST_CC instead of CC. I don't think that cross-compilation helps solve the bootstrap/upgrade problem caused by the signal changes. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 14:50:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id F2DD414A26 for ; Fri, 15 Oct 1999 14:50:33 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA07498 for ; Fri, 15 Oct 1999 23:50:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA51310 for freebsd-arch@freebsd.org; Fri, 15 Oct 1999 23:50:32 +0200 (MET DST) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 1D722150C3 for ; Fri, 15 Oct 1999 14:49:36 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id HAA78106; Sat, 16 Oct 1999 07:52:51 +1000 (EST) (envelope-from jb) Date: Sat, 16 Oct 1999 07:52:51 +1000 From: John Birrell To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: make world issues Message-ID: <19991016075251.D67481@freebsd1.cimlogic.com.au> References: <380716A4.20961526@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <380716A4.20961526@scc.nl>; from Marcel Moolenaar on Fri, Oct 15, 1999 at 01:57:24PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 15, 1999 at 01:57:24PM +0200, Marcel Moolenaar wrote: > D2. > introduce TARGET_ARCH and TARGET_OBJ to specify for which architecture > and object format we are building (resp.). MACHINE_ARCH and MACHINE_OBJ > will be set to reflect the current (ie running) environment. This should > help fix P3. 'make' knows about MACHINE and MACHINE_ARCH. 'sysctl' can tell us what the kernel thinks it is. We should stick to using these. > D4. > allow concurrent cross-builds by defining a TRGTROOT under OBJROOT using > TARGET_ARCH and TARGET_OBJ. If, for example, OBJROOT=/usr/obj, > TARGET_ARCH=i386 and TARGET_OBJ=elf, then TGTROOT can be defined as > cross-build for the Alpha can be performed at the same time > (TRGTROOT=/usr/obj/alpha/elf). This may help in fixing P9 and may be > advanteous in making snapshots and releases on build-machines. To cross-build, I don't need to set so many things. On i386, I just: export MACHINE=alpha export MACHINE_ARCH=alpha make world There are a few commits I will make RSN to allow others to do this too. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 15:10: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1347E151D6 for ; Fri, 15 Oct 1999 15:10:06 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA07624 for ; Sat, 16 Oct 1999 00:10:02 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA51434 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 00:10:02 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6FAAB151D6 for ; Fri, 15 Oct 1999 15:09:52 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA35708; Fri, 15 Oct 1999 16:09:49 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA66179; Fri, 15 Oct 1999 16:11:12 -0600 (MDT) Message-Id: <199910152211.QAA66179@harmony.village.org> To: John Birrell Subject: Re: make world issues Cc: Marcel Moolenaar , arch@freebsd.org In-reply-to: Your message of "Sat, 16 Oct 1999 07:52:51 +1000." <19991016075251.D67481@freebsd1.cimlogic.com.au> References: <19991016075251.D67481@freebsd1.cimlogic.com.au> <380716A4.20961526@scc.nl> Date: Fri, 15 Oct 1999 16:11:12 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19991016075251.D67481@freebsd1.cimlogic.com.au> John Birrell writes: : On Fri, Oct 15, 1999 at 01:57:24PM +0200, Marcel Moolenaar wrote: : > D2. : > introduce TARGET_ARCH and TARGET_OBJ to specify for which architecture : > and object format we are building (resp.). MACHINE_ARCH and MACHINE_OBJ : > will be set to reflect the current (ie running) environment. This should : > help fix P3. : : 'make' knows about MACHINE and MACHINE_ARCH. 'sysctl' can tell us what : the kernel thinks it is. We should stick to using these. When I added TARGET_ARCH and TARGET I did it so that a make could be built that hard wired MACHINE and MACHINE_ARCH in the right way so that the tools could be built. Right now w/o them you have to have your own, hand built cross compile tools. : To cross-build, I don't need to set so many things. On i386, I just: : : export MACHINE=alpha : export MACHINE_ARCH=alpha : make world : : There are a few commits I will make RSN to allow others to do this too. Hmmmm, I'd be keen on reviewing them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 15 15:20:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7A88414D71 for ; Fri, 15 Oct 1999 15:20:33 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA07710 for ; Sat, 16 Oct 1999 00:20:32 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA51518 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 00:20:31 +0200 (MET DST) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 734DB14D71 for ; Fri, 15 Oct 1999 15:20:18 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id IAA78857; Sat, 16 Oct 1999 08:23:23 +1000 (EST) (envelope-from jb) Date: Sat, 16 Oct 1999 08:23:23 +1000 From: John Birrell To: Warner Losh Cc: John Birrell , Marcel Moolenaar , arch@freebsd.org Subject: Re: make world issues Message-ID: <19991016082323.F67481@freebsd1.cimlogic.com.au> References: <19991016075251.D67481@freebsd1.cimlogic.com.au> <380716A4.20961526@scc.nl> <19991016075251.D67481@freebsd1.cimlogic.com.au> <199910152211.QAA66179@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199910152211.QAA66179@harmony.village.org>; from Warner Losh on Fri, Oct 15, 1999 at 04:11:12PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Oct 15, 1999 at 04:11:12PM -0600, Warner Losh wrote: > In message <19991016075251.D67481@freebsd1.cimlogic.com.au> John Birrell writes: > : 'make' knows about MACHINE and MACHINE_ARCH. 'sysctl' can tell us what > : the kernel thinks it is. We should stick to using these. > > When I added TARGET_ARCH and TARGET I did it so that a make could be > built that hard wired MACHINE and MACHINE_ARCH in the right way so > that the tools could be built. Right now w/o them you have to have > your own, hand built cross compile tools. I don't. I just build a cross-compiler and a cross-assembler during the host `make world'. All the other tools are just the normal host tools (with the extra BFD formats if they are binutils tools). If sys.mk detects that I am cross-compiling it munges the things that are required to get the binutils programs to use the desired target format. > > : To cross-build, I don't need to set so many things. On i386, I just: > : > : export MACHINE=alpha > : export MACHINE_ARCH=alpha > : make world > : > : There are a few commits I will make RSN to allow others to do this too. > > Hmmmm, I'd be keen on reviewing them. I'll package them up when I get a chance. I need to send the gcc/egcs makefile hierarchy to David O'Brien for review anyway. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 3:54: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6F5B414D31 for ; Sat, 16 Oct 1999 03:54:02 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA21282 for ; Sat, 16 Oct 1999 12:54:01 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA57049 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 12:54:01 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 0E48414D31 for ; Sat, 16 Oct 1999 03:53:50 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id MAA44741 for arch@FreeBSD.org; Sat, 16 Oct 1999 12:50:20 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sat, 16 Oct 1999 12:50:09 +0200 From: Marcel Moolenaar Message-ID: <38085861.1A16B95C@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991016074606.C67481@freebsd1.cimlogic.com.au> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > I don't think that cross-compilation helps solve the bootstrap/upgrade > problem caused by the signal changes. I think it does. Please explain to me why you think cross-compilation doesn't solve bootstrapping/upgrading. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 4:13:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 73DE414E82 for ; Sat, 16 Oct 1999 04:13:25 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA21379 for ; Sat, 16 Oct 1999 13:13:09 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA57125 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 13:13:08 +0200 (MET DST) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id D23CE14E82 for ; Sat, 16 Oct 1999 04:12:31 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id VAA81111; Sat, 16 Oct 1999 21:14:49 +1000 (EST) (envelope-from jb) Date: Sat, 16 Oct 1999 21:14:49 +1000 From: John Birrell To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: make world issues Message-ID: <19991016211449.H67481@freebsd1.cimlogic.com.au> References: <380716A4.20961526@scc.nl>, <19991016074606.C67481@freebsd1.cimlogic.com.au> <38085861.1A16B95C@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <38085861.1A16B95C@scc.nl>; from Marcel Moolenaar on Sat, Oct 16, 1999 at 12:50:09PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Oct 16, 1999 at 12:50:09PM +0200, Marcel Moolenaar wrote: > John Birrell wrote: > > > > I don't think that cross-compilation helps solve the bootstrap/upgrade > > problem caused by the signal changes. > > I think it does. Please explain to me why you think cross-compilation > doesn't solve bootstrapping/upgrading. Because when cross-compiling, you don't execute anything that you build for the target system. By contrast, for the host build, you need to update things in bootstrap order and then progessively execute the updated things in order to complete the build. If you make a change (like the signal changes) that isn't backward compatible, then you can't bootstrap properly because you can't execute what you build. You shouldn't blame the build process for it's inability to handle the lack of backward compatibility in your code. We shouldn't allow changes to libc that won't work with older kernels. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 4:24:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6C12A14A25 for ; Sat, 16 Oct 1999 04:24:07 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA21443 for ; Sat, 16 Oct 1999 13:24:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA57198 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 13:24:06 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 87B7B14A25 for ; Sat, 16 Oct 1999 04:23:50 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id MAA46849 for arch@FreeBSD.org; Sat, 16 Oct 1999 12:58:42 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sat, 16 Oct 1999 12:58:34 +0200 From: Marcel Moolenaar Message-ID: <38085A5A.9FB6FF97@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > On Fri, Oct 15, 1999 at 01:57:24PM +0200, Marcel Moolenaar wrote: > > D2. > > introduce TARGET_ARCH and TARGET_OBJ to specify for which architecture > > and object format we are building (resp.). MACHINE_ARCH and MACHINE_OBJ > > will be set to reflect the current (ie running) environment. This should > > help fix P3. > > 'make' knows about MACHINE and MACHINE_ARCH. 'sysctl' can tell us what > the kernel thinks it is. We should stick to using these. Exactly. We should therefore not change the semantics of the variables by using them to specify the machine we are building for, instead of the machine we are running on (compiled for). If there's one thing you need to seperate during cross-compilation, then it's the machine you're running on and the machine you're building for. > > D4. > > allow concurrent cross-builds by defining a TRGTROOT under OBJROOT using > > TARGET_ARCH and TARGET_OBJ. If, for example, OBJROOT=/usr/obj, > > TARGET_ARCH=i386 and TARGET_OBJ=elf, then TGTROOT can be defined as > > cross-build for the Alpha can be performed at the same time > > (TRGTROOT=/usr/obj/alpha/elf). This may help in fixing P9 and may be > > advanteous in making snapshots and releases on build-machines. > > To cross-build, I don't need to set so many things. On i386, I just: > > export MACHINE=alpha > export MACHINE_ARCH=alpha > make world I'm talking concurrent cross-builds here. This means: make -j4 TARGET_ARCH=mips world & make -j4 TARGET_ARCH=alpha world & -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 4:54: 1 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 64CDC15490 for ; Sat, 16 Oct 1999 04:53:58 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA21722 for ; Sat, 16 Oct 1999 13:53:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA57308 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 13:53:57 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 12B4C15490 for ; Sat, 16 Oct 1999 04:53:50 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id NAA59177 for arch@FreeBSD.org; Sat, 16 Oct 1999 13:49:04 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sat, 16 Oct 1999 13:48:57 +0200 From: Marcel Moolenaar Message-ID: <38086629.848BC1BF@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <380716A4.20961526@scc.nl>, <19991016211449.H67481@freebsd1.cimlogic.com.au> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > On Sat, Oct 16, 1999 at 12:50:09PM +0200, Marcel Moolenaar wrote: > > John Birrell wrote: > > > > > > I don't think that cross-compilation helps solve the bootstrap/upgrade > > > problem caused by the signal changes. > > > > I think it does. Please explain to me why you think cross-compilation > > doesn't solve bootstrapping/upgrading. > > Because when cross-compiling, you don't execute anything that you > build for the target system. I don't disagree on that :-) > By contrast, for the host build, you need to update things in bootstrap > order and then progessively execute the updated things in order to > complete the build. This is perfectly fine, as long as you use the native headers and libraries for building the bootstrap tools. This is what's wrong with our current build process. If you fix this, you can build releases for Alpha on i386 or build an IA64 world without actually having FreeBSD on IA64 yet. > If you make a change (like the signal changes) > that isn't backward compatible, then you can't bootstrap properly > because you can't execute what you build. You said a couple of lines above: \begin{quote} > Because when cross-compiling, you don't execute anything that you > build for the target system. \end{quote} I don't have anything to add to that :-) > You shouldn't blame the build process for it's inability to handle > the lack of backward compatibility in your code. We shouldn't allow > changes to libc that won't work with older kernels. I disagree. The build process is clearly at fault for mixing tool builds with target builds. Bloating libc is not a solution; it's a work-around. This implies that the bug is still their and it's going to bite you again (and again). And worst of all, in 20 years time FreeBSD will be the bloatest and slowest and most unstable OS on the world, because libc will have most of the kernel duplicated in userland simply to have it run on an archaic kernel for an (as then) obsoletedarchitecture... No. libc should be lean and mean, with only necessary compatibility added to it -- source compatibility that is, not kernel compatibility. footnote: IMO, of course :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 9:19: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F2AE14CCB for ; Sat, 16 Oct 1999 09:19:05 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA23684 for ; Sat, 16 Oct 1999 18:19:04 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA63472 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 18:19:03 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6269814CCB for ; Sat, 16 Oct 1999 09:18:56 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA39925; Sat, 16 Oct 1999 10:18:56 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA74984; Sat, 16 Oct 1999 10:20:28 -0600 (MDT) Message-Id: <199910161620.KAA74984@harmony.village.org> To: Marcel Moolenaar Subject: Re: make world issues Cc: arch@freebsd.org In-reply-to: Your message of "Sat, 16 Oct 1999 12:58:34 +0200." <38085A5A.9FB6FF97@scc.nl> References: <38085A5A.9FB6FF97@scc.nl> <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> Date: Sat, 16 Oct 1999 10:20:28 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <38085A5A.9FB6FF97@scc.nl> Marcel Moolenaar writes: : I'm talking concurrent cross-builds here. This means: : make -j4 TARGET_ARCH=mips world & make -j4 TARGET_ARCH=alpha world & At one point MACHINE was part of the OBJDIR path. Is that no longer the case? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 10:12:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 76A5714FA8 for ; Sat, 16 Oct 1999 10:12:25 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA24077 for ; Sat, 16 Oct 1999 19:12:25 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA63586 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 19:12:24 +0200 (MET DST) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 3946615111 for ; Sat, 16 Oct 1999 10:11:45 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11cXNt-000BAD-00; Sat, 16 Oct 1999 17:12:46 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id TAA60454; Sat, 16 Oct 1999 19:11:35 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <3808B1C7.742ECEFD@scc.nl> Date: Sat, 16 Oct 1999 19:11:35 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: arch@freebsd.org Subject: Re: make world issues References: <38085A5A.9FB6FF97@scc.nl> <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> <199910161620.KAA74984@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <38085A5A.9FB6FF97@scc.nl> Marcel Moolenaar writes: > : I'm talking concurrent cross-builds here. This means: > : make -j4 TARGET_ARCH=mips world & make -j4 TARGET_ARCH=alpha world & > > At one point MACHINE was part of the OBJDIR path. Is that no longer > the case? No. make(1) is installed into /usr/obj/usr/src/tmp/usr/bin, for example. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 10:15: 2 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B915214FA8 for ; Sat, 16 Oct 1999 10:15:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA24126 for ; Sat, 16 Oct 1999 19:14:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA63614 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 19:14:59 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 603D514FA8 for ; Sat, 16 Oct 1999 10:14:51 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA40043; Sat, 16 Oct 1999 11:14:50 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA75223; Sat, 16 Oct 1999 11:16:23 -0600 (MDT) Message-Id: <199910161716.LAA75223@harmony.village.org> To: Marcel Moolenaar Subject: Re: make world issues Cc: arch@freebsd.org In-reply-to: Your message of "Sat, 16 Oct 1999 19:11:35 +0200." <3808B1C7.742ECEFD@scc.nl> References: <3808B1C7.742ECEFD@scc.nl> <38085A5A.9FB6FF97@scc.nl> <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> <199910161620.KAA74984@harmony.village.org> Date: Sat, 16 Oct 1999 11:16:23 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3808B1C7.742ECEFD@scc.nl> Marcel Moolenaar writes: : > At one point MACHINE was part of the OBJDIR path. Is that no longer : > the case? : : No. make(1) is installed into /usr/obj/usr/src/tmp/usr/bin, for example. I could have sworn that I added ${TARGET} to the OBJDIR when cross compiling, but it looks like that was removed from Makefile.inc1 either before I committed it, or in some other cleanup of Makefile.inc1 since then. That's all that is needed to do what you propose. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 10:56:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 93CA314BEB for ; Sat, 16 Oct 1999 10:56:15 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA24576 for ; Sat, 16 Oct 1999 19:56:14 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA64360 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 19:56:14 +0200 (MET DST) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 0699514BEB for ; Sat, 16 Oct 1999 10:56:07 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11cY4s-000BZO-00; Sat, 16 Oct 1999 17:57:10 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id TAA61714; Sat, 16 Oct 1999 19:56:00 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <3808BC30.2699465B@scc.nl> Date: Sat, 16 Oct 1999 19:56:00 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: arch@freebsd.org Subject: Re: make world issues References: <3808B1C7.742ECEFD@scc.nl> <38085A5A.9FB6FF97@scc.nl> <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> <199910161620.KAA74984@harmony.village.org> <199910161716.LAA75223@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <3808B1C7.742ECEFD@scc.nl> Marcel Moolenaar writes: > : > At one point MACHINE was part of the OBJDIR path. Is that no longer > : > the case? > : > : No. make(1) is installed into /usr/obj/usr/src/tmp/usr/bin, for example. > > I could have sworn that I added ${TARGET} to the OBJDIR when cross > compiling, but it looks like that was removed from Makefile.inc1 > either before I committed it, or in some other cleanup of > Makefile.inc1 since then. That's all that is needed to do what you > propose. It basicly is. I also thought about adding TARGET_OBJ to it, though... -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 16 14:37:13 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 171D114CE7 for ; Sat, 16 Oct 1999 14:37:03 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA26363 for ; Sat, 16 Oct 1999 23:37:03 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA65886 for freebsd-arch@freebsd.org; Sat, 16 Oct 1999 23:37:02 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 16E9414CE7 for ; Sat, 16 Oct 1999 14:36:50 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA00747; Sat, 16 Oct 1999 15:36:48 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA01266; Sat, 16 Oct 1999 15:36:12 -0600 (MDT) Message-Id: <199910162136.PAA01266@harmony.village.org> To: Marcel Moolenaar Subject: Re: make world issues Cc: arch@freebsd.org In-reply-to: Your message of "Sat, 16 Oct 1999 19:56:00 +0200." <3808BC30.2699465B@scc.nl> References: <3808BC30.2699465B@scc.nl> <3808B1C7.742ECEFD@scc.nl> <38085A5A.9FB6FF97@scc.nl> <380716A4.20961526@scc.nl>, <19991016075251.D67481@freebsd1.cimlogic.com.au> <199910161620.KAA74984@harmony.village.org> <199910161716.LAA75223@harmony.village.org> Date: Sat, 16 Oct 1999 15:36:12 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3808BC30.2699465B@scc.nl> Marcel Moolenaar writes: : It basicly is. I also thought about adding TARGET_OBJ to it, though... I don't think there is a real need to do that, since we're ELF now and the transition to -current can be made to happen (eg take your pre-3.x system and the 3.2 release sources, do a make upgrade. From there boot a -current kernel and do a make world). However, if someone is seriously motivated to fix the aout->elf transition, go for it. Personally, I would have included backward compatibiltiy shims in libc for the signal stuff for a while, but that appears to have been hard to do... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message