From: Francois Romieu <romieu@fr.zoreil.com>
To: Thomas Winischhofer <thomas@winischhofer.net>
Cc: Arjan van de Ven <arjanv@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: ioctl number 0xF3
Date: Mon, 24 May 2004 01:39:30 +0200 [thread overview]
Message-ID: <20040524013930.A21374@electric-eye.fr.zoreil.com> (raw)
In-Reply-To: <40AF73D5.5010202@winischhofer.net>; from thomas@winischhofer.net on Sat, May 22, 2004 at 05:37:57PM +0200
Thomas Winischhofer <thomas@winischhofer.net> :
[...]
> The interface I intend to use matches the one the X driver has (using
> the Xv extension as an ioctl replacement) and will be documented. Since
> I develope both the SiS kernel framebuffer driver as well as the SiS X
> driver this will reduce duplicate code and ensures good cooperation.
> Furthermore, there could be a common library for both the framebuffer and X.
As you apparently manage the utility, you are at the first place to handle
the incompatibilities as well. Fine :o)
> Hm. Were the matrox folks asked for a "clear interface" in advance when
> they started using the 'n' ioctls? Am I too polite? ;)
Nonononono. It is just a bit optimistic to hope for an instant solution
here if there has not been one so far on the xfree/friends side. Imo
there are some grey areas:
- what does the common part need;
- who can/want/will do the dirty work.
Looking at the code, there is no instant answer and things won't be set
in stone today. The best you can do is to minimize the pain in the future:
use as few ioctls as possible so that you can control/verify the changes
of interface trough a single point and design this interface so that it
takes into account that things will change. No silver bullet.
[...]
> sisfb uses a few ioctls already, as an extension to the generic fb
> related ioctls. (Although the version currently in mainline 2.4 is not
> in any way 32/64 bit safe, and neiter is the mainline 2.6 version yet as
> regards the obviously required ioctl32 emulation stuff - investigating
> this at the moment).
Consider reusing these ? It may be a bit academic as you control the main
utility anyway.
--
Ueimor
prev parent reply other threads:[~2004-05-23 23:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-22 12:08 Thomas Winischhofer
2004-05-22 12:20 ` Arjan van de Ven
2004-05-22 12:39 ` Thomas Winischhofer
2004-05-22 12:51 ` Arjan van de Ven
2004-05-22 13:29 ` Thomas Winischhofer
2004-05-22 14:32 ` Francois Romieu
2004-05-22 15:37 ` Thomas Winischhofer
2004-05-23 1:35 ` Petr Vandrovec
2004-05-23 23:39 ` Francois Romieu [this message]
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=20040524013930.A21374@electric-eye.fr.zoreil.com \
--to=romieu@fr.zoreil.com \
--cc=arjanv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@winischhofer.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®