RE: [RFC PATCH 10/10] acpi: add support for loading SSDTs via configfs

[Zheng, Lv]

Hi,

> From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-
> owner@xxxxxxxxxxxxxxx] 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 <lv.zheng@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html