Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754774AbcDGCnA (ORCPT ); Wed, 6 Apr 2016 22:43:00 -0400 Received: from mga01.intel.com ([192.55.52.88]:46770 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923AbcDGCm4 (ORCPT ); Wed, 6 Apr 2016 22:42:56 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,448,1455004800"; d="scan'208";a="949751824" From: "Zheng, Lv" To: "Purdila, Octavian" CC: "Rafael J. Wysocki" , Len Brown , "Matt Fleming" , Mark Brown , "Wolfram Sang" , Joel Becker , Christoph Hellwig , "linux-acpi@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Tirdea, Irina" Subject: RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs Thread-Topic: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs Thread-Index: AQHRizE6e+pEvLq6o0qNmDH8tBt2hp90ja9A///QvwCABlgQEP//1WgAgAHrdTCAAFWDgIABCn6A Date: Thu, 7 Apr 2016 02:42:50 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB66E60@SHSMSX101.ccr.corp.intel.com> References: <1459417026-6697-1-git-send-email-octavian.purdila@intel.com> <1459417026-6697-11-git-send-email-octavian.purdila@intel.com> <1AE640813FDE7649BE1B193DEA596E883BB66233@SHSMSX101.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E883BB6677B@SHSMSX101.ccr.corp.intel.com> <1AE640813FDE7649BE1B193DEA596E883BB66B8C@SHSMSX101.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDU0NjEwOWMtYTRlYi00ZWY2LTg5ZmMtMDE1NTE5NzQyZWFjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjhJaWRJUkVuVDBxcUNNdE5Tb1ZmS2lzb2ZxbXpNRWVra2UxSFkrK0NnZVE9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u372h6qi006915 Content-Length: 4087 Lines: 92 Hi, > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Octavian Purdila > Subject: Re: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs > > On Wed, Apr 6, 2016 at 9:05 AM, Zheng, Lv wrote: > > >> It is hard to create new kernel objects from sysfs. You need to resort > >> to hacks like using new_table sysfs entries which does not map to a > >> kernel object. Writes larger then PAGE_SIZE are impossible to handle > >> with multiple open files because you have no open callback to create a > >> file context. It is also not possible to do any clean-up because there > >> is no close callback and if something goes wrong for example when > >> trying to install the table you will leak the allocated memory. > >> > >> configfs was designed for the specific purpose of creating kernel > >> objects from userspace and addresses all of the limitations above (and > >> some more). > >> > >> Initially I started to implement this functionality via sysfs but I > >> run into the issues mentioned above and decided to use configfs. > > [Lv Zheng] > > I can sense different difficulties from your descriptions. > > Let me break it down into details. > > > > We already have acpi_table_handler working there for creating new ACPI > table entries for us. > > Based on this facility, let's think about the following solution: > > 1. sysfs presenting change > > We can change the table file to a table directory whose name is in the > following format: > > TableSignature-OemId-OemTableId > > Then we can get rid of the annoying numbered table name suffix first. > > The numbered table name suffix cannot be kept consistent to reflect the real > index if we allow tables to be dynamically loaded/unloaded. > > > > This is the first design difficulty we need to solve. > > > > 2. acpi_table_handler change > > Now we can append 2 new events to acpi_table_handler - > ACPI_TABLE_INSTALL/ACPI_TABLE_UNINSTALL. > > With which, the sysfs entries can be created/deleted when the table is added > to/removed from the global table list. > > And this should be the working mechanism for us > > So we actually don't have the trouble to deal with the new kernel object > creation/deletion from sysfs. > > > > I agree the dynamic kernel object creation/deletion need special care. > > But this actually is what a kernel engineer should do because this kind of > things happen here and there throughout the kernel. > > We should have already been used to that. > > > > This is the second engineering difficulty we need to face. > > > > 3. load/unload commanding > > Now we need a character device in sysfs to handle load/unload command. > > Well, there are many such kind of files in sysfs, for example, device nodes. > > So this is not a non-achievable task, but just a difficult engineering task. > > The system engineers need to be skillful enough to implement this. > > Like the dynamic kernel object handling, we should have already been used to > this. > > > > > > If you still think this is difficult, the alternative choice is to use acpidbg char > device's ioctl interface. > > That could simplifies this task. > > And since the ioctl interface is required by ACPICA disassembler, the work on > that will be inherited by the disassembler porting. > > > > Why can't the dissembler access the tables through the existing sysfs interface? [Lv Zheng] The acpidbg utility should be self-contained. It will be back ported to ACPICA. So it might be ported to other OSPMs. >From this point of view, acpidbg need such kind of design - doing everything it need from an OSPM kernel using a single char device. Thanks and best regards -Lv > > > This is the last engineering difficulty we need to face. > > > > So why can't these solutions work for us? > > > > It can be done, but it is not the right way to do it, IMO. > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html