Date: Thu, 15 Feb 2007 19:34:53 +0100 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Cc: Luigi Rizzo <rizzo@icir.org> Subject: Re: one last firmware(9) issue Message-ID: <200702151934.59638.max@love2party.net> In-Reply-To: <20070215094342.B91479@xorpc.icir.org> References: <20070215094342.B91479@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3018003.kHYPkS2kDF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 15 February 2007 18:43, Luigi Rizzo wrote: > I have committed the cleanup to firmware(9) discussed earlier > on this list, see the commit log below. There is a remaining issue > on which i would like some advice. From the commit log: > > Note also that there is a subtle issue with the implementation of > firmware_register(): currently, as in the previous version, we just > store a reference to the 'imagename' argument, but we should rather > copy it because there is no guarantee that this is a static string. > > Now, what do you think is the best way to handle this ? The existing > code tries not to allocate memory on a firmware_register(), not > sure if it is on purpose (e.g. to avoid sleeping) or for other > reasons. To preserve this, we should use static buffers for the > image names, and pick a reasonable size for them (128 ? 256 ? 1025 ?). > > If on the other hand, we can afford a malloc in firmware_register(), > i'd move the whole registry to a linked list, to avoid the hard limit > of 30 slots in the firmware table. > > suggestions ? I say, let the caller deal with it. After all the caller must ensure that= =20 the firmware itself stays in memory until they call firmware_unregister,=20 why should we jump through all the hoops for the name? The linked list is another thing. As I recall, the static array is only=20 there due to our lazyness. It's a lot easier to use a static array and I=20 don't forsee us using more than 30 firmware images at a time. OTOH, it=20 would of course be nice to have a more flexible system. I'm not 100%=20 certain what the locking constrains for firmware_register() are. Usually=20 it is called from the mod_event of a firmware module, which in turn is=20 called from the linker subsystem. There might be some locks involved=20 that would prevent you from sleeping, but that's just a wild guess. Thanks for taking care of this, by the way. Much appreciated. =2D-=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 --nextPart3018003.kHYPkS2kDF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF1KfTXyyEoT62BG0RAme7AJ9t675pniD6Gzszp2Z/7+ptN221sgCfQg3W xn018rLc9EKGyWrIW4D87L0= =o/NM -----END PGP SIGNATURE----- --nextPart3018003.kHYPkS2kDF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702151934.59638.max>