From owner-freebsd-arch@FreeBSD.ORG Sun Sep 21 09:42:55 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2BF1065676 for ; Sun, 21 Sep 2008 09:42:55 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF5D8FC14 for ; Sun, 21 Sep 2008 09:42:54 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 8F67E2218AE2; Sun, 21 Sep 2008 19:27:02 +1000 (EST) X-Viruscan-Id: <48D61366000157B15EA163@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 4E39521B5BAD for ; Sun, 21 Sep 2008 19:27:02 +1000 (EST) Received: from k7.mavetju (ppp121-44-67-122.lns10.syd6.internode.on.net [121.44.67.122]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 06BA02218ACA for ; Sun, 21 Sep 2008 19:27:02 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id C87E16A1; Sun, 21 Sep 2008 19:27:04 +1000 (EST) Date: Sun, 21 Sep 2008 19:27:04 +1000 From: Edwin Groothuis To: freebsd-arch@freebsd.org Message-ID: <20080921092704.GC83347@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: tzcode update to 2008e X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2008 09:42:55 -0000 Currently the tzcode in the FreeBSD operating system is from 2004. I have updated, on my development machine at home, src/lib/libc/stdtime and src/usr.sbin/zic to tzcode version 2008e. It still works. zic compiles the zonefiles into version 2 format, zdump properly shows the data. The strftime() tests with the date regression tests (bin/127514: [patch] regression tests for date(1)) work fine. The patch can be found at http://www.mavetju.org/~edwin/tzcode2008e-update.txt, it is against current. The MFCs for 7.x and 6.x should be relatively simple. I have done it on i386, so I'm happy to hear how other architectures are going with it. And then, euhm... yeah, what's next? Edwin -- Edwin Groothuis edwin@freebsd.org http://www.mavetju.org From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 05:32:17 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 926891065672 for ; Mon, 22 Sep 2008 05:32:17 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id 591368FC17 for ; Mon, 22 Sep 2008 05:32:17 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wr-out-0506.google.com with SMTP id c8so176993wra.27 for ; Sun, 21 Sep 2008 22:32:16 -0700 (PDT) Received: by 10.100.143.12 with SMTP id q12mr2501504and.24.1222061536344; Sun, 21 Sep 2008 22:32:16 -0700 (PDT) Received: by 10.100.154.11 with HTTP; Sun, 21 Sep 2008 22:32:16 -0700 (PDT) Message-ID: Date: Sun, 21 Sep 2008 22:32:16 -0700 From: "Peter Wemm" To: "Edwin Groothuis" In-Reply-To: <20080921092704.GC83347@k7.mavetju> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080921092704.GC83347@k7.mavetju> Cc: freebsd-arch@freebsd.org Subject: Re: tzcode update to 2008e X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 05:32:17 -0000 On Sun, Sep 21, 2008 at 2:27 AM, Edwin Groothuis wrote: > Currently the tzcode in the FreeBSD operating system is from 2004. > I have updated, on my development machine at home, src/lib/libc/stdtime > and src/usr.sbin/zic to tzcode version 2008e. It still works. > > zic compiles the zonefiles into version 2 format, zdump properly > shows the data. The strftime() tests with the date regression tests > (bin/127514: [patch] regression tests for date(1)) work fine. > > The patch can be found at > http://www.mavetju.org/~edwin/tzcode2008e-update.txt, it is against > current. The MFCs for 7.x and 6.x should be relatively simple. > > I have done it on i386, so I'm happy to hear how other architectures > are going with it. And then, euhm... yeah, what's next? > > Edwin What happens when you run old static linked binaries? Will they understand 'version 2 format' zone files? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 09:23:16 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793A51065672 for ; Mon, 22 Sep 2008 09:23:16 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 3A24D8FC1F for ; Mon, 22 Sep 2008 09:23:16 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 62CA02218A7B; Mon, 22 Sep 2008 19:23:15 +1000 (EST) X-Viruscan-Id: <48D76403000171074A1C45@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 1E78221B5ECF; Mon, 22 Sep 2008 19:23:15 +1000 (EST) Received: from k7.mavetju (ppp121-44-67-122.lns10.syd6.internode.on.net [121.44.67.122]) by mail5auth.barnet.com.au (Postfix) with ESMTP id BA2392218A69; Mon, 22 Sep 2008 19:23:14 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id B61716BE; Mon, 22 Sep 2008 19:22:45 +1000 (EST) Date: Mon, 22 Sep 2008 19:22:45 +1000 From: Edwin Groothuis To: Peter Wemm Message-ID: <20080922092245.GA3233@k7.mavetju> References: <20080921092704.GC83347@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: tzcode update to 2008e X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 09:23:16 -0000 On Sun, Sep 21, 2008 at 10:32:16PM -0700, Peter Wemm wrote: > On Sun, Sep 21, 2008 at 2:27 AM, Edwin Groothuis wrote: > > Currently the tzcode in the FreeBSD operating system is from 2004. > > I have updated, on my development machine at home, src/lib/libc/stdtime > > and src/usr.sbin/zic to tzcode version 2008e. It still works. > > > > zic compiles the zonefiles into version 2 format, zdump properly > > shows the data. The strftime() tests with the date regression tests > > (bin/127514: [patch] regression tests for date(1)) work fine. > > > > The patch can be found at > > http://www.mavetju.org/~edwin/tzcode2008e-update.txt, it is against > > current. The MFCs for 7.x and 6.x should be relatively simple. > > > > I have done it on i386, so I'm happy to hear how other architectures > > are going with it. And then, euhm... yeah, what's next? > > > > Edwin > > What happens when you run old static linked binaries? Will they > understand 'version 2 format' zone files? If I understand the code and its behaviour correct (which I asusme I did, but feel free to correct me, the relevant data is tzload() in lib/libc/stdtime/localtime.c :-), the version two data is added to the end of the zonefile. A diff of the two shows that this is indeed happening. I have installed the new zonefile on an 7.0 OS and ran the regression tests and old zdump on it without problems. So the conclusion for me is that it is working fine with statically linked libraries. For 7.0 users, the patches can be found at http://www.mavetju.org/~edwin/tzcode2008e-update-7.txt. Edwin -- Edwin Groothuis edwin@freebsd.org http://www.mavetju.org From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 11:06:50 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2862C106564A for ; Mon, 22 Sep 2008 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F39988FC13 for ; Mon, 22 Sep 2008 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8MB6nx5015304 for ; Mon, 22 Sep 2008 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8MB6nTt015300 for freebsd-arch@FreeBSD.org; Mon, 22 Sep 2008 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Sep 2008 11:06:49 GMT Message-Id: <200809221106.m8MB6nTt015300@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 11:50:35 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 407511065677 for ; Mon, 22 Sep 2008 11:50:35 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 66FB48FC17 for ; Mon, 22 Sep 2008 11:50:33 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so503773nfh.33 for ; Mon, 22 Sep 2008 04:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:sender; bh=+6W6sRRm4IttpMGzDuxkA16nYASQBGrSj1LykV+Vv+g=; b=MK5LZrHbaIt3Rm9TNYvZG1JGWVKKEjjXaSCQGIIQ410atRYUesTt8EJEdLOn57UFRd nloJj8lwZVqxexVTL3pFAXh3mwMcrPpSeavmMdTFzfN6tldywgVgKnU4KgaR+TzYsbeN bg9umHBjJhpIMen/TxBugCGc197tLsH6TyurQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent:sender; b=po8gED59C4N7jvE5VlEx19talSkpXtFoxkf2obr3A6B00Ef/fzqwm7WinecfyxxNdt KAjK7Gu+HYAmdkjlVHRs4J2pE9TQs12V/3bd1qTmXhHMu4HExdcPQ1nIo4aoKtjh28Cr ihaMFYXX3GTKIHyq7jNACSn3ADKGrd+15kDsA= Received: by 10.210.123.2 with SMTP id v2mr1717496ebc.186.1222082296449; Mon, 22 Sep 2008 04:18:16 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id j8sm351575gvb.1.2008.09.22.04.18.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Sep 2008 04:18:15 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id CD4EDF554; Mon, 22 Sep 2008 12:15:46 +0100 (WEST) Date: Mon, 22 Sep 2008 12:15:46 +0100 From: Rui Paulo To: John Baldwin Message-ID: <20080922111546.GB10240@alpha.local> References: <200809191437.28550.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809191437.28550.jhb@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: arch@freebsd.org Subject: Re: Trim interrupt messages in dmesg.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 11:50:35 -0000 On Fri, Sep 19, 2008 at 02:37:28PM -0400, John Baldwin wrote: > Personally, I find the MPSAFE/ITHREAD/FILTER messages a bit much in dmesg. > I'd like to cut it back to just warning about GIANT-locked handlers. > Thoughts? Go for it. As Sam pointed out, it would be nice to have this information in devinfo, but don't let that stop you. Regards, -- Rui Paulo From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 13:19:47 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002EA1065670 for ; Mon, 22 Sep 2008 13:19:46 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id B51E68FC1D for ; Mon, 22 Sep 2008 13:19:46 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id C90FB2218A3F; Mon, 22 Sep 2008 23:19:45 +1000 (EST) X-Viruscan-Id: <48D79B710001622CD0C7AE@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 86FB021B5B79 for ; Mon, 22 Sep 2008 23:19:45 +1000 (EST) Received: from k7.mavetju (ppp121-44-67-122.lns10.syd6.internode.on.net [121.44.67.122]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 409C92218A3A for ; Mon, 22 Sep 2008 23:19:45 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 4477677F; Mon, 22 Sep 2008 23:19:16 +1000 (EST) Date: Mon, 22 Sep 2008 23:19:16 +1000 From: Edwin Groothuis To: freebsd-arch@freebsd.org Message-ID: <20080922131916.GB3233@k7.mavetju> References: <20080921092704.GC83347@k7.mavetju> <20080922092245.GA3233@k7.mavetju> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080922092245.GA3233@k7.mavetju> User-Agent: Mutt/1.4.2.3i Subject: Re: tzcode update to 2008e X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 13:19:47 -0000 On Mon, Sep 22, 2008 at 07:22:45PM +1000, Edwin Groothuis wrote: > For 7.0 users, the patches can be found at > http://www.mavetju.org/~edwin/tzcode2008e-update-7.txt. For people who want to try it, after compiling and installing libc and the files in usr.sbin/zic, you need to also (re)install src/share/zoneinfo or ports/misc/zoneinfo, to get the zone-files compiled with the right zic(8) binary, and then run tzsetup(8) to install /etc/localtime again. I just had it tested on an amd64 machine with releng_7 on it and it worked fine on it. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 15:44:31 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94FD31065685; Mon, 22 Sep 2008 15:44:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 716518FC0C; Mon, 22 Sep 2008 15:44:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m8MFiVLN059135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 08:44:31 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48D7BD5E.6060005@freebsd.org> Date: Mon, 22 Sep 2008 08:44:30 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Rui Paulo References: <200809191437.28550.jhb@freebsd.org> <20080922111546.GB10240@alpha.local> In-Reply-To: <20080922111546.GB10240@alpha.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: arch@freebsd.org Subject: Re: Trim interrupt messages in dmesg.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 15:44:31 -0000 Rui Paulo wrote: > On Fri, Sep 19, 2008 at 02:37:28PM -0400, John Baldwin wrote: > >> Personally, I find the MPSAFE/ITHREAD/FILTER messages a bit much in dmesg. >> I'd like to cut it back to just warning about GIANT-locked handlers. >> Thoughts? >> > > Go for it. As Sam pointed out, it would be nice to have this information > in devinfo, but don't let that stop you. > > Regards, > "nice" is NOT what I said. Until there's a way to find this information please do not remove the printfs. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 21:09:33 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC40E1065675; Mon, 22 Sep 2008 21:09:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5888FC2E; Mon, 22 Sep 2008 21:09:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8ML9A92063662; Mon, 22 Sep 2008 17:09:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marius Strobl Date: Mon, 22 Sep 2008 16:39:55 -0400 User-Agent: KMail/1.9.7 References: <200809181356.m8IDuaxT089888@repoman.freebsd.org> <89B9A8BE-05F2-4DB2-B7B2-AB240AA9F0DD@mac.com> <20080920231152.GA67442@alchemy.franken.de> In-Reply-To: <20080920231152.GA67442@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809221639.56429.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 22 Sep 2008 17:09:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8310/Mon Sep 22 14:58:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, Marcel Moolenaar , src-committers@freebsd.org, cvs-all@freebsd.org, arch@freebsd.org Subject: Re: removal of ipi_all() and ipi_self() [Re: cvs commit: src/sys/sparc64/include smp.h src/sys/sparc64/sparc64 genassym.c mp_machdep.c] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 21:09:33 -0000 On Saturday 20 September 2008 07:11:53 pm Marius Strobl wrote: > On Thu, Sep 18, 2008 at 12:48:52PM -0700, Marcel Moolenaar wrote: > > > > On Sep 18, 2008, at 12:19 PM, Marius Strobl wrote: > > > > >On Thu, Sep 18, 2008 at 10:27:51AM -0400, John Baldwin wrote: > > >>On Thursday 18 September 2008 09:56:30 am Marius Strobl wrote: > > >>>marius 2008-09-18 13:56:30 UTC > > >>> > > >>> FreeBSD src repository > > >>> > > >>> Modified files: > > >>> sys/sparc64/include smp.h > > >>> sys/sparc64/sparc64 genassym.c mp_machdep.c > > >>> Log: > > >>> SVN rev 183142 on 2008-09-18 13:56:30Z by marius > > >>> > > >>> - Newer firmware versions no longer provide SUNW,stop-self so just > > >>> disable interrupts and loop forever with these. > > >>> - Hide all MP-related bits in underneath #ifdef > > >>>SMP. > > >>> - Inline ipi_all_but_self(9) and ipi_selected(9). We don't expose > > >>>any > > >>> additional bits but save a few cycles by doing so. > > >>> - Remove ipi_all(9), which actually only called panic(9). It > > >>>can't be > > >>> implemented natively anyway and having it removed at least causes > > >>> MI users to fail already fail when linking. > > >> > > >>Should we just remove ipi_all() completely? > > >> > > > > > >Well, grepping in the CVS repository shows that there never was > > >an actually consumer of ipi_all() (only #ifdef'ed out ones in > > >ironically the sparc64 code) so it seems to be a good candidate > > >for axing. Generally I can't think of a reason why MI code would > > >want a CPU to send an IPI to itself. Actually, ipi_self() also > > >isn't and never was used in MI code, only in ia64 and powerpc > > >code for testing purposes. > > > > That's DS (=developer-specific) code rather than MI or MD code :-) > > > > Sending a test IPI to 'self' helps with bring-up or porting, but > > serves no real purpose (other than maybe a POST-like purpose) > > once IPIs are known to work... > > > > Okay, I take these as a call for removing ipi_all() and ipi_self() > along with the ia64 and powerpc test IPI code completely. A patch > doing just that and which passes a universe build just fine is at: > http://people.freebsd.org/~marius/nuke_ipi_all_self.diff > Does anybody object to committing it? Should __FreeBSD_version be > bumped for this? I think this is ok. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 21:09:41 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A507E10656DD for ; Mon, 22 Sep 2008 21:09:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 48CFA8FC2A for ; Mon, 22 Sep 2008 21:09:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8ML9A93063662; Mon, 22 Sep 2008 17:09:30 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ed Schouten Date: Mon, 22 Sep 2008 16:40:37 -0400 User-Agent: KMail/1.9.7 References: <200809191437.28550.jhb@freebsd.org> <20080920082949.GX81522@hoeg.nl> In-Reply-To: <20080920082949.GX81522@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809221640.37956.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 22 Sep 2008 17:09:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8310/Mon Sep 22 14:58:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: arch@freebsd.org Subject: Re: Trim interrupt messages in dmesg.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 21:09:41 -0000 On Saturday 20 September 2008 04:29:49 am Ed Schouten wrote: > Hello John, > > * John Baldwin wrote: > > Personally, I find the MPSAFE/ITHREAD/FILTER messages a bit much in dmesg. > > I'd like to cut it back to just warning about GIANT-locked handlers. > > Thoughts? > > What about printing all the flags only when bootverbose is turned on, > just like MPSAFE is right now? I think dmesg is the wrong place for this information. An intrinfo or some such would be better. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 19:12:30 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E95E1065678; Tue, 23 Sep 2008 19:12:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6FEF8FC0C; Tue, 23 Sep 2008 19:12:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8NJCNcj074806; Tue, 23 Sep 2008 15:12:23 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: arch@freebsd.org Date: Tue, 23 Sep 2008 15:09:40 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809231509.40279.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 23 Sep 2008 15:12:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8316/Tue Sep 23 05:40:56 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pjd@freebsd.org Subject: Using a file-backed swap via md0 results in panic on reboot.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 19:12:30 -0000 So if you attach an md device to a file and then use that md0 device for swap, you will get a panic on shutdown if the swap file was in use. The reason is that we remove swap devices _after_ unmounting the filesystems in boot(): if (nbusy) { /* * Failed to sync all blocks. Indicate this and don't * unmount filesystems (thus forcing an fsck on reboot). */ printf("Giving up on %d buffers\n", nbusy); DELAY(5000000); /* 5 seconds */ } else { if (!first_buf_printf) printf("Final sync complete\n"); /* * Unmount filesystems */ if (panicstr == 0) vfs_unmountall(); } swapoff_all(); DELAY(100000); /* wait for console output to finish */ Is there any reason we can't move the swapoff_all()? Should we perhaps only do it in "clean" case? Alternatively, should the swapoff_all() during shutdown have a special flag so that it doesn't actually read in any data from disk and just throws away the data instead? Sample panic: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done All buffers synced. Swap device ad0s1b removed. swap_pager: I/O error - pagein failed; blkno 2097177,size 4096, error 5 panic: swap_pager_force_pagein: read from swap failed cpuid = 0 KDB: stack backtrace: panic() at panic+0x2c5 swapoff_one() at swapoff_one+0x5bb swapoff_all() at swapoff_all+0xe4 boot() at boot+0x871 reboot() at reboot+0x45 syscall() at syscall+0x642 Xfast_syscall() at Xfast_syscall+0xa8 -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 19:55:32 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE0E4106566B for ; Tue, 23 Sep 2008 19:55:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 960CA8FC27 for ; Tue, 23 Sep 2008 19:55:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 47EA72484; Tue, 23 Sep 2008 12:55:32 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CDF192D600D; Tue, 23 Sep 2008 12:55:31 -0700 (PDT) Message-ID: <48D949B2.7020001@elischer.org> Date: Tue, 23 Sep 2008 12:55:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: John Baldwin References: <200809231509.40279.jhb@freebsd.org> In-Reply-To: <200809231509.40279.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, pjd@freebsd.org Subject: Re: Using a file-backed swap via md0 results in panic on reboot.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 19:55:32 -0000 John Baldwin wrote: > So if you attach an md device to a file and then use that md0 device for swap, > you will get a panic on shutdown if the swap file was in use. The reason is > that we remove swap devices _after_ unmounting the filesystems in boot(): > > if (nbusy) { > /* > * Failed to sync all blocks. Indicate this and don't > * unmount filesystems (thus forcing an fsck on reboot). > */ > printf("Giving up on %d buffers\n", nbusy); > DELAY(5000000); /* 5 seconds */ > } else { > if (!first_buf_printf) > printf("Final sync complete\n"); > /* > * Unmount filesystems > */ > if (panicstr == 0) > vfs_unmountall(); > } > swapoff_all(); > DELAY(100000); /* wait for console output to finish */ > > Is there any reason we can't move the swapoff_all()? Should we perhaps only > do it in "clean" case? Alternatively, should the swapoff_all() during > shutdown have a special flag so that it doesn't actually read in any data > from disk and just throws away the data instead? Sample panic: then what happens with a swap based filesystem? > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 > 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > Swap device ad0s1b removed. > swap_pager: I/O error - pagein failed; blkno 2097177,size 4096, error 5 > panic: swap_pager_force_pagein: read from swap failed > cpuid = 0 > KDB: stack backtrace: > panic() at panic+0x2c5 > swapoff_one() at swapoff_one+0x5bb > swapoff_all() at swapoff_all+0xe4 > boot() at boot+0x871 > reboot() at reboot+0x45 > syscall() at syscall+0x642 > Xfast_syscall() at Xfast_syscall+0xa8 > From owner-freebsd-arch@FreeBSD.ORG Tue Sep 23 20:15:06 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 996851065684 for ; Tue, 23 Sep 2008 20:15:06 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id F06468FC0C for ; Tue, 23 Sep 2008 20:15:05 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AC0EA456B1; Tue, 23 Sep 2008 21:44:57 +0200 (CEST) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5D0D445683; Tue, 23 Sep 2008 21:44:48 +0200 (CEST) Date: Tue, 23 Sep 2008 21:44:54 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20080923194454.GA2196@garage.freebsd.pl> References: <200809231509.40279.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <200809231509.40279.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: arch@freebsd.org Subject: Re: Using a file-backed swap via md0 results in panic on reboot.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 20:15:06 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 23, 2008 at 03:09:40PM -0400, John Baldwin wrote: > So if you attach an md device to a file and then use that md0 device for = swap,=20 > you will get a panic on shutdown if the swap file was in use. The reason= is=20 > that we remove swap devices _after_ unmounting the filesystems in boot(): >=20 > if (nbusy) { > /* > * Failed to sync all blocks. Indicate this and don't > * unmount filesystems (thus forcing an fsck on reboot). > */ > printf("Giving up on %d buffers\n", nbusy); > DELAY(5000000); /* 5 seconds */ > } else { > if (!first_buf_printf) > printf("Final sync complete\n"); > /* > * Unmount filesystems > */ > if (panicstr =3D=3D 0) > vfs_unmountall(); > } > swapoff_all(); > DELAY(100000); /* wait for console output to finish */ >=20 > Is there any reason we can't move the swapoff_all()? Should we perhaps o= nly=20 > do it in "clean" case? Alternatively, should the swapoff_all() during=20 > shutdown have a special flag so that it doesn't actually read in any data= =20 > from disk and just throws away the data instead? Sample panic: >=20 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0= 0 0=20 > 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > All buffers synced. > Swap device ad0s1b removed. > swap_pager: I/O error - pagein failed; blkno 2097177,size 4096, error 5 > panic: swap_pager_force_pagein: read from swap failed > cpuid =3D 0 > KDB: stack backtrace: > panic() at panic+0x2c5 > swapoff_one() at swapoff_one+0x5bb > swapoff_all() at swapoff_all+0xe4 > boot() at boot+0x871 > reboot() at reboot+0x45 > syscall() at syscall+0x642 > Xfast_syscall() at Xfast_syscall+0xa8 The problem is this: sometimes we want to first unmount file systems and sometimes we want to first remove swap devices. In your case you have swap device residing on a file system. Imagine the opposite situation where you have a file system residing on swap device: mdconfig -t swap; newfs /dev/mdX; mount /dev/mdX The solution I have been thinking about is to call vfs_unmountall() and swapoff_all() in a loop and changed them to return number of file system unmounted or swap devices removed respectively: do { i =3D vfs_unmountall(); j =3D swapoff_all(); } while (i > 0 || j > 0); Something like that would cover both situations and even more complex (although not very realistic) situations: FS on SWAP on FS on SWAP, etc. Of course vfs_unmountall() and swapoff_all() would have to skip busy file systems/swap devices. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFI2Uc2ForvXbEpPzQRAj8BAJ4tL3155Jc0ntg6LCwo+1VA5qTYggCgiD7c G8rWVF2s6cBzG9k60x+tAOY= =IuRy -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-arch@FreeBSD.ORG Wed Sep 24 04:45:59 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD11A1065678; Wed, 24 Sep 2008 04:45:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA6E8FC1B; Wed, 24 Sep 2008 04:45:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m8O4ipwX059544; Tue, 23 Sep 2008 22:44:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 23 Sep 2008 22:45:37 -0600 (MDT) Message-Id: <20080923.224537.-957831121.imp@bsdimp.com> To: jhein@timing.com From: "M. Warner Losh" In-Reply-To: <18641.24692.875414.533794@gromit.timing.com> References: <18641.9342.134166.77425@gromit.timing.com> <200809171321.45354.jhb@freebsd.org> <18641.24692.875414.533794@gromit.timing.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: 64 bit time_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2008 04:46:00 -0000 In message: <18641.24692.875414.533794@gromit.timing.com> John Hein writes: : John Baldwin wrote at 13:21 -0400 on Sep 17, 2008: : > On Wednesday 17 September 2008 11:38:38 am John Hein wrote: : > > John Baldwin wrote at 10:40 -0400 on Sep 17, 2008: : > > > And with amd64/x86-64, it may prove to not really be necessary. : > > : > > I'm not sure I understand the "may" part. Aren't we already using 64 : > > bit time_t natively on amd64? Or maybe you're talking about 32 bit : > > compat on amd64. : > : > Yes, we are, and as newer server-class machines (at least) are predominantly : > 64-bit, for at least the server-class market it would seem that boxes will : > probably move to an amd64 kernel with a 64-bit time_t w/o requiring lots of : > rototilling to support 64-bit time_t on i386. : : Right. I'm more concerned with planning now for y2038 on 32-bit : embedded boxes that may still be around in 30 years. In this case, I : think it's easy enough for me to just change my local FreeBSD tree to : have time_t be 64 bit and recompile. : : But that doesn't help those users desperately clinging to their : 7.1-RELEASE i386 boxes 30 years from now ;) It won't be on FreeBSD/arm embedded boxes :-) When we changed from 32-bit to 64-bit on arm, it wasn't a huge deal. If you don't care about ABI compatibility, then it is a simple matter of changing the definition of __time_t in sys/i386/include/_types.h and rebuilding. After all, there's no binaries not built as part of the controlled build process that you use in certain embedded boxes that I think you might be talking about ;-0. All that system call and ioctl and structure compat stuff is interesting, but just not relevant to your problem domain... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 18:59:44 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479F81065689 for ; Thu, 25 Sep 2008 18:59:44 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 362968FC15 for ; Thu, 25 Sep 2008 18:59:44 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7R00HD4JB99930@asmtp015.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 10:59:39 -0700 (PDT) Message-id: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> From: Marcel Moolenaar To: FreeBSD Arch Date: Thu, 25 Sep 2008 10:59:31 -0700 X-Mailer: Apple Mail (2.929.2) Cc: Subject: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 18:59:44 -0000 All, I'd like to switch all architectures to gpart for the reasons given below. All current partitioning schemes are supported by gpart and work on all platforms. On top of that, ia64 and powerpc are using gpart exclusively already. Rationale: 1. Having different utilities for different schemes, which are otherwise identical in functionality, is painful. Especially since they all provide a different user interface. While this is a non-issue for the old geezers among us (we don't know any better), it is something that the younger crowd perceives as "low-quality", especially when compared to Linux' parted. However, the fact that some allow scripting while others don't is important even for the old geezers. gpart(8) is the answer. 2. We currently have multiple GEOMs in the kernel that do not provide a unified, common and/or standard interface. This is especially problematic for unified tools like the installer. In fact, we don't have unified tools that use the ctlreq interface at all, because it's virtually impossible. The fact that we have sade, is an indication that we do want a unified tool for partitioning, but without using the GEOM I/F the tool is useless to modify partitions on a disk with mounted file systems. The gpart GEOM provides a unified I/F usable by any tool for creating and modifying any kind of partitioning scheme. 3. fsck and newfs contain some logic to find out what kind of file system they're working on and invoke the appropriate back-end executable. This is good functionality, but only works for BSD labels. With GPT being used more often and non-PC hardware using different partitioning schemes, this means that the functionality isn't working in most cases. There's fundamentally no reason why newfs or fsck cannot automatically detect a partition that uses the MSDOS file system and DTRT. With gpart, we can make that functionality working across all partitioning schemes. 4. Like the above, but for mount. By checking the partition type, it's possible to have mount DTRT much more often. 5. The gpart show command can give you a unified list of disks with their partitions, irrespective of the partitioning scheme used. For the first time a single command gives us the overview we're lacking. 6. Not all "disk" devices have a geometry. Especially md(4) devices and USB mass storage devices. This is a problem for newfs_msdos. With gpart, there's always a geometry that processes can query for so that newfs_msdos et al will work without any additional options. 7. gpart breaks the 8-partition barrier for bsdlabel. 8. gpart adds VTOC information to sunlabel. With gpart default, tools like fdisk and bsdlabel continue to work on new disks and disks that have no mounted file systems. In that respect there's no difference. However, they cannot be used when file systems are mounted. In those cases gpart needs to be used. As such, the impact is limited and makes the switch much more manageable. In short: gpart is the first step towards a unified set of tools and interfaces and provides the basis for extending file system related tools by allowing us to attach real meaning to partition types. With the commit and undo feature, gpart is ready for use by next generation installers that allow us to use any partitioning scheme on any platforms. Thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 19:46:25 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 329CA106568D for ; Thu, 25 Sep 2008 19:46:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CF3BE8FC19 for ; Thu, 25 Sep 2008 19:46:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 1883E170E4; Thu, 25 Sep 2008 19:46:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8PJkH53001897; Thu, 25 Sep 2008 19:46:18 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 25 Sep 2008 10:59:31 MST." <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> Date: Thu, 25 Sep 2008 19:46:17 +0000 Message-ID: <1896.1222371977@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 19:46:25 -0000 In message <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com>, Marcel Moolenaar wri tes: >All, > >I'd like to switch all architectures to gpart for the reasons given >below. I promised long time ago, that I would only use my 'GEOM Architect' hat to interfere with what people do _to_ GEOM, not what people do _with_ GEOM. The GEOM Architect therefore has only this comment: I would like to point out explicitly that Marcels proposal, to switch to gpart by default, does not prevent the use of other GEOM classes to interpret disk-layouts. I know there are users out there who use GEOM for backup and forensic purposes, who have such private geom classes, and these will not be affected by Marcels proposal in any way, except that you may need to grab a copy of geom_slice.* if Marcel obsoletes them. The following comments are my personal comments, and they may or may not be shared by the GEOM Architect, who is free to grind his teeth as he reads them: >Rationale: >1. Having different utilities for different schemes, which are > otherwise identical in functionality, is painful. On the other hand, trying to generalize widely different semantics is also not a recipe for eternal youth: Not all the worlds partitioning metadata formats have type information, some have weird ass restrictions and bootcode(-requirements) are generally magic. I didn't dare do what you've done now, but since you touched it last, I'm not worried :-) My proposed solution was to try to get the BSD label discontinued and rely entirely on the native partitioning on the relevant platforms, but that meant dealing with FAT extended partitions and going back to libdisk and I couldn't get myself to do that. >3. fsck and newfs contain some logic to find out what kind of > file system they're working on and invoke the appropriate > back-end executable. I have always found it scary that they did this based on the out-of-band information. Granted, fsck's generally choke on each others filesystems pretty conclusively, but fsck will happily trash a database stored in partition that previously contained a filesystem, provided enough magic bits survive near the start. I would prefer a scheme where fsck, like g_label, poked around a bit to find out what the partition content looked like, and started the then backend fsck_foofs with a "I *think* this is yours, but it might not be" flag. On the other hand, if fsck_foofs is explicitly started (for instance based on /etc/fstab) it has license to kill. Overall this is a fine point, but I'd hate to make it easier to trash filesystems. Lacking a reliable mechanism to keep the out-of-band filesystem type consistent with the partition content, think dd(1), g_mirror movements of data etc, I'm not too thrilled about this. >4. Like the above, but for mount. By checking the partition > type, it's possible to have mount DTRT much more often. Same argument, same code should be used, probably also for g_label(). >6. Not all "disk" devices have a geometry. Especially md(4) > devices and USB mass storage devices. This is a problem > for newfs_msdos. With gpart, there's always a geometry [...] I will argue this is wrong. For md(4), you an define a geometry if you want one, and if your plan is to move the filesystem to real media later, you had better do so correctly. For usb-sticks, the problem is that we do not even ask them about their geometry, but treat them as SCSI disks that are one-dimensional. In many cases you can infer the geometry from a preexisting MBR, but presently our code does not do this, and as we know from the Dangerously Dedicated Disk Layout, that is a pretty error-prone heuristic in the first place. We know from NanoBSD users that this is not a theoretical issue, I have countless emails where people put NanoBSD on a USB stick but find it unbootable because it presents a different geometry to the BIOS than the one we used. Dreaming up default geometries will just hide from the user that they are about to make a mistake. I don't recommend it. I would be better to fix umass/cam/da (cross out your own code) to get the correct geometry from the usb-sticks. >7. gpart breaks the 8-partition barrier for bsdlabel. We should discontinue the bsdlabel, it has too many problems and limitations. The best way is to not install more of them once sysinstall knows how to avoid it. >With gpart default, tools like fdisk and bsdlabel continue to >work on new disks and disks that have no mounted file systems. >In that respect there's no difference. However, they cannot >be used when file systems are mounted. This is going to break more scripts than you think. I think you should have talked a bit about naming of the partitions ? Are there any compatibility or transition concerns in that area ? Poul-Henning -- 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 Thu Sep 25 19:50:23 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E31106569C for ; Thu, 25 Sep 2008 19:50:23 +0000 (UTC) (envelope-from peter@wemm.org) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9ED8FC36 for ; Thu, 25 Sep 2008 19:50:22 +0000 (UTC) (envelope-from peter@wemm.org) Received: by qb-out-0506.google.com with SMTP id f30so402517qba.35 for ; Thu, 25 Sep 2008 12:50:22 -0700 (PDT) Received: by 10.142.48.3 with SMTP id v3mr90202wfv.8.1222371514503; Thu, 25 Sep 2008 12:38:34 -0700 (PDT) Received: by 10.142.255.21 with HTTP; Thu, 25 Sep 2008 12:38:34 -0700 (PDT) Message-ID: Date: Thu, 25 Sep 2008 12:38:34 -0700 From: "Peter Wemm" To: "Marcel Moolenaar" In-Reply-To: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 19:50:23 -0000 On Thu, Sep 25, 2008 at 10:59 AM, Marcel Moolenaar wrote: > I'd like to switch all architectures to gpart for the reasons given > below. All current partitioning schemes are supported by gpart and > work on all platforms. On top of that, ia64 and powerpc are using > gpart exclusively already. What, if anything, do we need to do to start using it ourselves now on i386 or amd64 platforms? Just change kernel options? Also, while here, the APM (apple partition manager) module doesn't quite work with Tivo disks. Tivo drives don't have the DDR signature. Simply removing the DDR code enables FreeBSD to mount and work with tivo drives. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 19:58:16 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5141C1065687 for ; Thu, 25 Sep 2008 19:58:16 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8208FC1C for ; Thu, 25 Sep 2008 19:58:16 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7R00J6BOSI2Y40@asmtp015.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 12:57:59 -0700 (PDT) Message-id: <69B1B4C5-8E98-4014-9767-A8D5D1919A75@mac.com> From: Marcel Moolenaar To: Peter Wemm In-reply-to: Date: Thu, 25 Sep 2008 12:57:52 -0700 References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 19:58:16 -0000 On Sep 25, 2008, at 12:38 PM, Peter Wemm wrote: > On Thu, Sep 25, 2008 at 10:59 AM, Marcel Moolenaar > wrote: >> I'd like to switch all architectures to gpart for the reasons given >> below. All current partitioning schemes are supported by gpart and >> work on all platforms. On top of that, ia64 and powerpc are using >> gpart exclusively already. > > What, if anything, do we need to do to start using it ourselves now on > i386 or amd64 platforms? Just change kernel options? Yes, that's it. At this time, the following 4 lines can be added to achieve the switch: nooption GEOM_BSD nooption GEOM_MBR options GEOM_PART_BSD options GEOM_PART_MBR > > Also, while here, the APM (apple partition manager) module doesn't > quite work with Tivo disks. Tivo drives don't have the DDR signature. > Simply removing the DDR code enables FreeBSD to mount and work with > tivo drives. Yes, I saw the commit. Do you know if there's anything we can check for in case there's no DDR? I'm thinking of accepting a DDR-less APM scheme only if we find some indication that it's a Tivo disk. I guess I like the comfort of checking the DDR and prefer not to eliminate it unconditionally. This may not be possible though... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 21:24:54 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190FD106568D for ; Thu, 25 Sep 2008 21:24:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 067558FC20 for ; Thu, 25 Sep 2008 21:24:53 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7R00KN7STEOU30@asmtp015.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 14:24:53 -0700 (PDT) Message-id: <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <1896.1222371977@critter.freebsd.dk> Date: Thu, 25 Sep 2008 14:24:49 -0700 References: <1896.1222371977@critter.freebsd.dk> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 21:24:54 -0000 On Sep 25, 2008, at 12:46 PM, Poul-Henning Kamp wrote: > In message <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com>, Marcel > Moolenaar wri > tes: >> All, >> >> I'd like to switch all architectures to gpart for the reasons given >> below. > > I promised long time ago, that I would only use my 'GEOM Architect' > hat to interfere with what people do _to_ GEOM, not what people > do _with_ GEOM. > > The GEOM Architect therefore has only this comment: > > I would like to point out explicitly that Marcels proposal, to > switch to gpart by default, does not prevent the use of other GEOM > classes to interpret disk-layouts. Nod. You can freely mix and match. People are already doing that: GPT is handled by gpart, whereas MBR and BSD are handled by the MBR and BSD slicers. >> Rationale: >> 1. Having different utilities for different schemes, which are >> otherwise identical in functionality, is painful. > > On the other hand, trying to generalize widely different semantics > is also not a recipe for eternal youth: Not all the worlds > partitioning > metadata formats have type information, some have weird ass > restrictions and bootcode(-requirements) are generally magic. I have wondered about the "different semantics" and found that it's the semantics that are actually the same. No matter what the details, they all serve the same purpose: chopping up a disk in multiple (non-overlapping) regions. Granted, supporting all the details of a particular scheme may not be easy or even possible. But when we only look at the aspects that affect FreeBSD, the details end up not being that important in the end. > I didn't dare do what you've done now, but since you touched it > last, I'm not worried :-) :-) > My proposed solution was to try to get the BSD label discontinued > and rely entirely on the native partitioning on the relevant > platforms, but that meant dealing with FAT extended partitions and > going back to libdisk and I couldn't get myself to do that. Trying to use the native scheme is generally good. But I do expect that FreeBSD on platform X knows or recognizes a disk created on or used by FreeBSD on platform Y. > Granted, fsck's generally choke on each others filesystems > pretty conclusively, but fsck will happily trash a database > stored in partition that previously contained a filesystem, > provided enough magic bits survive near the start. That's why I believe we need to attach real meaning to the partition type. We should disallow a newfs_ufs on a partition that is not of type freebsd-ufs. We should disallow swapon for a partition that is not of type freebsd-swap. etc.. With gpart it's trivial to change the partition type, so it's no hassle. The protection and support this gives users certainly outweighs the hassle IMO. > Overall this is a fine point, but I'd hate to make it easier to > trash filesystems. I agree. Enforcing that partition types match the content (within reason) is a good start. Already gpart checks the partition type for the dumpon command and fails when it's an obvious mismatch. > Lacking a reliable mechanism to keep the out-of-band filesystem > type consistent with the partition content, think dd(1), g_mirror > movements of data etc, I'm not too thrilled about this. Keeping consistency can only be the responsibility of the user/admin. We give them too much power to do it for them. All we can do is enforce and/or promote consistency by taking the partition type seriously. >> 6. Not all "disk" devices have a geometry. Especially md(4) >> devices and USB mass storage devices. This is a problem >> for newfs_msdos. With gpart, there's always a geometry [...] > > I will argue this is wrong. It's not wrong. It's a consequence. As long as there are partitioning schemes and file systems that use sectors, track and/or cyclinders we need to provide it. Even under GPT do we need a geometry simply because the EFI file system is the MSDOS file system. True, GPT itself doesn't need it, but that's not the point. > For md(4), you an define a geometry if you want one, and if > your plan is to move the filesystem to real media later, > you had better do so correctly. True. Geometries create problems. > In many cases you can infer the geometry from a preexisting MBR, > but presently our code does not do this, and as we know from the > Dangerously Dedicated Disk Layout, that is a pretty error-prone > heuristic in the first place. gpart does take this into account. When the underlying provider has no geometry, gpart synthesizes one. This geometry is "soft" in the sense that it can later be adjusted to match what partitioning schemes say it is (or should be). In either case, there can be a real mismatch. If that happens gpart will let you know and it can even reject the partitioning scheme. Again, this is based on the philosophy that there's meaning. Recording a geometry without there being a meaning is pointless. > Dreaming up default geometries will just hide from the user that > they are about to make a mistake. It's not the user that can make a mistake in this case. They're merely burdened by the inconsistencies due to sloppiness and/or bad design. > I would be better to fix umass/cam/da (cross out your own code) > to get the correct geometry from the usb-sticks. I totally agree. >> 7. gpart breaks the 8-partition barrier for bsdlabel. > > We should discontinue the bsdlabel, it has too many problems > and limitations. I agree, but compatibility is not bad and NetBSD does support more than 8 partitions. >> With gpart default, tools like fdisk and bsdlabel continue to >> work on new disks and disks that have no mounted file systems. >> In that respect there's no difference. However, they cannot >> be used when file systems are mounted. > > This is going to break more scripts than you think. Likely. > I think you should have talked a bit about naming of the > partitions ? Good point. With gpart, partition types are abstracted so that the user and tools are presented with a fixed alias and not with whatever identification scheme is used for a particular partitioning scheme. For example the MBR type 165 is presented by gpart as type "freebsd". When the underlying scheme is GPT, the on-disk identification is the following UUID: 516e7cb4-6ecf-11d6-8ff8-00022d09712b Of course, gpart doesn't have aliases for all possible partition types. Just the ones that we care about in FreeBSD. For a UFS partition, the gpart type is "freebsd-ufs". For a swap partition it is "freebsd-swap". On my server (FreeBSD 7.x) "gpart show" gives: ns1% gpart show => 63 80293185 ad0 MBR (41.1GB) 63 80292807 1 freebsd [active] (41.1GB) 80292870 378 - free - (193.5KB) => 0 80292807 ad0s1 BSD (41.1GB) 0 2097152 1 freebsd-ufs (1073.7MB) 2097152 16777216 2 freebsd-swap (8.6GB) 18874368 16777216 4 freebsd-ufs (8.6GB) 35651584 44641223 5 freebsd-ufs (22.9GB) => 34 976773101 ad1 GPT (500.1GB) 34 97656250 1 freebsd-ufs (50.0GB) 97656284 879116851 2 freebsd-zfs (450.1GB) => 34 976773101 ad2 GPT (500.1GB) 34 97656250 1 freebsd-ufs (50.0GB) 97656284 879116851 2 freebsd-zfs (450.1GB) => 34 1953525101 ad3 GPT (1000.2GB) 34 1953525101 1 freebsd-zfs (1000.2GB) => 34 976773101 ad4 GPT (500.1GB) 34 976773101 1 freebsd-zfs (500.1GB) => 34 976773101 ad5 GPT (500.1GB) 34 976773101 1 freebsd-zfs (500.1GB) The actual partitioning scheme, while shown, has been made irrelevant. A UFS or ZFS partition has the same abstract type no matter how the disk is partitioning. Currently gpart has aliases the following aliases: efi freebsd freebsd-boot freebsd-swap freebsd-ufs freebsd-vinum freebsd-zfs mbr Partition types for which we don't have aliases are shown in their raw (i.e. partitioning scheme specific) repesentation (numbers, UUIDs or labels). > Are there any compatibility or transition concerns in that area ? These are the problem areas I can think of: o My amd64 had a broken/invalid BSD label and was rejected by gpart. It had to be fixed-up first. I expect that this may be more common than we'd like it to be. Thus: previously accepted BSD labels may not be accepted by gpart due to better checking. o The partition given to the dumpon command needs to be of the right type. When switching to gpart on sparc64, the dumpon command failed because there are no partition types in the current sunlabel support. Assigning the proper partition types on sparc64 after the switch to gpart did the trick. This also applies to PowerPC... o I do not have a pc98 machine. I've been testing on a memory disk and validated inter-operability, but I don't have FreeBSD booting a running on pc98. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 21:45:15 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85DC91065746 for ; Thu, 25 Sep 2008 21:45:15 +0000 (UTC) (envelope-from peter@wemm.org) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.242]) by mx1.freebsd.org (Postfix) with ESMTP id 45E0B8FC12 for ; Thu, 25 Sep 2008 21:45:15 +0000 (UTC) (envelope-from peter@wemm.org) Received: by ag-out-0708.google.com with SMTP id 8so565971agc.3 for ; Thu, 25 Sep 2008 14:45:14 -0700 (PDT) Received: by 10.100.112.6 with SMTP id k6mr396303anc.71.1222379113839; Thu, 25 Sep 2008 14:45:13 -0700 (PDT) Received: by 10.100.154.11 with HTTP; Thu, 25 Sep 2008 14:45:13 -0700 (PDT) Message-ID: Date: Thu, 25 Sep 2008 14:45:13 -0700 From: "Peter Wemm" To: "Marcel Moolenaar" In-Reply-To: <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1896.1222371977@critter.freebsd.dk> <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> Cc: FreeBSD Arch , Poul-Henning Kamp Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 21:45:15 -0000 On Thu, Sep 25, 2008 at 2:24 PM, Marcel Moolenaar wrote: > On Sep 25, 2008, at 12:46 PM, Poul-Henning Kamp wrote: [..] >> pretty conclusively, but fsck will happily trash a database >> stored in partition that previously contained a filesystem, >> provided enough magic bits survive near the start. > > That's why I believe we need to attach real meaning > to the partition type. We should disallow a newfs_ufs > on a partition that is not of type freebsd-ufs. We > should disallow swapon for a partition that is not > of type freebsd-swap. etc.. > > With gpart it's trivial to change the partition type, > so it's no hassle. The protection and support this > gives users certainly outweighs the hassle IMO. Don't forget that we currently support creating file systems on raw disk devices. eg: /dev/ad1. You are currently allowed to swapon /dev/ad2. There are a lot of those out there, you can't break it because people know where you work and will come find you. :) This however, is a different issue to switching GEOM_BSD + GEOM_MBR to GEOM_PART_BSD + GEOM_PART_MBR. (I think the partition type thing could be solved by specifying the heuristic as "if the partition *has a type* and its not ufs, then disallow ufs" etc. Don't forget to include --shoot-foot=allowed override mode.) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 21:57:13 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D384106568E for ; Thu, 25 Sep 2008 21:57:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F2C728FC0A for ; Thu, 25 Sep 2008 21:57:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B8D76170E4; Thu, 25 Sep 2008 21:57:10 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8PLv8JD011709; Thu, 25 Sep 2008 21:57:09 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 25 Sep 2008 14:24:49 MST." <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> Date: Thu, 25 Sep 2008 21:57:08 +0000 Message-ID: <11708.1222379828@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 21:57:13 -0000 In message <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com>, Marcel Moolenaar wri tes: >Granted, supporting all the details of a particular >scheme may not be easy or even possible. That's my worry about the unified UI, I keep thinking of the old usenet joke about the HP Cafeteria. >Trying to use the native scheme is generally good. >But I do expect that FreeBSD on platform X knows >or recognizes a disk created on or used by FreeBSD >on platform Y. Until we have an endianes aware UFS that's only half the solution however :-/ >That's why I believe we need to attach real meaning >to the partition type. We should disallow a newfs_ufs >on a partition that is not of type freebsd-ufs. [...] Ouch. That is a level of policy that I would not want to enforce on users. This should probably be pointed out for arch@'s careful consideration: we are potentially talking about quite a lot of "it used to work, now it complains" email. >> Overall this is a fine point, but I'd hate to make it easier to >> trash filesystems. > >I agree. Enforcing that partition types match the >content (within reason) is a good start. I don't see it that way, I see it as increasing the risk when people move partitions around with g_mirror or dd. >Keeping consistency can only be the responsibility >of the user/admin. So we ask the users to keep it consistent so it can protect the users by being consistent ? I'm not quite sure I see the benefit, but I see lots of trouble: Does that mean I can't newfs /dev/da1 without partitioning ? What about DVD/ISO images which don't have parititioning, with the exception of Sparc boot-media ? In my view, enforcing out of band labels on partitions amounts to nothing but pointlessly putting signs with "coffee-machine" and "stupid ISO9000 signage guy" on stuff. It might make people thing twice, but likely only about what the point is supposed to be and why it has to be so difficult. I would strongly advice going for an inband scheme instead, we have that in g_label already. >>> 6. Not all "disk" devices have a geometry. Especially md(4) >>> devices and USB mass storage devices. This is a problem >>> for newfs_msdos. With gpart, there's always a geometry [...] >> >> I will argue this is wrong. > >It's not wrong. It's a consequence. As long as there are >partitioning schemes and file systems that use sectors, >track and/or cyclinders we need to provide it. It's not a matter of providing or not, it's a matter of constructing or not. md(4) has no geometry, and you don't know what the user is going to use the filesystem for. If you construct a synthetic default geometry, the user is not made aware that he needs to *think* about the correct geometry. >> I would be better to fix umass/cam/da (cross out your own code) >> to get the correct geometry from the usb-sticks. > >I totally agree. Then don't provide a hack to hide the hurt, let the hurt hit where it belongs. >> This is going to break more scripts than you think. > >Likely. I do find your attitude to compatibility refreshing, but will take care to be at a safe distance when the consequence strikes :-) >> I think you should have talked a bit about naming of the >> partitions ? > >Good point. >On my server (FreeBSD 7.x) "gpart show" gives: > >ns1% gpart show >=> 63 80293185 ad0 MBR (41.1GB) > 63 80292807 1 freebsd [active] (41.1GB) > 80292870 378 - free - (193.5KB) > >=> 0 80292807 ad0s1 BSD (41.1GB) > 0 2097152 1 freebsd-ufs (1073.7MB) > 2097152 16777216 2 freebsd-swap (8.6GB) > 18874368 16777216 4 freebsd-ufs (8.6GB) > 35651584 44641223 5 freebsd-ufs (22.9GB) My question was really if these partitions have the same name in /dev/ as today, ad0s1[a-d] presumably ? (I would suggest gpart always show the /dev names) Poul-Henning -- 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 Thu Sep 25 23:49:35 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09FA21065692 for ; Thu, 25 Sep 2008 23:49:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id EB42B8FC0C for ; Thu, 25 Sep 2008 23:49:34 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7R00GT2ZHK9F00@asmtp014.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 16:48:57 -0700 (PDT) Message-id: <37A80348-515C-48F4-8F88-A77679BEEA15@mac.com> From: Marcel Moolenaar To: Peter Wemm In-reply-to: Date: Thu, 25 Sep 2008 16:48:55 -0700 References: <1896.1222371977@critter.freebsd.dk> <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch , Poul-Henning Kamp Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 23:49:35 -0000 On Sep 25, 2008, at 2:45 PM, Peter Wemm wrote: > On Thu, Sep 25, 2008 at 2:24 PM, Marcel Moolenaar > wrote: >> On Sep 25, 2008, at 12:46 PM, Poul-Henning Kamp wrote: > [..] >>> pretty conclusively, but fsck will happily trash a database >>> stored in partition that previously contained a filesystem, >>> provided enough magic bits survive near the start. >> >> That's why I believe we need to attach real meaning >> to the partition type. We should disallow a newfs_ufs >> on a partition that is not of type freebsd-ufs. We >> should disallow swapon for a partition that is not >> of type freebsd-swap. etc.. >> >> With gpart it's trivial to change the partition type, >> so it's no hassle. The protection and support this >> gives users certainly outweighs the hassle IMO. > > Don't forget that we currently support creating file systems on raw > disk devices. eg: /dev/ad1. You are currently allowed to swapon > /dev/ad2. There are a lot of those out there, you can't break it > because people know where you work and will come find you. :) When there's no partitioning scheme on the disk, gpart will not be involved and the checks won't happen. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 00:26:57 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 851AB1065691 for ; Fri, 26 Sep 2008 00:26:57 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 736348FC19 for ; Fri, 26 Sep 2008 00:26:57 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7S00BDS18VHT10@asmtp020.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 17:26:57 -0700 (PDT) Message-id: <834AD44B-2372-41D2-A952-85095569BB48@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <11708.1222379828@critter.freebsd.dk> Date: Thu, 25 Sep 2008 17:26:54 -0700 References: <11708.1222379828@critter.freebsd.dk> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 00:26:57 -0000 On Sep 25, 2008, at 2:57 PM, Poul-Henning Kamp wrote: >> >> Trying to use the native scheme is generally good. >> But I do expect that FreeBSD on platform X knows >> or recognizes a disk created on or used by FreeBSD >> on platform Y. > > Until we have an endianes aware UFS that's only > half the solution however :-/ File system bugs are outside the scope of gpart. It's already a much better situation if we can see the partitions on a "foreign" disk, even if we can't interpret the data in it. >>> Overall this is a fine point, but I'd hate to make it easier to >>> trash filesystems. >> >> I agree. Enforcing that partition types match the >> content (within reason) is a good start. > > I don't see it that way, I see it as increasing the risk > when people move partitions around with g_mirror or dd. There's no risk that wasn't there already. In fact, certain things won't work, which means risk is reduced. >> Keeping consistency can only be the responsibility >> of the user/admin. > > So we ask the users to keep it consistent so it can > protect the users by being consistent ? No, we don't ask the user anything. We just reward the user with certain benefits when he/she is keeping things real. Changing the partition type to match the content is for the benefit of the admin as well. It's a win-win. > I'm not quite sure I see the benefit, but I see lots of trouble: > > Does that mean I can't newfs /dev/da1 without partitioning ? When there's no partitioning scheme, then gpart is not involved and we can obvouisly not check partition types. > What about DVD/ISO images which don't have parititioning, > with the exception of Sparc boot-media ? See above. > In my view, enforcing out of band labels on partitions amounts to > nothing but pointlessly putting signs with "coffee-machine" and > "stupid ISO9000 signage guy" on stuff. While I find some of the labels redundant, it would be a mistake to think that there isn't someone out there who depends on them. > I would strongly advice going for an inband scheme instead, > we have that in g_label already. It would be nice if g_label would use the labels that people put in the partition table for entries. > If you construct a synthetic default geometry, the user is not made > aware that he needs to *think* about the correct geometry. We obviously have 2 viewpoints here: On forces the user to worry about geometry, even if there's no need for it. The other avoids the user from having to think about geometry, even if the user should. I'd rather treat our users as knowledgeable and not as being stupid. I prefer to assume that the user knows when to worry about geometry so that we can make it easy in case it doesn't matter. It's all about the ability to specify a geometry when you create the partitioning scheme. This can not be done with gpart at this time, though. >>> This is going to break more scripts than you think. >> >> Likely. > > I do find your attitude to compatibility refreshing, but will take > care to be at a safe distance when the consequence strikes :-) There's limited compatibility in replacing arcane tools each with their own UI with a unified tool that's based on a totally different paradigm. Striving for tool-compatibility would not be successful by definition. It's much easier to rewrite bsdlabel and fdisk to use the gpart ctlreq I/F directly... >> On my server (FreeBSD 7.x) "gpart show" gives: >> >> ns1% gpart show >> => 63 80293185 ad0 MBR (41.1GB) >> 63 80292807 1 freebsd [active] (41.1GB) >> 80292870 378 - free - (193.5KB) >> >> => 0 80292807 ad0s1 BSD (41.1GB) >> 0 2097152 1 freebsd-ufs (1073.7MB) >> 2097152 16777216 2 freebsd-swap (8.6GB) >> 18874368 16777216 4 freebsd-ufs (8.6GB) >> 35651584 44641223 5 freebsd-ufs (22.9GB) > > My question was really if these partitions have > the same name in /dev/ as today, ad0s1[a-d] presumably ? Yes. The device naming has not changed. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 06:34:25 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06C1A1065686 for ; Fri, 26 Sep 2008 06:34:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BFB498FC1E for ; Fri, 26 Sep 2008 06:34:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 49436170E5; Fri, 26 Sep 2008 06:34:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m8Q6YMHI001589; Fri, 26 Sep 2008 06:34:22 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 25 Sep 2008 17:26:54 MST." <834AD44B-2372-41D2-A952-85095569BB48@mac.com> Date: Fri, 26 Sep 2008 06:34:22 +0000 Message-ID: <1588.1222410862@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 06:34:25 -0000 In message <834AD44B-2372-41D2-A952-85095569BB48@mac.com>, Marcel Moolenaar wri tes: >On Sep 25, 2008, at 2:57 PM, Poul-Henning Kamp wrote: >It's already a much better situation if we can >see the partitions on a "foreign" disk, even if >we can't interpret the data in it. Now, don't get too carried away with your creation, we have been able to do that since day 1 with GEOM :-) -- 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 Sep 26 07:58:01 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BEBF10656A0 for ; Fri, 26 Sep 2008 07:58:01 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (pittgoth.com [205.134.163.206]) by mx1.freebsd.org (Postfix) with ESMTP id EC2AE8FC13 for ; Fri, 26 Sep 2008 07:58:00 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (net-ix.gw.ai.net [205.134.160.6]) (authenticated bits=0) by pittgoth.com (8.14.2/8.14.2) with ESMTP id m8Q7Vlf1078665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Sep 2008 03:31:47 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 26 Sep 2008 03:31:26 -0400 From: Tom Rhodes To: "Poul-Henning Kamp" Message-Id: <20080926033126.7fdfa739.trhodes@FreeBSD.org> In-Reply-To: <1588.1222410862@critter.freebsd.dk> References: <834AD44B-2372-41D2-A952-85095569BB48@mac.com> <1588.1222410862@critter.freebsd.dk> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, xcllnt@mac.com Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 07:58:01 -0000 On Fri, 26 Sep 2008 06:34:22 +0000 "Poul-Henning Kamp" wrote: > In message <834AD44B-2372-41D2-A952-85095569BB48@mac.com>, Marcel Moolenaar wri > tes: > >On Sep 25, 2008, at 2:57 PM, Poul-Henning Kamp wrote: > > >It's already a much better situation if we can > >see the partitions on a "foreign" disk, even if > >we can't interpret the data in it. > > Now, don't get too carried away with your creation, we have been > able to do that since day 1 with GEOM :-) Killjoy. :P -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 11:13:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE7A1065686 for ; Fri, 26 Sep 2008 11:13:10 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B7E5D8FC37 for ; Fri, 26 Sep 2008 11:13:09 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KjBFv-00006I-V6 for freebsd-arch@freebsd.org; Fri, 26 Sep 2008 11:13:03 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Sep 2008 11:13:03 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Sep 2008 11:13:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Fri, 26 Sep 2008 13:12:58 +0200 Lines: 36 Message-ID: References: <1896.1222371977@critter.freebsd.dk> <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> <37A80348-515C-48F4-8F88-A77679BEEA15@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E25C1E109F5A7FD32BE1CA5" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <37A80348-515C-48F4-8F88-A77679BEEA15@mac.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 11:13:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E25C1E109F5A7FD32BE1CA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marcel Moolenaar wrote: >> Don't forget that we currently support creating file systems on raw >> disk devices. eg: /dev/ad1. You are currently allowed to swapon >> /dev/ad2. There are a lot of those out there, you can't break it >> because people know where you work and will come find you. :) >=20 > When there's no partitioning scheme on the disk, > gpart will not be involved and the checks won't > happen. Will there be "generic" parition types by default? (i.e. the "don't care what's on it, let me do my newfs" type) --------------enig5E25C1E109F5A7FD32BE1CA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3MO6ldnAQVacBcgRAiSZAKDjO3IsREf87MuUb90osejnRIImzwCgjsuY twaD+ND03YeKO/wdvAW4WDg= =s5dB -----END PGP SIGNATURE----- --------------enig5E25C1E109F5A7FD32BE1CA5-- From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 15:26:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DE341065693; Fri, 26 Sep 2008 15:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id 77A198FC0A; Fri, 26 Sep 2008 15:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.95] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7T0031F42ZW860@asmtp022.mac.com>; Fri, 26 Sep 2008 07:25:48 -0700 (PDT) Message-id: <3B2BD6FE-85D4-49F8-81A0-B2AB048ACFE8@mac.com> From: Marcel Moolenaar To: Ivan Voras In-reply-to: Date: Fri, 26 Sep 2008 07:25:47 -0700 References: <1896.1222371977@critter.freebsd.dk> <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> <37A80348-515C-48F4-8F88-A77679BEEA15@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: freebsd-arch@freebsd.org Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 15:26:10 -0000 On Sep 26, 2008, at 4:12 AM, Ivan Voras wrote: > Marcel Moolenaar wrote: > >>> Don't forget that we currently support creating file systems on raw >>> disk devices. eg: /dev/ad1. You are currently allowed to swapon >>> /dev/ad2. There are a lot of those out there, you can't break it >>> because people know where you work and will come find you. :) >> >> When there's no partitioning scheme on the disk, >> gpart will not be involved and the checks won't >> happen. > > Will there be "generic" parition types by default? (i.e. the "don't > care > what's on it, let me do my newfs" type) There's currently no such partition type and you don't need it to do a newfs. You can always do a newfs, irrespective of partition type. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 22:07:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C7B106569A for ; Fri, 26 Sep 2008 22:07:45 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECD58FC14 for ; Fri, 26 Sep 2008 22:07:44 +0000 (UTC) (envelope-from talon@lpthe.jussieu.fr) Received: from parthe.lpthe.jussieu.fr (parthe.lpthe.jussieu.fr [134.157.10.1]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id m8QLvZRV006795 for ; Fri, 26 Sep 2008 23:57:35 +0200 (CEST) X-Ids: 166 Received: from niobe.lpthe.jussieu.fr (niobe.lpthe.jussieu.fr [134.157.10.41]) by parthe.lpthe.jussieu.fr (Postfix) with ESMTP id 3547389CEE for ; Fri, 26 Sep 2008 23:57:34 +0200 (CEST) Received: by niobe.lpthe.jussieu.fr (Postfix, from userid 2005) id 23D7010B; Fri, 26 Sep 2008 23:57:34 +0200 (CEST) Date: Fri, 26 Sep 2008 23:57:34 +0200 From: Michel Talon To: arch@freebsd.org Message-ID: <20080926215734.GA48113@lpthe.jussieu.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (shiva.jussieu.fr [134.157.0.166]); Fri, 26 Sep 2008 23:57:35 +0200 (CEST) X-Virus-Scanned: ClamAV 0.93.3/8344/Fri Sep 26 17:34:14 2008 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 48DD5ACF.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 48DD5ACF.002/134.157.10.1/parthe.lpthe.jussieu.fr/parthe.lpthe.jussieu.fr/ X-j-chkmail-Score: MSGID : 48DD5ACF.002 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.014 -> S=0.014 X-j-chkmail-Status: Ham Cc: Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2008 22:07:45 -0000 Marcel Moolenaar wrote: > That's why I believe we need to attach real meaning > to the partition type. We should disallow a newfs_ufs > on a partition that is not of type freebsd-ufs. We > should disallow swapon for a partition that is not > of type freebsd-swap. etc.. However at present it is very convenient that one can share the swap partitions with Linux on a dual boot machine (at the price of running mkswap in the Linux boot scripts). I don't clearly see the benefit coming from enforcing the partition type. After all you should be able to do whatever you like with a chunk of your hard disk, for example cyclic buffers for inn, database space for databases working on raw disk, etc. space for ZFS which doesn't care about partition type (i have a ZFS partition which is marked of type Linux fs) and obviously swap. -- Michel TALON From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 02:04:44 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FEB1065689 for ; Sat, 27 Sep 2008 02:04:44 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 63F178FC16 for ; Sat, 27 Sep 2008 02:04:44 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.95] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7U00HH80FV7180@asmtp019.mac.com> for arch@freebsd.org; Fri, 26 Sep 2008 19:04:44 -0700 (PDT) Message-id: <1B08091F-5807-43C0-AAD5-A693D207BF5E@mac.com> From: Marcel Moolenaar To: Michel Talon In-reply-to: <20080926215734.GA48113@lpthe.jussieu.fr> Date: Fri, 26 Sep 2008 19:04:42 -0700 References: <20080926215734.GA48113@lpthe.jussieu.fr> X-Mailer: Apple Mail (2.929.2) Cc: arch@freebsd.org Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 02:04:44 -0000 On Sep 26, 2008, at 2:57 PM, Michel Talon wrote: > Marcel Moolenaar wrote: >> That's why I believe we need to attach real meaning >> to the partition type. We should disallow a newfs_ufs >> on a partition that is not of type freebsd-ufs. We >> should disallow swapon for a partition that is not >> of type freebsd-swap. etc.. > > However at present it is very convenient that one can share the swap > partitions with Linux on a dual boot machine (at the price of running > mkswap in the Linux boot scripts). This is already implemented. > After all you should be able > to do whatever you like with a chunk of your hard disk, for example > cyclic buffers for inn, database space for databases working on > raw disk, etc. space for ZFS which doesn't care about partition type > (i have a ZFS partition which is marked of type Linux fs) and > obviously > swap. You can still do whatever you want with a partition. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sat Sep 27 13:08:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 974CD106568C for ; Sat, 27 Sep 2008 13:08:45 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE218FC14 for ; Sat, 27 Sep 2008 13:08:45 +0000 (UTC) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) by watery.cc.kogakuin.ac.jp (unknown) with ESMTP id m8RCUstG030338; Sat, 27 Sep 2008 21:30:54 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Sat, 27 Sep 2008 21:30:40 +0900 (JST) Message-Id: <20080927.213040.27797529.nyan@jp.FreeBSD.org> To: xcllnt@mac.com From: Takahashi Yoshihiro In-Reply-To: <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> References: <1896.1222371977@critter.freebsd.dk> <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> X-Mailer: Mew version 6.1 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, phk@phk.freebsd.dk Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 13:08:45 -0000 In article <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> Marcel Moolenaar writes: > o I do not have a pc98 machine. I've been testing on > a memory disk and validated inter-operability, but > I don't have FreeBSD booting a running on pc98. I tested gpart on pc98 and found some problems. 1. A disklabel checking in g_part_bsd_read() is failed. 2. g_part_pc98_dumpconf() does not print a slice name. 3. g_part_pc98_probe() is too strict. 4. It's failed to recognize a big SCSI disk as BSD slice. 5. A (bit strange) FAT slice is recoginized as BSD slice. (6. Do we need more work for libdisk?) I fixed 1, 2 and 3. The patch is: http://home.jp.freebsd.org/~nyan/geom/g_part_pc98.diff My environment is: http://home.jp.freebsd.org/~nyan/geom/dmesg.txt http://home.jp.freebsd.org/~nyan/geom/geom_pc98.txt http://home.jp.freebsd.org/~nyan/geom/g_part_pc98.txt --- TAKAHASHI Yoshihiro