From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH/RFC] exposing ACPI objects in sysfs Date: Tue, 21 Sep 2004 21:31:04 +0200 Sender: linux-kernel-owner@vger.kernel.org Message-ID: <20040921193104.GC30425@elf.ucw.cz> References: <1095716476.5360.61.camel@tdi> <20040921122428.GB2383@elf.ucw.cz> <1095785315.6307.6.camel@tdi> <20040921172625.GA30425@elf.ucw.cz> <1095789614.24751.31.camel@tdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1095789614.24751.31.camel@tdi> To: Alex Williamson Cc: acpi-devel , linux-kernel List-Id: linux-acpi@vger.kernel.org Hi! > So, I think the library wrapper will need to deal with the 32/64 bit > problem or we'll have to translate data structures to strictly defined > sizes. Any other thoughts on how this could be done? I'm concerned > about alignment issues too, so this is definitely an area that could use > some work. You can't count on library. On 32-bit only system, noone will debug the library. Then 64-bit extensions came. 64-bit kernel has to be binary compatible with 32-bit applications. > > Perhaps ioctl is really right thing to use here? read() should not > > have side effects and it solves 32/64 bit problem. > > If it solved the entire 32/64 bit problem, an ioctl would probably be > the right choice. But it doesn't AFAICT. I also like how this > implementation fits into the existing ACPI sysfs tree and that you can > get useful info simply by cat'ing a file. Thanks, Well, you also get nasty sideeffects by simply catting the file. ioctl() does not solve entire 32/64 bit problem, but it at least makes the problem solvable. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!