From: Eric Anholt <eta@lclark.edu>
To: Dave Airlie <airlied@linux.ie>
Cc: linux-kernel@vger.kernel.org, DRI <dri-devel@lists.sourceforge.net>
Subject: Re: drm - first steps towards 64-bit correctness..
Date: Sat, 31 Jul 2004 02:32:25 -0700 [thread overview]
Message-ID: <1091266345.425.34.camel@leguin> (raw)
In-Reply-To: <Pine.LNX.4.58.0407310940540.6368@skynet>
On Sat, 2004-07-31 at 02:13, Dave Airlie wrote:
> Hi,
> As a first step towards sorting getting the DRM into shape for
> proper use on 32/64-bit systems, I'd like to sort out all the type
> definitions in drivers/char/drm/drm.h, this file is also included in
> userspace and BSD builds...
>
> After reading the thread "32/64bit issues in ioctl struct passing" on
> dri-devel, I'm still not 100% sure what we need to do, I just know we to
> do something sooner rather than later!! we are getting more and more
> 32/64-bit users everyday....
> While avoiding breakage of current users is "a good thing" I'm not sure it
> overrides "getting it right", at the moment mixed 32/64-bit is broken for
> most cards anyways... I'd like to try and not break pure-32 or pure-64 bit
> setups alright but I think pure-64 bit might take some collateral damage
> :-(..
>
> I've looked across the SuSE patch[1] for 64-bit, but it looks like it will
> add complexity and making future maintenance nightmareish...
>
> We do need to sort this out ASAP, and I also would like to say I'm
> probably not the best person to do the work, I've no non-32bit hardware to
> test this stuff on, I've little 32/64 mixed environment experience,
> everytime I think I've grasped the issues I dig a bit further :-), though
> I also believe this is the single biggest issue with the DRM currently (as
> the maintainer..)
I've got a 64-bit cleanliness patch for SiS that I'd like to either get
someone else to review (preferable) or find time to re-read myself. I
replace the memory management code that existed with much less code
(using bsd queue macros that I'm more familiar with).
Once the flames die down in X.Org I'll isolate the diff from my very
dirty local drm tree and post it again.
I'm hoping that most of the general DRM fixes will be replacing longs
with fixed-size types that are the same on x86, but I haven't looked at
Egbert's diffs yet, unfortunately. As long as you don't use the linux-y
"u32"-type types, BSD should be happy with the changes.
--
Eric Anholt eta@lclark.edu
http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
next prev parent reply other threads:[~2004-07-31 9:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-31 9:13 drm - first steps towards 64-bit correctness Dave Airlie
2004-07-31 9:32 ` Eric Anholt [this message]
2004-07-31 9:54 ` Arjan van de Ven
2004-07-31 9:57 ` Eric Anholt
2004-07-31 10:06 ` William Lee Irwin III
2004-07-31 11:02 ` Dave Airlie
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=1091266345.425.34.camel@leguin \
--to=eta@lclark.edu \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sourceforge.net \
--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.