DRM and 2.4 ...

DRM and 2.4 ...

[Dave Airlie]

At the moment we are adding a lot of 2.6 stuff to the DRM under
development in the DRM CVS tree and what will be merged into the -mm and
Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
still work,

At some point we are going to make a change that will break 2.4, and I
won't be able to patch it up nicely...

So the question is do we want to a final stable DRM for 2.4 in the next
2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
tree (and maybe branch it ...),

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: DRM and 2.4 ...

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Mon, 2004-08-16 at 07:56, Dave Airlie wrote:
> At the moment we are adding a lot of 2.6 stuff to the DRM under
> development in the DRM CVS tree and what will be merged into the -mm and
> Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
> still work,

which is uglyfying the code significantly if done wrong

> So the question is do we want to a final stable DRM for 2.4 in the next
> 2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
> tree (and maybe branch it ...),

I would strongly urge you to no longer update DRM in 2.4 in significant
ways. 2.4 is the release for doing strict maintenance; people who want
to run newer X will generally run 2.6 kernels as well anyway.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: DRM and 2.4 ...

[Keith Whitwell]

Arjan van de Ven wrote:
> On Mon, 2004-08-16 at 07:56, Dave Airlie wrote:
> 
>>At the moment we are adding a lot of 2.6 stuff to the DRM under
>>development in the DRM CVS tree and what will be merged into the -mm and
>>Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
>>still work,
> 
> 
> which is uglyfying the code significantly if done wrong
> 
> 
>>So the question is do we want to a final stable DRM for 2.4 in the next
>>2.4 release? and after that point I can tag the 2.4 release in the DRM CVS
>>tree (and maybe branch it ...),
> 
> 
> I would strongly urge you to no longer update DRM in 2.4 in significant
> ways. 2.4 is the release for doing strict maintenance; people who want
> to run newer X will generally run 2.6 kernels as well anyway.

I'm not at all convinced we (ie the DRI project) can abandon 2.4 support.  In 
fact we made this mistake with the 2.2/2.4 transition - we didn't support 2.2 
at all, only 2.4 and for a long time this was a big inconvenience to users.

We may not be feeding our changes into the 2.4 kernel (or maybe we are), but I 
definitely view 2.4 support as important for probably 1 to 2 years to come.

If we can manage to support FreeBSD and Linux from one codebase, surely 
supporting 2.4 and 2.6 isn't too difficult?

Keith

Re: DRM and 2.4 ...

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
> 
> If we can manage to support FreeBSD and Linux from one codebase, surely 
> supporting 2.4 and 2.6 isn't too difficult?

It for sure is possible.
However the DRM codebase proves that it's incapable of even doing BSD
support properly (eg without the right abstractions but instead fouling up
the entire codebase to the point of unreadability). That gives me no
confidence the "keep 2.4 support" will not turn out to be at least as
ugly/broken/wrong.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: DRM and 2.4 ...

[Keith Whitwell]

Arjan van de Ven wrote:
> On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
> 
>>If we can manage to support FreeBSD and Linux from one codebase, surely 
>>supporting 2.4 and 2.6 isn't too difficult?
> 
> 
> It for sure is possible.
> However the DRM codebase proves that it's incapable of even doing BSD
> support properly (eg without the right abstractions but instead fouling up
> the entire codebase to the point of unreadability). That gives me no
> confidence the "keep 2.4 support" will not turn out to be at least as
> ugly/broken/wrong.

Well...  I think there's some confusion regarding how much of the macro-itis 
in the current DRM is related to support for freebsd and how much is just a 
reasonable idea taken too far.

Most of the abstractions that you're complaining about existed prior to the 
addition of freebsd support, and right now, Dave Airlie is doing good work 
returning the codebase to something less obscure.

Anyway, as far as I'm concerned 2.4 support is of primary importance to the 
people who actually use this code, so I will work to see it retained.

Keith

Re: DRM and 2.4 ...

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

On Mon, Aug 16, 2004 at 11:12:53AM +0100, Keith Whitwell wrote:
> Most of the abstractions that you're complaining about existed prior to the 
> addition of freebsd support

DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: DRM and 2.4 ...

[Dave Airlie]

>
> DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
> DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
> god...

