From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFKWO-0006FY-Mp for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:06:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFKWL-0002kg-FC for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:06:40 -0400 Received: from mga14.intel.com ([192.55.52.115]:30699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFKWL-0002kV-AQ for qemu-devel@nongnu.org; Wed, 15 Jul 2015 07:06:37 -0400 Message-ID: <1436958390.25906.7.camel@intel.com> From: Matt Fleming Date: Wed, 15 Jul 2015 12:06:30 +0100 In-Reply-To: <20150714170019.GN1606@HEDWIG.INI.CMU.EDU> References: <20150713200936.GK1606@HEDWIG.INI.CMU.EDU> <55A443A6.7040601@redhat.com> <20150714170019.GN1606@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: "Gabriel L. Somlo" Cc: mdroth@linux.vnet.ibm.com, rjones@redhat.com, "Gabriel L. Somlo" , gleb@cloudius-systems.com, qemu-devel@nongnu.org, kraxel@redhat.com, jordan.l.justen@intel.com, pbonzini@redhat.com, Laszlo Ersek 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. The question is, how simple can you make the code ;-)