From owner-freebsd-arch@FreeBSD.ORG Sun Nov 9 17:07:15 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A974C16A4CE for ; Sun, 9 Nov 2003 17:07:15 -0800 (PST) Received: from beastie.mckusick.com (64118105180.sierratel.com [64.118.105.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9087543FAF for ; Sun, 9 Nov 2003 17:07:14 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id hA9NptaG001289; Sun, 9 Nov 2003 15:51:55 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200311092351.hA9NptaG001289@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Sat, 08 Nov 2003 19:35:16 +1100." <20031108191433.J608@gamplex.bde.org> Date: Sun, 09 Nov 2003 15:51:55 -0800 From: Kirk McKusick cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 01:07:15 -0000 > Date: Sat, 8 Nov 2003 19:35:16 +1100 (EST) > From: Bruce Evans > X-X-Sender: bde@gamplex.bde.org > To: Kirk McKusick > Cc: arch@freebsd.org > Subject: Re: newfs and mount vs. half-baked disks > X-ASK-Info: Whitelist match > > On Fri, 7 Nov 2003, Kirk McKusick wrote: > > > > From: Bruce Evans > > > ... > > > Some cases can be discerned anyway, depending on how much erasing of > > > metadata newfs does when it starts. E.g., if there was an ffs file > > > system on the disk, then this will be recorded in the disk label unless > > > that feature has been axed). newfs doesn't rewrite the label until > > > just before it finishes, so the old label can be looked at to determine > > > what was there. Writing the label last may be a bug though. Perhaps > > > newfs should erase all the primary metadata for the old filesystem > > > when it starts so as to minimise the window where there may be > > > conflicting metadata. > > > > You cannot depend on the disk label as the disklabel is going away > > or at least being wholly overhauled with GEOM. In particular, the > > existing disk label only has a 2^32 block count which is insufficient > > for filesystems larger than 2Tb. > > I don't use GEOM, so the label won't be going away for me. Anyway, there > is no dependency (the label is just one of the things that one might > examine to recover a crashed disk), and any overaul by GEOM would have > to duplicate the functionality of storing metadata about the superblocks > somewhere outside the superblocks. (I actually store metadata about file > systems in (backups of) disk files in /var/backups. Normal backups > provide inadequate backups of metadata.) I agree that there needs to be some place that the additional information be stored to let fsck find the alternate superblocks. However, it seems unllikely that it will be the disk label as FreeBSD is looking to go to one of the existing disk label standards which do not have space reserved for that purpose. So, my guess is that some of the "boot" area will have to be reserved to that purpose. > The block count is in units of sector size, so disks much larger than > 2TB can be supported by disklabel using (fake if necessary) sector sizes > larger than 512. File systems need to use similarly large block (fragment > for ffs) sizes, and some patches are needed for reading superblocks if > the sector size is larger than 8K. Since ffs uses a block size of 16K > by default, a sector size of 16K are not unreasonable and this is sufficent > for disks smaller then 64TB. > > Bruce Actually, FFS requires its fragment size be no smaller than the sector size (since it presumes that it cannot do read/write in smaller than sector sizes). So, on a 16K filesystem, you get 2K fragments. So your hack only gets you to 8TB which is not going to last long at current disk growth rates. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Sun Nov 9 23:02:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48E5916A4CE for ; Sun, 9 Nov 2003 23:02:16 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5787C43FDF for ; Sun, 9 Nov 2003 23:02:14 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id SAA10279; Mon, 10 Nov 2003 18:02:01 +1100 Date: Mon, 10 Nov 2003 18:01:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kirk McKusick In-Reply-To: <200311092351.hA9NptaG001289@beastie.mckusick.com> Message-ID: <20031110174559.Q2074@gamplex.bde.org> References: <200311092351.hA9NptaG001289@beastie.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 07:02:16 -0000 On Sun, 9 Nov 2003, Kirk McKusick wrote: > > From: Bruce Evans > > The block count is in units of sector size, so disks much larger than > > 2TB can be supported by disklabel using (fake if necessary) sector sizes > > larger than 512. File systems need to use similarly large block (fragment ^^^^^^^^ > > for ffs) sizes, and some patches are needed for reading superblocks if ^^^^^^^ > > the sector size is larger than 8K. Since ffs uses a block size of 16K > > by default, a sector size of 16K are not unreasonable and this is sufficent > > for disks smaller then 64TB. > > Actually, FFS requires its fragment size be no smaller than the sector size > (since it presumes that it cannot do read/write in smaller than sector > sizes). So, on a 16K filesystem, you get 2K fragments. So your hack only > gets you to 8TB which is not going to last long at current disk growth > rates. This point was noted in the underlined phrase. The blocks size for ffs is actually the fragment size in this context. So fragments would be as large as necessary (16K if that is the sector size), and the block size (he one given by newfs's -b parameter) would be larger. A fragment size of 16K may even be the right size for very large disks. My benchmarks say that 16K/8K block/fragment size is not much slower than 16K/2K on a 60GB disk, but 16K/16K and 32K/any are significantly slower. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 09:16:22 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BD0E16A4CE for ; Mon, 10 Nov 2003 09:16:22 -0800 (PST) Received: from ns1.gnf.org (ns1.gnf.org [63.196.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E3BD43FCB for ; Mon, 10 Nov 2003 09:16:19 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from EXCHCLUSTER01.lj.gnf.org (exch01.lj.gnf.org [172.25.10.19]) by ns1.gnf.org (8.12.8p2/8.12.8) with ESMTP id hAAHGILc023438 for ; Mon, 10 Nov 2003 09:16:18 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: from roark.gnf.org ([172.25.24.15]) by EXCHCLUSTER01.lj.gnf.org with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Nov 2003 09:16:19 -0800 Received: from roark.gnf.org (localhost [127.0.0.1]) by roark.gnf.org (8.12.10/8.12.10) with ESMTP id hAAHGIvL011346; Mon, 10 Nov 2003 09:16:18 -0800 (PST) (envelope-from gtetlow@gnf.org) Received: (from gtetlow@localhost) by roark.gnf.org (8.12.10/8.12.10/Submit) id hAAHGIUo011345; Mon, 10 Nov 2003 09:16:18 -0800 (PST) (envelope-from gtetlow) Date: Mon, 10 Nov 2003 09:16:18 -0800 From: Gordon Tetlow To: Wes Peters Message-ID: <20031110171618.GD71376@roark.gnf.org> References: <200311041737.20467.wes@softweyr.com> <20031105015709.GC28915@dan.emsphone.com> <20031105081516.GA38016@cirb503493.alcatel.com.au> <200311060943.34284.wes@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5l2qnUqb3CiDhrj9" Content-Disposition: inline In-Reply-To: <200311060943.34284.wes@softweyr.com> User-Agent: Mutt/1.4.1i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-OriginalArrivalTime: 10 Nov 2003 17:16:19.0183 (UTC) FILETIME=[5B255FF0:01C3A7AE] cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 17:16:22 -0000 --5l2qnUqb3CiDhrj9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2003 at 09:43:34AM -0800, Wes Peters wrote: >=20 > I found an unused field called "fs_state" and used that, as Kirk=20 > suggested. Here's the new patch, which changes fsck to notice the=20 > fs_state and doesn't require re-writing all of the superblocks. >=20 > This patch adds a -E (generate errors) option to fsck, causing fsck to=20 > exit at various stages or to otherwise leave the state of fs_state and=20 > fs_clean in other than pristine conditions. I will, of course, commit=20 > the -E changes separately from the fs_state changes. >=20 > Thanks in advance for reviewing. And yes, I did manage to attach the=20 > patch this time. Doh! After a cursory glance, a couple of nits. Perhaps ErrorFlag should be Eflag to be consistent with the style of the rest of the source? Also, your error reporting in fsck_ffs is fs.state !=3D 0 is less than obvious: "superblock %d is not finished" Perhaps it could be "superblock %d is in an inconsistent state, this is probably due to a premature exit of newfs" or some such message. -gordon --5l2qnUqb3CiDhrj9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/r8fiRu2t9DV9ZfsRAhebAJ98YoH5Bm9ldLenqlWxfXzPriLedQCdH/4U Bam0eoJTWuYZMfT7Lj1c8Sg= =Pqwh -----END PGP SIGNATURE----- --5l2qnUqb3CiDhrj9-- From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 13:22:20 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9328E16A4CE for ; Mon, 10 Nov 2003 13:22:20 -0800 (PST) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C5FE43FBD for ; Mon, 10 Nov 2003 13:22:19 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd05.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AJJUI-0008UU-00; Mon, 10 Nov 2003 22:22:18 +0100 Received: from Andro-Beta.Leidinger.net (VgDvD-ZlQepbuGXYa3iJuWalfTtbchQGmAMnuMlvJ3SEWT31Hw4Ycq@[80.131.123.151]) by fmrl05.sul.t-online.com with esmtp id 1AJJU5-15tyls0; Mon, 10 Nov 2003 22:22:05 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAALM3sm093932; Mon, 10 Nov 2003 22:22:03 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAALMLbV078568; Mon, 10 Nov 2003 22:22:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Mon, 10 Nov 2003 22:22:21 +0100 From: Alexander Leidinger To: arch@freebsd.org Message-Id: <20031110222221.36a11979.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: VgDvD-ZlQepbuGXYa3iJuWalfTtbchQGmAMnuMlvJ3SEWT31Hw4Ycq@t-dialin.net cc: Marius Strobl Subject: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 21:22:20 -0000 Hi, at http://www.leidinger.net/FreeBSD/current-patches/ I have some patches which allow to compile the kernel with icc (CC=icc make depend && CC=icc make). They are a joint effort of Marius Strobl and me. The resulting kernel still has some issues (no NFS, some packet loss, ... see icc.README in the above mentioned directory), but it boots and runs. A quick tour over icc.diff: - build infrastructure: just a "translate gcc switches into icc switches"-game - includes: more or less "if gcc" -> "if gcc or intel compiler" - assym.h: icc doesn't handle 0 sized arrays like gcc does, the patch was suggested by bde, a discussion of this is in the archive - aicasm: understand the icc syntax of -nostdinc - stdargh.h and _types.h: the changes are just a reminder to enable them when icc understands this particular gcc syntax, Intel is working on it The list of affected files: ---snip--- share/mk/bsd.cpu.mk \ share/mk/bsd.dep.mk \ share/mk/bsd.lib.mk \ share/mk/bsd.prog.mk \ share/mk/bsd.sys.mk \ share/mk/sys.mk \ sys/boot/i386/boot2/boot2.c \ sys/conf/defines \ sys/conf/kern.mk \ sys/conf/kern.post.mk \ sys/conf/kern.pre.mk \ sys/conf/kmod.mk \ sys/conf/files \ sys/dev/aic7xxx/aicasm/Makefile \ sys/dev/aic7xxx/aicasm/aicasm.c \ sys/dev/ichsmb/ichsmb.c \ sys/dev/iir/iir.h \ sys/dev/isp/ispvar.h \ sys/dev/mcd/mcdreg.h \ sys/dev/scd/scdreg.h \ sys/i386/acpica/acpi_wakeup.c \ sys/i386/i386/db_interface.c \ sys/i386/i386/identcpu.c \ sys/i386/include/_types.h \ sys/i386/include/atomic.h \ sys/i386/include/bus_at386.h \ sys/i386/include/cpufunc.h \ sys/i386/include/critical.h \ sys/i386/include/endian.h \ sys/i386/include/ieeefp.h \ sys/i386/include/in_cksum.h \ sys/i386/include/pcpu.h \ sys/i386/include/profile.h \ sys/i386/include/stdarg.h \ sys/i386/isa/npx.c \ sys/i386/isa/prof_machdep.c \ sys/kern/subr_prof.c \ sys/libkern/quad.h \ sys/netatm/atm_ioctl.h \ sys/sys/assym.h \ sys/sys/cdefs.h \ sys/sys/dir.h \ sys/sys/ioctl.h \ sys/sys/linker_set.h \ sys/sys/queue.h \ sys/sys/syslimits.h ---snip--- I run parts of these patches since a long time (months, parts of it over a year), no bad interactions with a gcc compiled kernel/world so far. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 15:16:52 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A673116A4CE for ; Mon, 10 Nov 2003 15:16:52 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E78F43FF2 for ; Mon, 10 Nov 2003 15:16:51 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAANGgXF031644; Mon, 10 Nov 2003 18:16:42 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031110222221.36a11979.Alexander@Leidinger.net> References: <20031110222221.36a11979.Alexander@Leidinger.net> Date: Mon, 10 Nov 2003 18:16:40 -0500 To: Alexander Leidinger , arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 23:16:52 -0000 At 10:22 PM +0100 11/10/03, Alexander Leidinger wrote: >Hi, > >at http://www.leidinger.net/FreeBSD/current-patches/ >I have some patches which allow to compile the kernel >with icc (CC=icc make depend && CC=icc make). They are >a joint effort of Marius Strobl and me. > >The resulting kernel still has some issues (no NFS, >some packet loss, ... see icc.README in the above >mentioned directory), but it boots and runs. Will some of these be reasonable to commit before 5.2? Even if there are some issues, those issues will only come up if someone *does* use the icc compiler, right? So, they'd be safe to add as far as anyone using gcc is concerned? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Nov 10 20:40:29 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1627E16A4E1 for ; Mon, 10 Nov 2003 20:40:29 -0800 (PST) Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3EC43FE0 for ; Mon, 10 Nov 2003 20:40:27 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.12.8/8.12.3) with ESMTP id hAB4eUaG002072; Mon, 10 Nov 2003 20:40:31 -0800 (PST) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200311110440.hAB4eUaG002072@beastie.mckusick.com> To: Bruce Evans In-Reply-To: Your message of "Mon, 10 Nov 2003 18:01:59 +1100." <20031110174559.Q2074@gamplex.bde.org> Date: Mon, 10 Nov 2003 20:40:30 -0800 From: Kirk McKusick cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 04:40:29 -0000 > Date: Mon, 10 Nov 2003 18:01:59 +1100 (EST) > From: Bruce Evans > To: Kirk McKusick > cc: arch@freebsd.org > Subject: Re: newfs and mount vs. half-baked disks > X-ASK-Info: Whitelist match > > On Sun, 9 Nov 2003, Kirk McKusick wrote: > > > > From: Bruce Evans > > > > The block count is in units of sector size, so disks much larger than > > > 2TB can be supported by disklabel using (fake if necessary) sector sizes > > > larger than 512. File systems need to use similarly large block (fragment > ^^^^^^^^ > > > for ffs) sizes, and some patches are needed for reading superblocks if > ^^^^^^^ > > > the sector size is larger than 8K. Since ffs uses a block size of 16K > > > by default, a sector size of 16K are not unreasonable and this is > > > sufficent for disks smaller then 64TB. > > > > Actually, FFS requires its fragment size be no smaller than the sector size > > (since it presumes that it cannot do read/write in smaller than sector > > sizes). So, on a 16K filesystem, you get 2K fragments. So your hack only > > gets you to 8TB which is not going to last long at current disk growth > > rates. > > This point was noted in the underlined phrase. The blocks size for ffs is > actually the fragment size in this context. So fragments would be as > large as necessary (16K if that is the sector size), and the block size > (he one given by newfs's -b parameter) would be larger. A fragment size > of 16K may even be the right size for very large disks. My benchmarks > say that 16K/8K block/fragment size is not much slower than 16K/2K on > a 60GB disk, but 16K/16K and 32K/any are significantly slower. > > Bruce Using 16K/16K will not change the speed of operation appreciably, but it will *more than double* the space required to hold the typical FreeBSD filesystem (e.g., what would fit on a 60Gb 16K/2K filesystem will require 120Gb on a 16K/16K filesystem). This happens because most files on a typical filesystem are small. That is a poor tradeoff in my opinion. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 02:03:52 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E57516A4CE for ; Tue, 11 Nov 2003 02:03:52 -0800 (PST) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A2E943FBD for ; Tue, 11 Nov 2003 02:03:50 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd03.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1AJULU-0001Ie-07; Tue, 11 Nov 2003 09:57:56 +0100 Received: from Andro-Beta.Leidinger.net (ZekLevZLreQOOXCAFzJWXGJlTF5Ij4ymO6KnSNBtPYXQS0LG2jmYgD@[217.83.23.62]) by fmrl03.sul.t-online.com with esmtp id 1AJULF-1uAd5U0; Tue, 11 Nov 2003 09:57:41 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hAB8vesm093608; Tue, 11 Nov 2003 09:57:40 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hAB8w1kP005706; Tue, 11 Nov 2003 09:58:01 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Tue, 11 Nov 2003 09:58:01 +0100 From: Alexander Leidinger To: Garance A Drosihn Message-Id: <20031111095801.66c6fdff.Alexander@Leidinger.net> In-Reply-To: References: <20031110222221.36a11979.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: ZekLevZLreQOOXCAFzJWXGJlTF5Ij4ymO6KnSNBtPYXQS0LG2jmYgD@t-dialin.net cc: arch@freebsd.org cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 10:03:52 -0000 On Mon, 10 Nov 2003 18:16:40 -0500 Garance A Drosihn wrote: > Will some of these be reasonable to commit before 5.2? All of them. Except for the "not_yet" parts of stdarg.h and _types.h, as icc needs to learn the gcc syntax of the used constructs first (it's on the TODO list @Intel). And except for parts where I get negative reviews here (none so far)... > Even if there are some issues, those issues will only > come up if someone *does* use the icc compiler, right? Yes. > So, they'd be safe to add as far as anyone using gcc > is concerned? Yes, as I use NFS on my desktop I can't run a icc compiled kernel on it, but I have (various incarnations of) the icc patches in the src tree since a long time and everything runs fine (or better: not different than for those on -current@ without the patches :-) ) on the gcc compiled system. If a src committer looks into them and offers to commit them (or approves to commit them): the FreeBSD version needs to get bumped because of the cdefs.h changes (short description: "cdefs.h support for Intel's C/C++ compiler"), I need to know about them in the icc port. Bye, Alexander. -- 0 and 1. Now what could be so hard about that? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 07:31:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC7116A4CE for ; Tue, 11 Nov 2003 07:31:45 -0800 (PST) Received: from gvr.gvr.org (gvr.gvr.org [212.61.40.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C66043F93 for ; Tue, 11 Nov 2003 07:31:44 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 7DADC39; Tue, 11 Nov 2003 16:31:42 +0100 (CET) Date: Tue, 11 Nov 2003 16:31:42 +0100 From: Guido van Rooij To: Alexander Leidinger Message-ID: <20031111153142.GA42684@gvr.gvr.org> References: <20031110222221.36a11979.Alexander@Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031110222221.36a11979.Alexander@Leidinger.net> cc: arch@freebsd.org cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 15:31:45 -0000 On Mon, Nov 10, 2003 at 10:22:21PM +0100, Alexander Leidinger wrote: > Hi, > > at http://www.leidinger.net/FreeBSD/current-patches/ I have some patches > which allow to compile the kernel with icc (CC=icc make depend && CC=icc > make). They are a joint effort of Marius Strobl and me. > > The resulting kernel still has some issues (no NFS, some packet loss, > ... see icc.README in the above mentioned directory), but it boots and > runs. What are the benefits of running an icc compiled kernel? -Guido From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 07:43:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F31A16A4CE for ; Tue, 11 Nov 2003 07:43:21 -0800 (PST) Received: from ray.idi.ntnu.no (ray.idi.ntnu.no [129.241.107.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C78143FCB for ; Tue, 11 Nov 2003 07:43:19 -0800 (PST) (envelope-from morten@rodal.no) Received: from hauk10.idi.ntnu.no (hauk10.idi.ntnu.no [129.241.102.222]) by ray.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id hABFhCDG017546; Tue, 11 Nov 2003 16:43:13 +0100 (MET) Received: from rodal.no (localhost [127.0.0.1]) by hauk10.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id hABFhCkX059374; Tue, 11 Nov 2003 16:43:12 +0100 (CET) (envelope-from morten@rodal.no) Message-ID: <3FB10386.8030802@rodal.no> Date: Tue, 11 Nov 2003 16:43:02 +0100 From: Morten Rodal User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031026 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guido van Rooij References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111153142.GA42684@gvr.gvr.org> In-Reply-To: <20031111153142.GA42684@gvr.gvr.org> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8755C425D82B4229942B4A26" X-Spam-Status: No, hits=-8.2 required=4 X-Virus-Scanned: by amavisd-new-IDI cc: arch@freebsd.org Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 15:43:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8755C425D82B4229942B4A26 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Guido van Rooij wrote: > On Mon, Nov 10, 2003 at 10:22:21PM +0100, Alexander Leidinger wrote: >>Hi, >> >>at http://www.leidinger.net/FreeBSD/current-patches/ I have some patches >>which allow to compile the kernel with icc (CC=icc make depend && CC=icc >>make). They are a joint effort of Marius Strobl and me. >> >>The resulting kernel still has some issues (no NFS, some packet loss, >>... see icc.README in the above mentioned directory), but it boots and >>runs. > > > What are the benefits of running an icc compiled kernel? > The Intel C compiler is known to generate far better code for the Pentium 4 processor family (and more likely the Itanium processors), and probably others as well. It certanly beats gcc in most benchmark tests and other scientific applications. I have found that icc generates far more, and more accurate, warnings and errors for programs and this is probably what the FreeBSD kernel could benefit most from. Having more than one compiler helps the developers find bugs faster. -- Morten Rodal --------------enig8755C425D82B4229942B4A26 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/sQOPbWe1Cy11WVsRAh3wAKCrznjz9+t8otwIwROf09tTEKGPEACg0Vfs nI4a0uTl0LffuEfcndbc9z8= =qr6Z -----END PGP SIGNATURE----- --------------enig8755C425D82B4229942B4A26-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 09:02:06 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 348B516A4CE for ; Tue, 11 Nov 2003 09:02:06 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id E074D43FE0 for ; Tue, 11 Nov 2003 09:02:04 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd00.aul.t-online.de by mailout01.sul.t-online.com with smtp id 1AJbnA-0003Z9-02; Tue, 11 Nov 2003 17:55:00 +0100 Received: from Andro-Beta.Leidinger.net (G-ExAsZvQeLJ6kgV+8iRtUPCnJM7e8Ct5ZOBBMSteoRHgtRDOXYckm@[217.83.23.62]) by fmrl00.sul.t-online.com with esmtp id 1AJbmo-0lPprs0; Tue, 11 Nov 2003 17:54:38 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hABGsVsm091826; Tue, 11 Nov 2003 17:54:32 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hABGspkP069179; Tue, 11 Nov 2003 17:54:51 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Tue, 11 Nov 2003 17:54:51 +0100 From: Alexander Leidinger To: Guido van Rooij , Marius Strobl Message-Id: <20031111175451.7b836abf.Alexander@Leidinger.net> In-Reply-To: <20031111153142.GA42684@gvr.gvr.org> References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111153142.GA42684@gvr.gvr.org> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: G-ExAsZvQeLJ6kgV+8iRtUPCnJM7e8Ct5ZOBBMSteoRHgtRDOXYckm@t-dialin.net cc: arch@freebsd.org Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 17:02:06 -0000 On Tue, 11 Nov 2003 16:31:42 +0100 Guido van Rooij wrote: > What are the benefits of running an icc compiled kernel? The same as every other program gets. a) Icc knows better to schedule instructions for a P4 than gcc does. b) If you have an application which stresses some critical path in the kernel, icc may be able to optimize parts of it and allows you to get a little bit more out of it. c) Someone is working on getting the icc profiling information out of the linux kernel back into icc to optimize the system based upon the measured values (think about branch prediction and probabilities). When this matures, it's very likely that we also get support for it. d) If 2 compilers agree on the behavior of the same code, either both compilers a buggy, or your code is fine (yes, an overly optimistic point of view, but a pragmatic one). If one of 2 compilers disagrees, something is wrong with one of the compilers, or with your code. Or perhaps you're just religious and want to use as less (L)GPLed code as possible. ;-) Obviously not everyone needs to run an icc compiled kernel or userland, but it doesn't hurts (modulo bugs in icc (as FreeBSD has a commercial license of icc, we get commercial support, and Intel fixed already some ICE issues for us) or in the code, but there could be/are bugs in gcc too) to run or to be able to run one. BTW.: even if Intel doesn't like it, but: icc produces the fastest 32bit code for AMD CPUs too (in specific applications of course). Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 09:09:02 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 139CC16A4CE for ; Tue, 11 Nov 2003 09:09:02 -0800 (PST) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B0743FA3 for ; Tue, 11 Nov 2003 09:09:00 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd01.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1AJc0h-0005bp-01; Tue, 11 Nov 2003 18:08:59 +0100 Received: from Andro-Beta.Leidinger.net (E6+992Za8eFgB52Xpi+pl0a9U5hXyaLN9ogBCmWV-eBqKZHcPy-yEZ@[217.83.23.62]) by fmrl01.sul.t-online.com with esmtp id 1AJc0A-1qzByK0; Tue, 11 Nov 2003 18:08:26 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hABH8Jsm093771 for ; Tue, 11 Nov 2003 18:08:19 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.10/8.12.10) with SMTP id hABH8dkP070976 for ; Tue, 11 Nov 2003 18:08:39 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Tue, 11 Nov 2003 18:08:39 +0100 From: Alexander Leidinger To: freebsd-arch@freebsd.org Message-Id: <20031111180839.233332ca.Alexander@Leidinger.net> In-Reply-To: <3FB10386.8030802@rodal.no> References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111153142.GA42684@gvr.gvr.org> <3FB10386.8030802@rodal.no> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: E6+992Za8eFgB52Xpi+pl0a9U5hXyaLN9ogBCmWV-eBqKZHcPy-yEZ@t-dialin.net Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 17:09:02 -0000 On Tue, 11 Nov 2003 16:43:02 +0100 Morten Rodal wrote: > The Intel C compiler is known to generate far better code for the > Pentium 4 processor family (and more likely the Itanium processors), and > probably others as well. It certanly beats gcc in most benchmark tests > and other scientific applications. It depends on the benchmarks you do and if they are optimized for a specific compiler or not (I don't want to implicate, that those benchmarks which show a large benefit for icc to be optimized for icc, generally I think icc produces better code than gcc, but as usual, this depends on the used code and the used data which gets processed (you know: benchmarks data != real world data you are confronted with) and many more factors than only the compiler). > I have found that icc generates far more, and more accurate, warnings > and errors for programs and this is probably what the FreeBSD kernel > could benefit most from. Having more than one compiler helps the > developers find bugs faster. Yes, it produces nice warnings. If some is interested (and isn't willing to download the >60 MB icc tarball) I can put up the log of a compiled GENERIC or LINT kernel (or a subsystem) for download. This isn't the same as seeing the warnings/errors at development time, but I think could be still usable. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 10:15:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0131316A4CE for ; Tue, 11 Nov 2003 10:15:35 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3438C43FBF for ; Tue, 11 Nov 2003 10:15:34 -0800 (PST) (envelope-from linimon@lonesome.com) Received: from lonesome.com (cs242746-11.austin.rr.com [24.27.46.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 3C88814687; Tue, 11 Nov 2003 12:15:33 -0600 (CST) Message-ID: <3FB05B98.6070009@lonesome.com> Date: Tue, 11 Nov 2003 03:46:32 +0000 From: Mark Linimon User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030713 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111153142.GA42684@gvr.gvr.org> <20031111175451.7b836abf.Alexander@Leidinger.net> In-Reply-To: <20031111175451.7b836abf.Alexander@Leidinger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 18:15:35 -0000 Let's also note here that the bento cluster builds routinely find cases where gcc produces internal errors. mcl From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 13:52:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 458E116A4CE for ; Tue, 11 Nov 2003 13:52:09 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D7A43FBF for ; Tue, 11 Nov 2003 13:52:08 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id 5AAF272DCB; Tue, 11 Nov 2003 13:45:14 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: arch@freebsd.org Date: Tue, 11 Nov 2003 13:52:05 -0800 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200311111339.30853.wes@softweyr.com> Content-Type: Multipart/Mixed; boundary="Boundary-00=_FoVs/1khD/qbQm2" cc: Kirk McKusick Subject: New newfs vs. half-baked disks patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 21:52:09 -0000 --Boundary-00=_FoVs/1khD/qbQm2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I re-did the patch using a differing magic number, as suggested. This approach works quite nicely. The patch is smaller and does more with no kernel mods. This patch does more because a filesystem partially created with newfs now has an invalid magic number on the first superblock. This means older kernels will not mount the filesystem and older fsck will at least warn about not finding the first superblock. This patch includes a change to fsck so it will recognize an incomplete newfs filesystem, exiting with a unique status (11) and issuing the message "This volume is incomplete, run newfs again." The patch to newfs includes the -E flag to generate error conditions; these changes will be committed separately. Barring lack of objections, I'd like to commit this tomorrow. Thanks to everyone who commented on the first round. This was my first foray into filesystem programming since my Minix days and you were all more than generous. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com --Boundary-00=_FoVs/1khD/qbQm2 Content-Type: text/x-diff; charset="us-ascii"; name="newfs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="newfs.patch" --- sys/ufs/ffs/fs.h.orig Mon Nov 10 17:13:43 2003 +++ sys/ufs/ffs/fs.h Mon Nov 10 17:14:57 2003 @@ -361,6 +361,7 @@ */ #define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ #define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ +#define FS_BAD2_MAGIG 0x19960408 /* UFS2 incomplete newfs magic number */ #define FS_OKAY 0x7c269d38 /* superblock checksum */ #define FS_42INODEFMT -1 /* 4.2BSD inode format */ #define FS_44INODEFMT 2 /* 4.4BSD inode format */ --- sbin/newfs/mkfs.c.orig Tue Oct 14 13:53:55 2003 +++ sbin/newfs/mkfs.c Mon Nov 10 17:31:35 2003 @@ -258,7 +258,7 @@ sblock.fs_old_postblformat = 1; sblock.fs_old_nrpos = 1; } else { - sblock.fs_magic = FS_UFS2_MAGIC; + sblock.fs_magic = FS_BAD2_MAGIC; sblock.fs_sblockloc = SBLOCK_UFS2; sblock.fs_nindir = sblock.fs_bsize / sizeof(ufs2_daddr_t); sblock.fs_inopb = sblock.fs_bsize / sizeof(struct ufs2_dinode); @@ -448,6 +448,16 @@ chdummy, SBLOCKSIZE); } } + if (!Nflag) + sbwrite(&disk, 0); + if (Eflag == 1) { + printf("** Exiting on Eflag 1\n"); + exit(0); + } + if (Eflag == 2) + printf("** Leaving BAD MAGIC on Eflag 2\n"); + else + sblock.fs_magic = FS_UFS2_MAGIC; /* * Now build the cylinders group blocks and @@ -502,6 +512,10 @@ sblock.fs_old_cstotal.cs_nbfree = sblock.fs_cstotal.cs_nbfree; sblock.fs_old_cstotal.cs_nifree = sblock.fs_cstotal.cs_nifree; sblock.fs_old_cstotal.cs_nffree = sblock.fs_cstotal.cs_nffree; + } + if (Eflag == 3) { + printf("** Exiting on Eflag 3\n"); + exit(0); } if (!Nflag) sbwrite(&disk, 0); --- sbin/newfs/newfs.h.orig Tue Nov 4 16:27:31 2003 +++ sbin/newfs/newfs.h Mon Nov 10 17:26:13 2003 @@ -52,6 +52,7 @@ extern int Oflag; /* build UFS1 format file system */ extern int Rflag; /* regression test */ extern int Uflag; /* enable soft updates for file system */ +extern int Eflag; /* exit as if error, for testing */ extern quad_t fssize; /* file system size */ extern int sectorsize; /* bytes/sector */ extern int realsectorsize; /* bytes/sector in hardware*/ --- sbin/newfs/newfs.c.orig Tue Nov 4 16:20:42 2003 +++ sbin/newfs/newfs.c Mon Nov 10 17:26:24 2003 @@ -119,6 +119,7 @@ int Oflag = 2; /* file system format (1 => UFS1, 2 => UFS2) */ int Rflag; /* regression test */ int Uflag; /* enable soft updates for file system */ +int Eflag = 0; /* exit in middle of newfs for testing */ quad_t fssize; /* file system size */ int sectorsize; /* bytes/sector */ int realsectorsize; /* bytes/sector in hardware */ @@ -156,8 +157,11 @@ off_t mediasize; while ((ch = getopt(argc, argv, - "L:NO:RS:T:Ua:b:c:d:e:f:g:h:i:m:o:s:")) != -1) + "EL:NO:RS:T:Ua:b:c:d:e:f:g:h:i:m:o:s:")) != -1) switch (ch) { + case 'E': + Eflag++; + break; case 'L': volumelabel = optarg; i = -1; --- sbin/fsck_ffs/setup.c.orig Wed Nov 5 15:50:12 2003 +++ sbin/fsck_ffs/setup.c Mon Nov 10 18:24:03 2003 @@ -301,6 +301,11 @@ super = bflag; if ((bread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); + if (sblock.fs_magic == FS_BAD2_MAGIC) { + fprintf(stderr, + "This volume is incomplete, run newfs again\n"); + exit(11); + } if (sblock.fs_magic != FS_UFS1_MAGIC && sblock.fs_magic != FS_UFS2_MAGIC) { fprintf(stderr, "%d is not a file system superblock\n", @@ -313,6 +318,11 @@ if ((bread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); + if (sblock.fs_magic == FS_BAD2_MAGIC) { + fprintf(stderr, "This volume is incomplete, " + "run newfs again\n"); + exit(11); + } if ((sblock.fs_magic == FS_UFS1_MAGIC || (sblock.fs_magic == FS_UFS2_MAGIC && sblock.fs_sblockloc == sblock_try[i])) && --Boundary-00=_FoVs/1khD/qbQm2-- From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 13:57:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0396C16A4CF for ; Tue, 11 Nov 2003 13:57:45 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C4D43F75 for ; Tue, 11 Nov 2003 13:57:41 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hABLvcYR021837; Tue, 11 Nov 2003 16:57:39 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20031111095801.66c6fdff.Alexander@Leidinger.net> References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111095801.66c6fdff.Alexander@Leidinger.net> Date: Tue, 11 Nov 2003 16:57:37 -0500 To: Alexander Leidinger From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 21:57:45 -0000 At 9:58 AM +0100 11/11/03, Alexander Leidinger wrote: > >If a src committer looks into them and offers to commit them >(or approves to commit them): the FreeBSD version needs to >get bumped because of the cdefs.h changes (short description: >"cdefs.h support for Intel's C/C++ compiler"), I need to know >about them in the icc port. I would like to see them committed, but my main development machine is dead right now (with hardware problems). I might try some of these on my sparc64 machine, if I have some time. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 14:17:50 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D8C16A4CE for ; Tue, 11 Nov 2003 14:17:50 -0800 (PST) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id A765543FB1 for ; Tue, 11 Nov 2003 14:17:46 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd10.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1AJgpP-0006qS-01; Tue, 11 Nov 2003 23:17:39 +0100 Received: from Andro-Beta.Leidinger.net (GE6Ko+ZUgem173vdvFfKC161kepYwNEAqXDKlg6nEzE49jA8991NQD@[217.83.23.62]) by fmrl10.sul.t-online.com with esmtp id 1AJgpH-0uetn60; Tue, 11 Nov 2003 23:17:31 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hABMHQsm018419; Tue, 11 Nov 2003 23:17:27 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) hABMHkkP013361; Tue, 11 Nov 2003 23:17:46 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Tue, 11 Nov 2003 23:17:46 +0100 From: Alexander Leidinger To: Garance A Drosihn Message-Id: <20031111231746.5757108c.Alexander@Leidinger.net> In-Reply-To: References: <20031110222221.36a11979.Alexander@Leidinger.net> <20031111095801.66c6fdff.Alexander@Leidinger.net> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: GE6Ko+ZUgem173vdvFfKC161kepYwNEAqXDKlg6nEzE49jA8991NQD@t-dialin.net cc: arch@freebsd.org cc: Marius Strobl Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2003 22:17:50 -0000 On Tue, 11 Nov 2003 16:57:37 -0500 Garance A Drosihn wrote: > I would like to see them committed, but my main development > machine is dead right now (with hardware problems). I might > try some of these on my sparc64 machine, if I have some time. Please fetch icc.diff again, I fixed some comments and an regexp in the icc specific part. Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 16:10:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5905B16A4CE for ; Tue, 11 Nov 2003 16:10:37 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDBEA43FA3 for ; Tue, 11 Nov 2003 16:10:35 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id LAA10223; Wed, 12 Nov 2003 11:10:27 +1100 Date: Wed, 12 Nov 2003 11:10:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Wes Peters In-Reply-To: <200311111339.30853.wes@softweyr.com> Message-ID: <20031112110823.V1618@gamplex.bde.org> References: <200311111339.30853.wes@softweyr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Kirk McKusick Subject: Re: New newfs vs. half-baked disks patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 00:10:37 -0000 On Tue, 11 Nov 2003, Wes Peters wrote: > I re-did the patch using a differing magic number, as suggested. This > approach works quite nicely. The patch is smaller and does more with > no kernel mods. Thanks for listening to me :-). > This patch includes a change to fsck so it will recognize an incomplete > newfs filesystem, exiting with a unique status (11) and issuing the > message "This volume is incomplete, run newfs again." No comma splices please. > The patch to newfs includes the -E flag to generate error conditions; > these changes will be committed separately. Barring lack of > objections, I'd like to commit this tomorrow. Detailed comments in private mail. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Nov 11 16:31:25 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C42216A4CE for ; Tue, 11 Nov 2003 16:31:25 -0800 (PST) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12ECB43FDF for ; Tue, 11 Nov 2003 16:31:25 -0800 (PST) (envelope-from atici@myrealbox.com) Received: from atici [128.59.192.93] by myrealbox.com with NetMail ModWeb Module; Tue, 11 Nov 2003 19:31:30 -0500 From: "Alp ATICI" To: arch@freebsd.org Date: Tue, 11 Nov 2003 19:31:30 -0500 X-Mailer: NetMail ModWeb Module X-Sender: atici MIME-Version: 1.0 Message-ID: <1068597090.625edae0atici@myrealbox.com> Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 00:31:25 -0000 > What are the benefits of running an icc compiled kernel? The main reason for icc development is to support IA-64 because EPIC archit= ecture is very demanding on the compiler side. That's why the real benefi= t should be apparent with an IA-64 computer eventually. Does this patch work for IA-64? From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 00:56:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51A5D16A4CE for ; Wed, 12 Nov 2003 00:56:26 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0037543F3F for ; Wed, 12 Nov 2003 00:56:25 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAC8uEtB032964; Wed, 12 Nov 2003 09:56:20 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 08 Nov 2003 19:35:16 +1100." <20031108191433.J608@gamplex.bde.org> Date: Wed, 12 Nov 2003 09:56:14 +0100 Message-ID: <32963.1068627374@critter.freebsd.dk> cc: arch@freebsd.org cc: Kirk McKusick Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 08:56:26 -0000 In message <20031108191433.J608@gamplex.bde.org>, Bruce Evans writes: >I don't use GEOM, so the label won't be going away for me. Anyway, there >is no dependency (the label is just one of the things that one might >examine to recover a crashed disk), and any overaul by GEOM would have >to duplicate the functionality of storing metadata about the superblocks >somewhere outside the superblocks. This is a very good example of where it is important to get your terminology straight: No sane "overhaul by GEOM" would implement this in GEOM. It could be hacked into various existing classes or even done cleanly in its own class which is almost as silly. > (I actually store metadata about file >systems in (backups of) disk files in /var/backups. Normal backups >provide inadequate backups of metadata.) This is probably a much better idea than anything you said until now on the subject. It might not be a bad idea to store the relevant magics in a /etc/ufs.conf file, but there are some details about device vs. media/filesystem identification in particular in context of dynanic devices to that must be worked out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 03:54:51 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CF3916A4CE for ; Wed, 12 Nov 2003 03:54:51 -0800 (PST) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC7D43FA3 for ; Wed, 12 Nov 2003 03:54:49 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd05.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AJtaC-0003vy-06; Wed, 12 Nov 2003 12:54:48 +0100 Received: from Andro-Beta.Leidinger.net (bdCP80ZAYeiWkt1kCXOwbWhr1+OyMOvBUjo7xF3z2EzltHVR11c3c8@[217.229.208.211]) by fmrl05.sul.t-online.com with esmtp id 1AJta0-2CICvI0; Wed, 12 Nov 2003 12:54:36 +0100 Received: from Magelan.Leidinger.net (Magellan [192.168.1.1]) hACBsasm072577 for ; Wed, 12 Nov 2003 12:54:36 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.10/8.12.10) with SMTP id hACBsxAJ037100 for ; Wed, 12 Nov 2003 12:54:59 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Wed, 12 Nov 2003 12:54:59 +0100 From: Alexander Leidinger To: freebsd-arch@freebsd.org Message-Id: <20031112125459.43478159.Alexander@Leidinger.net> In-Reply-To: <1068597090.625edae0atici@myrealbox.com> References: <1068597090.625edae0atici@myrealbox.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: bdCP80ZAYeiWkt1kCXOwbWhr1+OyMOvBUjo7xF3z2EzltHVR11c3c8@t-dialin.net Subject: Re: Patches to compile the kernel with Intel's C/C++ compiler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2003 11:54:51 -0000 On Tue, 11 Nov 2003 19:31:30 -0500 "Alp ATICI" wrote: > Does this patch work for IA-64? The MI parts are covered, the MD parts aren't. Besides this, FreeBSD on IA64 has no linux support yet, and it's not very important at the moment in Marcel's TODO list. I don't think it's hard to do the IA64-MD part, it's mostly looking for __GNUC__ and adding __ECC. Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 22:43:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 162D416A4CE for ; Wed, 12 Nov 2003 22:43:09 -0800 (PST) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A4A243FDF for ; Wed, 12 Nov 2003 22:43:07 -0800 (PST) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])hAD6gwf1052821; Thu, 13 Nov 2003 17:43:02 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost)hAD6gqru052820; Thu, 13 Nov 2003 17:42:52 +1100 (EST) (envelope-from jeremyp) Date: Thu, 13 Nov 2003 17:42:51 +1100 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20031113064251.GB39616@cirb503493.alcatel.com.au> References: <20031108191433.J608@gamplex.bde.org> <32963.1068627374@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32963.1068627374@critter.freebsd.dk> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 06:43:09 -0000 On Wed, Nov 12, 2003 at 09:56:14AM +0100, Poul-Henning Kamp wrote: >It might not be a bad idea to store the relevant magics in a >/etc/ufs.conf file, but there are some details about device vs. >media/filesystem identification in particular in context of dynanic >devices to that must be worked out. How do you handle the situation when the master superblock on / is hosed and you need to find the filesystem parameters (in /etc/ufs.conf) before you can access /? If the BSD-style disklabels are going away, at least the root parameters need to be in the boot blocks or somewhere similar. Peter From owner-freebsd-arch@FreeBSD.ORG Wed Nov 12 23:14:47 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7070716A4CE for ; Wed, 12 Nov 2003 23:14:47 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 385E643FB1 for ; Wed, 12 Nov 2003 23:14:46 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAD7EgNZ004938; Thu, 13 Nov 2003 08:14:43 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 13 Nov 2003 17:42:51 +1100." <20031113064251.GB39616@cirb503493.alcatel.com.au> Date: Thu, 13 Nov 2003 08:14:42 +0100 Message-ID: <4937.1068707682@critter.freebsd.dk> cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2003 07:14:47 -0000 In message <20031113064251.GB39616@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >On Wed, Nov 12, 2003 at 09:56:14AM +0100, Poul-Henning Kamp wrote: >>It might not be a bad idea to store the relevant magics in a >>/etc/ufs.conf file, but there are some details about device vs. >>media/filesystem identification in particular in context of dynanic >>devices to that must be worked out. > >How do you handle the situation when the master superblock on / is >hosed and you need to find the filesystem parameters (in >/etc/ufs.conf) before you can access /? I usually take great care to always newfs / with default parameters, because then I can use newfs -N /dev/ad0a to see where the superblocks are to be found. >If the BSD-style disklabels are going away, at least the root >parameters need to be in the boot blocks or somewhere similar. Sure, send a patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 11:41:21 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 692B716A4CE for ; Fri, 14 Nov 2003 11:41:21 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E57743F75 for ; Fri, 14 Nov 2003 11:41:20 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 330F0548A5 for ; Fri, 14 Nov 2003 13:41:20 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id C7E8C6D455; Fri, 14 Nov 2003 13:41:19 -0600 (CST) Date: Fri, 14 Nov 2003 13:41:19 -0600 From: "Jacques A. Vidrine" To: freebsd-arch@freebsd.org Message-ID: <20031114194119.GA94198@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 Subject: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 19:41:21 -0000 In at least one place in libc, it is necessary to range check a time_t value. One most platforms, time_t has the same range as `int', but on at least amd64, it has a larger range. Any objections to adding definitions of __TIME_MIN and __TIME_MAX to sys/${arch}/_limits.h? I could just do the usual check for lossage after casting, except that in theory time_t could be a floating-point value (but not in reality in FreeBSD). It seems cleaner to me to have an explicit range. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 16:54:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956A216A4CE; Fri, 14 Nov 2003 16:54:38 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80DB343F3F; Fri, 14 Nov 2003 16:54:36 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id LAA25698; Sat, 15 Nov 2003 11:54:34 +1100 Date: Sat, 15 Nov 2003 11:54:33 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Jacques A. Vidrine" In-Reply-To: <20031114194119.GA94198@madman.celabo.org> Message-ID: <20031115114906.L11453@gamplex.bde.org> References: <20031114194119.GA94198@madman.celabo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 00:54:38 -0000 On Fri, 14 Nov 2003, Jacques A. Vidrine wrote: > In at least one place in libc, it is necessary to range check a time_t > value. One most platforms, time_t has the same range as `int', but > on at least amd64, it has a larger range. Any objections to adding > definitions of __TIME_MIN and __TIME_MAX to sys/${arch}/_limits.h? > > I could just do the usual check for lossage after casting, except that > in theory time_t could be a floating-point value (but not in reality > in FreeBSD). It seems cleaner to me to have an explicit range. I prefer the cast. It doesn't require nonstandard infrastructure that would need to be maintained forever, and works even better for floating point too (assuming a C99 compiler, but not in reality in FreeBSD :) (min/max checks don't work right for floating point because precision may be just as important as range). Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 20:18:41 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CF3416A4CE for ; Fri, 14 Nov 2003 20:18:41 -0800 (PST) Received: from regina.plastikos.com (216-107-106-250.wan.networktel.net [216.107.106.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74AB843F75 for ; Fri, 14 Nov 2003 20:18:40 -0800 (PST) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-212-172-144.jan.bellsouth.net [68.212.172.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by regina.plastikos.com (Postfix) with ESMTP id 86CBA6EECD for ; Fri, 14 Nov 2003 23:18:39 -0500 (EST) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 8FD6420F2A; Fri, 14 Nov 2003 22:18:37 -0600 (CST) Date: Fri, 14 Nov 2003 22:18:37 -0600 From: "Matthew D. Fuller" To: Poul-Henning Kamp Message-ID: <20031115041837.GU12248@over-yonder.net> References: <20031113064251.GB39616@cirb503493.alcatel.com.au> <4937.1068707682@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4937.1068707682@critter.freebsd.dk> User-Agent: Mutt/1.4.1i-fullermd.1 X-Editor: vi X-OS: FreeBSD cc: Peter Jeremy cc: arch@freebsd.org Subject: Re: newfs and mount vs. half-baked disks X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 04:18:41 -0000 On Thu, Nov 13, 2003 at 08:14:42AM +0100 I heard the voice of Poul-Henning Kamp, and lo! it spake thus: > >On Wed, Nov 12, 2003 at 09:56:14AM +0100, Poul-Henning Kamp wrote: > > > >How do you handle the situation when the master superblock on / is > >hosed and you need to find the filesystem parameters (in > >/etc/ufs.conf) before you can access /? > > I usually take great care to always newfs / with default parameters, > because then I can use newfs -N /dev/ad0a to see where the superblocks > are to be found. Doesn't always help much... My / has 8192/1024 block/frags, and I somehow expect other defaults things have changed since last I newfs'd it. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 20:57:56 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53E5616A4CE for ; Fri, 14 Nov 2003 20:57:56 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E3743F3F for ; Fri, 14 Nov 2003 20:57:55 -0800 (PST) (envelope-from nectar@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id B0F01548A2; Fri, 14 Nov 2003 22:57:54 -0600 (CST) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 02859-01; Fri, 14 Nov 2003 22:57:44 -0600 (CST) Received: from lum.celabo.org (dhcp-204.celabo.org [10.0.1.204]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id F162854883; Fri, 14 Nov 2003 22:57:43 -0600 (CST) Received: from freebsd.org (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 2FF53108FFE; Fri, 14 Nov 2003 22:58:01 -0600 (CST) Message-ID: <3FB5B258.6010207@freebsd.org> Date: Fri, 14 Nov 2003 22:58:00 -0600 From: Jacques Vidrine User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20031114194119.GA94198@madman.celabo.org> <20031115114906.L11453@gamplex.bde.org> In-Reply-To: <20031115114906.L11453@gamplex.bde.org> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@FreeBSD.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 04:57:56 -0000 Bruce Evans said the following on 11/14/03 6:54 PM: > I prefer the cast. Actually, so do I :-) MIN/MAX values won't work for removing some (IMHO stupid) warnings emitted by GCC. So this kind of thing OK? long n; time_t t; errno = 0; n = strtoul(...); if (errno == ERANGE || (long)(t = n) != n) /* out of range */; > It doesn't require nonstandard infrastructure that > would need to be maintained forever, and works even better for floating > point too (assuming a C99 compiler, but not in reality in FreeBSD :) > (min/max checks don't work right for floating point because precision > may be just as important as range). Good points, thank you. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 22:24:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9CB216A4CE; Fri, 14 Nov 2003 22:24:30 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF38A43FA3; Fri, 14 Nov 2003 22:24:29 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAF6OTYR019044; Sat, 15 Nov 2003 01:24:29 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 15 Nov 2003 01:24:28 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 06:24:30 -0000 Recently on the freebsd-sparc64 list, it was mentioned that it would be nice to upgrade time_t on that port to be 64-bit. It is pretty obvious (to me at least) that we could bite the bullet and do it (disruptively) right now. If we don't, then (IMO) we pretty much have to wait until the 6.x-branch. On the plus side for doing it RightNow: The amd64 and ia64 ports already have a 64-bit time_t, and it would be nice if the sparc64 port did too. It will be easier to do it now (when sparc64 has very few users), then it will be a few years from now (by the time 6.0-release is released). Harti Brandt did do a buildworld/installworld of a 64-bit time_t on sparc64, and it seemed to work pretty well once he made it through the install. On the minus side: The sparc64 port is big-endian, while the ia64 and amd64 ports are little-endian, so incorrect code is more likely to cause serious problems on sparc64. (maybe that's a good thing...). There is already plenty to do for 5.2-release. The code freeze is about 48 hours away. When this came up on the sparc64 list, I believe there were four people who offered to do help with some of the work that would be caused by making this change. Me, Marcel, Matt@grogged.dyndns, and Harti. No one jumped up and said they were explicitly against the idea. On the other hand, none of us who do want the change really have a lot of time to devote to whatever problems come up. Given the imminent code freeze, I am not comfortable with commiting the actual change for 64-bit time_t on sparc64 given only four people who seem actively interested. On the other hand, I haven't the slightest idea how many people are actively running sparc64... Maybe four is a significant part of the active userbase! So, I thought I'd explicitly say that I don't think we should make the change this late in the game.. But I *would* be happy if other developers wanted to shout me down and go ahead with the it... :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 22:36:33 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3667E16A4CE for ; Fri, 14 Nov 2003 22:36:33 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 5C97C43FAF for ; Fri, 14 Nov 2003 22:36:32 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 32350 invoked by uid 1002); 15 Nov 2003 06:36:31 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 15 Nov 2003 06:36:31 -0000 Message-ID: <3FB5C942.1010907@freebsd.org> Date: Fri, 14 Nov 2003 23:35:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 06:36:33 -0000 Garance A Drosihn wrote: > Recently on the freebsd-sparc64 list, it was mentioned that it > would be nice to upgrade time_t on that port to be 64-bit. It > is pretty obvious (to me at least) that we could bite the bullet > and do it (disruptively) right now. If we don't, then (IMO) we > pretty much have to wait until the 6.x-branch. > > On the plus side for doing it RightNow: > The amd64 and ia64 ports already have a 64-bit time_t, > and it would be nice if the sparc64 port did too. > It will be easier to do it now (when sparc64 has very > few users), then it will be a few years from now > (by the time 6.0-release is released). > Harti Brandt did do a buildworld/installworld of a > 64-bit time_t on sparc64, and it seemed to work > pretty well once he made it through the install. > > On the minus side: > The sparc64 port is big-endian, while the ia64 and > amd64 ports are little-endian, so incorrect > code is more likely to cause serious problems > on sparc64. (maybe that's a good thing...). > There is already plenty to do for 5.2-release. > The code freeze is about 48 hours away. > > When this came up on the sparc64 list, I believe there were > four people who offered to do help with some of the work > that would be caused by making this change. Me, Marcel, > Matt@grogged.dyndns, and Harti. No one jumped up and said > they were explicitly against the idea. On the other hand, > none of us who do want the change really have a lot of time > to devote to whatever problems come up. > > Given the imminent code freeze, I am not comfortable with > commiting the actual change for 64-bit time_t on sparc64 > given only four people who seem actively interested. On > the other hand, I haven't the slightest idea how many people > are actively running sparc64... Maybe four is a significant > part of the active userbase! > > So, I thought I'd explicitly say that I don't think we > should make the change this late in the game.. But I > *would* be happy if other developers wanted to shout me > down and go ahead with the it... :-) > Switching to 64-bit time_t this late in the 5.2 cycle will likely cause more excitement than we can handle. I'm not even sure if sparc64 can build a release at this point; I need to get that going this weekend. I agree with you points and agree that it needs to be done soon. Why don't we put this on the TODO list for 5.3, and plan to do it in early January, assuming that Jake and Thomas are ok with it. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Nov 14 23:12:05 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0A3D16A4D0; Fri, 14 Nov 2003 23:12:05 -0800 (PST) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D662D43F3F; Fri, 14 Nov 2003 23:12:04 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAF7C4tp027558; Sat, 15 Nov 2003 02:12:04 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3FB5C942.1010907@freebsd.org> References: <3FB5C942.1010907@freebsd.org> Date: Sat, 15 Nov 2003 02:12:02 -0500 To: Scott Long From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 07:12:05 -0000 At 11:35 PM -0700 11/14/03, Scott Long wrote: >Garance A Drosihn wrote: >>Recently on the freebsd-sparc64 list, it was mentioned >>that it would be nice to upgrade time_t on that port to >>be 64-bit. [...mumble mumble...] >>So, I thought I'd explicitly say that I don't think we >>should make the change this late in the game.. > >Switching to 64-bit time_t this late in the 5.2 cycle will >likely cause more excitement than we can handle. ... >...Why don't we put this on the TODO list for 5.3, and >plan to do it in early January, assuming that Jake and >Thomas are ok with it. Personally I am inclined to think that we have to stop making ABI/API changes to 5.x or we will never ever get to "5.x-stable". It would be nice if 5.2 were the last set of API/ABI changes, so that people who install it can at least have a painless upgrade to 5.3-release (which will hopefully be 5.x-stable). However, I really would like to see the 64-bit time_t happen, and I'm certainly willing to help out (as time permits) if we were to make this change on sparc64 in early January. I'll even start testing such changes on my own sparc64 system during the code-freeze for 5.2. [however, it takes about 11 hours for build/installworld on my system, so there's a limit to how much I can test!] Certainly it's more important to get make-release and kse-for-sparc64 working for 5.2-release than it is to make this time_t change. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 00:17:16 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D4816A4CE; Sat, 15 Nov 2003 00:17:16 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 251C343F3F; Sat, 15 Nov 2003 00:17:15 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id TAA03482; Sat, 15 Nov 2003 19:17:11 +1100 Date: Sat, 15 Nov 2003 19:17:10 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Jacques Vidrine In-Reply-To: <3FB5B258.6010207@freebsd.org> Message-ID: <20031115190419.G1478@gamplex.bde.org> References: <20031114194119.GA94198@madman.celabo.org> <20031115114906.L11453@gamplex.bde.org> <3FB5B258.6010207@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@FreeBSD.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 08:17:16 -0000 On Fri, 14 Nov 2003, Jacques Vidrine wrote: > Bruce Evans said the following on 11/14/03 6:54 PM: > > > I prefer the cast. > > Actually, so do I :-) MIN/MAX values won't work for removing some (IMHO > stupid) warnings emitted by GCC. So this kind of thing OK? > > long n; > time_t t; > errno = 0; > n = strtoul(...); > if (errno == ERANGE || (long)(t = n) != n) > /* out of range */; Not quite like that. strtoul() returns an unsigned long whose value may be lost by assigning it to a plain long. Mixtures of signed and unsigned types are tricky to handle as usual. Suppose we make n unsigned long and it has value ULONG_MAX, and time_t is long, then (t = n) == n, but t doesn't actually represent n (casting (t = n) to long or unsigned long doesn't help). So it seems to be necessary to be aware that time_t is signed and either use strtol() initially or check that t >= 0 if n is unsigned long. If time_t is actually signed then we may get a GCC warning for this check... Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 05:04:01 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B272D16A4CE for ; Sat, 15 Nov 2003 05:04:01 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80BD643FE3 for ; Sat, 15 Nov 2003 05:03:58 -0800 (PST) (envelope-from nectar@freebsd.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 0BD035489C; Sat, 15 Nov 2003 07:03:58 -0600 (CST) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08540-07; Sat, 15 Nov 2003 07:03:47 -0600 (CST) Received: from lum.celabo.org (dhcp-204.celabo.org [10.0.1.204]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 443F654883; Sat, 15 Nov 2003 07:03:47 -0600 (CST) Received: from freebsd.org (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 2DFC010902D; Sat, 15 Nov 2003 07:04:05 -0600 (CST) Message-ID: <3FB62444.9000102@freebsd.org> Date: Sat, 15 Nov 2003 07:04:04 -0600 From: Jacques Vidrine User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20031114194119.GA94198@madman.celabo.org> <20031115114906.L11453@gamplex.bde.org> <3FB5B258.6010207@freebsd.org> <20031115190419.G1478@gamplex.bde.org> In-Reply-To: <20031115190419.G1478@gamplex.bde.org> X-Enigmail-Version: 0.81.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@FreeBSD.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 13:04:01 -0000 Bruce Evans said the following on 11/15/03 2:17 AM: > On Fri, 14 Nov 2003, Jacques Vidrine wrote: >> So this kind of thing OK? >> >> long n; >> time_t t; >> errno = 0; >> n = strtoul(...); >> if (errno == ERANGE || (long)(t = n) != n) >> /* out of range */; > > > Not quite like that. strtoul() returns an unsigned long whose value may > be lost by assigning it to a plain long. Mixtures of signed and unsigned > types are tricky to handle as usual. Suppose we make n unsigned long > and it has value ULONG_MAX, and time_t is long, then (t = n) == n, > but t doesn't actually represent n (casting (t = n) to long or unsigned > long doesn't help). So it seems to be necessary to be aware that time_t > is signed and either use strtol() initially or check that t >= 0 if > n is unsigned long. If time_t is actually signed then we may get a GCC > warning for this check... Doh, sorry, that's a typo. I meant strtol (which is what is currently used in the relevant portion of libc--- strptime.c, BTW). Negative values must be allowed here. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 07:06:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1341616A4CE; Sat, 15 Nov 2003 07:06:42 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 407B043FBD; Sat, 15 Nov 2003 07:06:40 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])hAFF6au20115; Sat, 15 Nov 2003 16:06:36 +0100 (MET) Date: Sat, 15 Nov 2003 16:06:36 +0100 (CET) From: Harti Brandt To: Garance A Drosihn In-Reply-To: Message-ID: <20031115155943.W87142@beagle.fokus.fraunhofer.de> References: <3FB5C942.1010907@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 15:06:42 -0000 On Sat, 15 Nov 2003, Garance A Drosihn wrote: GAD>At 11:35 PM -0700 11/14/03, Scott Long wrote: GAD>>Garance A Drosihn wrote: GAD>>>Recently on the freebsd-sparc64 list, it was mentioned GAD>>>that it would be nice to upgrade time_t on that port to GAD>>>be 64-bit. GAD> [...mumble mumble...] GAD> GAD>>>So, I thought I'd explicitly say that I don't think we GAD>>>should make the change this late in the game.. GAD>> GAD>>Switching to 64-bit time_t this late in the 5.2 cycle will GAD>>likely cause more excitement than we can handle. ... GAD>>...Why don't we put this on the TODO list for 5.3, and GAD>>plan to do it in early January, assuming that Jake and GAD>>Thomas are ok with it. GAD> GAD>Personally I am inclined to think that we have to stop GAD>making ABI/API changes to 5.x or we will never ever get GAD>to "5.x-stable". It would be nice if 5.2 were the last GAD>set of API/ABI changes, so that people who install it can GAD>at least have a painless upgrade to 5.3-release (which GAD>will hopefully be 5.x-stable). GAD> GAD>However, I really would like to see the 64-bit time_t GAD>happen, and I'm certainly willing to help out (as time GAD>permits) if we were to make this change on sparc64 in GAD>early January. I'll even start testing such changes on GAD>my own sparc64 system during the code-freeze for 5.2. GAD> GAD>[however, it takes about 11 hours for build/installworld GAD>on my system, so there's a limit to how much I can test!] GAD> GAD>Certainly it's more important to get make-release and GAD>kse-for-sparc64 working for 5.2-release than it is to GAD>make this time_t change. I'm running one of my two sparcs since then without any problem with 64-bit time_t (I don't have many ports on it - perl, bash, a dozen or so). I was waiting for thomas and jake to say something on this. Also someone wanted to test it, but I did not here from him. I think that Scott is right, it's too late for 5.2 but we should definitely try to do it for 5.3. The biggest problem is getting the upgrade process right, but this should be manageable. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 14:38:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FA0916A4CE; Sat, 15 Nov 2003 14:38:32 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55FF643FE5; Sat, 15 Nov 2003 14:38:31 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfj2j.dialup.mindspring.com ([165.247.204.83] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AL92t-0004Or-00; Sat, 15 Nov 2003 14:37:36 -0800 Message-ID: <3FB6AA8F.37ED6D50@mindspring.com> Date: Sat, 15 Nov 2003 14:37:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20031114194119.GA94198@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e92a567895908f40805ed6208cb31923387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 22:38:32 -0000 "Jacques A. Vidrine" wrote: > In at least one place in libc, it is necessary to range check a time_t > value. One most platforms, time_t has the same range as `int', but > on at least amd64, it has a larger range. Any objections to adding > definitions of __TIME_MIN and __TIME_MAX to sys/${arch}/_limits.h? > > I could just do the usual check for lossage after casting, except that > in theory time_t could be a floating-point value (but not in reality > in FreeBSD). It seems cleaner to me to have an explicit range. XSI: time_t and clock_t shall be integer or real-floating types. The range should be derived from th type. Defining separate values outside the implementation namespace might be OK, but keeping those values synchronized with the size_t is likely to be painful for years to come. -- Terry From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 15:02:44 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28C5516A4CE for ; Sat, 15 Nov 2003 15:02:44 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D2B43F85 for ; Sat, 15 Nov 2003 15:02:43 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 83DAC72DB5; Sat, 15 Nov 2003 15:02:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 816BB72DAD; Sat, 15 Nov 2003 15:02:43 -0800 (PST) Date: Sat, 15 Nov 2003 15:02:43 -0800 (PST) From: Doug White To: Garance A Drosihn In-Reply-To: Message-ID: <20031115150022.U5733@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.ORG Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2003 23:02:44 -0000 On Sat, 15 Nov 2003, Garance A Drosihn wrote: > Recently on the freebsd-sparc64 list, it was mentioned that it > would be nice to upgrade time_t on that port to be 64-bit. It > is pretty obvious (to me at least) that we could bite the bullet > and do it (disruptively) right now. If we don't, then (IMO) we > pretty much have to wait until the 6.x-branch. Considering the scope and potential disruptiveness of such a change, I think waiting till 6.x is a better avenue, when we can pull the switch on all the platforms. This isn't the sort of thing to pull after a .0 release, even if it means more user impact down the road. We already reserve new major branch releases for serious breakage and no compatibility guarantees; lets try to save game-breakers like this for those times. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 22:32:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAA8A16A4CF; Sat, 15 Nov 2003 22:32:10 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C67843FB1; Sat, 15 Nov 2003 22:32:10 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 529F272D9B; Sat, 15 Nov 2003 22:31:55 -0800 (PST) From: Wes Peters Organization: Softweyr To: Garance A Drosihn , Scott Long Date: Sat, 15 Nov 2003 22:32:07 -0800 User-Agent: KMail/1.5.4 References: <3FB5C942.1010907@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311152232.07935.wes@softweyr.com> cc: arch@freebsd.org Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2003 06:32:10 -0000 On Friday 14 November 2003 11:12 pm, Garance A Drosihn wrote: > At 11:35 PM -0700 11/14/03, Scott Long wrote: > >Switching to 64-bit time_t this late in the 5.2 cycle will > >likely cause more excitement than we can handle. ... > >...Why don't we put this on the TODO list for 5.3, and > >plan to do it in early January, assuming that Jake and > >Thomas are ok with it. > > Personally I am inclined to think that we have to stop > making ABI/API changes to 5.x or we will never ever get > to "5.x-stable". It would be nice if 5.2 were the last > set of API/ABI changes, so that people who install it can > at least have a painless upgrade to 5.3-release (which > will hopefully be 5.x-stable). Refraining from changing the ABI is one of the many thing that "STABLE" means in FreeBSD. We agreed quite some time ago there is too much to do to get everything in by 5.2 and pushed back the -STABLE timeline to 5.3. So you've been given a reprieve. And just think of all that testing time you'll have over the holidays to make sure it's really really right. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-arch@FreeBSD.ORG Sat Nov 15 23:41:38 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B66F16A4CE; Sat, 15 Nov 2003 23:41:38 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A294043F93; Sat, 15 Nov 2003 23:41:37 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.10/8.12.9) with ESMTP id hAG7faYR003973; Sun, 16 Nov 2003 02:41:37 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200311152232.07935.wes@softweyr.com> References: <3FB5C942.1010907@freebsd.org> <200311152232.07935.wes@softweyr.com> Date: Sun, 16 Nov 2003 02:41:35 -0500 To: Wes Peters , Scott Long From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: arch@freebsd.org Subject: Re: 64-bit time_t on sparc64, epilogue(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2003 07:41:38 -0000 At 10:32 PM -0800 11/15/03, Wes Peters wrote: > >... and pushed back the -STABLE timeline to 5.3. So you've >been given a reprieve. And just think of all that testing >time you'll have over the holidays to make sure it's really >really right. ;^) Okay, I'll get right on it! :-) (well, maybe not until next weekend...) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu