From owner-freebsd-firewire@FreeBSD.ORG Sun Sep 7 02:19:59 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B61911065676 for ; Sun, 7 Sep 2008 02:19:59 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8668FC19 for ; Sun, 7 Sep 2008 02:19:59 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 5CC041A9182; Sat, 6 Sep 2008 19:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-thEa0ntyQl; Sat, 6 Sep 2008 19:19:02 -0700 (PDT) Received: from [10.47.1.6] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id B39F51A90D1; Sat, 6 Sep 2008 19:19:02 -0700 (PDT) Message-ID: <48C33A35.6090203@miralink.com> Date: Sat, 06 Sep 2008 19:19:33 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Dieter References: <200808311934.TAA10392@sopwith.solgatos.com> In-Reply-To: <200808311934.TAA10392@sopwith.solgatos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-firewire@freebsd.org Subject: Re: New and improved? patch X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 02:19:59 -0000 > usage: > >> [-f force_root ] >> > > Suggestion: [-f force_root_node ] or maybe "desired_root_node" or maybe > "root_node" or maybe just "node", same as -c -d -o -s > > I think the variable name is fine, but the man page should be expanded. >> -g: broadcast gap_count by phy_config packet >> > > Suggestion: -g: set gap_count by broadcasting phy_config packet > or maybe just: -g: set gap_count > I agree. The description is deficient and should not only be expanded, but should reference the IEEE specifications, i.e. 1394a-2005 >> -f: broadcast force_root by phy_config packet >> > > Suggestion: -f force a node to become the root node by broadcasting phy_config packet > or maybe just: -f force a node to become the root node > > 7.0 AMD64 # ./fwcontrol -f -5 > fwcontrol: main:set_root_node out of range: No such file or directory > > "No such file or directory" seems wrong > > 7.0 AMD64 # ./fwcontrol -g 70 > fwcontrol: main:set_gap_count out of range: No such file or directory > > "No such file or directory" seems wrong > > 7.0 AMD64 # ./fwcontrol -d 70 > fwcontrol: no such node -1. > > (a) 70 becomes -1 ? > (b) Wouldn't -d have the same range as -f ? > > 7.0 AMD64 # ./fwcontrol -c 70 > fwcontrol: no such node -1. > > (a) 70 becomes -1 ? > (b) Wouldn't -c have the same range as -f ? > > 7.0 AMD64 # ./fwcontrol -o 70 > fwcontrol: main: node out of range: 70 > : No such file or directory > > "No such file or directory" seems wrong > > 7.0 AMD64 # ./fwcontrol -s 70 > fwcontrol: main: node out of range: 70 > : No such file or directory > > "No such file or directory" seems wrong > > > > - asyreq->pkt.mode.ld[1] |= (root_node & 0x3f) << 24 | 1 << 23; > + asyreq->pkt.mode.ld[1] |= ((root_node << 24) | (1 << 23)); > if (gap_count >= 0) > - asyreq->pkt.mode.ld[1] |= 1 << 22 | (gap_count & 0x3f) << 16; > + asyreq->pkt.mode.ld[1] |= ((1 << 22) | (gap_count << 16)); > > Any reason for pulling out the "& 0x3f" ? Yeah it should be redundant > now that there is range checking on the arguments, but as you said, > fwcontrol is dangerous and the mask makes it safer at very little cost. > > > I find a range check to be an easier reference than a bit mask/shift operation. I'd like the next guy who comes through the code to be able to understand the changes and the code path. Also, more comments are probably required. > - for (i = 0; i < 4; i++) { > - snprintf(name, sizeof(name), "%s.%d", devbase, i); > - if ((*fd = open(name, O_RDWR)) >= 0) > - break; > - } > + *fd = open(devname, O_RDWR); > > > Looking at various firewire man pages, I don't find any explanation of > the various /dev filenames, such as what the .%d part was/is for. So I > have no clue why this code was changed. Did I miss a discussion? > I'm going to have to put a big "I have no idea" here. This predates my attempts at stabilization. Let's examine it further in the driver code. Perhaps that will explain it's use. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From owner-freebsd-firewire@FreeBSD.ORG Sun Sep 7 02:20:36 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAE11065674 for ; Sun, 7 Sep 2008 02:20:36 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 821198FC21 for ; Sun, 7 Sep 2008 02:20:36 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 933F71A9182; Sat, 6 Sep 2008 19:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWQESnfgsxZq; Sat, 6 Sep 2008 19:19:40 -0700 (PDT) Received: from [10.47.1.6] (vpn.office.miralink.com [10.0.0.5]) by plato.miralink.com (Postfix) with ESMTP id 22F5B1A90D1; Sat, 6 Sep 2008 19:19:40 -0700 (PDT) Message-ID: <48C33A73.80504@miralink.com> Date: Sat, 06 Sep 2008 19:20:35 -0700 From: Sean Bruno User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Dieter References: <200808312005.UAA08072@sopwith.solgatos.com> In-Reply-To: <200808312005.UAA08072@sopwith.solgatos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-firewire@freebsd.org Subject: Re: New and improved? patch X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 02:20:36 -0000 Dieter wrote: >> 7.0 AMD64 # ./fwcontrol -f -5 >> fwcontrol: main:set_root_node out of range: No such file or directory >> >> "No such file or directory" seems wrong >> > > err(EX_USAGE, "%s:set_root_node out of range", __func__); > > Err() is correct for places where errno would be set, such as > checking the return code from read(2). But for the range checks, > errno does not apply, so err() gives misleading results. > > The err(3) man page isn't clear, but it looks like errx(3) is > the function you want for the range checks. > > Changing err() to errx() gives: > > 7.0 AMD64 # ./fwcontrol -f 70 > fwcontrol: main:set_root_node out of range > Yup. I completely agree here. -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: sbruno@miralink.com Google: seanwbruno@gmail.com From owner-freebsd-firewire@FreeBSD.ORG Sun Sep 7 06:28:51 2008 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2001065675 for ; Sun, 7 Sep 2008 06:28:51 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from parsely.rain.com (parsely.rain.com [199.26.172.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD8C8FC27 for ; Sun, 7 Sep 2008 06:28:51 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (uucp@localhost) by parsely.rain.com (8.11.4/8.11.4) with UUCP id m876SjN09234; Sat, 6 Sep 2008 23:28:45 -0700 (PDT) (envelope-from freebsd@sopwith.solgatos.com) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id GAA22550; Sun, 7 Sep 2008 06:24:12 GMT Message-Id: <200809070624.GAA22550@sopwith.solgatos.com> To: Sean Bruno In-reply-to: Your message of "Sat, 06 Sep 2008 19:19:33 PDT." <48C33A35.6090203@miralink.com> Date: Sat, 06 Sep 2008 23:24:12 +0100 From: Dieter Cc: freebsd-firewire@freebsd.org Subject: Re: New and improved? patch X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2008 06:28:51 -0000 > > - for (i = 0; i < 4; i++) { > > - snprintf(name, sizeof(name), "%s.%d", devbase, i); > > - if ((*fd = open(name, O_RDWR)) >= 0) > > - break; > > - } > > + *fd = open(devname, O_RDWR); > > > > > > > Looking at various firewire man pages, I don't find any explanation of > > the various /dev filenames, such as what the .%d part was/is for. So I > > have no clue why this code was changed. Did I miss a discussion? > > > I'm going to have to put a big "I have no idea" here. This predates my > attempts > at stabilization. Let's examine it further in the driver code. Perhaps > that will explain it's use. I've been working on getting your new fwcontrol to compile and run on NetBSD. Looks like FreeBSD used to use /dev/fw0.0 but now uses fw0, which...is...a symlink to fw0.0. I only have .0 no .[123] NetBSD still uses fw0.0, MAKEDEV doesn't create the symlink. So now you know why I noticed that fwcontrol doesn't tell you what filename it couldn't open. :-) Still no idea what the trailing digit is for, or why the fwcontrol code was changed. From owner-freebsd-firewire@FreeBSD.ORG Mon Sep 8 02:22:19 2008 Return-Path: Delivered-To: freebsd-firewire@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E3F51065675 for ; Mon, 8 Sep 2008 02:22:19 +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 7BD358FC1C for ; Mon, 8 Sep 2008 02:22:19 +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 m882MJjv006655 for ; Mon, 8 Sep 2008 02:22:19 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m882MIUM006651 for freebsd-firewire@FreeBSD.org; Mon, 8 Sep 2008 02:22:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Sep 2008 02:22:18 GMT Message-Id: <200809080222.m882MIUM006651@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-firewire@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-firewire@FreeBSD.org X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2008 02:22:19 -0000 The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/113785 firewire [firewire] dropouts when playing DV on firewire o kern/74238 firewire [firewire] fw_rcv: unknown response; firewire ad-hoc w 2 problems total. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned.