From owner-freebsd-current@FreeBSD.ORG Sun Feb 11 18:35:26 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F62516A407; Sun, 11 Feb 2007 18:35:26 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 141D213C474; Sun, 11 Feb 2007 18:35:25 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l1BIZPrd028654; Sun, 11 Feb 2007 10:35:25 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l1BIZO8q028653; Sun, 11 Feb 2007 10:35:24 -0800 (PST) (envelope-from rizzo) Date: Sun, 11 Feb 2007 10:35:24 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20070211103524.A28356@xorpc.icir.org> References: <20070202183453.A2996@xorpc.icir.org> <200702101735.12609.max@love2party.net> <20070210165921.A18732@xorpc.icir.org> <200702110425.40130.max@love2party.net> <20070211021427.A23377@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070211021427.A23377@xorpc.icir.org>; from rizzo@icir.org on Sun, Feb 11, 2007 at 02:14:27AM -0800 Cc: Subject: firmware(9) revision X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2007 18:35:26 -0000 Over the past days i have discussed with a few people (in Bcc) about issues in firmware(9) that i would like to fix and possibly MFC. I have prepared a revision version of the code at http://info.iet.unipi.it/~luigi/FreeBSD/firmware/ and would appreciate a review. If you see a discrepancy between the comments and the code, trust the comments. My main goal when i started this work was to fix some bugs related to the automatic unloading of firmware images, i.e.: - there is a potential race condition in the automatic unloading of modules, when [image] registry entries could be reused while the firmware_thread releases the lock to unload the container module; (affects HEAD and probably RELENG_6 as well) - incorrect handling of unload requests for images loaded from the bootloader (RELENG_6). (RELENG_6 might have more problems as the cleanup done to the code in HEAD has not been merged yet; but it is pointless to enter into details). While working on the code, more things came up, e.g. the handling of errors in unloading a module is unclear at best (and possibly buggy); the semantics of FIRMWARE_UNLOAD needs to be explained better; also, one could get the chance to cleanup the API (reducing the amount of internal information exposed to clients, and also putting const qualifiers on some arguments). Clearly, the API change in RELENG_6 needs to be carefully evaluated; on the other hand, the api change is limited to adding const qualifiers to the arguments, and removing some fields from a structure, as below: struct firmware { const char *name; /* system-wide name */ const void *data; /* location of image */ size_t datasize; /* size of image in bytes */ unsigned int version; /* version of the image */ - int refcnt; /* held references */ - struct firmware *parent; /* not null if a subimage */ - linker_file_t file; /* loadable module */ - int flags; /* FIRMWAREFLAG_ flags */ }; and clients are not supposed to touch or even look at such fields. So in practice there should be full compatibility at the binary level. cheers luigi