I'm currently open for constructive critics with ideas on how to fix these
things, the DRM is open for business if we can fix things up now it will
be a lot easier while I'm knee deep with time than after I'm finished and
back travelling .. should we have try to implement Linux fns in BSD, what
do we do if more parameters/info are needed from a BSD side, or do we try
and sideline all these into a separate library of functions and wrap them
on both bsd and linux?

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: DRM and 2.4 ...

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Mon, Aug 16, 2004 at 11:42:00AM +0100, Dave Airlie wrote:
> 
> >
> > DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
> > DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
> > god...
> 
> I'm currently open for constructive critics with ideas on how to fix these
> things, the DRM is open for business if we can fix things up now it will
> be a lot easier while I'm knee deep with time than after I'm finished and
> back travelling .. should we have try to implement Linux fns in BSD, what
> do we do if more parameters/info are needed from a BSD side, or do we try
> and sideline all these into a separate library of functions and wrap them
> on both bsd and linux?

it's a bit of all of this.
If BSD doesn't have a conflicting udelay(), why not just implement one
there instead of a superfluous rename.
DRM_ERR() otoh should have been dealt with by making a core function for the
ioctl with only the really needed/used arguments (probably even such that
the arguments are already copied from userspace) and then a linux and a bsd
specific API wrapper. The BSD one can then easily flip the sign (that's
basically free), it also takes case of DRM_IOCTL_ARGS mess as well and
DRM_COPY_FROM_USER_IOCTL if you do it right.
DRM_CURRENTPID probably shouldn't exist at all, drivers shouldn't use pid's
in general.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: DRM and 2.4 ...

[Keith Whitwell]

Dave Airlie wrote:
>>DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
>>DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
>>god...

Heh.  I actually find those ones pretty innocuous and easy to work with, 
compared to some of the stuff in there.  Nothing that etags can't disambiguate 
for you.

What's more challenging is are the macros defined in the drivers which then 
customize the behaviour of shared header files - these are really the 
challenging aspect to working with that code, and what Dave has been working 
to remove.

> I'm currently open for constructive critics with ideas on how to fix these
> things, the DRM is open for business if we can fix things up now it will
> be a lot easier while I'm knee deep with time than after I'm finished and
> back travelling .. should we have try to implement Linux fns in BSD, what
> do we do if more parameters/info are needed from a BSD side, or do we try
> and sideline all these into a separate library of functions and wrap them
> on both bsd and linux?

Dave's hit the nail on the head here.  If you'd like some changes, feel free 
to make suggestions.

The macros you outline aren't great, but they aren't the real impediment to 
working with/understanding drm either.  But if we can fix that stuff up at the 
same time, why not?

Keith

Re: DRM and 2.4 ...

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Mon, Aug 16, 2004 at 12:42:51PM +0100, Keith Whitwell wrote:
> 
> Dave's hit the nail on the head here.  If you'd like some changes, feel 
> free to make suggestions.

once the new intel DRM driver hits Linus' tree I want to start an experiment
to make it look like a linux driver.. (I'm waiting for that driver since
most of my hw is intel gfx based)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: DRM and 2.4 ...

[Keith Whitwell]

Arjan van de Ven wrote:
> On Mon, Aug 16, 2004 at 12:42:51PM +0100, Keith Whitwell wrote:
> 
>>Dave's hit the nail on the head here.  If you'd like some changes, feel 
>>free to make suggestions.
> 
> 
> once the new intel DRM driver hits Linus' tree I want to start an experiment
> to make it look like a linux driver.. (I'm waiting for that driver since
> most of my hw is intel gfx based)

Fair enough.  Hopefully that will include Dave's changes as well, as they're 
going to resolve a lot of the issues that I find make DRM difficult to work with.

Keith

Re: DRM and 2.4 ...

[Alan Cox]

On Llu, 2004-08-16 at 08:11, Arjan van de Ven wrote:
> I would strongly urge you to no longer update DRM in 2.4 in significant
> ways. 2.4 is the release for doing strict maintenance; people who want
> to run newer X will generally run 2.6 kernels as well anyway.

Then 2.4 users can't use the new Xorg release fully. That would be
rather out of keeping with X policy.

Re: DRM and 2.4 ...

[Dave Airlie]

> > ways. 2.4 is the release for doing strict maintenance; people who want
> > to run newer X will generally run 2.6 kernels as well anyway.
>
> Then 2.4 users can't use the new Xorg release fully. That would be
> rather out of keeping with X policy.

Nope never said that, they won't be able to use the one after this one ;-)

They can use as much of the release as they can currently, if they want
new 3D driver features they'll need to upgrade.. (to be honest there isn't
much extra in the DRM from Xorg 6.7 to Xorg 6.8).. and I'd like to get the
DRM be a kernel thing rather than a X thing all this spread-out
development doesn't seem to be helping anyone...

And if we do get around to this great super unified graphics driver that
also ends world hunger I ain't backporting it to 2.4 :-)

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person