Thread (17 messages) 17 messages, 5 authors, 2004-10-26

Re: [ACPI] Re: [PATCH/RFC] exposing ACPI objects in sysfs

From: Alex Williamson <hidden>
Date: 2004-09-21 19:45:40
Also in: lkml

On Tue, 2004-09-21 at 21:18 +0200, Andi Kleen wrote:
quoted
   All pointers are actually interpreted as offsets into the buffer for
this interface.  They are not actually pointers.  I believe the 32bit
emulation problem is limited to an ILP32 application generating data
structures appropriate for an LP64 kernel.  While difficult, it can be
done.
If this involves patching the application - no it cannot be done.
The 64bit kernel is supposed to run vanilla 32bit user land.

Please find some other solution for this. An ioctl doesn't sound that bad.
   Please read the rest of my response to Pavel, I don't think we're on
the same page as to the extent of this problem.  There is no application
yet, we're in the process of architecting the interface to it right now.
Is it impossible to expect an ILP32 application to generate LP64 data
structures?  Perhaps the LP64 kernel interface could be made smart
enough to digest ILP32 data structures as Arjan suggests.

   I don't believe an ioctl solves all the problems.  An ioctl AND
redefining all the ACPI data types in use to a single ILP model might.
I think we lose a lot and add quite a bit of complexity in doing that
though.  Note the "pointer" in the command structure is superfluous, I'd
be happy to remove it, but that still leaves the basic ACPI data
structures.

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help