From owner-freebsd-arch@FreeBSD.ORG Sun Jul 9 19:12:19 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7510E16A4DA for ; Sun, 9 Jul 2006 19:12:19 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2050743D45 for ; Sun, 9 Jul 2006 19:12:18 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k69JCHYZ082260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Jul 2006 12:12:18 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B15511.206@errno.com> Date: Sun, 09 Jul 2006 12:12:17 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: vlans and cloning 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, 09 Jul 2006 19:12:19 -0000 I committed the revised netif cloning api so you can now specify parameters when cloning. I also modified the vlan code to use this mechanism so doing something like: ifconfig vlan create vlan 1 vlandev em0 causes a single request to clone a vlan together with the tag+parent device parameters (i.e. and no subsequent SIOCSETVLAN request). Given the above do we still need to support setting vlan tag+device separately or can we just require everything be specified when doing the clone operation? This would change the user api but otherwise I can see no reason for continuing to support the old mechanism where you do: ifconfig vlan create ifconfig vlan0 vlan 1 vlandev em0 Anyone _against_ nuking the above? Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 07:45:09 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFE7816A550 for ; Mon, 10 Jul 2006 07:45:09 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 592F543E1C for ; Mon, 10 Jul 2006 07:44:30 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6A7i5VA090306; Mon, 10 Jul 2006 10:44:05 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 10 Jul 2006 10:44:05 +0300 (EEST) From: Dmitry Pryanishnikov To: Sam Leffler In-Reply-To: <44B15511.206@errno.com> Message-ID: <20060710103404.I25526@atlantis.atlantis.dp.ua> References: <44B15511.206@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 07:45:10 -0000 Hello! On Sun, 9 Jul 2006, Sam Leffler wrote: > clone operation? This would change the user api but otherwise I can see > no reason for continuing to support the old mechanism where you do: > > ifconfig vlan create > ifconfig vlan0 vlan 1 vlandev em0 > > Anyone _against_ nuking the above? Do you mean that you're going to nuke ifconfig vlan create but not ifconfig vlan0 create ? As I understand the flow of /etc/rc processing, support of the ifconfig vlan0 create ifconfig vlan0 vlan 1 vlandev em0 sequence is required for now. Also, I thing it's perfectly correct to have cloned_interfaces="vlan30" while NOT having 'ifconfig_vlan30' assignment - system administrator could just reserve a spare interface w/o assigning it's parameters. So I think that possibility of the specific device cloning w/o arguments, e.g., ifconfig vlan30 create should be preserved. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 08:52:30 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E3C716A4DD for ; Mon, 10 Jul 2006 08:52:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B37EE43D45 for ; Mon, 10 Jul 2006 08:52:29 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 11116 invoked from network); 10 Jul 2006 08:48:20 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Jul 2006 08:48:20 -0000 Message-ID: <44B21551.5050002@freebsd.org> Date: Mon, 10 Jul 2006 10:52:33 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Sam Leffler References: <44B15511.206@errno.com> In-Reply-To: <44B15511.206@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 08:52:30 -0000 Sam Leffler wrote: > I committed the revised netif cloning api so you can now specify > parameters when cloning. I also modified the vlan code to use this > mechanism so doing something like: > > ifconfig vlan create vlan 1 vlandev em0 > > causes a single request to clone a vlan together with the tag+parent > device parameters (i.e. and no subsequent SIOCSETVLAN request). > > Given the above do we still need to support setting vlan tag+device > separately or can we just require everything be specified when doing the > clone operation? This would change the user api but otherwise I can see > no reason for continuing to support the old mechanism where you do: > > ifconfig vlan create > ifconfig vlan0 vlan 1 vlandev em0 /me wants to do: "ifconfig em0.1 inet 192.168.2.2/24" Even simpler. And yes, this works already but only if if_vlan.ko was loaded before or compiled into the kernel. It doesn't do auto- load. -- Andre From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 09:02:18 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D14216A4DA for ; Mon, 10 Jul 2006 09:02:18 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D60443D46 for ; Mon, 10 Jul 2006 09:02:17 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.3) with ESMTP id k6A92Abx035638; Mon, 10 Jul 2006 13:02:10 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 10 Jul 2006 13:02:09 +0400 (MSD) From: Maxim Konovalov To: Sam Leffler In-Reply-To: <44B15511.206@errno.com> Message-ID: <20060710125919.D35569@mp2.macomnet.net> References: <44B15511.206@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 09:02:18 -0000 [...] > This would change the user api but otherwise I can see no reason for > continuing to support the old mechanism where you do: > > ifconfig vlan create > ifconfig vlan0 vlan 1 vlandev em0 > > Anyone _against_ nuking the above? As you said it will break POLA and a number of scripts outside our tree. If it doesn't cost much for us I wouldn't killed "ifconfig vlan create". -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 14:35:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 406E216A4DA; Mon, 10 Jul 2006 14:35:23 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA12243D45; Mon, 10 Jul 2006 14:35:22 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6AEZ8dY061078; Mon, 10 Jul 2006 10:35:17 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 10 Jul 2006 09:52:46 -0400 User-Agent: KMail/1.9.1 References: <20060708152801.GA3671@crodrigues.org> <44B00011.9050902@samsco.org> <20060708215321.GJ16201@garage.freebsd.pl> In-Reply-To: <20060708215321.GJ16201@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607100952.47158.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 10 Jul 2006 10:35:17 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1590/Mon Jul 10 01:34:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-104.4 required=4.2 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Craig Rodrigues , Scott Long , freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 14:35:23 -0000 On Saturday 08 July 2006 17:53, Pawel Jakub Dawidek wrote: > One thing I don't like about this idea, is that simple mount(8) command > will load all file system kernel modules if we give for example device > with no file system on it. No it won't. The patch instructs the kernel to try all of the currently loaded filesystems. It doesn't try to load any filesystem modules. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 15:24:54 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B913316A4E2 for ; Mon, 10 Jul 2006 15:24:54 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD53943D68 for ; Mon, 10 Jul 2006 15:24:49 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6AFOgXW087349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 08:24:43 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B2713A.2020204@errno.com> Date: Mon, 10 Jul 2006 08:24:42 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> In-Reply-To: <20060710103404.I25526@atlantis.atlantis.dp.ua> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 15:24:54 -0000 Dmitry Pryanishnikov wrote: > > Hello! > > On Sun, 9 Jul 2006, Sam Leffler wrote: >> clone operation? This would change the user api but otherwise I can see >> no reason for continuing to support the old mechanism where you do: >> >> ifconfig vlan create >> ifconfig vlan0 vlan 1 vlandev em0 >> >> Anyone _against_ nuking the above? > > Do you mean that you're going to nuke > > ifconfig vlan create > > but not > > ifconfig vlan0 create No, you can still specify the name of the cloned device. > > ? As I understand the flow of /etc/rc processing, support of the > > ifconfig vlan0 create > ifconfig vlan0 vlan 1 vlandev em0 > > sequence is required for now. Also, I thing it's perfectly correct to have > > cloned_interfaces="vlan30" > > while NOT having 'ifconfig_vlan30' assignment - system administrator > could just reserve a spare interface w/o assigning it's parameters. So I > think > that possibility of the specific device cloning w/o arguments, e.g., > > ifconfig vlan30 create > > should be preserved. Clearly one would need to fix rc scripts. The question is should the old behaviour be preserved; it provides no functionality--i.e. a cloned device is unusable until you set the tag+parent and you cannot set the tag or parent on an existing cloned device (once setup). So the only benefit to the ability to create a usable vlan device in 2 steps is to preserve existing practice. Removing the 2 step procedure would allow code to be removed and (IMO) clarify how a vlan is crafted. In the future there will be cloned devices that cannot/will-not be specified with a 2-step procedure so having vlans work this way will violate POLA. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 15:25:30 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0738D16A4DE; Mon, 10 Jul 2006 15:25:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB97343D5F; Mon, 10 Jul 2006 15:25:28 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6AFPRo7087365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 08:25:28 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B27167.8090406@errno.com> Date: Mon, 10 Jul 2006 08:25:27 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Andre Oppermann References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> In-Reply-To: <44B21551.5050002@freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 15:25:30 -0000 Andre Oppermann wrote: > Sam Leffler wrote: >> I committed the revised netif cloning api so you can now specify >> parameters when cloning. I also modified the vlan code to use this >> mechanism so doing something like: >> >> ifconfig vlan create vlan 1 vlandev em0 >> >> causes a single request to clone a vlan together with the tag+parent >> device parameters (i.e. and no subsequent SIOCSETVLAN request). >> >> Given the above do we still need to support setting vlan tag+device >> separately or can we just require everything be specified when doing the >> clone operation? This would change the user api but otherwise I can see >> no reason for continuing to support the old mechanism where you do: >> >> ifconfig vlan create >> ifconfig vlan0 vlan 1 vlandev em0 > > /me wants to do: > > "ifconfig em0.1 inet 192.168.2.2/24" That can still be done and is just different syntax to ifconfig. > > Even simpler. And yes, this works already but only if if_vlan.ko > was loaded before or compiled into the kernel. It doesn't do auto- > load. > From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 15:26:42 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C99016A4DA for ; Mon, 10 Jul 2006 15:26:42 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6419F43D93 for ; Mon, 10 Jul 2006 15:26:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6AFQP1Z087381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 08:26:26 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B271A1.9020800@errno.com> Date: Mon, 10 Jul 2006 08:26:25 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Maxim Konovalov References: <44B15511.206@errno.com> <20060710125919.D35569@mp2.macomnet.net> In-Reply-To: <20060710125919.D35569@mp2.macomnet.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 15:26:42 -0000 Maxim Konovalov wrote: > [...] >> This would change the user api but otherwise I can see no reason for >> continuing to support the old mechanism where you do: >> >> ifconfig vlan create >> ifconfig vlan0 vlan 1 vlandev em0 >> >> Anyone _against_ nuking the above? > > As you said it will break POLA and a number of scripts outside our > tree. If it doesn't cost much for us I wouldn't killed "ifconfig vlan > create". > As I said in separate mail having the 2-step procedure provides no functionality and in the future (when I bring in virtual ap support for the wireless system) it will not be possible to create cloned wlan devices w/ a 2-step process. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 16:04:47 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 664BB16A4DD; Mon, 10 Jul 2006 16:04:47 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 087B443D6D; Mon, 10 Jul 2006 16:04:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k6AG4fR4025518; Mon, 10 Jul 2006 09:04:41 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k6AG4fL9025517; Mon, 10 Jul 2006 09:04:41 -0700 Date: Mon, 10 Jul 2006 09:04:41 -0700 From: Brooks Davis To: Andre Oppermann Message-ID: <20060710160441.GB31026@odin.ac.hmc.edu> References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <44B21551.5050002@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 16:04:47 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote: > Sam Leffler wrote: > >I committed the revised netif cloning api so you can now specify > >parameters when cloning. I also modified the vlan code to use this > >mechanism so doing something like: > > > >ifconfig vlan create vlan 1 vlandev em0 > > > >causes a single request to clone a vlan together with the tag+parent > >device parameters (i.e. and no subsequent SIOCSETVLAN request). > > > >Given the above do we still need to support setting vlan tag+device > >separately or can we just require everything be specified when doing the > >clone operation? This would change the user api but otherwise I can see > >no reason for continuing to support the old mechanism where you do: > > > >ifconfig vlan create > >ifconfig vlan0 vlan 1 vlandev em0 >=20 > /me wants to do: >=20 > "ifconfig em0.1 inet 192.168.2.2/24" >=20 > Even simpler. And yes, this works already but only if if_vlan.ko > was loaded before or compiled into the kernel. It doesn't do auto- > load. Unless cause ifconfig to autoload all if_ modules when cloning fails, it's impossiable to support this without having if_vlan loaded. That said the current plan it to eliminate if_vlan and integrate vlan support directly into if_ethersubr.c to allow use to correctly handle the default vlan case among otherthings. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEsnqZXY6L6fI4GtQRAgUvAKC80nx6ScoGYLnWeOW0x6WtT+VpowCgxEfO QJWEgh5z8xdKyEpBgoEsb/E= =A+bK -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 18:25:08 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9949B16A509 for ; Mon, 10 Jul 2006 18:25:08 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1904F43D78 for ; Mon, 10 Jul 2006 18:25:04 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6AIOmks071264; Mon, 10 Jul 2006 21:24:48 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 10 Jul 2006 21:24:48 +0300 (EEST) From: Dmitry Pryanishnikov To: Sam Leffler In-Reply-To: <44B2713A.2020204@errno.com> Message-ID: <20060710211733.Y58186@atlantis.atlantis.dp.ua> References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> <44B2713A.2020204@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 18:25:08 -0000 Hello! On Mon, 10 Jul 2006, Sam Leffler wrote: >> ifconfig vlan0 create >> ifconfig vlan0 vlan 1 vlandev em0 >> >> sequence is required for now. Also, I thing it's perfectly correct to have >> >> cloned_interfaces="vlan30" >> >> while NOT having 'ifconfig_vlan30' assignment - system administrator >> could just reserve a spare interface w/o assigning it's parameters. So I >> think >> that possibility of the specific device cloning w/o arguments, e.g., >> >> ifconfig vlan30 create >> >> should be preserved. > > Clearly one would need to fix rc scripts. The question is should the > old behaviour be preserved; it provides no functionality--i.e. a cloned > device is unusable until you set the tag+parent and you cannot set the > tag or parent on an existing cloned device (once setup). So the only I don't agree: 1) Cloned but unset device is perfectly legal for, e.g., mentioning in ipfw rules (or any other context which requires interface name); 2) Sure, you _can_ change tag+parent afterwards: root@homelynx# ifconfig vlan32 create root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0 root@homelynx# ifconfig vlan32 -vlandev root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0 root@homelynx# > preserve existing practice. Removing the 2 step procedure would allow > code to be removed and (IMO) clarify how a vlan is crafted. In the > future there will be cloned devices that cannot/will-not be specified > with a 2-step procedure so having vlans work this way will violate POLA. Please don't break well-known and useful behaviour! Remember that it allows to switch easily physical vlanXXX device assignment (e.g., migration to the another trunk) w/o reloading firewall rules. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 18:53:28 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00A1A16A4DE for ; Mon, 10 Jul 2006 18:53:28 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7689843D5E for ; Mon, 10 Jul 2006 18:53:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k6AIrKiO088515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 11:53:20 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44B2A220.4090705@errno.com> Date: Mon, 10 Jul 2006 11:53:20 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> <44B2713A.2020204@errno.com> <20060710211733.Y58186@atlantis.atlantis.dp.ua> In-Reply-To: <20060710211733.Y58186@atlantis.atlantis.dp.ua> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 18:53:28 -0000 Dmitry Pryanishnikov wrote: > > Hello! > > On Mon, 10 Jul 2006, Sam Leffler wrote: >>> ifconfig vlan0 create >>> ifconfig vlan0 vlan 1 vlandev em0 >>> >>> sequence is required for now. Also, I thing it's perfectly correct to >>> have >>> >>> cloned_interfaces="vlan30" >>> >>> while NOT having 'ifconfig_vlan30' assignment - system administrator >>> could just reserve a spare interface w/o assigning it's parameters. So I >>> think >>> that possibility of the specific device cloning w/o arguments, e.g., >>> >>> ifconfig vlan30 create >>> >>> should be preserved. >> >> Clearly one would need to fix rc scripts. The question is should the >> old behaviour be preserved; it provides no functionality--i.e. a cloned >> device is unusable until you set the tag+parent and you cannot set the >> tag or parent on an existing cloned device (once setup). So the only > > I don't agree: > > 1) Cloned but unset device is perfectly legal for, e.g., mentioning > in ipfw rules (or any other context which requires interface name); > > 2) Sure, you _can_ change tag+parent afterwards: > > root@homelynx# ifconfig vlan32 create > root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0 > root@homelynx# ifconfig vlan32 -vlandev > root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0 > root@homelynx# Hmm, that did not work yesterday in my testing. That's the answer I've been looking for. Thank you. OTOH I can easily see that plumbing a vlan into firewall rules and then changing it's configuration might generate very hard to find bugs; but whatever. > >> preserve existing practice. Removing the 2 step procedure would allow >> code to be removed and (IMO) clarify how a vlan is crafted. In the >> future there will be cloned devices that cannot/will-not be specified >> with a 2-step procedure so having vlans work this way will violate POLA. > > Please don't break well-known and useful behaviour! Remember that it > allows > to switch easily physical vlanXXX device assignment (e.g., migration to the > another trunk) w/o reloading firewall rules. I've got no plans. You'll note I committed the new stuff as completely separate. I only asked now because I saw an opportunity to remove cruft. But given that it's used that cruft can just stay around. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 19:06:35 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0811716A4E2; Mon, 10 Jul 2006 19:06:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F1843D49; Mon, 10 Jul 2006 19:06:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6AJ6AU8048048; Mon, 10 Jul 2006 13:06:16 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44B2A51A.4040103@samsco.org> Date: Mon, 10 Jul 2006 13:06:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> In-Reply-To: <20060708174606.GA29602@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 19:06:35 -0000 Christoph Hellwig wrote: > On Sat, Jul 08, 2006 at 09:05:51AM -0700, Sam Leffler wrote: > >>Linux has -t auto; haven't looked at how it works. > > > It's implemented in mount(8). It has a table of magic numbers and offsets > and tries all of them in a well defined order. If everything fails it > tries a few heuristics whether the filesystems might be a FAT filesystem > as thos don't have magic numbers. > So in your opinion and experience, what are the pros and cons of maintaining a table of magic numbers? Scott From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 19:23:53 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2696F16A4FF for ; Mon, 10 Jul 2006 19:23:53 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 652E443D45 for ; Mon, 10 Jul 2006 19:23:52 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k6AJNb8F020149; Mon, 10 Jul 2006 22:23:37 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Mon, 10 Jul 2006 22:23:37 +0300 (EEST) From: Dmitry Pryanishnikov To: Sam Leffler In-Reply-To: <44B2A220.4090705@errno.com> Message-ID: <20060710215459.W95495@atlantis.atlantis.dp.ua> References: <44B15511.206@errno.com> <20060710103404.I25526@atlantis.atlantis.dp.ua> <44B2713A.2020204@errno.com> <20060710211733.Y58186@atlantis.atlantis.dp.ua> <44B2A220.4090705@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 19:23:53 -0000 On Mon, 10 Jul 2006, Sam Leffler wrote: >> root@homelynx# ifconfig vlan32 create >> root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0 >> root@homelynx# ifconfig vlan32 -vlandev >> root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0 >> root@homelynx# > > Hmm, that did not work yesterday in my testing. That's the answer I've > been looking for. Thank you. OTOH I can easily see that plumbing a > vlan into firewall rules and then changing it's configuration might > generate very hard to find bugs; but whatever. This (changing vlan binding w/o device destruction) is very handy for providing software-assisted failover in some hardware configurations. Suppose you have 2 VLAN trunks (say fxp2 and fxp3) which (via different physical media) are connected to the same remote switch (which demultiplexes VLANs to the different clients). Changing 'vlandev' on-the-fly (actually removing old parent with -vlandev, then assigning the new one), you can just move all vlans from e.g. fxp2 to fxp3 (in the event of fxp2's hardware link failure) w/o touching the firewall. I had this scheme in production during several months, and didn't see any bugs (under RELENG_4, but I doubt that such a simple yet efficient feature is broken in newer branches). >> Please don't break well-known and useful behaviour! Remember that it >> allows >> to switch easily physical vlanXXX device assignment (e.g., migration to the >> another trunk) w/o reloading firewall rules. > > I've got no plans. You'll note I committed the new stuff as completely > separate. I only asked now because I saw an opportunity to remove > cruft. But given that it's used that cruft can just stay around. I hope I've managed to show that it isn't a cruft ;) Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 19:30:12 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 988C916A4E0; Mon, 10 Jul 2006 19:30:12 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A7343D45; Mon, 10 Jul 2006 19:30:11 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-71-233-168-2.hsd1.ma.comcast.net ([71.233.168.2]) by comcast.net (rwcrmhc12) with ESMTP id <20060710193010m12000a1n8e>; Mon, 10 Jul 2006 19:30:10 +0000 Received: from c-71-233-168-2.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1) with ESMTP id k6AJU6kF034337; Mon, 10 Jul 2006 15:30:12 -0400 (EDT) (envelope-from rodrigc@c-71-233-168-2.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-71-233-168-2.hsd1.ma.comcast.net (8.13.6/8.13.1/Submit) id k6AJU6cj034336; Mon, 10 Jul 2006 15:30:06 -0400 (EDT) (envelope-from rodrigc) Date: Mon, 10 Jul 2006 15:30:05 -0400 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20060710193005.GA34287@crodrigues.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B2A51A.4040103@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 19:30:12 -0000 On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > So in your opinion and experience, what are the pros and cons of > maintaining a table of magic numbers? One con: every time you add a new filesystem, you need to update mount(8). Not a big deal, but it is something. For Linux, the mount program usually is part of the util-linux package which is separate from the kernel. util-linux and kernel are maintained by separate groups in Linux....it is the responsibility of the Linux distribution to bundle together versions of util-linux and kernel that work together. For FreeBSD, the direction I have been going is to try to make mount(8) as simple and generic as possible, and push all the stuff for doing filesystem specific things into the kernel, i.e. into vfs_mount.c for generic stuff, and into each specific filesystem for fs-specific stuff. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 20:22:42 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AC8716A4DF; Mon, 10 Jul 2006 20:22:42 +0000 (UTC) (envelope-from SRS0+82d3cd74a67493595751+1051+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D76C43D49; Mon, 10 Jul 2006 20:22:40 +0000 (GMT) (envelope-from SRS0+82d3cd74a67493595751+1051+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G02Gp-0007pl-5f; Mon, 10 Jul 2006 21:22:19 +0100 Date: Mon, 10 Jul 2006 21:22:19 +0100 From: Christoph Hellwig To: Scott Long Message-ID: <20060710202219.GA29786@infradead.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B2A51A.4040103@samsco.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 20:22:42 -0000 On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > So in your opinion and experience, what are the pros and cons of > maintaining a table of magic numbers? The feature is imensely useful. The implementation won't win any points for a clean design but works very well in practice. I think it's definitly better than probing in the kernel because letting a filesystem driver try to make sense of something that's not it's own format can lead to all kinds of funnies. Linux does this (iterating all filesystem types in kernel) for the special case of the root filesystem where mount(8) is not available, and it showeds various interesting bugs at least in the fat driver. From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 20:27:15 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B626616A4E1 for ; Mon, 10 Jul 2006 20:27:15 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt13.ihug.co.nz (grunt13.ihug.co.nz [203.109.254.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CAD343D49 for ; Mon, 10 Jul 2006 20:27:15 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt13.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1G02LZ-0000VF-00; Tue, 11 Jul 2006 08:27:13 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id C3A8A1CC22; Tue, 11 Jul 2006 08:27:14 +1200 (NZST) Date: Tue, 11 Jul 2006 08:27:14 +1200 From: Andrew Thompson To: Brooks Davis Message-ID: <20060710202714.GC16054@heff.fud.org.nz> References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> <20060710160441.GB31026@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710160441.GB31026@odin.ac.hmc.edu> User-Agent: Mutt/1.5.11 Cc: Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 10 Jul 2006 20:27:15 -0000 On Mon, Jul 10, 2006 at 09:04:41AM -0700, Brooks Davis wrote: > On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote: > > Sam Leffler wrote: > > >I committed the revised netif cloning api so you can now specify > > >parameters when cloning. I also modified the vlan code to use this > > >mechanism so doing something like: > > > > > >ifconfig vlan create vlan 1 vlandev em0 > > > > > > > /me wants to do: > > > > "ifconfig em0.1 inet 192.168.2.2/24" > > > > Even simpler. And yes, this works already but only if if_vlan.ko > > was loaded before or compiled into the kernel. It doesn't do auto- > > load. > > Unless cause ifconfig to autoload all if_ modules when cloning fails, > it's impossiable to support this without having if_vlan loaded. That > said the current plan it to eliminate if_vlan and integrate vlan support > directly into if_ethersubr.c to allow use to correctly handle the > default vlan case among otherthings. Is anyone working on this? The bridge code needs access to the vlan tag to properly hash the address as each vlan is a seperate broadcast domain, this would be much easier with vlan merged to if_ethersubr.c. Andrew From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 20:32:07 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 880F416A4DA; Mon, 10 Jul 2006 20:32:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFAAF43D4C; Mon, 10 Jul 2006 20:32:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6AKUSpf048522; Mon, 10 Jul 2006 14:30:34 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44B2B8DC.8070201@samsco.org> Date: Mon, 10 Jul 2006 14:30:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> In-Reply-To: <20060710202219.GA29786@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 20:32:07 -0000 Christoph Hellwig wrote: > On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > >>So in your opinion and experience, what are the pros and cons of >>maintaining a table of magic numbers? > > > The feature is imensely useful. The implementation won't win any > points for a clean design but works very well in practice. I think > it's definitly better than probing in the kernel because letting a filesystem > driver try to make sense of something that's not it's own format can > lead to all kinds of funnies. Linux does this (iterating all filesystem > types in kernel) for the special case of the root filesystem where mount(8) > is not available, and it showeds various interesting bugs at least in the > fat driver. > How does it resolve situations like with UDF vs iso9660, where both structures can co-exist? Scott From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 20:39:57 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 167B416A4DA; Mon, 10 Jul 2006 20:39:57 +0000 (UTC) (envelope-from SRS0+82d3cd74a67493595751+1051+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C7A43D49; Mon, 10 Jul 2006 20:39:56 +0000 (GMT) (envelope-from SRS0+82d3cd74a67493595751+1051+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1G02Xl-0008AL-Q5; Mon, 10 Jul 2006 21:39:49 +0100 Date: Mon, 10 Jul 2006 21:39:49 +0100 From: Christoph Hellwig To: Scott Long Message-ID: <20060710203949.GA31267@infradead.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> <44B2B8DC.8070201@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B2B8DC.8070201@samsco.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 10 Jul 2006 20:39:57 -0000 On Mon, Jul 10, 2006 at 02:30:20PM -0600, Scott Long wrote: > >lead to all kinds of funnies. Linux does this (iterating all filesystem > >types in kernel) for the special case of the root filesystem where mount(8) > >is not available, and it showeds various interesting bugs at least in the > >fat driver. > > > > How does it resolve situations like with UDF vs iso9660, where both > structures can co-exist? The kernel doesn't do anything fancy. It just walks the list of filesystem and the first fs that takes it gets it. To answer the specific example iso9660 is registered before udf so if you wanted to use a dual-fs cdrom as root you would get iso9600 unless you specified the rootfstype=udf boot option. From owner-freebsd-arch@FreeBSD.ORG Mon Jul 10 22:38:50 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1018F16A4E6; Mon, 10 Jul 2006 22:38:50 +0000 (UTC) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 336E043D49; Mon, 10 Jul 2006 22:38:49 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.6/8.13.6) with ESMTP id k6AMcknx047607; Mon, 10 Jul 2006 15:38:46 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.6/8.13.1/Submit) id k6AMcjH9047606; Mon, 10 Jul 2006 15:38:45 -0700 (PDT) (envelope-from obrien) Date: Mon, 10 Jul 2006 15:38:45 -0700 From: "David O'Brien" To: Craig Rodrigues Message-ID: <20060710223845.GA47557@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Craig Rodrigues References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708161719.GB3871@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060708161719.GB3871@crodrigues.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 22:38:50 -0000 On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote: > I was thinking of doing something like that. You can basically > get the same info by doing something like: > file - < /dev/ad0s1e > /dev/stdin: Unix Fast File system (little-endian) > file - < /dev/ad0s4 > /dev/stdin: SGI XFS filesystem > > I leaned away from this approach in mount(8) because: > - I didn't want to tie mount(8) to file(1) Why not? We have libmagic for purposes like this. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 00:39:43 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2328016A4DA; Tue, 11 Jul 2006 00:39:43 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C0F043D46; Tue, 11 Jul 2006 00:39:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.201] ([192.168.254.201]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6B0dN16049742; Mon, 10 Jul 2006 18:39:28 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44B2F326.1090203@samsco.org> Date: Mon, 10 Jul 2006 18:39:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708161719.GB3871@crodrigues.org> <20060710223845.GA47557@dragon.NUXI.org> In-Reply-To: <20060710223845.GA47557@dragon.NUXI.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 00:39:43 -0000 David O'Brien wrote: > On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote: > >>I was thinking of doing something like that. You can basically >>get the same info by doing something like: >>file - < /dev/ad0s1e >>/dev/stdin: Unix Fast File system (little-endian) >>file - < /dev/ad0s4 >>/dev/stdin: SGI XFS filesystem >> >>I leaned away from this approach in mount(8) because: >>- I didn't want to tie mount(8) to file(1) > > > Why not? We have libmagic for purposes like this. > This is an interesting idea. However, it has the potential to add a dependency on /usr to the early boot environment. Maybe it could be done via rtld? Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 01:05:47 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10A7216A4DD; Tue, 11 Jul 2006 01:05:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9447743D53; Tue, 11 Jul 2006 01:05:46 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.92] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k6B15apt043483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 18:05:38 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <44B2F94A.6020309@FreeBSD.org> Date: Mon, 10 Jul 2006 18:05:14 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Scott Long References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708161719.GB3871@crodrigues.org> <20060710223845.GA47557@dragon.NUXI.org> <44B2F326.1090203@samsco.org> In-Reply-To: <44B2F326.1090203@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 01:05:47 -0000 Scott Long wrote: > David O'Brien wrote: >> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote: >> >>> I was thinking of doing something like that. You can basically >>> get the same info by doing something like: >>> file - < /dev/ad0s1e >>> /dev/stdin: Unix Fast File system (little-endian) >>> file - < /dev/ad0s4 >>> /dev/stdin: SGI XFS filesystem >>> >>> I leaned away from this approach in mount(8) because: >>> - I didn't want to tie mount(8) to file(1) >> >> >> Why not? We have libmagic for purposes like this. >> > > This is an interesting idea. However, it has the potential to > add a dependency on /usr to the early boot environment. Maybe it > could be done via rtld? Well, we have dynamic /sbin now, so that it's only the matter of moving libmagic into /lib. -Maxim From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 01:23:57 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E804116A4E0; Tue, 11 Jul 2006 01:23:57 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5741A43D4C; Tue, 11 Jul 2006 01:23:57 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.201] ([192.168.254.201]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k6B1NoNo049994; Mon, 10 Jul 2006 19:23:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44B2FD91.4010503@samsco.org> Date: Mon, 10 Jul 2006 19:23:29 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Sobolev References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708161719.GB3871@crodrigues.org> <20060710223845.GA47557@dragon.NUXI.org> <44B2F326.1090203@samsco.org> <44B2F94A.6020309@FreeBSD.org> In-Reply-To: <44B2F94A.6020309@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Craig Rodrigues , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 01:23:58 -0000 Maxim Sobolev wrote: > Scott Long wrote: > >> David O'Brien wrote: >> >>> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote: >>> >>>> I was thinking of doing something like that. You can basically >>>> get the same info by doing something like: >>>> file - < /dev/ad0s1e >>>> /dev/stdin: Unix Fast File system (little-endian) >>>> file - < /dev/ad0s4 >>>> /dev/stdin: SGI XFS filesystem >>>> >>>> I leaned away from this approach in mount(8) because: >>>> - I didn't want to tie mount(8) to file(1) >>> >>> >>> >>> Why not? We have libmagic for purposes like this. >>> >> >> This is an interesting idea. However, it has the potential to >> add a dependency on /usr to the early boot environment. Maybe it >> could be done via rtld? > > > Well, we have dynamic /sbin now, so that it's only the matter of moving > libmagic into /lib. > > -Maxim libmagic depends on libz. Let's not go down the path of populating /lib with every convenience under the sun. Scott From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 05:14:17 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC4ED16A4E1; Tue, 11 Jul 2006 05:14:17 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A6943D46; Tue, 11 Jul 2006 05:14:16 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1G0AZa-000GIQ-Rl; Tue, 11 Jul 2006 08:14:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <44B2FD91.4010503@samsco.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708161719.GB3871@crodrigues.org> <20060710223845.GA47557@dragon.NUXI.org> <44B2F326.1090203@samsco.org> <44B2F94A.6020309@FreeBSD.org> <44B2FD91.4010503@samsco.org> Comments: In-reply-to Scott Long message dated "Mon, 10 Jul 2006 19:23:29 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jul 2006 08:14:14 +0300 From: Danny Braniss Message-ID: Cc: Maxim Sobolev , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org, Craig Rodrigues Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 05:14:17 -0000 > Maxim Sobolev wrote: > > > Scott Long wrote: > > > >> David O'Brien wrote: > >> > >>> On Sat, Jul 08, 2006 at 12:17:19PM -0400, Craig Rodrigues wrote: > >>> > >>>> I was thinking of doing something like that. You can basically > >>>> get the same info by doing something like: > >>>> file - < /dev/ad0s1e > >>>> /dev/stdin: Unix Fast File system (little-endian) > >>>> file - < /dev/ad0s4 > >>>> /dev/stdin: SGI XFS filesystem > >>>> > >>>> I leaned away from this approach in mount(8) because: > >>>> - I didn't want to tie mount(8) to file(1) > >>> > >>> > >>> > >>> Why not? We have libmagic for purposes like this. > >>> > >> > >> This is an interesting idea. However, it has the potential to > >> add a dependency on /usr to the early boot environment. Maybe it > >> could be done via rtld? > > > > > > Well, we have dynamic /sbin now, so that it's only the matter of moving > > libmagic into /lib. > > > > -Maxim > > libmagic depends on libz. Let's not go down the path of populating > /lib with every convenience under the sun. > and /usr/share/misc/magic btw, the idea of mount figuring out the nount-type has allot of merit, but using a 10 ton hammer is not the way. danny From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 11:45:19 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1E1A16A4DE; Tue, 11 Jul 2006 11:45:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF1743D45; Tue, 11 Jul 2006 11:45:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 10A4846C53; Tue, 11 Jul 2006 07:45:19 -0400 (EDT) Date: Tue, 11 Jul 2006 12:45:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Christoph Hellwig In-Reply-To: <20060710202219.GA29786@infradead.org> Message-ID: <20060711124356.Y78628@fledge.watson.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , Scott Long , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 11:45:20 -0000 On Mon, 10 Jul 2006, Christoph Hellwig wrote: > On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: >> So in your opinion and experience, what are the pros and cons of >> maintaining a table of magic numbers? > > The feature is imensely useful. The implementation won't win any points for > a clean design but works very well in practice. I think it's definitly > better than probing in the kernel because letting a filesystem driver try to > make sense of something that's not it's own format can lead to all kinds of > funnies. Linux does this (iterating all filesystem types in kernel) for the > special case of the root filesystem where mount(8) is not available, and it > showeds various interesting bugs at least in the fat driver. In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is excessively permissive as to what it considers a FAT file system. This is presumably necessary due to the enourmous diversity of FAT file systems floating around, but it makes it a little too easy to cause msdos to trip over layouts that violate its layout assumptions. :-) FAT is much more reliably detected by looking at the partition type it lives in than by looking at the bytes that appear inside the partition, I believe. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 13:27:58 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E878216A4E6; Tue, 11 Jul 2006 13:27:57 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51B1A43D49; Tue, 11 Jul 2006 13:27:56 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G0IHJ-000I6y-0B; Tue, 11 Jul 2006 14:27:53 +0100 Date: Tue, 11 Jul 2006 14:27:52 +0100 From: Ceri Davies To: Robert Watson Message-ID: <20060711132752.GF65857@submonkey.net> Mail-Followup-To: Ceri Davies , Robert Watson , Christoph Hellwig , Craig Rodrigues , Scott Long , freebsd-current@freebsd.org, freebsd-arch@freebsd.org References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> <20060711124356.Y78628@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7LkOrbQMr4cezO2T" Content-Disposition: inline In-Reply-To: <20060711124356.Y78628@fledge.watson.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: Craig Rodrigues , Scott Long , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 13:27:58 -0000 --7LkOrbQMr4cezO2T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2006 at 12:45:18PM +0100, Robert Watson wrote: >=20 > On Mon, 10 Jul 2006, Christoph Hellwig wrote: >=20 > >On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > >>So in your opinion and experience, what are the pros and cons of=20 > >>maintaining a table of magic numbers? > > > >The feature is imensely useful. The implementation won't win any points= =20 > >for a clean design but works very well in practice. I think it's=20 > >definitly better than probing in the kernel because letting a filesystem= =20 > >driver try to make sense of something that's not it's own format can lea= d=20 > >to all kinds of funnies. Linux does this (iterating all filesystem type= s=20 > >in kernel) for the special case of the root filesystem where mount(8) is= =20 > >not available, and it showeds various interesting bugs at least in the f= at=20 > >driver. >=20 > In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is= =20 > excessively permissive as to what it considers a FAT file system. This i= s=20 > presumably necessary due to the enourmous diversity of FAT file systems= =20 > floating around, but it makes it a little too easy to cause msdos to trip= =20 > over layouts that violate its layout assumptions. :-) FAT is much more= =20 > reliably detected by looking at the partition type it lives in than by=20 > looking at the bytes that appear inside the partition, I believe. Assuming that there is a valid partition type. I don't really know what this makes, but there's a valid FAT filesystem on it: % truncate -s 1440k floppy % sudo mdconfig -a -f floppy=20 md1 % sudo newfs_msdos -f 1440 /dev/md1 /dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster) bps=3D512 spc=3D1 res=3D1 nft=3D2 rde=3D224 sec=3D2880 mid=3D0xf0 spf=3D9 s= pt=3D18 hds=3D2 hid=3D0 % sudo mount -t msdos /dev/md1 /mnt % df -h /mnt Filesystem Size Used Avail Capacity Mounted on /dev/md1 1.4M 1.0K 1.4M 0% /mnt {ceri@shrike}-{~} % fdisk /dev/md1 ******* Working on device /dev/md1 ******* parameters extracted from in-core disklabel are: cylinders=3D0 heads=3D255 sectors/track=3D63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=3D0 heads=3D255 sectors/track=3D63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --7LkOrbQMr4cezO2T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEs6dYocfcwTS3JF8RAsrUAJ9+TRZzDxgoOyCdLI3OZlr/kzK5lACggnX6 +WSMM1QR1dJmhFpNq36zVY0= =/QdA -----END PGP SIGNATURE----- --7LkOrbQMr4cezO2T-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 15:02:23 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4E6316A695; Tue, 11 Jul 2006 15:02:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A95343D68; Tue, 11 Jul 2006 15:02:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6BF1qGc075013; Tue, 11 Jul 2006 11:01:59 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Tue, 11 Jul 2006 09:54:00 -0400 User-Agent: KMail/1.9.1 References: <20060708152801.GA3671@crodrigues.org> <20060711124356.Y78628@fledge.watson.org> <20060711132752.GF65857@submonkey.net> In-Reply-To: <20060711132752.GF65857@submonkey.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607110954.01691.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 11 Jul 2006 11:02:03 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1591/Mon Jul 10 15:41:02 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Craig Rodrigues , Scott Long , Ceri Davies , Robert Watson , freebsd-current@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 15:02:23 -0000 On Tuesday 11 July 2006 09:27, Ceri Davies wrote: > On Tue, Jul 11, 2006 at 12:45:18PM +0100, Robert Watson wrote: > > > > On Mon, 10 Jul 2006, Christoph Hellwig wrote: > > > > >On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > > >>So in your opinion and experience, what are the pros and cons of > > >>maintaining a table of magic numbers? > > > > > >The feature is imensely useful. The implementation won't win any points > > >for a clean design but works very well in practice. I think it's > > >definitly better than probing in the kernel because letting a filesystem > > >driver try to make sense of something that's not it's own format can lead > > >to all kinds of funnies. Linux does this (iterating all filesystem types > > >in kernel) for the special case of the root filesystem where mount(8) is > > >not available, and it showeds various interesting bugs at least in the fat > > >driver. > > > > In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is > > excessively permissive as to what it considers a FAT file system. This is > > presumably necessary due to the enourmous diversity of FAT file systems > > floating around, but it makes it a little too easy to cause msdos to trip > > over layouts that violate its layout assumptions. :-) FAT is much more > > reliably detected by looking at the partition type it lives in than by > > looking at the bytes that appear inside the partition, I believe. > > Assuming that there is a valid partition type. I don't really know what > this makes, but there's a valid FAT filesystem on it: > > % truncate -s 1440k floppy > % sudo mdconfig -a -f floppy > md1 > % sudo newfs_msdos -f 1440 /dev/md1 > /dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster) > bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0 > % sudo mount -t msdos /dev/md1 /mnt > % df -h /mnt > Filesystem Size Used Avail Capacity Mounted on > /dev/md1 1.4M 1.0K 1.4M 0% /mnt > {ceri@shrike}-{~} % fdisk /dev/md1 > ******* Working on device /dev/md1 ******* > parameters extracted from in-core disklabel are: > cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl) > > parameters to be used for BIOS calculations are: > cylinders=0 heads=255 sectors/track=63 (16065 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > Ceri Dos floppies don't have an MBR (so fdisk on them is meaningless). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 15:04:03 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A3A216A4EA; Tue, 11 Jul 2006 15:04:03 +0000 (UTC) (envelope-from ceri@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-0-0-cust107.cdif.cable.ntl.com [81.104.168.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id D04B743D66; Tue, 11 Jul 2006 15:04:02 +0000 (GMT) (envelope-from ceri@submonkey.net) Received: from ceri by shrike.submonkey.net with local (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G0JmL-000KWe-6y; Tue, 11 Jul 2006 16:04:01 +0100 Date: Tue, 11 Jul 2006 16:04:01 +0100 From: Ceri Davies To: John Baldwin Message-ID: <20060711150401.GI65857@submonkey.net> Mail-Followup-To: Ceri Davies , John Baldwin , freebsd-arch@freebsd.org, Robert Watson , Craig Rodrigues , Scott Long , freebsd-current@freebsd.org References: <20060708152801.GA3671@crodrigues.org> <20060711124356.Y78628@fledge.watson.org> <20060711132752.GF65857@submonkey.net> <200607110954.01691.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+sHJum3is6Tsg7/J" Content-Disposition: inline In-Reply-To: <200607110954.01691.jhb@freebsd.org> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.11 Sender: Ceri Davies Cc: Craig Rodrigues , Scott Long , freebsd-current@freebsd.org, Robert Watson , freebsd-arch@freebsd.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 15:04:03 -0000 --+sHJum3is6Tsg7/J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2006 at 09:54:00AM -0400, John Baldwin wrote: > On Tuesday 11 July 2006 09:27, Ceri Davies wrote: > >=20 > > Assuming that there is a valid partition type. I don't really know what > > this makes, but there's a valid FAT filesystem on it: > >=20 > > % truncate -s 1440k floppy > > % sudo mdconfig -a -f floppy=20 > > md1 > > % sudo newfs_msdos -f 1440 /dev/md1 > > /dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster) > > bps=3D512 spc=3D1 res=3D1 nft=3D2 rde=3D224 sec=3D2880 mid=3D0xf0 spf= =3D9 spt=3D18 hds=3D2 hid=3D0 > > % sudo mount -t msdos /dev/md1 /mnt > > % df -h /mnt > > Filesystem Size Used Avail Capacity Mounted on > > /dev/md1 1.4M 1.0K 1.4M 0% /mnt > > {ceri@shrike}-{~} % fdisk /dev/md1 > > ******* Working on device /dev/md1 ******* > > parameters extracted from in-core disklabel are: > > cylinders=3D0 heads=3D255 sectors/track=3D63 (16065 blks/cyl) > >=20 > > parameters to be used for BIOS calculations are: > > cylinders=3D0 heads=3D255 sectors/track=3D63 (16065 blks/cyl) > >=20 > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > > > The data for partition 2 is: > > > > The data for partition 3 is: > > > > The data for partition 4 is: > > > >=20 > > Ceri >=20 > Dos floppies don't have an MBR (so fdisk on them is meaningless). That agrees with observation :) Thanks! Ceri --=20 That must be wonderful! I don't understand it at all. -- Moliere --+sHJum3is6Tsg7/J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEs73gocfcwTS3JF8RAlfpAJ9Vrmj2JBz7qJVJXraRdSNp7zPTWwCfYPtr /MA7r0NQO8fHKd/5zJ9dBh0= =z1zj -----END PGP SIGNATURE----- --+sHJum3is6Tsg7/J-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 16:29:55 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A087316A4E1; Tue, 11 Jul 2006 16:29:55 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E38F443D53; Tue, 11 Jul 2006 16:29:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k6BGTriJ028745; Tue, 11 Jul 2006 09:29:53 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k6BGTrna028744; Tue, 11 Jul 2006 09:29:53 -0700 Date: Tue, 11 Jul 2006 09:29:53 -0700 From: Brooks Davis To: Andrew Thompson Message-ID: <20060711162953.GC20418@odin.ac.hmc.edu> References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> <20060710160441.GB31026@odin.ac.hmc.edu> <20060710202714.GC16054@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8X7/QrJGcKSMr1RN" Content-Disposition: inline In-Reply-To: <20060710202714.GC16054@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 11 Jul 2006 16:29:55 -0000 --8X7/QrJGcKSMr1RN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 11, 2006 at 08:27:14AM +1200, Andrew Thompson wrote: > On Mon, Jul 10, 2006 at 09:04:41AM -0700, Brooks Davis wrote: > > On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote: > > > Sam Leffler wrote: > > > >I committed the revised netif cloning api so you can now specify > > > >parameters when cloning. I also modified the vlan code to use this > > > >mechanism so doing something like: > > > > > > > >ifconfig vlan create vlan 1 vlandev em0 > > > > > > >=20 > > > /me wants to do: > > >=20 > > > "ifconfig em0.1 inet 192.168.2.2/24" > > >=20 > > > Even simpler. And yes, this works already but only if if_vlan.ko > > > was loaded before or compiled into the kernel. It doesn't do auto- > > > load. > >=20 > > Unless cause ifconfig to autoload all if_ modules when cloning fails, > > it's impossiable to support this without having if_vlan loaded. That > > said the current plan it to eliminate if_vlan and integrate vlan support > > directly into if_ethersubr.c to allow use to correctly handle the > > default vlan case among otherthings. >=20 > Is anyone working on this? The bridge code needs access to the vlan tag > to properly hash the address as each vlan is a seperate broadcast > domain, this would be much easier with vlan merged to if_ethersubr.c. I think it ended up with Robert's name on it at the last devsummit, but he's got a lot of higher priority stuff on his plate. It doesn't look like this change would be all that much work. The one thing that might be worth investigating is seeing if there's a sane way to make vlan tag parsing part of ether_input, but keep if_vlan.c around as a module for actual support of trunks so we get most of the architectural benefits of correctly treating vlan tags as part of the spec, but let embedded users who don't need trunks avoid the overhead. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --8X7/QrJGcKSMr1RN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEs9H/XY6L6fI4GtQRAktzAJ0dQkVd5cYjmwHROYL6DO7J1c6McQCfaAig yWl2RPNHhmAo6ENqblD0jYk= =9E92 -----END PGP SIGNATURE----- --8X7/QrJGcKSMr1RN-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 20:09:57 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A30316A4DD; Tue, 11 Jul 2006 20:09:57 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AF8243D70; Tue, 11 Jul 2006 20:09:55 +0000 (GMT) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.1/8.13.3) with ESMTP id k6BK9pWU042699; Tue, 11 Jul 2006 13:09:51 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.1/8.13.3/Submit) id k6BK9oXu042698; Tue, 11 Jul 2006 13:09:50 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Tue, 11 Jul 2006 13:09:49 -0700 From: Greg Lewis To: Christoph Hellwig Message-ID: <20060711200949.GA42576@misty.eyesbeyond.com> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060710202219.GA29786@infradead.org> User-Agent: Mutt/1.4.2.1i Cc: Craig Rodrigues , Scott Long , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 11 Jul 2006 20:09:57 -0000 On Mon, Jul 10, 2006 at 09:22:19PM +0100, Christoph Hellwig wrote: > On Mon, Jul 10, 2006 at 01:06:02PM -0600, Scott Long wrote: > > So in your opinion and experience, what are the pros and cons of > > maintaining a table of magic numbers? > > The feature is imensely useful. The implementation won't win any > points for a clean design but works very well in practice. I think > it's definitly better than probing in the kernel because letting a filesystem > driver try to make sense of something that's not it's own format can > lead to all kinds of funnies. Linux does this (iterating all filesystem > types in kernel) for the special case of the root filesystem where mount(8) > is not available, and it showeds various interesting bugs at least in the > fat driver. It also (the root filesystem special case) has a tendency to give misleading error messages which cost me a number of lost hours and grey hairs in my previous job. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 22:51:51 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 552F316A4DF; Tue, 11 Jul 2006 22:51:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B3E543D68; Tue, 11 Jul 2006 22:51:49 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 54C8046B98; Tue, 11 Jul 2006 18:51:49 -0400 (EDT) Date: Tue, 11 Jul 2006 23:51:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20060711162953.GC20418@odin.ac.hmc.edu> Message-ID: <20060711234931.P14749@fledge.watson.org> References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> <20060710160441.GB31026@odin.ac.hmc.edu> <20060710202714.GC16054@heff.fud.org.nz> <20060711162953.GC20418@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andre Oppermann , Andrew Thompson , freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 11 Jul 2006 22:51:51 -0000 On Tue, 11 Jul 2006, Brooks Davis wrote: >>> Unless cause ifconfig to autoload all if_ modules when cloning fails, it's >>> impossiable to support this without having if_vlan loaded. That said the >>> current plan it to eliminate if_vlan and integrate vlan support directly >>> into if_ethersubr.c to allow use to correctly handle the default vlan case >>> among otherthings. >> >> Is anyone working on this? The bridge code needs access to the vlan tag to >> properly hash the address as each vlan is a seperate broadcast domain, this >> would be much easier with vlan merged to if_ethersubr.c. > > I think it ended up with Robert's name on it at the last devsummit, but he's > got a lot of higher priority stuff on his plate. It doesn't look like this > change would be all that much work. The one thing that might be worth > investigating is seeing if there's a sane way to make vlan tag parsing part > of ether_input, but keep if_vlan.c around as a module for actual support of > trunks so we get most of the architectural benefits of correctly treating > vlan tags as part of the spec, but let embedded users who don't need trunks > avoid the overhead. Yes -- the specific proposal I have made is that we combine if_vlan.c into if_ethersubr.c, as well as LLC encapsulation decapsulation. Vlans and LLC bits are all considered standard ethernet features today, and integrating the basic support (regardless of virtual interfaces) into if_ethersubr.c makes sense. It would also make the book keeping and event handling go a bit more naturally, I think. I've not had a chance to prototype this to explore what the above words actually mean, so I think some experimental prototyping is called for. It's on my todo list but something I'm likely not to get to for a few months, so if someone else wants to look into this, I think that would be great. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 23:29:34 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D40616A4E0 for ; Tue, 11 Jul 2006 23:29:34 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt8.ihug.co.nz (grunt8.ihug.co.nz [203.109.254.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D2C343D5A for ; Tue, 11 Jul 2006 23:29:33 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt8.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1G0RfW-0004rR-00; Wed, 12 Jul 2006 11:29:31 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id BEB3B1CC22; Wed, 12 Jul 2006 11:29:32 +1200 (NZST) Date: Wed, 12 Jul 2006 11:29:32 +1200 From: Andrew Thompson To: Robert Watson Message-ID: <20060711232932.GB62353@heff.fud.org.nz> References: <44B15511.206@errno.com> <44B21551.5050002@freebsd.org> <20060710160441.GB31026@odin.ac.hmc.edu> <20060710202714.GC16054@heff.fud.org.nz> <20060711162953.GC20418@odin.ac.hmc.edu> <20060711234931.P14749@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711234931.P14749@fledge.watson.org> User-Agent: Mutt/1.5.11 Cc: Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: vlans and cloning 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, 11 Jul 2006 23:29:34 -0000 On Tue, Jul 11, 2006 at 11:51:49PM +0100, Robert Watson wrote: > On Tue, 11 Jul 2006, Brooks Davis wrote: > > >>>Unless cause ifconfig to autoload all if_ modules when cloning fails, > >>>it's impossiable to support this without having if_vlan loaded. That > >>>said the current plan it to eliminate if_vlan and integrate vlan support > >>>directly into if_ethersubr.c to allow use to correctly handle the > >>>default vlan case among otherthings. > >> > >>Is anyone working on this? The bridge code needs access to the vlan tag > >>to properly hash the address as each vlan is a seperate broadcast domain, > >>this would be much easier with vlan merged to if_ethersubr.c. > > > >I think it ended up with Robert's name on it at the last devsummit, but > >he's got a lot of higher priority stuff on his plate. It doesn't look > >like this change would be all that much work. The one thing that might be > >worth investigating is seeing if there's a sane way to make vlan tag > >parsing part of ether_input, but keep if_vlan.c around as a module for > >actual support of trunks so we get most of the architectural benefits of > >correctly treating vlan tags as part of the spec, but let embedded users > >who don't need trunks avoid the overhead. > > Yes -- the specific proposal I have made is that we combine if_vlan.c into > if_ethersubr.c, as well as LLC encapsulation decapsulation. Vlans and LLC > bits are all considered standard ethernet features today, and integrating > the basic support (regardless of virtual interfaces) into if_ethersubr.c > makes sense. It would also make the book keeping and event handling go a > bit more naturally, I think. I've not had a chance to prototype this to > explore what the above words actually mean, so I think some experimental > prototyping is called for. It's on my todo list but something I'm likely > not to get to for a few months, so if someone else wants to look into this, > I think that would be great. This is something I can start working on, all keep the interested parties informed. Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jul 11 19:16:09 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3456316A528 for ; Tue, 11 Jul 2006 19:16:09 +0000 (UTC) (envelope-from don_b_vu@yahoo.com) Received: from web36512.mail.mud.yahoo.com (web36512.mail.mud.yahoo.com [209.191.85.12]) by mx1.FreeBSD.org (Postfix) with SMTP id D2B2443D45 for ; Tue, 11 Jul 2006 19:16:07 +0000 (GMT) (envelope-from don_b_vu@yahoo.com) Received: (qmail 21199 invoked by uid 60001); 11 Jul 2006 19:16:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MqF0lKEoQsLyUAFvl4GG0320uvKQ7GoAr5DMTdN1XR5t5OwEUEcDbvMJSuPeJEFnCLrzG4JgHfbrFv2Q5NRZTGPq4TqWNreBGxpcBR7vKVLMU1l+G2ysEkQva+00kzyw8ittpVWlJZlL4Roh+4GB85b7QBrLBuOtLcdBQvZwKF8= ; Message-ID: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> Received: from [24.227.133.45] by web36512.mail.mud.yahoo.com via HTTP; Tue, 11 Jul 2006 12:16:07 PDT Date: Tue, 11 Jul 2006 12:16:07 -0700 (PDT) From: Don Vu To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 12 Jul 2006 00:05:59 +0000 Cc: Subject: FreeBSD support for Mac OS X platform 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, 11 Jul 2006 19:16:09 -0000 Will there be software to incorporate Fogbugz and CVS on the Mac OS X platform? Thanks in advance Don Vu Software Engineer Geocenter, Inc. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-arch@FreeBSD.ORG Wed Jul 12 02:38:22 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C065516A4DD for ; Wed, 12 Jul 2006 02:38:22 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 843B843D45 for ; Wed, 12 Jul 2006 02:38:22 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 6E62B2DAD; Tue, 11 Jul 2006 21:38:21 -0500 (CDT) Date: Tue, 11 Jul 2006 21:38:21 -0500 To: Don Vu Message-ID: <20060712023821.GA18586@soaustin.net> References: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-arch@FreeBSD.org Subject: Re: FreeBSD support for Mac OS X platform 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, 12 Jul 2006 02:38:22 -0000 On Tue, Jul 11, 2006 at 12:16:07PM -0700, Don Vu wrote: > Will there be software to incorporate Fogbugz and CVS > on the Mac OS X platform? Although Mac OS X shares some code with FreeBSD, they are very different operating systems. You'll need to ask in a forum specifically dedicated to OS X. mcl From owner-freebsd-arch@FreeBSD.ORG Wed Jul 12 03:48:35 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 602CE16A4DA for ; Wed, 12 Jul 2006 03:48:35 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from omta01ps.mx.bigpond.com (omta01ps.mx.bigpond.com [144.140.82.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB64143D45 for ; Wed, 12 Jul 2006 03:48:33 +0000 (GMT) (envelope-from andrew@areilly.bpa.nu) Received: from areilly.bpa.nu ([141.168.7.22]) by omta01ps.mx.bigpond.com with ESMTP id <20060712034832.BJPF20327.omta01ps.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 12 Jul 2006 03:48:32 +0000 Received: (qmail 34087 invoked by uid 501); 12 Jul 2006 03:48:32 -0000 Date: Wed, 12 Jul 2006 13:48:32 +1000 From: Andrew Reilly To: Don Vu Message-ID: <20060712034832.GA33934@duncan.reilly.home> References: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@FreeBSD.org Subject: Re: FreeBSD support for Mac OS X platform 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, 12 Jul 2006 03:48:35 -0000 As others have pointed out, FreeBSD isn't really a Mac OS X support site. However, On Tue, Jul 11, 2006 at 12:16:07PM -0700, Don Vu wrote: > Will there be software to incorporate Fogbugz and CVS > on the Mac OS X platform? I have to say that this is a very strange question. I suspect that you actually wanted to ask some different question, so go ahead and have another try (privately, perhaps, if you don't want to annoy the FreeBSD-arch list again). It's strange because (a) Mac OS X has cvs installed out of the box, in /usr/bin/cvs. It's version 1.11.20, wich is a good bit *more* recent than the version 1.11.17 that FreeBSD is still using (why? incompatabilities with developers' pet scripts?) and (b) ten seconds of googling shows that Frogbugz is commercial software that supports Mac OS X (according to the system requirements web page). (There also seems to be a FreeBSD version, so I guess that the question isn't so totally out there...) So: what was it, exactly, that you were hoping the FreeBSD community might be able to do for you? Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Thu Jul 13 11:03:35 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94B7316A4E1; Thu, 13 Jul 2006 11:03:35 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB09A43D46; Thu, 13 Jul 2006 11:03:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id A91703295A8; Thu, 13 Jul 2006 21:03:33 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6DB3QSd011182; Thu, 13 Jul 2006 21:03:27 +1000 Date: Thu, 13 Jul 2006 21:03:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <20060711124356.Y78628@fledge.watson.org> Message-ID: <20060713204716.D23325@delplex.bde.org> References: <20060708152801.GA3671@crodrigues.org> <44AFD7DF.8090002@errno.com> <20060708174606.GA29602@infradead.org> <44B2A51A.4040103@samsco.org> <20060710202219.GA29786@infradead.org> <20060711124356.Y78628@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , Scott Long , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [RFC] mount can figure out fstype automatically 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, 13 Jul 2006 11:03:35 -0000 On Tue, 11 Jul 2006, Robert Watson wrote: > In both FreeBSD and Darwin, I've noticed that the kernel msdosfs code is > excessively permissive as to what it considers a FAT file system. This is > presumably necessary due to the enourmous diversity of FAT file systems > floating around, but it makes it a little too easy to cause msdos to trip > over layouts that violate its layout assumptions. :-) FAT is much more > reliably detected by looking at the partition type it lives in than by > looking at the bytes that appear inside the partition, I believe. Um, most msdosfs file systems are on floppies so they don't even have a partition. Msdosfs can be very reliably detected from the bpb provided the bpb isn't uncleared garbage left from a previous file system, but the checks aren't very cocomplete and people keep relaxing them. In the old version that I use, the checks are mainly: % #ifndef MSDOSFS_NOCHECKSIG % if (bsp->bs50.bsBootSectSig0 != BOOTSIG0 % || bsp->bs50.bsBootSectSig1 != BOOTSIG1) { % error = EINVAL; % goto error_exit; % } % #endif Was relaxed. % [... a few too many assignments before checking anything] % /* XXX - We should probably check more values here */ % if (!pmp->pm_BytesPerSec || !SecPerClust % || !pmp->pm_Heads % #ifdef PC98 % || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 255) { % #else % || !pmp->pm_SecPerTrack || pmp->pm_SecPerTrack > 63) { % #endif % error = EINVAL; % goto error_exit; % } Not a very good check. % if (pmp->pm_Sectors == 0) { % pmp->pm_HiddenSects = getulong(b50->bpbHiddenSecs); % pmp->pm_HugeSectors = getulong(b50->bpbHugeSectors); % } else { % pmp->pm_HiddenSects = getushort(b33->bpbHiddenSecs); % pmp->pm_HugeSectors = pmp->pm_Sectors; % } Not a consistency check, but how the extension works. % if (pmp->pm_HugeSectors > 0xffffffff / % (pmp->pm_BytesPerSec / sizeof(struct direntry)) + 1) { % /* % * We cannot deal currently with this size of disk % * due to fileid limitations (see msdosfs_getattr and % * msdosfs_readdir) % */ % error = EINVAL; % printf("mountmsdosfs(): disk too big, sorry\n"); % goto error_exit; % } Consistency check only as a side effect. % % if (pmp->pm_RootDirEnts == 0) { % if (bsp->bs710.bsBootSectSig2 != BOOTSIG2 % || bsp->bs710.bsBootSectSig3 != BOOTSIG3 % || pmp->pm_Sectors % || pmp->pm_FATsecs % || getushort(b710->bpbFSVers)) { % error = EINVAL; % printf("mountmsdosfs(): bad FAT32 filesystem\n"); % goto error_exit; % } Not a very good consistency check. % pmp->pm_fatmask = FAT32_MASK; % pmp->pm_fatmult = 4; % pmp->pm_fatdiv = 1; % pmp->pm_FATsecs = getulong(b710->bpbBigFATsecs); % if (getushort(b710->bpbExtFlags) & FATMIRROR) % pmp->pm_curfat = getushort(b710->bpbExtFlags) & FATNUM; % else % pmp->pm_flags |= MSDOSFS_FATMIRROR; % } else % pmp->pm_flags |= MSDOSFS_FATMIRROR; % % /* % * Check a few values (could do some more): % * - logical sector size: power of 2, >= block size % * - sectors per cluster: power of 2, >= 1 % * - number of sectors: >= 1, <= size of partition % * - number of FAT sectors: >= 1 % */ % if ( (SecPerClust == 0) % || (SecPerClust & (SecPerClust - 1)) % || (pmp->pm_BytesPerSec < DEV_BSIZE) % || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1)) % || (pmp->pm_HugeSectors == 0) % || (pmp->pm_FATsecs == 0) % ) { % error = EINVAL; % goto error_exit; % } More not very good consistency checks. Better checks would determine the location of the FAT and root directory and check that is there. % if (pmp->pm_fatmask == 0) { % if (pmp->pm_maxcluster % <= ((CLUST_RSRVD - CLUST_FIRST) & FAT12_MASK)) { % /* % * This will usually be a floppy disk. This size makes % * sure that one fat entry will not be split across % * multiple blocks. % */ % pmp->pm_fatmask = FAT12_MASK; % pmp->pm_fatmult = 3; % pmp->pm_fatdiv = 2; % } else { % pmp->pm_fatmask = FAT16_MASK; % pmp->pm_fatmult = 2; % pmp->pm_fatdiv = 1; % } % } We do check the FAT, but default to FAT16 if it doesn't lool like FAT12. % [... a few more] Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Jul 13 11:15:00 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81D6416A4DA for ; Thu, 13 Jul 2006 11:15:00 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81EA943D46 for ; Thu, 13 Jul 2006 11:14:59 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (wtcfqp@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k6DBEqP5067293 for ; Thu, 13 Jul 2006 13:14:57 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k6DBEqQ6067292; Thu, 13 Jul 2006 13:14:52 +0200 (CEST) (envelope-from olli) Date: Thu, 13 Jul 2006 13:14:52 +0200 (CEST) Message-Id: <200607131114.k6DBEqQ6067292@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG In-Reply-To: <20060710193005.GA34287@crodrigues.org> X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 13 Jul 2006 13:14:57 +0200 (CEST) Cc: Subject: Re: [RFC] mount can figure out fstype automatically X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-arch@FreeBSD.ORG List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 11:15:00 -0000 Sorry for re-posting this, but I only posted to the -current list ... now I'm seeing that the real discussion seems to take place here on -arch. Craig Rodrigues wrote: > Scott Long wrote: > > So in your opinion and experience, what are the pros and cons of > > maintaining a table of magic numbers? > > One con: every time you add a new filesystem, you need to update > mount(8). Not a big deal, but it is something. How about this idea: Every filesystem registers a piece of "magic information" somewhere (maybe kenv or sysctl, or even a file somewhere in /etc or whatever). Then mount(8) just has to look at that list, compare in turn with the device in question, and call the respective filesystem if found (if the mount fails even though the magic matched, mount(8) could print a warning and continue looking at the remaining filesystems' magics). If a new filesystem is added, it registers its magic as explained above. No need to update mount(8) itself. For the case where multiple filesystems can share their structures (like UDF + ISO9660), a priority code could be assigned, so that the filesystem that's "more useful" (or more popular) is probed first. Also, filesystems that are difficult to recognize (like FAT) would get a low priority code, so they are probed last. Note that the user can always override the selection by manually specifying the filesystem with the -t flag of mount(8), so there shouldn't be any regression. Just my 2 cents. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 10:03:07 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5766A16A4E0; Fri, 14 Jul 2006 10:03:07 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2F4843D45; Fri, 14 Jul 2006 10:03:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id AB4F5496F1; Fri, 14 Jul 2006 12:03:04 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 8DE889BF57; Fri, 14 Jul 2006 10:03:33 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 5A0E8405A; Fri, 14 Jul 2006 12:03:33 +0200 (CEST) Date: Fri, 14 Jul 2006 12:03:33 +0200 From: Jeremie Le Hen To: Robert Watson Message-ID: <20060714100333.GE3466@obiwan.tataz.chchile.org> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060608123125.W26068@fledge.watson.org> User-Agent: Mutt/1.5.11 Cc: Alex Lyashkov , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: [fbsd] Re: jail extensions 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, 14 Jul 2006 10:03:07 -0000 Hi, On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: > On Wed, 7 Jun 2006, Brooks Davis wrote: > > >It's not clear to me that we want to use the same containers to control > >all resouces since you might want a set of jails sharing IPC resources or > >being allocated a slice of processor time to divide amongst them selves if > >we had a hierarchical scheduler. That said, using a single prison > >structure could do this if we allowed the administrator to specifiy a > >hierarchy of prisons and not necessicairly enclose all resources in all > >prisons. > > When looking at improved virtualization support for things like System V > IPC, my opinion has generally been that we introduce virtualization as a > primitive, and then have jail use the primitive much in the same way it > does chroot. This leaves flexibility to use it without jail, etc, but means > we have a well-understood and well-defined interaction with jail. IMHO, it is worth having virtualization primitives wherever it is required and make jails use them. This can be the case for the System V IPC as well as for the network stack (think of Marko's work). My point is that the usability of virtual network stacks remains interesting outside the jail framework and should be able to be managed from its own userland tool (though the latter should probably not be able to destroy a virtual network stack associated with a jail). However I don't think that IPC are worth virtualizing outside a jail framework. My two cents. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 16:22:17 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC16F16A4DE; Fri, 14 Jul 2006 16:22:17 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C85643D49; Fri, 14 Jul 2006 16:22:16 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060714162205m92002sasme>; Fri, 14 Jul 2006 16:22:15 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k6EGM1jk076525; Fri, 14 Jul 2006 11:22:01 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k6EGLsgu076511; Fri, 14 Jul 2006 11:21:54 -0500 (CDT) (envelope-from brooks) Date: Fri, 14 Jul 2006 11:21:54 -0500 From: Brooks Davis To: Jeremie Le Hen Message-ID: <20060714162154.GA75657@lor.one-eyed-alien.net> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> <20060714100333.GE3466@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <20060714100333.GE3466@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.11 Cc: Alex Lyashkov , Robert Watson , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: [fbsd] Re: jail extensions 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, 14 Jul 2006 16:22:18 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote: > Hi, >=20 > On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: > > On Wed, 7 Jun 2006, Brooks Davis wrote: > >=20 > > >It's not clear to me that we want to use the same containers to contro= l=20 > > >all resouces since you might want a set of jails sharing IPC resources= or=20 > > >being allocated a slice of processor time to divide amongst them selve= s if=20 > > >we had a hierarchical scheduler. That said, using a single prison=20 > > >structure could do this if we allowed the administrator to specifiy a= =20 > > >hierarchy of prisons and not necessicairly enclose all resources in al= l=20 > > >prisons. > >=20 > > When looking at improved virtualization support for things like System = V=20 > > IPC, my opinion has generally been that we introduce virtualization as = a=20 > > primitive, and then have jail use the primitive much in the same way it= =20 > > does chroot. This leaves flexibility to use it without jail, etc, but m= eans=20 > > we have a well-understood and well-defined interaction with jail. >=20 > IMHO, it is worth having virtualization primitives wherever it is > required and make jails use them. This can be the case for the > System V IPC as well as for the network stack (think of Marko's work). >=20 > My point is that the usability of virtual network stacks remains > interesting outside the jail framework and should be able to be managed > from its own userland tool (though the latter should probably not be > able to destroy a virtual network stack associated with a jail). > However I don't think that IPC are worth virtualizing outside a > jail framework. I could definitly use the ability to virtualize IPC inside a lighter container then a jail. I'd like to be able to tie them to jobs in a batch system managed by Sun Grid Engine so I can constrain resources on a per-job basis and insure the no IPC objects outlive the job. -- Brooks --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEt8ShXY6L6fI4GtQRAkpSAKC1igSpM/x/luhXU0HmthTxB+HO7gCdG4uR 7wABUyF7TT8rWyjwUalNZ78= =YTF8 -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 20:44:28 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0334416A4DA; Fri, 14 Jul 2006 20:44:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACD7F43D46; Fri, 14 Jul 2006 20:44:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 14 Jul 2006 13:44:27 -0700 Message-ID: <44B8022A.60104@elischer.org> Date: Fri, 14 Jul 2006 13:44:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> <20060714100333.GE3466@obiwan.tataz.chchile.org> <20060714162154.GA75657@lor.one-eyed-alien.net> In-Reply-To: <20060714162154.GA75657@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , Alex Lyashkov , Jeremie Le Hen , freebsd-arch@freebsd.org Subject: Re: [fbsd] Re: jail extensions 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, 14 Jul 2006 20:44:28 -0000 Brooks Davis wrote: >On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote: > > >>Hi, >> >>On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: >> >> >>>On Wed, 7 Jun 2006, Brooks Davis wrote: >>> >>> >>> >>>>It's not clear to me that we want to use the same containers to control >>>>all resouces since you might want a set of jails sharing IPC resources or >>>>being allocated a slice of processor time to divide amongst them selves if >>>>we had a hierarchical scheduler. That said, using a single prison >>>>structure could do this if we allowed the administrator to specifiy a >>>>hierarchy of prisons and not necessicairly enclose all resources in all >>>>prisons. >>>> >>>> >>>When looking at improved virtualization support for things like System V >>>IPC, my opinion has generally been that we introduce virtualization as a >>>primitive, and then have jail use the primitive much in the same way it >>>does chroot. This leaves flexibility to use it without jail, etc, but means >>>we have a well-understood and well-defined interaction with jail. >>> >>> >>IMHO, it is worth having virtualization primitives wherever it is >>required and make jails use them. This can be the case for the >>System V IPC as well as for the network stack (think of Marko's work). >> >>My point is that the usability of virtual network stacks remains >>interesting outside the jail framework and should be able to be managed >>from its own userland tool (though the latter should probably not be >>able to destroy a virtual network stack associated with a jail). >>However I don't think that IPC are worth virtualizing outside a >>jail framework. >> >> > >I could definitly use the ability to virtualize IPC inside a lighter >container then a jail. I'd like to be able to tie them to jobs in a >batch system managed by Sun Grid Engine so I can constrain resources on >a per-job basis and insure the no IPC objects outlive the job. > >-- Brooks > > I think that the term "jail" needs to be replaced by something else in this context.. maybe a "virtual context".. virtual contexts would have the option of virtualising different parts of the system. for example they would have the option of whether or not to have a chroot, or their own networking stack, or their own process space.. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 14 23:25:21 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E42C116A4DE; Fri, 14 Jul 2006 23:25:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA7243D49; Fri, 14 Jul 2006 23:25:20 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20060714232515m92002sg5ee>; Fri, 14 Jul 2006 23:25:19 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.6/8.13.6) with ESMTP id k6ENPBeZ079979; Fri, 14 Jul 2006 18:25:11 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.6/8.13.6/Submit) id k6ENP4TN079978; Fri, 14 Jul 2006 18:25:04 -0500 (CDT) (envelope-from brooks) Date: Fri, 14 Jul 2006 18:25:04 -0500 From: Brooks Davis To: Julian Elischer Message-ID: <20060714232504.GA79925@lor.one-eyed-alien.net> References: <1149610678.4074.42.camel@berloga.shadowland> <448633F2.7030902@elischer.org> <20060607095824.W53690@fledge.watson.org> <200606070819.04301.jhb@freebsd.org> <20060607160850.GB18940@odin.ac.hmc.edu> <20060608123125.W26068@fledge.watson.org> <20060714100333.GE3466@obiwan.tataz.chchile.org> <20060714162154.GA75657@lor.one-eyed-alien.net> <44B8022A.60104@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <44B8022A.60104@elischer.org> User-Agent: Mutt/1.5.11 Cc: Robert Watson , Alex Lyashkov , Jeremie Le Hen , freebsd-arch@freebsd.org Subject: Re: [fbsd] Re: jail extensions 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, 14 Jul 2006 23:25:21 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 14, 2006 at 01:44:26PM -0700, Julian Elischer wrote: > Brooks Davis wrote: >=20 > >On Fri, Jul 14, 2006 at 12:03:33PM +0200, Jeremie Le Hen wrote: > >=20 > >>On Thu, Jun 08, 2006 at 12:32:42PM +0100, Robert Watson wrote: > >> =20 > >>>On Wed, 7 Jun 2006, Brooks Davis wrote: > >>> > >>>>It's not clear to me that we want to use the same containers to contr= ol=20 > >>>>all resouces since you might want a set of jails sharing IPC resource= s=20 > >>>>or being allocated a slice of processor time to divide amongst them= =20 > >>>>selves if we had a hierarchical scheduler. That said, using a single= =20 > >>>>prison structure could do this if we allowed the administrator to=20 > >>>>specifiy a hierarchy of prisons and not necessicairly enclose all=20 > >>>>resources in all prisons. > >>>> =20 > >>>When looking at improved virtualization support for things like System= V=20 > >>>IPC, my opinion has generally been that we introduce virtualization as= a=20 > >>>primitive, and then have jail use the primitive much in the same way i= t=20 > >>>does chroot. This leaves flexibility to use it without jail, etc, but= =20 > >>>means we have a well-understood and well-defined interaction with jail. > >>> =20 > >>IMHO, it is worth having virtualization primitives wherever it is > >>required and make jails use them. This can be the case for the > >>System V IPC as well as for the network stack (think of Marko's work). > >> > >>My point is that the usability of virtual network stacks remains > >>interesting outside the jail framework and should be able to be managed > >>from its own userland tool (though the latter should probably not be > >>able to destroy a virtual network stack associated with a jail). > >>However I don't think that IPC are worth virtualizing outside a > >>jail framework. > >> =20 > >> > > > >I could definitly use the ability to virtualize IPC inside a lighter > >container then a jail. I'd like to be able to tie them to jobs in a > >batch system managed by Sun Grid Engine so I can constrain resources on > >a per-job basis and insure the no IPC objects outlive the job. > > > I think that the term "jail" needs to be replaced by something else in=20 > this context.. > maybe a "virtual context".. virtual contexts would have the option of=20 > virtualising > different parts of the system. > for example they would have the option of whether or not to have a=20 > chroot, or their own > networking stack, or their own process space.. This sounds good to me if we could do it in a way that performed decently. -- Brooks --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEuCfQXY6L6fI4GtQRAiHkAKCivKSr+Y3kZriX8bIHNsC1nNAFVgCdEvYs Dw6DWwJTJtiucNu0Rc6FJno= =phPD -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 15 11:35:14 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6BD816A4DD; Sat, 15 Jul 2006 11:35:14 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7A943D46; Sat, 15 Jul 2006 11:35:14 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k6FBYxOx047414; Sat, 15 Jul 2006 04:34:59 -0700 (PDT) Date: Sat, 15 Jul 2006 14:54:05 +0900 Message-ID: From: gnn@freebsd.org To: Robert Watson In-Reply-To: <20060618014337.V67789@fledge.watson.org> References: <20060618014337.V67789@fledge.watson.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.6.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: Proposal: add pru_close protosw method, refactor abort/detach 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, 15 Jul 2006 11:35:14 -0000 At Sun, 18 Jun 2006 02:01:01 +0100 (BST), rwatson wrote: > > > Over the past 6-12 months, I've spent quite a bit of time working with our > socket and protocol locking and reference models. These efforts have been > aimed at a couple of things: Apologies for the length of time I let this sit. > Attached is a patch that attempts to further rationalize tear-down. > Specifically, it refactors pru_detach (disconnect and conditionally > free) and pru_abort (disconnect abruptly and free) into three > protocol switch functions: > > pru_close: socket has been closed and a sensible shutdown without > data loss is desired. > > pru_abort: socket is being aborted, generally due to insufficient queue space > in a listen socket, or close of a listen socket while connections are waiting > to be accepted: close abruptly and potentially with data loss. > > pru_detach: teardown is now unconditional -- both the protocol and socket are > done. > This to me is a sensible approach and if it works for both TCP and SCTP then I suspect it should work for other protocols which are less complicated. > The changes require protocol implementors to distinguish close and > deatch, which while generally clarifying for some protocols (such as > TCP, where the logic becomes much more clear), for others it has > never been clear how exactly close worked, and does not become > clearer. I believe your statements above are clear. Can you put similar, sensible comments in places where protocols implementors are likely to see them? > What I'm looking for: > > - yay/nay on this approach, and the general change in protosw > behavior. It does touch all protocols, but I think makes things > generally more sensible. this doesn't just support the > resock_vertical exploration, but also generally makes things more > sensible by moving towards a more typical constructor/destructor > and avoiding combining protocol state transitions with socket > state freeing. Yay. > - Review of the details of the patch. In particular, help deciding > if my splitting up of events between pru_abort, pru_close, and > pru_detach for each protocol is right. It "looks" OK. Is there a branch you have that I can create a p4 client for and do my usual NetPIPE style abuse testing? I have been trying to make a nightly test script for NetPIPE so it might be a good thing to try on this branch. Later, George