From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 11:06:55 2008 Return-Path: Delivered-To: freebsd-arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD69F106566B for ; Mon, 7 Apr 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B40A28FC21 for ; Mon, 7 Apr 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m37B6tbF048718 for ; Mon, 7 Apr 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m37B6trr048714 for freebsd-arch@FreeBSD.org; Mon, 7 Apr 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2008 11:06:55 GMT Message-Id: <200804071106.m37B6trr048714@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 11:06:55 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 18:30:23 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E57C2106566B; Mon, 7 Apr 2008 18:30:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 76B3C8FC25; Mon, 7 Apr 2008 18:30:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 9A07A28449; Tue, 8 Apr 2008 02:30:21 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 4016EEBB9FF; Tue, 8 Apr 2008 02:30:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id YZ4AEy+G7u9r; Tue, 8 Apr 2008 02:30:16 +0800 (CST) Received: from LI-Xins-MacBook.local (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 90E2BEBB9C9; Tue, 8 Apr 2008 02:30:15 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=BWk9Hp8qM5d637J1fUwdaXRGh1OYaTgZzE5l6EX0Qfe3OhRmrv4ojqSpXZvbYGKGE tRH/GiJifJQvWcERprTLQ== Message-ID: <47FA6833.8080904@delphij.net> Date: Mon, 07 Apr 2008 11:30:11 -0700 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <20080407181250.6733810656C9@hub.freebsd.org> In-Reply-To: <20080407181250.6733810656C9@hub.freebsd.org> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0160B57ADC3280A9343DD942" Cc: delphij@FreeBSD.ORG Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 18:30:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0160B57ADC3280A9343DD942 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Picking a random commit: > FreeBSD src repository >=20 > Modified files: > sys/ufs/ufs ufs_gjournal.c=20 > Log: > Correct function name in panic(). > =20 > Reported by: kensmith > =20 > Revision Changes Path > 1.3 +1 -1 src/sys/ufs/ufs/ufs_gjournal.c > _______________________________________________ > cvs-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-all > To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" >=20 >=20 > Index: src/sys/ufs/ufs/ufs_gjournal.c > diff -u src/sys/ufs/ufs/ufs_gjournal.c:1.2 src/sys/ufs/ufs/ufs_gjournal= =2Ec:1.3 > --- src/sys/ufs/ufs/ufs_gjournal.c:1.2 Mon May 28 00:28:15 2007 > +++ src/sys/ufs/ufs/ufs_gjournal.c Mon Apr 7 18:12:37 2008 > @@ -82,7 +82,7 @@ > cgbno =3D fsbtodb(fs, cgtod(fs, cg)); > } > if ((u_int)ino >=3D fs->fs_ipg * fs->fs_ncg) > - panic("ffs_freefile: range: dev =3D %s, ino =3D %lu, fs =3D %s", > + panic("ufs_gjournal_modref: range: dev =3D %s, ino =3D %lu, fs =3D %= s", > devtoname(dev), (u_long)ino, fs->fs_fsmnt); > if ((error =3D bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, &bp)))= { > brelse(bp); Is it suitable to use something like __func__ here? I mean, will the=20 usage of __func__ encouraged practice for base/kernel code or not? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig0160B57ADC3280A9343DD942 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+mgzOfuToMruuMARCmFcAJsEWl5kqDgehV1wWWnbZ1Rdu8smqACfSmvG /V3tE/pUv/+lUXj51rQge+w= =8te6 -----END PGP SIGNATURE----- --------------enig0160B57ADC3280A9343DD942-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 18:48:34 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9F85106566B; Mon, 7 Apr 2008 18:48:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.72]) by mx1.freebsd.org (Postfix) with ESMTP id A1E9C8FC22; Mon, 7 Apr 2008 18:48:34 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp006-s [10.150.69.69]) by smtpoutm.mac.com (Xserve/smtpout009/MantshX 4.0) with ESMTP id m37IYLRO010019; Mon, 7 Apr 2008 11:34:27 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp006/MantshX 4.0) with ESMTP id m37IYJnh004932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Apr 2008 11:34:19 -0700 (PDT) Message-Id: <970636D8-F789-44EE-864D-49489D17D7D9@mac.com> From: Marcel Moolenaar To: d@delphij.net In-Reply-To: <47FA6833.8080904@delphij.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 7 Apr 2008 11:33:56 -0700 References: <20080407181250.6733810656C9@hub.freebsd.org> <47FA6833.8080904@delphij.net> X-Mailer: Apple Mail (2.919.2) Cc: delphij@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2008 18:48:34 -0000 On Apr 7, 2008, at 11:30 AM, LI Xin wrote: > Picking a random commit: > >> Index: src/sys/ufs/ufs/ufs_gjournal.c >> diff -u src/sys/ufs/ufs/ufs_gjournal.c:1.2 src/sys/ufs/ufs/ >> ufs_gjournal.c:1.3 >> --- src/sys/ufs/ufs/ufs_gjournal.c:1.2 Mon May 28 00:28:15 2007 >> +++ src/sys/ufs/ufs/ufs_gjournal.c Mon Apr 7 18:12:37 2008 >> @@ -82,7 +82,7 @@ >> cgbno = fsbtodb(fs, cgtod(fs, cg)); >> } >> if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg) >> - panic("ffs_freefile: range: dev = %s, ino = %lu, fs = %s", >> + panic("ufs_gjournal_modref: range: dev = %s, ino = %lu, fs = %s", >> devtoname(dev), (u_long)ino, fs->fs_fsmnt); >> if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, >> &bp))) { >> brelse(bp); > > Is it suitable to use something like __func__ here? I mean, will > the usage of __func__ encouraged practice for base/kernel code or not? Speaking only for myself: yes, __func__ should be used at all times when the function name is needed... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 19:27:13 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4464A106566B for ; Mon, 7 Apr 2008 19:27:13 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.245]) by mx1.freebsd.org (Postfix) with ESMTP id F260D8FC0A for ; Mon, 7 Apr 2008 19:27:07 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by hs-out-0708.google.com with SMTP id m63so1150825hsc.11 for ; Mon, 07 Apr 2008 12:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=39xUhQPtM3KWFhOjFVI7+IlbemBSewY2T9jprnw/xD8=; b=hYyULJwgk6FHjPT1kIJ21Im3B3KdIav7akynkKpA3Lxco6zFoe/NiP+Ba+kEetR50+yJ0n2Hy6lG3FdXf/TwIVHlkFzHefAEKTfE8/RwEAwXERjy6B+zwJnSTOGObz+BXkPO5XGbiZtEMQ+mnepOhVwcxp3V2my/j74S5WPeSXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GniwlGY9c8JcUd5F4KDta6LVXl1q6mDNICG82NmZqF/y4N34WW8T5y9XOJ0jY/r265yP77blW/ke5WYUXGZF0abHjiydEtKkGRixZ8o+jQayTmu3LWWWaAm+xB2NWz2762tYQ1ujwEdcASHCNB3XLVchxelVOG6L7dJ/1PeLFbk= Received: by 10.100.152.5 with SMTP id z5mr11014688and.83.1207594878664; Mon, 07 Apr 2008 12:01:18 -0700 (PDT) Received: by 10.100.227.7 with HTTP; Mon, 7 Apr 2008 12:01:18 -0700 (PDT) Message-ID: <9a542da30804071201o520812f8w4fc413131c4140b0@mail.gmail.com> Date: Mon, 7 Apr 2008 21:01:18 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Question about network interface naming and devfs(5)! 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, 07 Apr 2008 19:27:13 -0000 Hello, it seems that devfs(5) is not consistent with network interface naming feature. Network interface naming is offered by ifconfig $interface name $name. This feature is really helpful to distinguish interfaces properly in a machine and helps in scripting things. The problem is that the ioctl that renames the device advertises it as an interface arrival event which devfs does not handle and such you have inconsistence between ifconfig output and the information in devfs. Are there any plans to fix this or is there any issue for not making devfs(5) aware of network interfaces events?! Ermal From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 20:25:26 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A0D5106564A for ; Mon, 7 Apr 2008 20:25:26 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4D58FC15 for ; Mon, 7 Apr 2008 20:25:25 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m37KPRsJ042355; Mon, 7 Apr 2008 15:25:27 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m37KPRh6042354; Mon, 7 Apr 2008 15:25:27 -0500 (CDT) (envelope-from brooks) Date: Mon, 7 Apr 2008 15:25:27 -0500 From: Brooks Davis To: Ermal Lu?i Message-ID: <20080407202527.GG28511@lor.one-eyed-alien.net> References: <9a542da30804071201o520812f8w4fc413131c4140b0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zGQnqpIoxlsbsOfg" Content-Disposition: inline In-Reply-To: <9a542da30804071201o520812f8w4fc413131c4140b0@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 07 Apr 2008 15:25:28 -0500 (CDT) Cc: freebsd-arch@freebsd.org Subject: Re: Question about network interface naming and devfs(5)! 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, 07 Apr 2008 20:25:26 -0000 --zGQnqpIoxlsbsOfg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 07, 2008 at 09:01:18PM +0200, Ermal Lu?i wrote: > Hello, >=20 > it seems that devfs(5) is not consistent with network interface naming fe= ature. >=20 > Network interface naming is offered by ifconfig $interface name $name. > This feature is really helpful to distinguish interfaces properly in a > machine and helps in scripting things. > The problem is that the ioctl that renames the device advertises it as > an interface arrival event which devfs does not handle and such you > have inconsistence between ifconfig output and the information in > devfs. >=20 > Are there any plans to fix this or is there any issue for not making > devfs(5) aware of network interfaces events?! I haven't dealt with it because a) there's no way to rename entries which currently means you've have to destroy the current entry and add a completely new one which would break applications using the devfs entries across renames and b) I think the devfs entries are a mistake and should die. -- Brooks --zGQnqpIoxlsbsOfg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFH+oM3XY6L6fI4GtQRApIRAKDLVECgTdMb6Ba/331rYq3lhtBl3wCgyFHV XwHgDF/q3lOwPFuMcr5imcI= =EwHx -----END PGP SIGNATURE----- --zGQnqpIoxlsbsOfg-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 7 21:40:28 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C350D1065672 for ; Mon, 7 Apr 2008 21:40:28 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 6B60D8FC1A for ; Mon, 7 Apr 2008 21:40:28 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so426508anc.13 for ; Mon, 07 Apr 2008 14:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=KS/1NYIfAl1v9sWfw+JAORehKe/uuh86Kw7Aitq+GF4=; b=nJxpaSu3EPJ0+65wIOdESjzgOGJlbhfW/8lyI9iAdSpwUTleEzxIdqRe9pdoOBwGRllXWwDxPYN/jCYnCgbRyUf8UH3ksvsqlVcHDzNNxhwX3sW+OS6LNxHmRaDCX+9SMXEaUl5KsjnusO6EdPXW5bqXXYwEBQIuE2jUVYStFkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ppa9Qhm67JfHStfd12+YkAXWCpvg8zhjrTS8kobm3SmrL0rqBZNNqa2weUu7T5GrmOqHq9kVScnvXJJ+GHpGMBRmlNnsdJF2VNeMQRf05UcpHuPz3eFYG2pqmz02KYoIIRmEYIpWfDsfGLgdAriElU40pJDkkHhHRqZFKAUR4nk= Received: by 10.100.110.16 with SMTP id i16mr11316097anc.40.1207604427645; Mon, 07 Apr 2008 14:40:27 -0700 (PDT) Received: by 10.100.227.7 with HTTP; Mon, 7 Apr 2008 14:40:27 -0700 (PDT) Message-ID: <9a542da30804071440i1d7b0c6cwbdc44625b94fb90e@mail.gmail.com> Date: Mon, 7 Apr 2008 23:40:27 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Brooks Davis" In-Reply-To: <20080407202527.GG28511@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a542da30804071201o520812f8w4fc413131c4140b0@mail.gmail.com> <20080407202527.GG28511@lor.one-eyed-alien.net> Cc: freebsd-arch@freebsd.org Subject: Re: Question about network interface naming and devfs(5)! 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, 07 Apr 2008 21:40:28 -0000 On Mon, Apr 7, 2008 at 10:25 PM, Brooks Davis wrote: > > On Mon, Apr 07, 2008 at 09:01:18PM +0200, Ermal Lu?i wrote: > > Hello, > > > > it seems that devfs(5) is not consistent with network interface naming feature. > > > > Network interface naming is offered by ifconfig $interface name $name. > > This feature is really helpful to distinguish interfaces properly in a > > machine and helps in scripting things. > > The problem is that the ioctl that renames the device advertises it as > > an interface arrival event which devfs does not handle and such you > > have inconsistence between ifconfig output and the information in > > devfs. > > > > Are there any plans to fix this or is there any issue for not making > > devfs(5) aware of network interfaces events?! > > I haven't dealt with it because a) there's no way to rename entries > which currently means you've have to destroy the current entry and add > a completely new one which would break applications using the devfs > entries across renames and b) I think the devfs entries are a mistake and > should die. Can't it be made to behave like a real file system?! Meaning to have reference count for its devices/entries so the entry/descriptor is kept open till the last close() is performed! Ermal > > -- Brooks > From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 08:42:43 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44604106564A; Tue, 8 Apr 2008 08:42:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id B9D1A8FC13; Tue, 8 Apr 2008 08:42:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m384prPr009919; Tue, 8 Apr 2008 14:51:53 +1000 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m384pUqJ017723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 14:51:35 +1000 Date: Tue, 8 Apr 2008 14:51:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <47FA6833.8080904@delphij.net> Message-ID: <20080408142942.B18072@delplex.bde.org> References: <20080407181250.6733810656C9@hub.freebsd.org> <47FA6833.8080904@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: delphij@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2008 08:42:43 -0000 On Mon, 7 Apr 2008, LI Xin wrote: > Picking a random commit: > >> FreeBSD src repository >> >> Modified files: >> sys/ufs/ufs ufs_gjournal.c Log: >> Correct function name in panic(). >> Reported by: kensmith >> Revision Changes Path >> 1.3 +1 -1 src/sys/ufs/ufs/ufs_gjournal.c >> if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg) >> - panic("ffs_freefile: range: dev = %s, ino = %lu, fs = %s", >> + panic("ufs_gjournal_modref: range: dev = %s, ino = %lu, fs = >> %s", >> devtoname(dev), (u_long)ino, fs->fs_fsmnt); >> if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, &bp))) { >> brelse(bp); > > Is it suitable to use something like __func__ here? I mean, will the usage > of __func__ encouraged practice for base/kernel code or not? No, __func__ is an obfuscation. It is sort of write-only. It should only be used when the function name is not a compile-time constant (mainly in macros). Its use would be an especially large style bug in ufs, since ufs consistently doesn't use it (except in 1 recently broken place). The above commit also breaks the style using blind substitution which happens to expand a line beyond 80 characters. Bruce From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 11:48:46 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2228A106566B; Tue, 8 Apr 2008 11:48:46 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id D7F838FC3C; Tue, 8 Apr 2008 11:48:45 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id B1F8CEA9A9; Tue, 8 Apr 2008 07:33:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 08 Apr 2008 07:33:17 -0400 X-Sasl-enc: 4SygQc4JI0z4FyVIVSxabNxABQPiLhHpDRQGrPVgrnsb 1207654397 Received: from [192.168.1.235] (76-191-150-176.dsl.dynamic.sonic.net [76.191.150.176]) by mail.messagingengine.com (Postfix) with ESMTPSA id CA52113A3B; Tue, 8 Apr 2008 07:33:16 -0400 (EDT) Message-ID: <47FB586F.90606@freebsd.org> Date: Tue, 08 Apr 2008 04:35:11 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Robert Watson References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> In-Reply-To: <20080317134335.A3253@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, freebsd-current@freebsd.org, "Christian S.J. Peron" Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 08 Apr 2008 11:48:46 -0000 Robert Watson wrote: > On Mon, 17 Mar 2008, Christian S.J. Peron wrote: > >> Just wanted to give a heads up that I plan to start merging the work >> located in the zerocopy bpf perforce branch. We have been working on >> this project for about a year now and feel that it is ready to come >> into the tree. >> >> I will begin to merge hopefully today [assuming nobody has any >> concerns] or tommorow. Zerocopy bpf will be disabled by default, and >> can be enabled globally though the use of a sysctl variable. Once the >> kernel bits are in and we sort out a couple minor nits in >> libpcap+tcpdump, we will be be looking at getting our libpcap patches >> committed upstream. I will post a patch for people to experiment >> with in the meantime after the kernel commits are complete. >> >> We do not anticipate this will have any effect on existing bpf >> consumers like libpcap, tcpdump etc... so if something breaks, it >> shouldn't have and we need to know about :) We were pretty careful >> about preserving the ABI. The only exception to this is, netstat will >> need a recompile because the size of it's bpf stats structure changed. >> >> So if there are any objections or concerns, now is the time to raise >> them. > > Per previous posts, interested parties can find the slides on the > design from the BSDCan 2008 developer summit here: > > > http://www.watson.org/~robert/freebsd/2007bsdcan/20070517-devsummit-zerocopybpf.pdf Is there a performance analysis of the copy vs zerocopy available? (I don't see one in the paper, just a "to do" item.) The numbers I'm interested in seeing are how many Mb/s you can capture before you start suffering packet loss. This needs to be done with sequenced packets so that you can observe gaps in the sequence captured. I kind of experimented with this back in 2004: http://mail-index.netbsd.org/tech-net/2004/05/02/0001.html http://mail-index.netbsd.org/tech-net/2004/05/21/0001.html Rather than map the user space memory into the kernel, I used mmap(2) to access the kernel's buffer from user space and then did the ioctl thing to move pointers. I also played with changing the size of the primary buffer to be smaller but to have more alternate buffers. So while one buffer was mapped out to the user space, one (or more) buffer(s) were available in the kernel. Speed improvement? Slight (less than 2%) in the testing I did. Why only slight? Because there's another factor here, and that's how long it takes to process the data that is in the buffer and free it up for the kernel. But then the time you gain from having more buffer space available in the kernel you lose (in part) to the management overhead. In the end I decided that change, while interesting, didn't really solve the problem which was that the speed at which capturing could be effectively done was bounded by the time spent analysing the data captured. If there are packets that you want to analyse arriving faster than you can do the analysis, then you will drop packets - end of story. So why isn't there a huge performance increase? My $0.2c... When using read(2) to get bpf data, you straight away transfer the data from the kernel to the user space buffer and that immediately free's up that buffer in the kernel for more capture. When you share the buffer between the kernel and user space, you either (1) delay kernel access to that buffer while you process all the contents, and if there any bits that you want to keep, then you need to copy them out or (2) do another copy from the shared buffer to a private buffer, releasing contention for the shared buffer but again doing a copy, so the end result is not much different. The problem with (1) is that you always have less buffer space available at the kernel level for storing packet data than you do without that segment "held" for user space activity. So even if you do a write(2) of the buffer used in (1) straight away, there is a delay in the turnaround time for the buffer of how even long your disk I/O takes to complete. And someone asked about packet capture direct to disk - too slow if you do it through a vnode with an eye on 10G. Heck, at 10G speeds, you need to be handling 2GB/sec - can any affordable disk write that fast? Why 2GB/sec? To successfully sniff a 10G stream, you need two 10G NICs, for a combined total of 20G incoming (remember, full duplex, 10G going in both direction... and you thought plugging your single NIC into any full-duplex monitor port on a switch was always enough....ha!) State of the art packet capture has moved to hardware assisted cards, such as those from Endace: http://www.endace.com/our-products/dag-network-monitoring-cards/ethernet If you want to get 10G capture on FreeBSD, get drivers for those cards made for FreeBSD. Those cards are absolutely necessary on Linux to get performance anywhere near FreeBSD"s ;) Darren From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 12:28:19 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB8210656A8; Tue, 8 Apr 2008 12:28: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 0CDD48FC12; Tue, 8 Apr 2008 12:28:18 +0000 (UTC) (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 6E98546B3F; Tue, 8 Apr 2008 08:28:18 -0400 (EDT) Date: Tue, 8 Apr 2008 13:28:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Darren Reed In-Reply-To: <47FB586F.90606@freebsd.org> Message-ID: <20080408132058.U10870@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <47FB586F.90606@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-current@freebsd.org, "Christian S.J. Peron" Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 08 Apr 2008 12:28:19 -0000 On Tue, 8 Apr 2008, Darren Reed wrote: > Is there a performance analysis of the copy vs zerocopy available? (I don't > see one in the paper, just a "to do" item.) > > The numbers I'm interested in seeing are how many Mb/s you can capture > before you start suffering packet loss. This needs to be done with > sequenced packets so that you can observe gaps in the sequence captured. We've done some analysis, and a couple of companies have the zero-copy BPF code deployed. I hope to generate a more detailed analysis before the developer summit so we can review it at BSDCan. The basic observation is that for quite a few types of network links, the win isn't in packet loss per se, but in reduced CPU use, freeing up CPU for other activities. There are a number of sources of win: - Reduced system call overhead -- as load increases, # system calls goes down, especially if you get a two-CPU pipeline going. - Reduced memory access, especially for larger buffer sizes, avoids filling the cache twice (first in copyout, then again in using the buffer in userspace). - Reduced lock contention, as only a single thread, the device driver ithread, is acquiring the bpf descriptor's lock, and it's no longer contending with the user thread. One interesting, and in retrospect reasonable, side effect is that user CPU time goes up in the SMP scenario, as cache misses on the BPF buffer move from the read() system call to userspace. And, as you observe, you have to use somewhat larger buffer sizes, as in the previous scenario there were three buffers: two kernel buffers and a user buffer, and now there are simply two kernel buffers shared directly with user space. The original committed version has a problem in that it allows only one kernel buffer to be "owned" by userspace at a time, which can lead to excess calls to select(); this has now been corrected, so if people have run performance benchmarks, they should update to the new code and re-run them. I don't have numbers off-hand, but 5%-25% were numbers that appeared in some of the measurements, and I'd like to think that the recent fix will further improve that. For 10gbps, something we need to think about is how to modify the structure of BPF to allow different BPF devices for different input queues... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 15:56:09 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C61C106566C for ; Tue, 8 Apr 2008 15:56:09 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 58B838FC1E for ; Tue, 8 Apr 2008 15:56:09 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m38Fu8vQ066809 for ; Tue, 8 Apr 2008 09:56:08 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m38Fu7GE026499; Tue, 8 Apr 2008 09:56:07 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m38Fu7NT026496; Tue, 8 Apr 2008 09:56:07 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18427.38295.399422.305048@gromit.timing.com> Date: Tue, 8 Apr 2008 09:56:07 -0600 From: John E Hein To: arch@freebsd.org In-Reply-To: <18427.36758.266944.74378@gromit.timing.com> References: <18427.36758.266944.74378@gromit.timing.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Subject: Re: tt_ioctl 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, 08 Apr 2008 15:56:09 -0000 John E Hein wrote at 09:30 -0600 on Apr 8, 2008: > Back in 2005-10, phk added the tt_{open,ioctl,etc.} inline calls in > sys/tty.h allowing drivers that hook into the tty layer a way to > override or supplement the basic tty functions with their own > flavoring. > > They were also connected up in kern/tty.c - well most of them. > > tt_ioctl remains unused. > > What about the following: Woops... updated patch for missing 'td' in ttyld_ioctl call... Index: kern/tty.c =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/kern/tty.c,v retrieving revision 1.275 diff -u -p -r1.275 tty.c --- kern/tty.c 19 Mar 2008 06:19:00 -0000 1.275 +++ kern/tty.c 8 Apr 2008 15:36:43 -0000 @@ -3297,7 +3297,9 @@ ttyioctl(struct cdev *dev, u_long cmd, c dt->c_ospeed = tp->t_ospeed; } - error = ttyld_ioctl(tp, cmd, data, flag, td); + error = tt_ioctl(tp, cmd, data, flag, td); + if (error == ENOIOCTL) + error = ttyld_ioctl(tp, cmd, data, flag, td); if (error == ENOIOCTL) error = ttioctl(tp, cmd, data, flag); ttyldoptim(tp); Index: sys/tty.h =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/sys/tty.h,v retrieving revision 1.102 diff -u -p -r1.102 tty.h --- sys/tty.h 16 Dec 2007 06:12:53 -0000 1.102 +++ sys/tty.h 8 Apr 2008 05:30:04 -0000 @@ -442,6 +442,8 @@ tt_ioctl(struct tty *t, u_long cmd, void int fflag, struct thread *td) { + if (t->t_ioctl == NULL) + return (ENOIOCTL); return (t->t_ioctl(t, cmd, data, fflag, td)); } From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 16:09:20 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E87E91065675 for ; Tue, 8 Apr 2008 16:09:20 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (ns2.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id B6B608FC14 for ; Tue, 8 Apr 2008 16:09:20 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m38FUUil063127; Tue, 8 Apr 2008 09:30:30 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m38FUU0j025905; Tue, 8 Apr 2008 09:30:30 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m38FUU8D025902; Tue, 8 Apr 2008 09:30:30 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18427.36758.266944.74378@gromit.timing.com> Date: Tue, 8 Apr 2008 09:30:30 -0600 From: John E Hein To: arch@freebsd.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: Subject: tt_ioctl 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, 08 Apr 2008 16:09:21 -0000 Back in 2005-10, phk added the tt_{open,ioctl,etc.} inline calls in sys/tty.h allowing drivers that hook into the tty layer a way to override or supplement the basic tty functions with their own flavoring. They were also connected up in kern/tty.c - well most of them. tt_ioctl remains unused. What about the following: Index: kern/tty.c =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/kern/tty.c,v retrieving revision 1.275 diff -u -p -r1.275 tty.c --- kern/tty.c 19 Mar 2008 06:19:00 -0000 1.275 +++ kern/tty.c 8 Apr 2008 05:37:22 -0000 @@ -3297,7 +3297,9 @@ ttyioctl(struct cdev *dev, u_long cmd, c dt->c_ospeed = tp->t_ospeed; } - error = ttyld_ioctl(tp, cmd, data, flag, td); + error = tt_ioctl(tp, cmd, data, flag, td); + if (error == ENOIOCTL) + error = ttyld_ioctl(tp, cmd, data, flag); if (error == ENOIOCTL) error = ttioctl(tp, cmd, data, flag); ttyldoptim(tp); Index: sys/tty.h =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/sys/tty.h,v retrieving revision 1.102 diff -u -p -r1.102 tty.h --- sys/tty.h 16 Dec 2007 06:12:53 -0000 1.102 +++ sys/tty.h 8 Apr 2008 05:30:04 -0000 @@ -442,6 +442,8 @@ tt_ioctl(struct tty *t, u_long cmd, void int fflag, struct thread *td) { + if (t->t_ioctl == NULL) + return (ENOIOCTL); return (t->t_ioctl(t, cmd, data, fflag, td)); } One thing I'm not sure about is whether ttyld_ioctl should be called regardless of whether a driver's ioctl method is used. I opted for 'not' since it seems bogus for two different ioctl layers to handle the same cmd. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 16:16:36 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F8C810656C2 for ; Tue, 8 Apr 2008 16:16:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DABA48FC0C for ; Tue, 8 Apr 2008 16:16:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 651F217107; Tue, 8 Apr 2008 16:16:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m38GGXns040374; Tue, 8 Apr 2008 16:16:33 GMT (envelope-from phk@critter.freebsd.dk) To: John E Hein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 08 Apr 2008 09:30:30 CST." <18427.36758.266944.74378@gromit.timing.com> Date: Tue, 08 Apr 2008 16:16:33 +0000 Message-ID: <40373.1207671393@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 08 Apr 2008 16:16:36 -0000 In message <18427.36758.266944.74378@gromit.timing.com>, John E Hein writes: >Back in 2005-10, phk added the tt_{open,ioctl,etc.} inline calls in >sys/tty.h allowing drivers that hook into the tty layer a way to >override or supplement the basic tty functions with their own >flavoring. > >They were also connected up in kern/tty.c - well most of them. > >tt_ioctl remains unused. > >What about the following: That was sort of deliberate, based on a theory that our ttys should behave as much the same as possible, no matter what driver was behind them, and therefore all ioctls should be handled as linedisc. If a driver needs a special ioctl to do something like load firmware, that should, IMO, not happen on a tty but on a special control device which is not used for login-sessions. If for no other reason, then for purely security reasons. As always, I'm prepared to be persuaded by good examples :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 17:39:04 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 149DC1065678 for ; Tue, 8 Apr 2008 17:39:04 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id CD2048FC1F for ; Tue, 8 Apr 2008 17:39:03 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m38Hd3Mb082288; Tue, 8 Apr 2008 11:39:03 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m38Hcwtd029304; Tue, 8 Apr 2008 11:38:58 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m38Hcw82029301; Tue, 8 Apr 2008 11:38:58 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18427.44466.423562.510257@gromit.timing.com> Date: Tue, 8 Apr 2008 11:38:58 -0600 From: John Hein To: "Poul-Henning Kamp" In-Reply-To: <40373.1207671393@critter.freebsd.dk> References: <18427.36758.266944.74378@gromit.timing.com> <40373.1207671393@critter.freebsd.dk> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 08 Apr 2008 17:39:04 -0000 Poul-Henning Kamp wrote at 16:16 +0000 on Apr 8, 2008: > In message <18427.36758.266944.74378@gromit.timing.com>, John E Hein writes: > >tt_ioctl remains unused. > > That was sort of deliberate, based on a theory that our ttys should > behave as much the same as possible, no matter what driver was behind > them, and therefore all ioctls should be handled as linedisc. > > If a driver needs a special ioctl to do something like load firmware, > that should, IMO, not happen on a tty but on a special control device > which is not used for login-sessions. > > If for no other reason, then for purely security reasons. The old 'call it a security issue' to end all debate ploy ;) > As always, I'm prepared to be persuaded by good examples :-) Well this started out as an exercise to allow us to put FTDI parts (USB-to-serial chips, specifically using the dual port variety here) into so-called "bit bang" modes (for writing to parts via SPI, JTAG, and similar connections). The FreeBSD uftdi driver supports the uart emulation mode through the ucom(4) driver but not the former. The ucom(4) driver has a hook to to allow ucom-based drivers to be called via struct tty's t_ioctl. Currently that will never get called through the tty infrastructure since tp->t_ioctl is not called from ttyioctl (which is what prompted the patch). I'm not sure if that counts as a good example. At the risk of expanding this conversation beyond its original scope... To support the different mode, there are a couple generic USB commands you can send to these devices. To that end, this could also be considered a more general question of supporting pass-through of generic USB commands on USB serial devices (as you could do if it was attached as a ugen device instead of a cuaU device). Should that be supported (via separate dev node or some other way) generically? However, even if that were supported, that would put the ball in userland's court to send the right USB commands to put the device into the right mode. I like the idea of keeping the knowledge how to do that in the uftdi driver (and not having specific usb devices pass through to ugen). One thing I have noticed is that it's hard to switch between ugen and ucom (via kldunload/kldload) without rebooting. I haven't tracked down whether that's by design. Unless someone else votes toward supporting driver-specific ioctls through the tty layer, adding a control device is okay with me. As far as naming, it could be cuaU0.ctl or uftdi0.ctl or something else. I guess I'd lean toward the second choice. And if we decide driver-specific ioctls via tty layer should not be used, then perhaps we should just remove t_ioctl from struct tty? It's not called from anywhere right now, although it is set it a few places... ./dev/usb/ucom.c: tp->t_ioctl = ucomioctl; ./dev/digi/digi.c: tp->t_ioctl = digiioctl; ./sys/tty.h: t_ioctl_t *t_ioctl; /* Set ioctl handling (optional). */ ./sys/tty.h: if (t->t_ioctl == NULL) ./sys/tty.h: return (t->t_ioctl(t, cmd, data, fflag, td)); digiioctl also seems to want to do some real things, and I can't see how it gets called right now. That became connected to the tty layer (and thus effectively not connected to anything - correct me if that's wrong) in 2004-10. I guess no one missed those knobs? Currently ucomioctl just calls back to ucom-based drivers that have registered their ioctls with it. There is one ucom-based driver that wants to do real things in its ioctl callback (umodem). And two others (uvscom, uplcom) that appear to want to in the future (commented out with "TODO"). From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 19:06:20 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32C621065671 for ; Tue, 8 Apr 2008 19:06:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EA0B88FC1C for ; Tue, 8 Apr 2008 19:06:19 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9D69A17108; Tue, 8 Apr 2008 19:06:18 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m38J6IeJ040915; Tue, 8 Apr 2008 19:06:18 GMT (envelope-from phk@critter.freebsd.dk) To: John Hein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 08 Apr 2008 11:38:58 CST." <18427.44466.423562.510257@gromit.timing.com> Date: Tue, 08 Apr 2008 19:06:18 +0000 Message-ID: <40914.1207681578@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 08 Apr 2008 19:06:20 -0000 In message <18427.44466.423562.510257@gromit.timing.com>, John Hein writes: > > If a driver needs a special ioctl to do something like load firmware, > > that should, IMO, not happen on a tty but on a special control device > > which is not used for login-sessions. > > > > If for no other reason, then for purely security reasons. > >The old 'call it a security issue' to end all debate ploy ;) No, not really. Try to read how far POSIX went, to make sure that ttys were non-compromised and un-compromising. Then consider the price we pay for an extra /dev/mumble.ctl device. There is really no excuse for overlaying non-per-tty functionality on a random tty device. If the functionality is per-tty, IOC_TRANSLATE_TO_HINDU and such, then this argument does not apply, I'm only talking about "out-of-band" ioctls, which were the ones I faced when I did this. > > As always, I'm prepared to be persuaded by good examples :-) > >Well this started out as an exercise to allow us to put FTDI parts >(USB-to-serial chips, specifically using the dual port variety here) >into so-called "bit bang" modes (for writing to parts via SPI, JTAG, >and similar connections). Is there an existing defined API for this ? ie: does linux have some ioctls defined already ? If so, we should stay compatible with that. If this is a new API we're defining, we should think carefully about how general we make it, it should hopefully not be private to one particular kind/brand/type of USB-SERIAL chip. >To that end, this could also be considered a more general question of >supporting pass-through of generic USB commands on USB serial devices >(as you could do if it was attached as a ugen device instead of a cuaU >device). That is another option, but in general, passing USB through TTY, GEOM or any other high-level subsystem is a troubling and bad idea, if for nothing else, for code complexity reasons. >However, even if that were supported, that >would put the ball in userland's court to send the right USB commands >to put the device into the right mode. Yes, sounds trivial, but then again: I put a USB dongle on my dial-in modem and suddenly a user can diddle it at USB level ? I think not... So we would have to restrict these ioctls to /dev/cua* devices instead of /dev/tty* devices. And then we would have to teach our uses the difference between the two kinds. And who besides me (and bde ?) have a dial-in modem anyway ? It is a fair comment that the POSIX model for a tty is totally out of whack with what people use them for these days. Summary: If there is a well established ioctl for such bit-banging already, and you restrict it properly (/dev/cua* I would say), then go for it. Otherwise, use ugen, it's easier, simpler and likely faster. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 23:40:35 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4B4106566C for ; Tue, 8 Apr 2008 23:40:35 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1F01C8FC1B for ; Tue, 8 Apr 2008 23:40:34 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m38NeYN5033724; Tue, 8 Apr 2008 17:40:34 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m38NeW4i038017; Tue, 8 Apr 2008 17:40:32 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m38NeWCI038014; Tue, 8 Apr 2008 17:40:32 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18428.624.490619.248235@gromit.timing.com> Date: Tue, 8 Apr 2008 17:40:32 -0600 From: John E Hein To: "Poul-Henning Kamp" In-Reply-To: <40914.1207681578@critter.freebsd.dk> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 08 Apr 2008 23:40:35 -0000 Poul-Henning Kamp wrote at 19:06 +0000 on Apr 8, 2008: > In message <18427.44466.423562.510257@gromit.timing.com>, John Hein writes: > > > > If a driver needs a special ioctl to do something like load firmware, > > > that should, IMO, not happen on a tty but on a special control device > > > which is not used for login-sessions. > > > > > > If for no other reason, then for purely security reasons. > > > >The old 'call it a security issue' to end all debate ploy ;) > > No, not really. > > Try to read how far POSIX went, to make sure that ttys were > non-compromised and un-compromising. Then consider the price we > pay for an extra /dev/mumble.ctl device. There is really no excuse > for overlaying non-per-tty functionality on a random tty device. Fair enough. I didn't mean to trivialize the concern with a joke. > Is there an existing defined API for this ? > > ie: does linux have some ioctls defined already ? Yes. They use ioctls on top of the sio device in the latest driver on sourceforge (from 2003)... http://sourceforge.net/projects/ftdi-usb-sio/ In fact it just uses a different ioctl command character to separate the bit bang ioctls from the sio ioctls. That is not the driver that comes with the linux kernel source, however. That driver does not support bit bang mode. It seems they have not pulled in the support into their repository. So the bit bang driver for linux is somewhat renegade. Netbsd does not have support for bit bang mode in cvs. But there was one email inquiring about it on tech-kern recently. And for more existing precedent, FTDI looks like they have separate windows drivers for "virtual com port" access and for "direct via usb" access. Not that we want to base our work on what windows does, of course. But it's more information. > If so, we should stay compatible with that. > > If this is a new API we're defining, we should think carefully about > how general we make it, it should hopefully not be private to one > particular kind/brand/type of USB-SERIAL chip. Yes. So there are two questions here. One which opened this thread: Do we want to allow tty sub-devices to get to device-specific ioctls through the tty layer? Second (which is larger than the scope of the first question), how to integrate the non-tty functionality of certain usb serial devices into FreeBSD. We can do the first without having usb serial devices use it, so the questions are somewhat separable. I also have two motivations: one to get it done quickly in my local tree. But I'd like to see it implemented cleanly and into FreeBSD. I can do the former easily enough, but need the help from opinions on arch@ for the latter. I guess I'm leaning toward a separate uftdi0.ctl minor device despite what the sourceforge linux driver does. > >To that end, this could also be considered a more general question of > >supporting pass-through of generic USB commands on USB serial devices > > That is another option, but in general, passing USB through TTY, > GEOM or any other high-level subsystem is a troubling and bad idea, > if for nothing else, for code complexity reasons. Agreed. I almost deleted that comment before I sent it in the last email. I should have. Forget I mentioned it. > And who besides me (and bde ?) have a dial-in modem anyway ? You'd be surprised. > Summary: > > If there is a well established ioctl for such bit-banging already, > and you restrict it properly (/dev/cua* I would say), then go for > it. Well established? From my research, I can't say there is a well established ioctl for this. Lots of example code I've seen is using libusb & libftdi with ugen rather than the device driver. But I'd like to get support for bit bang mode into driverland. > Otherwise, use ugen, it's easier, simpler and likely faster. You can't use ugen, for instance, for the dual ftdi chip where you want one port to be uart and the other to be jtag. And you can't use it if you want to switch between ucom and ugen without rebooting (at least not in 6.x or 7.x). As I said, I haven't figured out if that is by design or not. I don't have a problem with opening two different devices for the two different modes, but requiring an intervening reboot is out of the question. From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 23:36:12 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1CB7106564A for ; Tue, 8 Apr 2008 23:36:12 +0000 (UTC) (envelope-from rk_hunnicutt@yahoo.com) Received: from web37604.mail.mud.yahoo.com (web37604.mail.mud.yahoo.com [209.191.87.87]) by mx1.freebsd.org (Postfix) with SMTP id 66C068FC12 for ; Tue, 8 Apr 2008 23:36:12 +0000 (UTC) (envelope-from rk_hunnicutt@yahoo.com) Received: (qmail 94433 invoked by uid 60001); 8 Apr 2008 23:09:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=45nZKRL01YXHp16bi2VYEKn0B9BGidXiJO2y3jNEN3AVKDhLu+MRJEzzEWerk1s74xxqVVbyj8ZFLhUEwYyfC1FP1gg7sd1zt+A3/PhtUF3S/VDmoSCjt+GiyBZR3DA/edh+aaxwYCYctlBIOK4O9X/e9l757KtfS7fdrU0Wzos=; X-YMail-OSG: i8mTJgkVM1luqXkzTsuJ8so1rppcttP2CElekrWWtJKrjVmfOHCnXIbVRWUUb33gcnCe1DpnGkJmAPI7onqvdhJQL0OQObLi5RoRwMhp6Kwda3MLyHY- Received: from [70.166.18.214] by web37604.mail.mud.yahoo.com via HTTP; Tue, 08 Apr 2008 16:09:30 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 8 Apr 2008 16:09:30 -0700 (PDT) From: Rick Hunnicutt To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <321309.94192.qm@web37604.mail.mud.yahoo.com> X-Mailman-Approved-At: Wed, 09 Apr 2008 02:10:43 +0000 Cc: kostikbel@gmail.com Subject: fdclone KPI 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, 08 Apr 2008 23:36:12 -0000 I'm curious if someone can tell me why the fdclone KPI was not included in the 7.0 release? Thanks, Rick ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 04:16:50 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366E81065677 for ; Wed, 9 Apr 2008 04:16:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id CAA0C8FC1C for ; Wed, 9 Apr 2008 04:16:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JjRVL-0007LS-70 for freebsd-arch@freebsd.org; Wed, 09 Apr 2008 07:01:47 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3941rRU038019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 07:01:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3941iSq044674; Wed, 9 Apr 2008 07:01:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m3941iL1044673; Wed, 9 Apr 2008 07:01:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2008 07:01:44 +0300 From: Kostik Belousov To: Rick Hunnicutt Message-ID: <20080409040144.GK21209@deviant.kiev.zoral.com.ua> References: <321309.94192.qm@web37604.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l4IMblsHEWQg+b+m" Content-Disposition: inline In-Reply-To: <321309.94192.qm@web37604.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: e35cef5ed21d82303c208435479e4a86 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2588 [Apr 08 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-arch@freebsd.org Subject: Re: fdclone KPI 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, 09 Apr 2008 04:16:50 -0000 --l4IMblsHEWQg+b+m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 08, 2008 at 04:09:30PM -0700, Rick Hunnicutt wrote: > I'm curious if someone can tell me why the fdclone KPI was not included in the 7.0 release? Because it got no - review; - interest from the driver authors; - agreement that this is the way to go. --l4IMblsHEWQg+b+m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkf8P6cACgkQC3+MBN1Mb4haRQCglSz5jPbTNiQFFOZhjU45NIzO Jj8An1d7u7lRh9OeH9z7jvAguU742Js7 =zVpV -----END PGP SIGNATURE----- --l4IMblsHEWQg+b+m-- From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 10:44:20 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3745106564A for ; Wed, 9 Apr 2008 10:44:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCE68FC20 for ; Wed, 9 Apr 2008 10:44:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m39Ahi45073912; Wed, 9 Apr 2008 04:43:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Apr 2008 04:44:39 -0600 (MDT) Message-Id: <20080409.044439.1273921668.imp@bsdimp.com> To: jhein@timing.com From: "M. Warner Losh" In-Reply-To: <18428.624.490619.248235@gromit.timing.com> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> <18428.624.490619.248235@gromit.timing.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl 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, 09 Apr 2008 10:44:20 -0000 In message: <18428.624.490619.248235@gromit.timing.com> John E Hein writes: : You can't use ugen, for instance, for the dual ftdi chip where you : want one port to be uart and the other to be jtag. And you can't use : it if you want to switch between ucom and ugen without rebooting : (at least not in 6.x or 7.x). As I said, I haven't figured out : if that is by design or not. It is possible with enough kernel hacking to make it happen. This particular misfeature is due to the really poor job that the usb code does integrating with newbus. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 10:44:27 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72A0810656CA for ; Wed, 9 Apr 2008 10:44:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2D40B8FC27 for ; Wed, 9 Apr 2008 10:44:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m39AfXS6073899; Wed, 9 Apr 2008 04:41:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Apr 2008 04:42:28 -0600 (MDT) Message-Id: <20080409.044228.-201314267.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <40914.1207681578@critter.freebsd.dk> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, jhein@timing.com Subject: Re: tt_ioctl 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, 09 Apr 2008 10:44:27 -0000 In message: <40914.1207681578@critter.freebsd.dk> "Poul-Henning Kamp" writes: : Summary: : If there is a well established ioctl for such bit-banging already, : and you restrict it properly (/dev/cua* I would say), then go for : it. : : Otherwise, use ugen, it's easier, simpler and likely faster. I disagree here. There's real problems using ugen. I isn't easier and it isn't faster to do what John needs to do with ugen. The whole point of making it an ioctl was so that we could use all the infrastructure in ucom without having to reinvent the wheel. Were we to do what you suggest, we'd need some of the ftdi devices to attach to ugen, and others to uftdi. This isn't possible in the current state of the world. It just isn't. It is more problematical than adding the ioctl to control the mode. I think I may have originally added the code that John proposed to the tsc tree (or maybe just my private tree when I was investigating the problem for others at TSC). I think it is the right way to go, and that the ioctl vs security argument is a bit specious. There's already a number of ways that a badly written driver can cause security problems on the system, why call this one out specially? I do agree that you don't want the ioctl to give the ability to send out raw USB packets, but the ioctls that he's talking about are at a higher level: Set the device into this mode or that mode rather than 'send this arbitrary packet'. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 10:56:46 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 712F31065670 for ; Wed, 9 Apr 2008 10:56:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 35CEB8FC26 for ; Wed, 9 Apr 2008 10:56:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CF03317104; Wed, 9 Apr 2008 10:56:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m39Auikp044322; Wed, 9 Apr 2008 10:56:44 GMT (envelope-from phk@critter.freebsd.dk) To: John E Hein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 08 Apr 2008 17:40:32 CST." <18428.624.490619.248235@gromit.timing.com> Date: Wed, 09 Apr 2008 10:56:44 +0000 Message-ID: <44321.1207738604@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 09 Apr 2008 10:56:46 -0000 In message <18428.624.490619.248235@gromit.timing.com>, John E Hein writes: >I guess I'm leaning toward a separate >uftdi0.ctl minor device despite what the sourceforge >linux driver does. That would be my inclination too. We had something slightly similar with a sync/async board at one point. The driver never made it into the tree for a number of reasons, but the same problem was present: We have one physical connector, and it can either be a tty or something else. By adding a uftdi0.ctl (or whatever you name it, "uftdi0" is probably even preferable) you get a separate and direct channel to the device, and you can issue whatever IOCTLs, generic (preferably) or device specific, it takes to make the port do whatever non-tty task it is you want. That seems like the sensible model to me. > > Otherwise, use ugen, it's easier, simpler and likely faster. > >You can't use ugen, [...] Forget that then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 15:38:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50BA5106564A for ; Wed, 9 Apr 2008 15:38:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1408A8FC15 for ; Wed, 9 Apr 2008 15:38:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BBFDA17104; Wed, 9 Apr 2008 15:38:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m39FcE1t045301; Wed, 9 Apr 2008 15:38:15 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Apr 2008 08:36:17 MST." Date: Wed, 09 Apr 2008 15:38:14 +0000 Message-ID: <45300.1207755494@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, John E Hein Subject: Re: sync/async [was: Re: tt_ioctl] 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, 09 Apr 2008 15:38:17 -0000 In message , Marcel Moolenaar wri tes: >I think the complexity or problems stem from the fact that >there's a single driver. With scc(4) the design is such that >the driving is left to subordinate drivers like uart(4) and >the only thing that scc(4) does is arbitration. Yeah, we have the same thing over at the ppbus. I remember talking with Warner about making this a facility in newbus instead, but I think we had too much beer and too little time :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 15:58:02 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BA2E106566B for ; Wed, 9 Apr 2008 15:58:02 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.82]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8C28FC0C for ; Wed, 9 Apr 2008 15:58:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp010-s [10.150.69.73]) by smtpoutm.mac.com (Xserve/smtpout019/MantshX 4.0) with ESMTP id m39FaSfu018307; Wed, 9 Apr 2008 08:36:29 -0700 (PDT) Received: from [192.168.1.100] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/asmtp010/MantshX 4.0) with ESMTP id m39FaIwS001953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2008 08:36:19 -0700 (PDT) Message-Id: From: Marcel Moolenaar To: Poul-Henning Kamp In-Reply-To: <44321.1207738604@critter.freebsd.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 9 Apr 2008 08:36:17 -0700 References: <44321.1207738604@critter.freebsd.dk> X-Mailer: Apple Mail (2.919.2) Cc: arch@freebsd.org, John E Hein Subject: sync/async [was: Re: tt_ioctl] 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, 09 Apr 2008 15:58:02 -0000 On Apr 9, 2008, at 3:56 AM, Poul-Henning Kamp wrote: > In message <18428.624.490619.248235@gromit.timing.com>, John E Hein > writes: > >> I guess I'm leaning toward a separate >> uftdi0.ctl minor device despite what the sourceforge >> linux driver does. > > That would be my inclination too. > > We had something slightly similar with a sync/async board at one > point. > > The driver never made it into the tree for a number of reasons, but > the same problem was present: We have one physical connector, and > it can either be a tty or something else. I think the complexity or problems stem from the fact that there's a single driver. With scc(4) the design is such that the driving is left to subordinate drivers like uart(4) and the only thing that scc(4) does is arbitration. The mode the hardware is in corresponds to which sub-ordinate driver is selected. As such, scc(4) presents a time-shared bus onto which multiple drivers can attach -- each of which dealing with a particular mode of the hardware. We currently only have uart(4) for async communication in the tree, but I have some sketches for drivers for bi-sync and hdlc/sdlc in P4. This approach yields logical behaviour in general. Whenever the device special file of uart(4) is being opened, uart(4) will try to activate the resources. If those resources aren't already activated (i.e. the hardware is currently idle), then uart(4) gets to use the resources and the hardware can be put in async mode. Otherwise the open will fail or block. Suppose we have a driver for sdlc/hdlc that presents a network interface. The process above is not triggered by the opening of a device, but by bringing the interface up or configuring it. This succeeds if the hardware is idle (e.g. uart(4) isn't used for async communications). I think this scheme will work well in general and should be applicable in John's case as well. JFYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:06:34 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73988106566B for ; Wed, 9 Apr 2008 16:06:34 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (ns2.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9288FC15 for ; Wed, 9 Apr 2008 16:06:34 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m39G6VW9071369; Wed, 9 Apr 2008 10:06:31 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m39G6U6W058521; Wed, 9 Apr 2008 10:06:30 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m39G6Usv058518; Wed, 9 Apr 2008 10:06:30 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18428.59782.318085.53492@gromit.timing.com> Date: Wed, 9 Apr 2008 10:06:30 -0600 From: John E Hein To: "M. Warner Losh" In-Reply-To: <20080409.044228.-201314267.imp@bsdimp.com> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> <20080409.044228.-201314267.imp@bsdimp.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: arch@freebsd.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl 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, 09 Apr 2008 16:06:34 -0000 M. Warner Losh wrote at 04:42 -0600 on Apr 9, 2008: > I think I may have originally added the code that John proposed to the > tsc tree (or maybe just my private tree when I was investigating the > problem for others at TSC). It wasn't checked in the local tree - I guess we came up with it independently (assume you're talking about hooking up t_ioctl?). > I think it is the right way to go, and that the ioctl vs security > argument is a bit specious. Well, I could go either way on this issue - 'specious' might be a bit too strong. I could see issues with pass-through device-specific ioctls on tty devs - especially due to the fact that it's a tty device is somewhat obscured in the case of ucom children. On the other hand, tty-based devices are generally protected by other mechanisms (notably unix file permissions). And driver writers should be aware of security implications of ioctls they expose. That requires a bit of thought and more comprehensive system knowledge, however, and maybe it's better to just keep it simple and only allow tty ioctls on tty devices. That said... if we do decide to _not_ hook up t_ioctl, then we should just remove it entirely since it's misleading that it's there but not hooked up. The only thing that remains then (if we remove it) would be what to do with the drivers that have been broken for 3+ years since the ioctl pass-through was removed (digi and the usb driver or two I mentioned in the previous email). Does anyone need to use the unhooked ioctls? How do we find out if they are or are not needed any longer (other than just leaving them unhooked and wait for PRs to appear or not)? I guess that just a more public call might be in order (-stable, -current?). Thanks for the responses so far, by the way. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:09:36 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D73106566C for ; Wed, 9 Apr 2008 16:09:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 583B58FC22 for ; Wed, 9 Apr 2008 16:09:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4840517104; Wed, 9 Apr 2008 16:09:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m39G9YsI050326; Wed, 9 Apr 2008 16:09:34 GMT (envelope-from phk@critter.freebsd.dk) To: John E Hein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Apr 2008 10:06:30 CST." <18428.59782.318085.53492@gromit.timing.com> Date: Wed, 09 Apr 2008 16:09:34 +0000 Message-ID: <50325.1207757374@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: tt_ioctl 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, 09 Apr 2008 16:09:36 -0000 In message <18428.59782.318085.53492@gromit.timing.com>, John E Hein writes: >That said... if we do decide to _not_ hook up t_ioctl, then we should >just remove it entirely since it's misleading that it's there but not >hooked up. Well, if we agree that you should use a non-tty device, we may still miss the poster child ioctl to make the decision... >The only thing that remains then (if we remove it) would be what to do >with the drivers that have been broken for 3+ years since the ioctl >pass-through was removed (digi and the usb driver or two I mentioned >in the previous email). Also a good question. A check in the PR database is probably first order of business. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:17:15 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622171065677 for ; Wed, 9 Apr 2008 16:17:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 24FCF8FC2B for ; Wed, 9 Apr 2008 16:17:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m39GFY2g077590; Wed, 9 Apr 2008 10:15:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Apr 2008 10:16:29 -0600 (MDT) Message-Id: <20080409.101629.-146244298.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <50325.1207757374@critter.freebsd.dk> References: <18428.59782.318085.53492@gromit.timing.com> <50325.1207757374@critter.freebsd.dk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, jhein@timing.com Subject: Re: tt_ioctl 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, 09 Apr 2008 16:17:15 -0000 In message: <50325.1207757374@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <18428.59782.318085.53492@gromit.timing.com>, John E Hein writes: : : >That said... if we do decide to _not_ hook up t_ioctl, then we should : >just remove it entirely since it's misleading that it's there but not : >hooked up. : : Well, if we agree that you should use a non-tty device, we may still : miss the poster child ioctl to make the decision... I don't think we agreed that should use a non-tty device. There's good reasons to allow ioctls passed through to the driver. There's historical precedent, and if there's a security concern, the driver writer can put a suser() call to make sure that things are cool for mere mortals. Basically, having another device would be very duplicative in the driver, and the reasons for it don't make sense to me. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:20:50 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B06106566C for ; Wed, 9 Apr 2008 16:20:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2423E8FC21 for ; Wed, 9 Apr 2008 16:20:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m39GHLlh077606; Wed, 9 Apr 2008 10:17:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Apr 2008 10:18:16 -0600 (MDT) Message-Id: <20080409.101816.1824031653.imp@bsdimp.com> To: jhein@timing.com From: "M. Warner Losh" In-Reply-To: <18428.59782.318085.53492@gromit.timing.com> References: <40914.1207681578@critter.freebsd.dk> <20080409.044228.-201314267.imp@bsdimp.com> <18428.59782.318085.53492@gromit.timing.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl 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, 09 Apr 2008 16:20:50 -0000 In message: <18428.59782.318085.53492@gromit.timing.com> John E Hein writes: : M. Warner Losh wrote at 04:42 -0600 on Apr 9, 2008: : > I think I may have originally added the code that John proposed to the : > tsc tree (or maybe just my private tree when I was investigating the : > problem for others at TSC). : : It wasn't checked in the local tree - I guess we came up with it : independently (assume you're talking about hooking up t_ioctl?). Yes. I almost just quietly committed it to FreeBSD at the time, but I got busy on another project and never got back to it. Maybe I should have just done it and saw if phk noticed :-) : > I think it is the right way to go, and that the ioctl vs security : > argument is a bit specious. : : Well, I could go either way on this issue - 'specious' might be a bit : too strong. I could see issues with pass-through device-specific : ioctls on tty devs - especially due to the fact that it's a tty device : is somewhat obscured in the case of ucom children. I'm not sure I follow what you are saying here... Warner From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 16:21:55 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B487106564A for ; Wed, 9 Apr 2008 16:21:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D2D868FC0A for ; Wed, 9 Apr 2008 16:21:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3242917104; Wed, 9 Apr 2008 16:21:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m39GLrFD050459; Wed, 9 Apr 2008 16:21:53 GMT (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 09 Apr 2008 10:16:29 CST." <20080409.101629.-146244298.imp@bsdimp.com> Date: Wed, 09 Apr 2008 16:21:53 +0000 Message-ID: <50458.1207758113@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org, jhein@timing.com Subject: Re: tt_ioctl 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, 09 Apr 2008 16:21:55 -0000 In message <20080409.101629.-146244298.imp@bsdimp.com>, "M. Warner Losh" writes : >In message: <50325.1207757374@critter.freebsd.dk> > "Poul-Henning Kamp" writes: >: In message <18428.59782.318085.53492@gromit.timing.com>, John E Hein writes: >: >: >That said... if we do decide to _not_ hook up t_ioctl, then we should >: >just remove it entirely since it's misleading that it's there but not >: >hooked up. >: >: Well, if we agree that you should use a non-tty device, we may still >: miss the poster child ioctl to make the decision... > >I don't think we agreed that should use a non-tty device. There's >good reasons to allow ioctls passed through to the driver. Yes, but these particular ioctls don't sound anything like that reason. If you make them available, you either have to make them unavailable when the tty is used as a login terminal (either by the documentation wise laborious cua/tty split or by other worse means) If you make them available on a separate device, that entire issue disappears. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 17:59:39 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E441065741 for ; Wed, 9 Apr 2008 17:59:39 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (w.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id D1C488FC0C for ; Wed, 9 Apr 2008 17:59:38 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id m39HxaP1088211; Wed, 9 Apr 2008 11:59:36 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.2/8.14.2) with ESMTP id m39HxZjO061598; Wed, 9 Apr 2008 11:59:35 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.2/8.14.2/Submit) id m39HxUtg061595; Wed, 9 Apr 2008 11:59:30 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18429.1026.716346.691351@gromit.timing.com> Date: Wed, 9 Apr 2008 11:59:30 -0600 From: John E Hein To: "M. Warner Losh" In-Reply-To: <20080409.101816.1824031653.imp@bsdimp.com> References: <40914.1207681578@critter.freebsd.dk> <20080409.044228.-201314267.imp@bsdimp.com> <18428.59782.318085.53492@gromit.timing.com> <20080409.101816.1824031653.imp@bsdimp.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: arch@FreeBSD.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl 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, 09 Apr 2008 17:59:39 -0000 M. Warner Losh wrote at 10:18 -0600 on Apr 9, 2008: > Yes. I almost just quietly committed it to FreeBSD at the time, but I > got busy on another project and never got back to it. Maybe I should > have just done it and saw if phk noticed :-) Never try to accomplish through planning what can be done more simply through subterfuge. > : Well, I could go either way on this issue - 'specious' might be a bit > : too strong. I could see issues with pass-through device-specific > : ioctls on tty devs - especially due to the fact that it's a tty device > : is somewhat obscured in the case of ucom children. > > I'm not sure I follow what you are saying here... I'm not sure which part your asking about, so I'll just try to be a bit more verbose. - re: issues with pass-thru ioctls... I'm just commenting that I understand phk's concerns about potentially ill-advised ioctls on the tty dev. - re: ucom-based driver ioctls... those drivers just set the ucomioctl method and so don't know (without digging) that it hooks up to the tty ioctl method... hence the 'obscured' comment and since the relationship to the tty device is somewhat obscured through an indirect relationship, the ucom-based driver writer may not be aware of the potential problems with exposing ioctls on the tty dev. From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 18:32:20 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E6A1065686 for ; Wed, 9 Apr 2008 18:32:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id AE7F98FC12 for ; Wed, 9 Apr 2008 18:32:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 238504192-1834499 for multiple; Wed, 09 Apr 2008 14:31:06 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m39IW7MO070262; Wed, 9 Apr 2008 14:32:07 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 9 Apr 2008 11:25:46 -0400 User-Agent: KMail/1.9.7 References: <321309.94192.qm@web37604.mail.mud.yahoo.com> <20080409040144.GK21209@deviant.kiev.zoral.com.ua> In-Reply-To: <20080409040144.GK21209@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804091125.46505.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]); Wed, 09 Apr 2008 14:32:07 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6689/Wed Apr 9 12:20:19 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , Rick Hunnicutt Subject: Re: fdclone KPI 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, 09 Apr 2008 18:32:20 -0000 On Wednesday 09 April 2008 12:01:44 am Kostik Belousov wrote: > On Tue, Apr 08, 2008 at 04:09:30PM -0700, Rick Hunnicutt wrote: > > I'm curious if someone can tell me why the fdclone KPI was not included in the 7.0 release? > > Because it got no > - review; > - interest from the driver authors; > - agreement that this is the way to go. Oof, where is the patch? I think it is definitely easier for people to use than devfs cloning when all that is needed is per-instance data. I would use it in the ipmi(4) driver and the nvidia graphics driver would likely prefer it to devfs cloning as well. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 19:29:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4EA81065676; Wed, 9 Apr 2008 19:29:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 400258FC25; Wed, 9 Apr 2008 19:29:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jjfz1-000KnP-9V; Wed, 09 Apr 2008 22:29:23 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m39JTRav071164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 22:29:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m39JTI21041820; Wed, 9 Apr 2008 22:29:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m39JTICp041819; Wed, 9 Apr 2008 22:29:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 9 Apr 2008 22:29:18 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080409192918.GM21209@deviant.kiev.zoral.com.ua> References: <321309.94192.qm@web37604.mail.mud.yahoo.com> <20080409040144.GK21209@deviant.kiev.zoral.com.ua> <200804091125.46505.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mHEGYOlXWdrdotU2" Content-Disposition: inline In-Reply-To: <200804091125.46505.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b3971b7ac160fe45482707327a257f38 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2596 [Apr 09 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Rick Hunnicutt , freebsd-arch@freebsd.org Subject: Re: fdclone KPI 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, 09 Apr 2008 19:29:25 -0000 --mHEGYOlXWdrdotU2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 09, 2008 at 11:25:46AM -0400, John Baldwin wrote: > On Wednesday 09 April 2008 12:01:44 am Kostik Belousov wrote: > > On Tue, Apr 08, 2008 at 04:09:30PM -0700, Rick Hunnicutt wrote: > > > I'm curious if someone can tell me why the fdclone KPI was not includ= ed in=20 > the 7.0 release? > >=20 > > Because it got no > > - review; > > - interest from the driver authors; > > - agreement that this is the way to go. >=20 > Oof, where is the patch? I think it is definitely easier for people to u= se=20 > than devfs cloning when all that is needed is per-instance data. I would= use=20 > it in the ipmi(4) driver and the nvidia graphics driver would likely pref= er=20 > it to devfs cloning as well. http://people.freebsd.org/~kib/misc/fdclone.10.patch http://people.freebsd.org/~kib/misc/fclone.c The patch was developed before the struct file becomes lockless. The link above contains the mechanically updated patch, that was given one smoke-test run. fclone.c is the trivial driver that utilizes the new KPI. --mHEGYOlXWdrdotU2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkf9GQ4ACgkQC3+MBN1Mb4h2qwCfeH2LW+5dlHxQWfFzSfdj/xxm 4dkAoNhN81b8UJtO+uTLCjY4ZDkl+Rwu =vUHo -----END PGP SIGNATURE----- --mHEGYOlXWdrdotU2-- From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 19:59:23 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9294C106566C for ; Wed, 9 Apr 2008 19:59:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 15E6B8FC0A for ; Wed, 9 Apr 2008 19:59:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 238513915-1834499 for multiple; Wed, 09 Apr 2008 15:58:16 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m39JxAuE070969; Wed, 9 Apr 2008 15:59:11 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Wed, 9 Apr 2008 15:50:27 -0400 User-Agent: KMail/1.9.7 References: <321309.94192.qm@web37604.mail.mud.yahoo.com> <200804091125.46505.jhb@freebsd.org> <20080409192918.GM21209@deviant.kiev.zoral.com.ua> In-Reply-To: <20080409192918.GM21209@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804091550.27806.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]); Wed, 09 Apr 2008 15:59:11 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/6689/Wed Apr 9 12:20:19 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Rick Hunnicutt , freebsd-arch@freebsd.org Subject: Re: fdclone KPI 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, 09 Apr 2008 19:59:23 -0000 On Wednesday 09 April 2008 03:29:18 pm Kostik Belousov wrote: > On Wed, Apr 09, 2008 at 11:25:46AM -0400, John Baldwin wrote: > > On Wednesday 09 April 2008 12:01:44 am Kostik Belousov wrote: > > > On Tue, Apr 08, 2008 at 04:09:30PM -0700, Rick Hunnicutt wrote: > > > > I'm curious if someone can tell me why the fdclone KPI was not included in > > the 7.0 release? > > > > > > Because it got no > > > - review; > > > - interest from the driver authors; > > > - agreement that this is the way to go. > > > > Oof, where is the patch? I think it is definitely easier for people to use > > than devfs cloning when all that is needed is per-instance data. I would use > > it in the ipmi(4) driver and the nvidia graphics driver would likely prefer > > it to devfs cloning as well. > > http://people.freebsd.org/~kib/misc/fdclone.10.patch > http://people.freebsd.org/~kib/misc/fclone.c > > The patch was developed before the struct file becomes lockless. The link > above contains the mechanically updated patch, that was given one > smoke-test run. > > fclone.c is the trivial driver that utilizes the new KPI. Oh, so this still does devfs style cloning just under the covers. Hmm, I thought you had actually added a new 'void *f_foo' member to struct file. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 04:56:43 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCBB7106564A for ; Thu, 10 Apr 2008 04:56:43 +0000 (UTC) (envelope-from peter@wemm.org) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 908778FC29 for ; Thu, 10 Apr 2008 04:56:43 +0000 (UTC) (envelope-from peter@wemm.org) Received: by an-out-0708.google.com with SMTP id c14so766463anc.13 for ; Wed, 09 Apr 2008 21:56:43 -0700 (PDT) Received: by 10.100.247.14 with SMTP id u14mr1148116anh.128.1207801927821; Wed, 09 Apr 2008 21:32:07 -0700 (PDT) Received: by 10.100.8.6 with HTTP; Wed, 9 Apr 2008 21:32:07 -0700 (PDT) Message-ID: Date: Wed, 9 Apr 2008 21:32:07 -0700 From: "Peter Wemm" To: "Bruce Evans" In-Reply-To: <20080408142942.B18072@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080407181250.6733810656C9@hub.freebsd.org> <47FA6833.8080904@delphij.net> <20080408142942.B18072@delplex.bde.org> Cc: delphij@freebsd.org, d@delphij.net, freebsd-arch@freebsd.org Subject: Re: [src] cvs commit: src/sys/ufs/ufs ufs_gjournal.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2008 04:56:43 -0000 On Mon, Apr 7, 2008 at 9:51 PM, Bruce Evans wrote: > On Mon, 7 Apr 2008, LI Xin wrote: > > > > Picking a random commit: > > > > > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/ufs/ufs ufs_gjournal.c Log: > > > Correct function name in panic(). > > > Reported by: kensmith > > > Revision Changes Path > > > 1.3 +1 -1 src/sys/ufs/ufs/ufs_gjournal.c > > > > > > if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg) > > > - panic("ffs_freefile: range: dev = %s, ino = %lu, fs = > %s", > > > + panic("ufs_gjournal_modref: range: dev = %s, ino = %lu, > fs = %s", > > > devtoname(dev), (u_long)ino, fs->fs_fsmnt); > > > if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, > &bp))) { > > > brelse(bp); > > > > > > > > > Is it suitable to use something like __func__ here? I mean, will the > usage of __func__ encouraged practice for base/kernel code or not? > > > > No, __func__ is an obfuscation. It is sort of write-only. It should > only be used when the function name is not a compile-time constant > (mainly in macros). Its use would be an especially large style bug > in ufs, since ufs consistently doesn't use it (except in 1 recently > broken place). > > The above commit also breaks the style using blind substitution which > happens to expand a line beyond 80 characters. > > Bruce I tend to agree. My own personal reason is that I tend to frequently grep the source for printf and panic strings. grep can't do __func__ substitution. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell **WANTED TO BUY: Garmin Streetpilot 2650 or 2660. Not later model! ** From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 08:11:48 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BEC51065672; Thu, 10 Apr 2008 08:11:48 +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 19D0C8FC1B; Thu, 10 Apr 2008 08:11:48 +0000 (UTC) (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 9ABF446B08; Thu, 10 Apr 2008 04:11:47 -0400 (EDT) Date: Thu, 10 Apr 2008 09:11:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20080410091002.E83465@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: 8.0 network stack MPsafety goals (fwd) 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, 10 Apr 2008 08:11:48 -0000 While not explicitly in the schedule, this is a reminder of the impending disabling of IFF_NEEDSGIANT (and hence affected network interfaces). The in-progress USB stack work should take care of the USB drivers below, but the others require immediate attention if they are to continue working beyond 26 May. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Fri, 7 Mar 2008 16:01:26 +0000 (GMT) From: Robert Watson To: arch@FreeBSD.org Subject: Re: 8.0 network stack MPsafety goals On Mon, 24 Dec 2007, Robert Watson wrote: > Date Goals > ---- ----- > 26 Dec 2007 Post proposed schedule for flag and infrastructure removal > Post affected driver list > > 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal > Post updated affected driver list > > 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud > warning. > Post updated affected driver list Dear all, Per the in-progress plan to remove IFF_NEEDSGIANT support, I have increased the verbosity of the boot-time warning for IFF_NEEDSGIANT-dependent network interface drivers. 8-CURRENT users who are seeing this more verbose warning in their dmesg might want to watch out for the next two scheduled steps in May and June respectively. I've attached the remainder of the schedule and related details below. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > 26 May 2008 Post HEADS UP of impending driver disabling > Post updated affected driver list > > 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT > Post updated affected driver list > > 26 Sep 2008 Post HEADS up of impending driver removal > Post updated affected driver list > > 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT > Remove flag and infrastructure > > Here is a list of potentially affected drivers: > > Name Bus Man page description > --- --- -------------------- > ar ISA/PCI synchronous Digi/Arnet device driver > arl ISA Aironet Arlan 655 wireless network adapter driver > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network > driver > axe USB ASIX Electronics AX88172 USB Ethernet driver > cdce USB USB Communication Device Class Ethernet driver > cnw PCCARD Netwave AirSurfer wireless network driver > cs ISA/PCCARD Ethernet device driver > cue USB CATC USB-EL1210A USB Ethernet driver > ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress > Pro/10 and Pro/10+ > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters > ic I2C I2C bus system > ie ISA Ethernet device driver > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver > oltr ISA/PCI Olicom Token Ring device driver > plip PPBUS printer port Internet Protocol driver > ppp TTY point to point protocol network interface > ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver > rue USB RealTek RTL8150 USB to Fast Ethernet controller driver > rum USB Ralink Technology USB IEEE 802.11a/b/g wireless > network device > sbni ISA/PCI Granch SBNI12 leased line modem driver > sbsh PCI Granch SBNI16 SHDSL modem device driver > sl TTY slip network interface > snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter > driver > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver > udav USB Davicom DM9601 USB Ethernet driver > ural USB Ralink Technology RT2500USB IEEE 802.11 driver > xe PCCARD Xircom PCMCIA Ethernet device driver > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless > network device > > In some cases, the requirement for Giant is a property of a subsystem the > driver depends on as the driver itself; for example, the tty subsystem for > SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless > drivers. With most of a year before to go on the proposed schedule, my hope > is that we will have lots of time to address these issues, but wanted to get > a roadmap out from a network protocol stack architecture perspective so that > device driver and subsystem authors could have a schedule in mind. > > FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order > to provide their own conditional MPSAFEty, which can be removed without > affecting device driver functionality (I believe): > > Name Bus Man page description > --- --- -------------------- > ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters > cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters > ctau ISA driver for synchronous Cronyx Tau WAN adapters > cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN > adapters > > Developers and users of the above drivers are heavily encouraged to update > the drivers to remove dependence on Giant, and/or make other contingency > plans. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 17:23:39 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF5A4106566B for ; Thu, 10 Apr 2008 17:23:39 +0000 (UTC) (envelope-from gwalum@hotmail.com) Received: from blu139-omc2-s13.blu139.hotmail.com (blu139-omc2-s13.blu139.hotmail.com [65.55.175.183]) by mx1.freebsd.org (Postfix) with ESMTP id 765158FC12 for ; Thu, 10 Apr 2008 17:23:39 +0000 (UTC) (envelope-from gwalum@hotmail.com) Received: from BLU138-W45 ([65.55.162.185]) by blu139-omc2-s13.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 10:11:38 -0700 Message-ID: X-Originating-IP: [75.247.241.75] From: Dave Lieu To: Date: Thu, 10 Apr 2008 13:11:38 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2008 17:11:38.0598 (UTC) FILETIME=[F0364060:01C89B2D] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPv6 RFC Question 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, 10 Apr 2008 17:23:39 -0000 Greetings All, I was hoping someone could help me with this question. Are the following R= FCs supported in freebsd's implementation of IPv6? 4443 (ICMPv6) 4213 (Dual-Stack mode) 4007 4291 4193 Any feedback is greatly appreciated!= From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 18:12:52 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285291065670 for ; Thu, 10 Apr 2008 18:12:52 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id B43DA8FC1D for ; Thu, 10 Apr 2008 18:12:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-176-092.pools.arcor-ip.net [88.64.176.92]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Jk14J0cGN-0000E0; Thu, 10 Apr 2008 20:00:15 +0200 Received: (qmail 48463 invoked from network); 10 Apr 2008 17:59:09 -0000 Received: from myhost.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 10 Apr 2008 17:59:09 -0000 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 10 Apr 2008 19:57:24 +0200 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804101957.24401.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+MQBZ7vNgBaag+YU+HopSIrHYwOKhqbFNt9WU xCpkQLaj8btPyJNuu3FPEPQ8+UBZvJx0fN5tE5eyRCC3WMAhx2 lRVbUnHwMJ+rb9BdhP50Q== Cc: Dave Lieu Subject: Re: IPv6 RFC Question 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, 10 Apr 2008 18:12:52 -0000 On Thursday 10 April 2008 19:11:38 Dave Lieu wrote: > Greetings All, > > I was hoping someone could help me with this question. Are the > following RFCs supported in freebsd's implementation of IPv6? > > 4443 (ICMPv6) Yes, though some implementations might still be based on RFC 2463. > 4213 (Dual-Stack mode) Yes, -"- 2893. > 4007 Yes. > 4291 > > 4193 These two don't really care about the OS all that much, but rather give guidance on configuration and setup issues. Still FreeBSD should allow you to configure your system in a compliant way. > Any feedback is greatly appreciated! More details can be found in the old KAME documentation. I believe we have (?had?) a README somewhere that was derived from there, but I couldn't find it. Anyone remember where that stuff ended up? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 18:32:20 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D76E61065670 for ; Thu, 10 Apr 2008 18:32:20 +0000 (UTC) (envelope-from gwalum@hotmail.com) Received: from blu139-omc3-s16.blu139.hotmail.com (blu139-omc3-s16.blu139.hotmail.com [65.55.175.216]) by mx1.freebsd.org (Postfix) with ESMTP id 98ECF8FC14 for ; Thu, 10 Apr 2008 18:32:20 +0000 (UTC) (envelope-from gwalum@hotmail.com) Received: from BLU138-W21 ([65.55.162.187]) by blu139-omc3-s16.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 11:32:20 -0700 Message-ID: X-Originating-IP: [75.247.241.75] From: Dave Lieu To: Max Laier , Date: Thu, 10 Apr 2008 14:32:20 -0400 Importance: Normal In-Reply-To: <200804101957.24401.max@love2party.net> References: <200804101957.24401.max@love2party.net> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2008 18:32:20.0022 (UTC) FILETIME=[35ECED60:01C89B39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: IPv6 RFC Question 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, 10 Apr 2008 18:32:21 -0000 Thanks much! > From: max@love2party.net > To: freebsd-arch@freebsd.org > Date: Thu, 10 Apr 2008 19:57:24 +0200 > CC: gwalum@hotmail.com > Subject: Re: IPv6 RFC Question >=20 > On Thursday 10 April 2008 19:11:38 Dave Lieu wrote: > > Greetings All, > > > > I was hoping someone could help me with this question. Are the > > following RFCs supported in freebsd's implementation of IPv6? > > > > 4443 (ICMPv6) >=20 > Yes, though some implementations might still be based on RFC 2463. >=20 > > 4213 (Dual-Stack mode) >=20 > Yes, -"- 2893. >=20 > > 4007 >=20 > Yes. >=20 > > 4291 > > > > 4193 >=20 > These two don't really care about the OS all that much, but rather give=20 > guidance on configuration and setup issues. Still FreeBSD should allow=20 > you to configure your system in a compliant way. >=20 > > Any feedback is greatly appreciated! >=20 > More details can be found in the old KAME documentation. I believe we=20 > have (?had?) a README somewhere that was derived from there, but I=20 > couldn't find it. Anyone remember where that stuff ended up? >=20 > --=20 > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 11:47:34 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46499106566B; Sat, 12 Apr 2008 11:47:34 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6EB8FC17; Sat, 12 Apr 2008 11:47:33 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7E37245E11; Sat, 12 Apr 2008 13:20:35 +0200 (CEST) Received: from localhost (chello087206046210.chello.pl [87.206.46.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 2CCF445D8D; Sat, 12 Apr 2008 13:20:30 +0200 (CEST) Date: Sat, 12 Apr 2008 13:20:19 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20080412112019.GI45299@garage.freebsd.pl> References: <20071218092222.GA9695@freebsd.org> <200712201138.56423.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rV8arf8D5Dod9UkK" Content-Disposition: inline In-Reply-To: <200712201138.56423.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: Roman Divacky , kib@FreeBSD.org, rwatson@FreeBSD.garage.freebsd.pl, freebsd-arch@FreeBSD.org Subject: Re: final decision about *at syscalls 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, 12 Apr 2008 11:47:34 -0000 --rV8arf8D5Dod9UkK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 20, 2007 at 11:38:55AM -0500, John Baldwin wrote: > On Tuesday 18 December 2007 04:22:22 am Roman Divacky wrote: > > Dear arch@ > >=20 > > Over this summer I was working (among other things) on *at family of sy= scalls > > kindly sponsored by Google (in their Summer of Code). The resulting pat= ch is=20 > > almost finished but I need to decide one design question. If you are no= t interested=20 > > in *at/namei feel free to skip this mail. > >=20 > > The *at syscalls are a threads-oriented extension to basic file syscall= s (think > > of open(), fstat(), etc.) adding the possibility to specify from where = the search > > for relative path should start. > >=20 > > image that we have /tmp/foo/bar > >=20 > > and CWD is set to "/tmp/", and the process has opened "foo" as dirfd. w= ith ordinary > > open() syscall you have to either > >=20 > > chdir("/tmp/foo");open("./bar"); > >=20 > > or > >=20 > > open("/tmp/foo/bar"); > >=20 > > The first approach is problematic because it changes CWD for all thread= s in the process, > > the second is prone to race-conditions as some of the components of the= path can > > change in parallel with the "open". > >=20 > > So POSIX introduced a new API, called "Extended API set part 2, ISBN: 1= -931624-67-4" (at > > least this was the latest when I looked last time), which solves that b= y introducing "*at" > > syscalls that supply an fd of previously opened directory which is used= instead of CWD > > for searching relative path, ie. the previous example becomes > >=20 > > dirfd =3D open("/tmp/foo"); openat("foo", dirfd); > >=20 > > I implemented the whole API as native FreeBSD syscalls + in linuxulator= emulation layer. > > Here's the problem: > >=20 > > There are two approaches to the name translation from "filedescriptor" = to the "vnode". > >=20 > > 1) we can do it in the kern_fooat() syscall and pass namei() the result= ing vnode > > 2) we can pass namei() the filedescriptor and do the translation there > >=20 > > PROs of #1: > >=20 > > o namei() does not need to know about the curthread, you can use this = *at > > ability for different purposes, it's cleaner (imho) > >=20 > > PROs of #2 > >=20 > > o raceless implementation > > o no code duplication > >=20 > > CONs of #1 > >=20 > > o some very small code duplication (the translation is done in every= =20 > > kern_fooat() function) > > o there is a race between the name translation and the actual use of t= he result > > of the translation that needs to be handled, the "path_to_file" strin= g is copied > > to the kernel space twice hence a race > >=20 > > CONs of #2 > >=20 > > o namei is made thread dependant =09 > >=20 > > Please tell me what approach you like more. I personally favour #1 beca= use I don't like namei() > > being thread dependant, Kostik Belousov prefers #2. >=20 > Considering Robert's paper on security race problems in things like systr= ace > stemming from when you copy parameters out of userland and into the kernel > multiple times, I think #2 is definitely the better choice. Also, namei(= ) is > already thread aware AFAICT since 'struct componentname' already contains= a > 'cnp_thread' member (was 'cnp_proc' in 4.x). It looks like I'm a bit too late, but anyway... =46rom what you write John, #1 is a better choice than #2. If you want to avoid races, you can pass already locked vnode. In case of file descriptors, if p_fd is not locked another thread can close and open different directory under the same descriptor number. I also need such functionality for recent ZFS and #2 makes it impossible to use it. NDINIT_AT() is kernel (VFS) API so it should operate on vnodes, not file descriptor numbers, IMHO. For completness can you Kostik and Robert provide your arguments against #1? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --rV8arf8D5Dod9UkK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIAJrzForvXbEpPzQRAuaLAJ9CTWpcMOvRjzqpLSqlCZUR7ThV5ACeIO2y DG+DRIroPDDqxpVveIREmnA= =wDOB -----END PGP SIGNATURE----- --rV8arf8D5Dod9UkK-- From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 12:39:56 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF111065670 for ; Sat, 12 Apr 2008 12:39:56 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1918FC1B for ; Sat, 12 Apr 2008 12:39:56 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wf-out-1314.google.com with SMTP id 25so870228wfa.7 for ; Sat, 12 Apr 2008 05:39:56 -0700 (PDT) Received: by 10.142.70.17 with SMTP id s17mr251197wfa.303.1208002321011; Sat, 12 Apr 2008 05:12:01 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id 28sm6973319wfd.1.2008.04.12.05.11.59 (version=SSLv3 cipher=OTHER); Sat, 12 Apr 2008 05:12:00 -0700 (PDT) Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: <20080412021209.W43186@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: VOP_LEASE 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, 12 Apr 2008 12:39:56 -0000 As far as I can tell this has never been used. Unless someone can show me otherwise I'm going to go ahead and remove it. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 13:16:09 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F66106566C; Sat, 12 Apr 2008 13:16:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 79EB68FC12; Sat, 12 Apr 2008 13:16:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JkfaR-000Ffh-Rf; Sat, 12 Apr 2008 16:16:08 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3CDGDQk005667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 16:16:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3CDG4uH082249; Sat, 12 Apr 2008 16:16:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m3CDG4CD082248; Sat, 12 Apr 2008 16:16:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Apr 2008 16:16:04 +0300 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20080412131604.GX21209@deviant.kiev.zoral.com.ua> References: <20071218092222.GA9695@freebsd.org> <200712201138.56423.jhb@freebsd.org> <20080412112019.GI45299@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lFRK9w0o3gensELN" Content-Disposition: inline In-Reply-To: <20080412112019.GI45299@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: a14d1af8d19e5cbf0f3a8f9bfbb6792f X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2617 [Apr 11 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Roman Divacky , rwatson@FreeBSD.garage.freebsd.pl, freebsd-arch@freebsd.org Subject: Re: final decision about *at syscalls 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, 12 Apr 2008 13:16:10 -0000 --lFRK9w0o3gensELN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 12, 2008 at 01:20:19PM +0200, Pawel Jakub Dawidek wrote: > On Thu, Dec 20, 2007 at 11:38:55AM -0500, John Baldwin wrote: > > On Tuesday 18 December 2007 04:22:22 am Roman Divacky wrote: > > > Dear arch@ > > >=20 > > > Over this summer I was working (among other things) on *at family of = syscalls > > > kindly sponsored by Google (in their Summer of Code). The resulting p= atch is=20 > > > almost finished but I need to decide one design question. If you are = not interested=20 > > > in *at/namei feel free to skip this mail. > > >=20 > > > The *at syscalls are a threads-oriented extension to basic file sysca= lls (think > > > of open(), fstat(), etc.) adding the possibility to specify from wher= e the search > > > for relative path should start. > > >=20 > > > image that we have /tmp/foo/bar > > >=20 > > > and CWD is set to "/tmp/", and the process has opened "foo" as dirfd.= with ordinary > > > open() syscall you have to either > > >=20 > > > chdir("/tmp/foo");open("./bar"); > > >=20 > > > or > > >=20 > > > open("/tmp/foo/bar"); > > >=20 > > > The first approach is problematic because it changes CWD for all thre= ads in the process, > > > the second is prone to race-conditions as some of the components of t= he path can > > > change in parallel with the "open". > > >=20 > > > So POSIX introduced a new API, called "Extended API set part 2, ISBN:= 1-931624-67-4" (at > > > least this was the latest when I looked last time), which solves that= by introducing "*at" > > > syscalls that supply an fd of previously opened directory which is us= ed instead of CWD > > > for searching relative path, ie. the previous example becomes > > >=20 > > > dirfd =3D open("/tmp/foo"); openat("foo", dirfd); > > >=20 > > > I implemented the whole API as native FreeBSD syscalls + in linuxulat= or emulation layer. > > > Here's the problem: > > >=20 > > > There are two approaches to the name translation from "filedescriptor= " to the "vnode". > > >=20 > > > 1) we can do it in the kern_fooat() syscall and pass namei() the resu= lting vnode > > > 2) we can pass namei() the filedescriptor and do the translation there > > >=20 > > > PROs of #1: > > >=20 > > > o namei() does not need to know about the curthread, you can use thi= s *at > > > ability for different purposes, it's cleaner (imho) > > >=20 > > > PROs of #2 > > >=20 > > > o raceless implementation > > > o no code duplication > > >=20 > > > CONs of #1 > > >=20 > > > o some very small code duplication (the translation is done in every= =20 > > > kern_fooat() function) > > > o there is a race between the name translation and the actual use of= the result > > > of the translation that needs to be handled, the "path_to_file" str= ing is copied > > > to the kernel space twice hence a race > > >=20 > > > CONs of #2 > > >=20 > > > o namei is made thread dependant =09 > > >=20 > > > Please tell me what approach you like more. I personally favour #1 be= cause I don't like namei() > > > being thread dependant, Kostik Belousov prefers #2. > >=20 > > Considering Robert's paper on security race problems in things like sys= trace > > stemming from when you copy parameters out of userland and into the ker= nel > > multiple times, I think #2 is definitely the better choice. Also, name= i() is > > already thread aware AFAICT since 'struct componentname' already contai= ns a > > 'cnp_thread' member (was 'cnp_proc' in 4.x). >=20 > It looks like I'm a bit too late, but anyway... >=20 > From what you write John, #1 is a better choice than #2. If you want to > avoid races, you can pass already locked vnode. In case of file > descriptors, if p_fd is not locked another thread can close and open > different directory under the same descriptor number. This is the application imposed race, not the externally imposed one. Moreover, I would argue that this is application error. >=20 > I also need such functionality for recent ZFS and #2 makes it impossible > to use it. NDINIT_AT() is kernel (VFS) API so it should operate on > vnodes, not file descriptor numbers, IMHO. Following the same arguments, NDINIT() shall not operate on the pathes too. >=20 > For completness can you Kostik and Robert provide your arguments against > #1? The #2 was already committed. The #1 caused a code duplication that was quite error-prone. What are your problems with the #2 ? --lFRK9w0o3gensELN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkgAthMACgkQC3+MBN1Mb4gDYwCgykUIzTo3qvA5x0Ur5om8U88Q QcEAoNn6skWv0ohUmvvp8V+XrcV0Xv4b =cBi2 -----END PGP SIGNATURE----- --lFRK9w0o3gensELN-- From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 17:03:02 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF63F106564A for ; Sat, 12 Apr 2008 17:03:02 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id 7D70D8FC0C for ; Sat, 12 Apr 2008 17:03:02 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost.mckusick.com [127.0.0.1]) by chez.mckusick.com (8.13.8/8.13.8) with ESMTP id m3CH3StJ081660; Sat, 12 Apr 2008 10:03:28 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <200804121703.m3CH3StJ081660@chez.mckusick.com> To: Jeff Roberson Date: Sat, 12 Apr 2008 10:03:28 -0700 From: Kirk McKusick Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 17:03:02 -0000 > Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) > From: Jeff Roberson > To: arch@freebsd.org > Subject: VOP_LEASE > > As far as I can tell this has never been used. Unless someone can show me > otherwise I'm going to go ahead and remove it. > > Thanks, > Jeff VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file is modified locally so that they know to update any outstanding leases (e.g., evict any write lease for the file and do callbacks for any read leases for the file). Deleting VOP_LEASE would break NFS big time. Kirk McKusick From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 17:24:12 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A861065685 for ; Sat, 12 Apr 2008 17:24:12 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (mail.rabson.org [IPv6:2002:50b1:e8f2:1::143]) by mx1.freebsd.org (Postfix) with ESMTP id 95BD58FC23 for ; Sat, 12 Apr 2008 17:24:12 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2002:50b1:e8f2:1:21b:63ff:feb8:5abc] (unknown [IPv6:2002:50b1:e8f2:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id BC0603FA7; Sat, 12 Apr 2008 18:24:11 +0100 (BST) Message-Id: <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> From: Doug Rabson To: Kirk McKusick In-Reply-To: <200804121703.m3CH3StJ081660@chez.mckusick.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 12 Apr 2008 18:24:11 +0100 References: <200804121703.m3CH3StJ081660@chez.mckusick.com> X-Mailer: Apple Mail (2.919.2) Cc: arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 17:24:13 -0000 On 12 Apr 2008, at 18:03, Kirk McKusick wrote: >> Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) >> From: Jeff Roberson >> To: arch@freebsd.org >> Subject: VOP_LEASE >> >> As far as I can tell this has never been used. Unless someone can >> show me >> otherwise I'm going to go ahead and remove it. >> >> Thanks, >> Jeff > > VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file > is modified locally so that they know to update any outstanding > leases (e.g., evict any write lease for the file and do callbacks > for any read leases for the file). Deleting VOP_LEASE would break > NFS big time. I think our NQNFS support might have been removed some time ago - I can't see any calls to VOP_LEASE in the code right now. Something like VOP_LEASE would certainly be useful for a hypothetical future NFSv4 server. I believe that samba could use it too for its oplocks feature which appears to be similar to NQNFS's leases and NFSv4's delegations. From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 19:41:41 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB751065671 for ; Sat, 12 Apr 2008 19:41:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4BC8FC31 for ; Sat, 12 Apr 2008 19:41:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m3CJfeiJ004485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 12:41:40 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48011074.9060906@freebsd.org> Date: Sat, 12 Apr 2008 12:41:40 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Doug Rabson References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> In-Reply-To: <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 19:41:41 -0000 Doug Rabson wrote: > > On 12 Apr 2008, at 18:03, Kirk McKusick wrote: > >>> Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) >>> From: Jeff Roberson >>> To: arch@freebsd.org >>> Subject: VOP_LEASE >>> >>> As far as I can tell this has never been used. Unless someone can >>> show me >>> otherwise I'm going to go ahead and remove it. >>> >>> Thanks, >>> Jeff >> >> VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file >> is modified locally so that they know to update any outstanding >> leases (e.g., evict any write lease for the file and do callbacks >> for any read leases for the file). Deleting VOP_LEASE would break >> NFS big time. > > I think our NQNFS support might have been removed some time ago - I > can't see any calls to VOP_LEASE in the code right now. Something like > VOP_LEASE would certainly be useful for a hypothetical future NFSv4 > server. I believe that samba could use it too for its oplocks feature > which appears to be similar to NQNFS's leases and NFSv4's delegations. > Note NQNFS is long dead (netbsd removed it also not too long ago--together with VOP_LEASE). Jeff doesn't say why he wants to remove it but it might be best removed only to return when there's a real consumer of the api. Sam From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 22:59:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D289E106566B for ; Sat, 12 Apr 2008 22:59:45 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AED058FC0C for ; Sat, 12 Apr 2008 22:59:45 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A75E81A4D7E; Sat, 12 Apr 2008 15:59:45 -0700 (PDT) Date: Sat, 12 Apr 2008 15:59:45 -0700 From: Alfred Perlstein To: Sam Leffler Message-ID: <20080412225945.GY95731@elvis.mu.org> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <48011074.9060906@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48011074.9060906@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 22:59:45 -0000 * Sam Leffler [080412 12:41] wrote: > Doug Rabson wrote: > > > >On 12 Apr 2008, at 18:03, Kirk McKusick wrote: > > > >>>Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) > >>>From: Jeff Roberson > >>>To: arch@freebsd.org > >>>Subject: VOP_LEASE > >>> > >>>As far as I can tell this has never been used. Unless someone can > >>>show me > >>>otherwise I'm going to go ahead and remove it. > >>> > >>>Thanks, > >>>Jeff > >> > >>VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file > >>is modified locally so that they know to update any outstanding > >>leases (e.g., evict any write lease for the file and do callbacks > >>for any read leases for the file). Deleting VOP_LEASE would break > >>NFS big time. > > > >I think our NQNFS support might have been removed some time ago - I > >can't see any calls to VOP_LEASE in the code right now. Something like > >VOP_LEASE would certainly be useful for a hypothetical future NFSv4 > >server. I believe that samba could use it too for its oplocks feature > >which appears to be similar to NQNFS's leases and NFSv4's delegations. > > > > Note NQNFS is long dead (netbsd removed it also not too long > ago--together with VOP_LEASE). Jeff doesn't say why he wants to remove > it but it might be best removed only to return when there's a real > consumer of the api. We have people on the verge of implementing NFSv4, in fact we have a half-done client right now. I don't think it makes sense to remove it as I have stated before. -Alfred From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 23:13:45 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C332D106566B for ; Sat, 12 Apr 2008 23:13:45 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9359C8FC16 for ; Sat, 12 Apr 2008 23:13:45 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id k17so1154415waf.3 for ; Sat, 12 Apr 2008 16:13:45 -0700 (PDT) Received: by 10.114.192.1 with SMTP id p1mr5176228waf.47.1208042025033; Sat, 12 Apr 2008 16:13:45 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id n33sm7925132wag.47.2008.04.12.16.13.43 (version=SSLv3 cipher=OTHER); Sat, 12 Apr 2008 16:13:44 -0700 (PDT) Date: Sat, 12 Apr 2008 13:15:04 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Doug Rabson In-Reply-To: <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> Message-ID: <20080412131017.S43186@desktop> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 23:13:45 -0000 On Sat, 12 Apr 2008, Doug Rabson wrote: > > On 12 Apr 2008, at 18:03, Kirk McKusick wrote: > >>> Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) >>> From: Jeff Roberson >>> To: arch@freebsd.org >>> Subject: VOP_LEASE >>> >>> As far as I can tell this has never been used. Unless someone can show me >>> otherwise I'm going to go ahead and remove it. >>> >>> Thanks, >>> Jeff >> >> VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file >> is modified locally so that they know to update any outstanding >> leases (e.g., evict any write lease for the file and do callbacks >> for any read leases for the file). Deleting VOP_LEASE would break >> NFS big time. > > I think our NQNFS support might have been removed some time ago - I can't see > any calls to VOP_LEASE in the code right now. Something like VOP_LEASE would > certainly be useful for a hypothetical future NFSv4 server. I believe that > samba could use it too for its oplocks feature which appears to be similar to > NQNFS's leases and NFSv4's delegations. So the idea with delegations is that close() doesn't actually release the file entirely to make future access cheaper? My issue with VOP_LEASE is only that there are no in kernel implementations of the VOP. I doubt it is applied regularly in syscalls. It also seems odd that it is called without a lock. Is the intent that the server will trap all accesses to a local vnode in order to invalidate the client leases? Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 23:45:48 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2566E106566C for ; Sat, 12 Apr 2008 23:45:48 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 04D938FC16 for ; Sat, 12 Apr 2008 23:45:47 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id F15401A4D7E; Sat, 12 Apr 2008 16:45:47 -0700 (PDT) Date: Sat, 12 Apr 2008 16:45:47 -0700 From: Alfred Perlstein To: Jeff Roberson Message-ID: <20080412234547.GZ95731@elvis.mu.org> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080412131017.S43186@desktop> User-Agent: Mutt/1.4.2.3i Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 23:45:48 -0000 * Jeff Roberson [080412 16:13] wrote: > On Sat, 12 Apr 2008, Doug Rabson wrote: > > > > >On 12 Apr 2008, at 18:03, Kirk McKusick wrote: > > > >>>Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) > >>>From: Jeff Roberson > >>>To: arch@freebsd.org > >>>Subject: VOP_LEASE > >>> > >>>As far as I can tell this has never been used. Unless someone can show > >>>me > >>>otherwise I'm going to go ahead and remove it. > >>> > >>>Thanks, > >>>Jeff > >> > >>VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file > >>is modified locally so that they know to update any outstanding > >>leases (e.g., evict any write lease for the file and do callbacks > >>for any read leases for the file). Deleting VOP_LEASE would break > >>NFS big time. > > > >I think our NQNFS support might have been removed some time ago - I can't > >see any calls to VOP_LEASE in the code right now. Something like VOP_LEASE > >would certainly be useful for a hypothetical future NFSv4 server. I > >believe that samba could use it too for its oplocks feature which appears > >to be similar to NQNFS's leases and NFSv4's delegations. > > So the idea with delegations is that close() doesn't actually release the > file entirely to make future access cheaper? > > My issue with VOP_LEASE is only that there are no in kernel > implementations of the VOP. I doubt it is applied regularly in syscalls. > It also seems odd that it is called without a lock. > > Is the intent that the server will trap all accesses to a local vnode in > order to invalidate the client leases? VOP_LEASE is supposed to implemented by a filesystem client. For insance, NFS client with NQNFS would implement the VOP_LEASE and trap those accesses to manage the lease with the remote server. The remote server would get "lease RPCs" from the client and manage the cache appropriately. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 23:49:56 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16C12106564A for ; Sat, 12 Apr 2008 23:49:56 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id C62898FC18 for ; Sat, 12 Apr 2008 23:49:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so337995rvf.43 for ; Sat, 12 Apr 2008 16:49:55 -0700 (PDT) Received: by 10.141.74.17 with SMTP id b17mr2470617rvl.113.1208044195334; Sat, 12 Apr 2008 16:49:55 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id f21sm7359486rvb.0.2008.04.12.16.49.53 (version=SSLv3 cipher=OTHER); Sat, 12 Apr 2008 16:49:54 -0700 (PDT) Date: Sat, 12 Apr 2008 13:51:15 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: <20080412132457.W43186@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: f_offset 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, 12 Apr 2008 23:49:56 -0000 So I'm in the midst of working on other filesystem concurrency issues and that has brought me back around to f_offset again. I'm working on a method to allow non-overlapping writes and reads to proceed concurrently to the same file. This means the exclusive vnode lock can not be used to protect f_offset even in the write case. To maintain the existing semantics I'm simply going to add an exclusive sx_xlock() around access to f_offset. This is done inconsistently today which is fine from the perspective of the updates in most cases being user-space races. However, f_offset is 64bit and can not be written atomically on 32bit systems and so requires some extra synchronization there. The sx lock will nearly double the size of struct file. Although it's lost some weight in 8.0 that is quite unfortunate. However, the method of using LOCKED & WAITING flags, msleep and a mutex has ruined performance in too many cases to continue using it. It's worth discussing what posix actually guarantees for f_offset as well as what other operating systems do. POSIX actually does not guarantee any behavior with simultaneous access. Multiple readers may read the same position in the file concurrently and update the position to different offsets. Multiple writers may write to the same file location, although the io should be serialized by some other means. Posix allows for and Solaris, Linux, and historic implementations of f_offset work in the following way: off = fp->f_offset; lock(vnode); vn_rdwr() unlock(vnode) fp->f_offset = uio->uio_offset; What we implement is much stricter. It is essentially this: lock(offset); off = fp->f_offset; lock(vnode); vn_rdwr() unlock(vnode); fp->f_offset = uio->uio_offset; unlock(offset); We provide the following extra guarantees: 1) Multiple readers will never see overlapping segments of the file 2) Multiple writers will never write to overlapping segments of the file McKusick changed the behavior in 1986, I would guess for an rforked process. There is some test code in this fairly interesting lkml thread where they discuss the problem in linux: http://lkml.org/lkml/2006/4/12/227 Simply having multiple threads write to stdout in a file on linux is enough to lose or corrupt output. I believe it is worth retaining the write guarantee. However, I believe the read guarantees are simply a side-effect of the original implementation of the write fix. I will probably commit a patch to add the sx with exclusive behavior to start. We need to at least protect 64bit access on 32bit machines in lseek() which we don't today. Beyond that I think we can relax the read restriction and allow f_offset readers to operate locklessly and only serialize writers. For this to work it would be nice if we had a MD way to write 64bits atomically that simply acquired a lock on 32bit platforms without something like cmpxchg8b. Or on UP just did the write with interrupts disabled. Comments? Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sat Apr 12 23:51:54 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E6801065671 for ; Sat, 12 Apr 2008 23:51:54 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA868FC13 for ; Sat, 12 Apr 2008 23:51:53 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so338361rvf.43 for ; Sat, 12 Apr 2008 16:51:53 -0700 (PDT) Received: by 10.141.48.10 with SMTP id a10mr2479771rvk.35.1208044313778; Sat, 12 Apr 2008 16:51:53 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id g31sm7351027rvb.7.2008.04.12.16.51.51 (version=SSLv3 cipher=OTHER); Sat, 12 Apr 2008 16:51:53 -0700 (PDT) Date: Sat, 12 Apr 2008 13:53:13 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Alfred Perlstein In-Reply-To: <20080412234547.GZ95731@elvis.mu.org> Message-ID: <20080412135135.V43186@desktop> References: <200804121703.m3CH3StJ081660@chez.mckusick.com> <41ED3941-E5E6-45F0-B880-C1B2861FDE32@rabson.org> <20080412131017.S43186@desktop> <20080412234547.GZ95731@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kirk McKusick , arch@freebsd.org Subject: Re: VOP_LEASE 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, 12 Apr 2008 23:51:54 -0000 On Sat, 12 Apr 2008, Alfred Perlstein wrote: > * Jeff Roberson [080412 16:13] wrote: >> On Sat, 12 Apr 2008, Doug Rabson wrote: >> >>> >>> On 12 Apr 2008, at 18:03, Kirk McKusick wrote: >>> >>>>> Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST) >>>>> From: Jeff Roberson >>>>> To: arch@freebsd.org >>>>> Subject: VOP_LEASE >>>>> >>>>> As far as I can tell this has never been used. Unless someone can show >>>>> me >>>>> otherwise I'm going to go ahead and remove it. >>>>> >>>>> Thanks, >>>>> Jeff >>>> >>>> VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file >>>> is modified locally so that they know to update any outstanding >>>> leases (e.g., evict any write lease for the file and do callbacks >>>> for any read leases for the file). Deleting VOP_LEASE would break >>>> NFS big time. >>> >>> I think our NQNFS support might have been removed some time ago - I can't >>> see any calls to VOP_LEASE in the code right now. Something like VOP_LEASE >>> would certainly be useful for a hypothetical future NFSv4 server. I >>> believe that samba could use it too for its oplocks feature which appears >>> to be similar to NQNFS's leases and NFSv4's delegations. >> >> So the idea with delegations is that close() doesn't actually release the >> file entirely to make future access cheaper? >> >> My issue with VOP_LEASE is only that there are no in kernel >> implementations of the VOP. I doubt it is applied regularly in syscalls. >> It also seems odd that it is called without a lock. >> >> Is the intent that the server will trap all accesses to a local vnode in >> order to invalidate the client leases? > > VOP_LEASE is supposed to implemented by a filesystem client. > > For insance, NFS client with NQNFS would implement the VOP_LEASE > and trap those accesses to manage the lease with the remote server. > > The remote server would get "lease RPCs" from the client and manage > the cache appropriately. So why isn't this done within the actual VOP? If the lease expires between calling VOP_LEASE and vn_lock(), VOP_READ() you have to do that work all over again anyway. I don't yet see why this is in filesystem independent code. I'm not asserting that it doesn't need to be. I'd just like to understand it better. Thanks, Jeff > > -- > - Alfred Perlstein >