From: Pavel Machek <pavel@ucw.cz>
To: Alex Williamson <alex.williamson@hp.com>
Cc: acpi-devel <acpi-devel@lists.sourceforge.net>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC] exposing ACPI objects in sysfs
Date: Tue, 21 Sep 2004 21:31:04 +0200 [thread overview]
Message-ID: <20040921193104.GC30425@elf.ucw.cz> (raw)
In-Reply-To: <1095789614.24751.31.camel@tdi>
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!
next prev parent reply other threads:[~2004-09-21 19:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-20 21:41 [PATCH/RFC] exposing ACPI objects in sysfs Alex Williamson
2004-09-21 12:24 ` Pavel Machek
2004-09-21 14:18 ` Alex Williamson
2004-09-21 16:48 ` Alex Williamson
2004-09-21 17:26 ` Pavel Machek
2004-09-21 18:00 ` Alex Williamson
2004-09-21 19:31 ` Pavel Machek [this message]
2004-09-21 19:06 ` [ACPI] " Andi Kleen
2004-09-21 19:13 ` Alex Williamson
2004-09-21 19:18 ` Andi Kleen
2004-09-21 19:45 ` Alex Williamson
2004-09-21 19:58 ` Pavel Machek
2004-09-21 20:40 ` Alex Williamson
2004-09-21 21:02 ` Pavel Machek
[not found] ` <20040921210218.GJ30425-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2004-10-15 22:39 ` Alex Williamson
2004-10-15 22:39 ` [ACPI] " Alex Williamson
2004-10-26 20:55 ` [RFC] dev_acpi: support for userspace access to acpi Alex Williamson
2004-10-26 20:55 ` Alex Williamson
2004-09-21 19:21 ` [ACPI] Re: [PATCH/RFC] exposing ACPI objects in sysfs Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040921193104.GC30425@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=acpi-devel@lists.sourceforge.net \
--cc=alex.williamson@hp.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.