Date: Sun, 11 Feb 2007 10:35:24 -0800 From: Luigi Rizzo <rizzo@icir.org> To: current@freebsd.org Subject: firmware(9) revision Message-ID: <20070211103524.A28356@xorpc.icir.org> In-Reply-To: <20070211021427.A23377@xorpc.icir.org>; from rizzo@icir.org on Sun, Feb 11, 2007 at 02:14:27AM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070211103524.A28356>