From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFKek-0001xW-ES for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:15:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFKef-0000Jl-CS for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:15:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFKef-0000Jb-6K for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:15:13 -0400 Message-ID: <55A640BC.7090301@redhat.com> Date: Wed, 15 Jul 2015 13:15:08 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU> <55A443A6.7040601@redhat.com> <20150714170019.GN1606@HEDWIG.INI.CMU.EDU> <1436958390.25906.7.camel@intel.com> In-Reply-To: <1436958390.25906.7.camel@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matt Fleming , "Gabriel L. Somlo" Cc: mdroth@linux.vnet.ibm.com, rjones@redhat.com, jordan.l.justen@intel.com, "Gabriel L. Somlo" , qemu-devel@nongnu.org, gleb@cloudius-systems.com, kraxel@redhat.com, pbonzini@redhat.com On 07/15/15 13:06, Matt Fleming wrote: > On Tue, 2015-07-14 at 13:00 -0400, Gabriel L. Somlo wrote: >> >> That being said, I did reimplement systemd's escape method in cca. 30 >> lines of C, so that shouldn't be too onerous. > > I really don't see a reason to use systemd's naming scheme instead of > the one already provided by the kernel. > >> Besides, Laszlo said he liked a real folder hierarchy, and I do too, >> so I'm still pondering how much doing that would complicate the module >> init function. I'm somewhat worried about what the added complexity >> will mean in terms of upstream acceptance in the linux kernel :) > > Yeah, going that route will complicate the patch and you're going to get > asked "Umm.. why?" by Greg Kroah-Hartman (definitely Cc Greg when > sending this to the kernel mailing lists btw). > > But if you can provide sound technical arguments for the added > complexity I'm sure the kernel folks will be happy. Laszlo's argument > makes sense to me, i.e. wanting to use standard utilities to know > whether a blob is available. > > Instead of rolling all this kobject-creation logic into your driver I'd > suggest writing a patch to lib/kobject.c., since the problem sounds like > something that should be solved with the kobject API. Haha, this feature just got extended by six months. :) > The question is, how simple can you make the code ;-) The first question is how strong Gabriel's nerves are, but (from past experience) they *are* strong. :) Laszlo