Am Montag 11 August 2008 02:53:44 schrieb Stephane Marchesin:
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote:
I might be totaly wrong so feel free to ignore these. I got the feeling
that the user test base on linux kernel is far bigger than ours. Also
i think that our test user base are
On 8/2/08, Jerome Glisse [EMAIL PROTECTED] wrote:
I might be totaly wrong so feel free to ignore these. I got the feeling
that the user test base on linux kernel is far bigger than ours. Also
i think that our test user base are people wanting lastest things with
old kernel, while i
On Thu, Aug 07, 2008 at 04:08:49PM -0700, Eric Anholt wrote:
a) BSD
I'd like to hear Robert's concerns here, but I've been working with some of
the BSD folks lately, and it seems like the main concerns are:
1) making it easy for contributors to identify which portions of code are
On Thu, 2008-07-31 at 19:53 -0700, Jesse Barnes wrote:
On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote:
Well, if the overhead of merging upstream is a concern, then how about
not worrying about bc at all and let people who want to back port deal
with it? Oh, and what about just
On Fri, Aug 1, 2008 at 6:27 PM, Dave Airlie [EMAIL PROTECTED] wrote:
Personally, I only use the existing DRM repo on old kernels because that's
how
it's structured. It's actually more work for me to download build a
recent
kernel, then update build the DRM drivers against it that
As we discussed on IRC last night, I think these changes are perfectly
reasonable (in fact just what I'd expect if we moved to this model).
Sure, it will force contributors to be more disciplined, but that's
probably a good thing anyway. I'd still like to hear from the BSD guys
about
Then this, the thing is to keep it building you need compat code, code
that can't go into Linus tree, so we end up with a tree that isn't like
Linus tree, and we still have to patch manage transitions so we don't save
anything doing this over what we have now.
I was thinking that
On Fri, 1 Aug 2008 17:29:39 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
The biggest thing I have against this is that it cuts our testing base
down, we have a small testing base already, cutting it further jsut to
benefit some developers who are frustrated isn't really a gain.
I
On Thu, Jul 31, 2008 at 10:53 PM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote:
Well, if the overhead of merging upstream is a concern, then how about
not worrying about bc at all and let people who want to back port deal
with it? Oh, and what
Personally, I only use the existing DRM repo on old kernels because that's
how
it's structured. It's actually more work for me to download build a
recent
kernel, then update build the DRM drivers against it that it is to simply
update the DRM drivers and build against my current
On Fri, 2008-08-01 at 15:45 -0700, Jesse Barnes wrote:
On Friday, August 1, 2008 3:27:33 pm Dave Airlie wrote:
So, I very much agree with your proposal and don't feel I can add
much, except to point out that a migration to in-tree drm development
doesn't need to be a big and painful
On Wed, Jul 30, 2008 at 10:58 PM, Dave Airlie [EMAIL PROTECTED] wrote:
What do you think?
We try to keep #ifdef's out of the code and in drm_compat.h instead.
Something like
#if linuxversion = 2.6.27
#define drm_on_each_cpu(handler, data, wait) ...
#else
...
#endif
and then
Well, if the overhead of merging upstream is a concern, then how about
not worrying about bc at all and let people who want to back port deal
with it? Oh, and what about just keeping the drm drivers in a linux
kernel tree? That'll make upstream merging even easier yet...
The less crap I
On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote:
Well, if the overhead of merging upstream is a concern, then how about
not worrying about bc at all and let people who want to back port deal
with it? Oh, and what about just keeping the drm drivers in a linux
kernel tree? That'll
On Wed, Jul 30, 2008 at 8:19 AM, Johannes Engel [EMAIL PROTECTED] wrote:
Hi folks,
this rather trivial patch makes drm compile again on kernel = 2.6.27. It is
necessary since in kernel 2.6.27 on_each_cpu (defined in
include/linux/smp.h) lost the third argument (retry).
What do you think?
We
What do you think?
We try to keep #ifdef's out of the code and in drm_compat.h instead.
Something like
#if linuxversion = 2.6.27
#define drm_on_each_cpu(handler, data, wait) ...
#else
...
#endif
and then just user drm_on_each_cpu in the code.
I'd prefer not to do that
16 matches
Mail list logo
