Re: DRM function pointer work..

Re: DRM function pointer work..

[Ian Romanick]

Jon Smirl wrote:

> The only case I see a problem is when drm-core is compiled into the
> kernel. Why don't we just change the Makefile to default to copying the
> CVS code into the kernel source tree and tell the user to rebuild his
> kernel? 

I don't think that will fly with Joe-user that just wants to upgrade his 
graphics driver.  The other problem case is if the user has two graphics 
cards in his system.  He wants to upgrade the driver for one of them (or 
install a new driver for a new card), but the interface between the 
device-independent (in-kernel) layer and the device-dependent 
(in-kernel) layer has changed.

Unless there is some way to have multiple device-independent modules (on 
a built-in and a module) loaded, the user is stuck in a situation where 
he has to update both drivers, but it may not be obvious that they need 
to do so.

I don't think this situation is likely to happen, but if there is even 
the potential for it to happen, we will get bitten. :(

> Then for us DRM hackers just have another make target that builds
> outside of the tree like we are currently doing. We could add a single
> symbol as a check, drm_core in kernel would not provide the symbol.
> drm_core compiled as a module provides it. drm compiled out of tree
> requires it. drm compiled in tree doesn't care.

Re: DRM function pointer work..

[Keith Whitwell]

Ian Romanick wrote:
> Jon Smirl wrote:
> 
>> The only case I see a problem is when drm-core is compiled into the
>> kernel. Why don't we just change the Makefile to default to copying the
>> CVS code into the kernel source tree and tell the user to rebuild his
>> kernel? 
> 
> 
> I don't think that will fly with Joe-user that just wants to upgrade his 
> graphics driver.  The other problem case is if the user has two graphics 
> cards in his system.  He wants to upgrade the driver for one of them (or 
> install a new driver for a new card), but the interface between the 
> device-independent (in-kernel) layer and the device-dependent 
> (in-kernel) layer has changed.
> 
> Unless there is some way to have multiple device-independent modules (on 
> a built-in and a module) loaded, the user is stuck in a situation where 
> he has to update both drivers, but it may not be obvious that they need 
> to do so.
> 
> I don't think this situation is likely to happen, but if there is even 
> the potential for it to happen, we will get bitten. :(

Yes, while I support the current rework and de-templatization of the code, I 
don't support any attempt to split the drm modules to try and share code at 
runtime - ie. I don't support a core/submodule approach.

The arguments are pretty much the same as those against unbundling core mesa 
from the drivers - as soon as somebody tries to do an upgrade you're screwed. 
  Anyone trying to run dual head with different 'versions' on each head, 
you're screwed.

The last thing we need right now is a new ABI to worry about.

Keith

Re: DRM function pointer work..

[Jon Smirl]

--- Keith Whitwell <keith@tungstengraphics.com> wrote:
> Ian Romanick wrote:
> > Jon Smirl wrote:
> > 
> >> The only case I see a problem is when drm-core is compiled into
> >> the kernel. Why don't we just change the Makefile to default to
> >> copying the CVS code into the kernel source tree and tell the 
> >> user to rebuild his kernel? 
> > 
> > 
> > I don't think that will fly with Joe-user that just wants to
> > upgrade his graphics driver.  The other problem case is if the 
> > user has two graphics cards in his system.  He wants to upgrade
> > the driver for one of them (or install a new driver for a new 
> > card), but the interface between the device-independent 
> > (in-kernel) layer and the device-dependent (in-kernel) layer 
> > has changed.

fbdev is in exactly this model and it isn't causing anyone problems.
The simple rule is that if you want to upgrade fbdev past the current
version you have to do it in entirety. You do that for fbdev but
pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
something only developers do.

Distributions release new kernels all of the time. If Joe wants to
upgrade he graphics driver he should wait until we push it into the
kernel and it arrives via his distribution. If he really wants to be
bleeding edge he can copy the entirety of the DRM CVS into his kernel
tree. 

Linux doesn't have a stable driver binary interface. It isn't meant for
you to be able to upgrade one module while keeping the core and an
older module.

The key here is that distributions release new kernels at a rapid pace.
This is not X where we get a new release every five years. The standard
mechanism for upgrading device drivers in Linux is to add them to the
kernel and wait for a release.  If DRM uses that mechanism for
distribution we won't have problems.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: DRM function pointer work..

[Keith Whitwell]

Jon Smirl wrote:
> --- Keith Whitwell <keith@tungstengraphics.com> wrote:
> 
>>Ian Romanick wrote:
>>
>>>Jon Smirl wrote:
>>>
>>>
>>>>The only case I see a problem is when drm-core is compiled into
>>>>the kernel. Why don't we just change the Makefile to default to
>>>>copying the CVS code into the kernel source tree and tell the 
>>>>user to rebuild his kernel? 
>>>
>>>
>>>I don't think that will fly with Joe-user that just wants to
>>>upgrade his graphics driver.  The other problem case is if the 
>>>user has two graphics cards in his system.  He wants to upgrade
>>>the driver for one of them (or install a new driver for a new 
>>>card), but the interface between the device-independent 
>>>(in-kernel) layer and the device-dependent (in-kernel) layer 
>>>has changed.
> 
> 
> fbdev is in exactly this model and it isn't causing anyone problems.
> The simple rule is that if you want to upgrade fbdev past the current
> version you have to do it in entirety. You do that for fbdev but
> pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
> something only developers do.
> 
> Distributions release new kernels all of the time. If Joe wants to
> upgrade he graphics driver he should wait until we push it into the
> kernel and it arrives via his distribution. If he really wants to be
> bleeding edge he can copy the entirety of the DRM CVS into his kernel
> tree. 
> 
> Linux doesn't have a stable driver binary interface. It isn't meant for
> you to be able to upgrade one module while keeping the core and an
> older module.
> 
> The key here is that distributions release new kernels at a rapid pace.
> This is not X where we get a new release every five years. The standard
> mechanism for upgrading device drivers in Linux is to add them to the
> kernel and wait for a release.  If DRM uses that mechanism for
> distribution we won't have problems.

Sorry, I don't buy it.  Graphics drivers are a special case and people upgrade 
them with a passion...  No new interfaces, thankyou.

Keith

Re: DRM function pointer work..

[Jon Smirl]

--- Keith Whitwell <keith@tungstengraphics.com> wrote:
> 
> Sorry, I don't buy it.  Graphics drivers are a special case and
> people upgrade them with a passion...  No new interfaces, thankyou.

I get a new kernel from Redhat about every two weeks. Redhat is at
2.6.7 and Linus is at 2.6.8. Nobody releases graphics drivers faster
than that. Why do you want to build a new release mechanism that
bypasses the kernel one?

If people are upgrading faster that every two weeks I would classify
them as developers or people that can deal with broken drivers. That
class of person can deal with pulling the code from CVS and copying it
into their kernel tree.

There are three main ways to get a driver:
1) vendor release - most stable, I get one every two weeks
2) Linus bk - very up to date, not as well tested, once a day
3) copy DRM CVS into Linus bk - bleeding edge, hope you know what you
are doing.

Besides, DRM drivers are relatively stable. It's the user space stuff
that is volatile.


> 
> Keith
> 
> 

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

Re: DRM function pointer work..

[Dave Jones]

On Fri, Aug 06, 2004 at 10:46:45AM -0700, Jon Smirl wrote:
 > There are three main ways to get a driver:
 > 1) vendor release - most stable, I get one every two weeks
 > 2) Linus bk - very up to date, not as well tested, once a day
 > 3) copy DRM CVS into Linus bk - bleeding edge, hope you know what you
 > are doing.

In the case of bleeding edge Fedora, (Ie FC3 t1 right now), 1 and 2 are
the same. Ie, we rebase to the upstream -bk release almost daily.
(The only time we don't is when both myself and Arjan are otherwise
 occupied, like recently at OLS etc, but it's rare that both of us
 are too busy to do a rebase).

The current release version of Fedora (Ie, FC2 right now) has a slightly
less aggressive update cycle, typically only when either a) the upstream
kernel has fixed a lot of bugs that have been biting users, or b) there's
a security problem to justify another update.

		Dave

Re: DRM function pointer work..

[Keith Whitwell]

> The key here is that distributions release new kernels at a rapid pace.
> This is not X where we get a new release every five years. The standard
> mechanism for upgrading device drivers in Linux is to add them to the
> kernel and wait for a release.  

So, people have to reboot to install a new graphics driver?   How very 
windows...

At least with windows you don't have to re-install the whole OS first...

Keith

Re: DRM function pointer work..

[Jon Smirl]

--- Keith Whitwell <keith@tungstengraphics.com> wrote:

> 
> > The key here is that distributions release new kernels at a rapid
> pace.
> > This is not X where we get a new release every five years. The
> standard
> > mechanism for upgrading device drivers in Linux is to add them to
> the
> > kernel and wait for a release.  
> 
> So, people have to reboot to install a new graphics driver?   How
> very 
> windows...

You only have to reboot if you built drm-core into the kernel. If you
don't want to reboot don't do that.


> 
> At least with windows you don't have to re-install the whole OS
> first...
> 
> Keith
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks?
> Now,
> one more big change to announce. We are now OSTG- Open Source
> Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 


=====
Jon Smirl
jonsmirl@yahoo.com


		
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com

Re: DRM function pointer work..

[Dave Airlie]

>
> fbdev is in exactly this model and it isn't causing anyone problems.
> The simple rule is that if you want to upgrade fbdev past the current
> version you have to do it in entirety. You do that for fbdev but
> pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
> something only developers do.

fbdev only has one distribution vector - the kernel, DRM has multiple
distribution vectors, kernel, DRI snapshots, X releases, they all contain
their own DRM modules, also people with older kernels should be able to
use new drivers with little hassle, if we force people to upgrade their
kernel we are restricting what we allow them to do now ...

If we do go for a library split, we should use the kernel config system
like I mentioned and fight any attempts to change it, to re-iterate, if
you build drm into the kernel you have to build the graphics drivers in as
well, (we can use a symbol to enforce it), if you build the drm as a
module all drivers have to be modular, and the DRM makefile installs the
core DRM, we could also create a drm_ver.h file that gets
generateed at compile time automatically and then included into
both drm core and module at build time, if this differs just refuse to
load and stick a FAQ up telling the user they are messing something up ..

> The key here is that distributions release new kernels at a rapid pace.
> This is not X where we get a new release every five years. The standard
> mechanism for upgrading device drivers in Linux is to add them to the
> kernel and wait for a release.  If DRM uses that mechanism for
> distribution we won't have problems.
>

Like Keith I don't buy this argument too much either, I think we should be
able to continue as much as possible with what people can do now ..
especially snapshot type systems..

Dave.

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

Re: DRM function pointer work..

[Christoph Hellwig]

On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote:
> fbdev only has one distribution vector - the kernel, DRM has multiple
> distribution vectors, kernel, DRI snapshots, X releases, they all contain
> their own DRM modules, also people with older kernels should be able to

which is the root problem.  Make sure the kernel is the canonical source and
all those problems magically disappear.

Re: DRM function pointer work..

[Alan Cox]

On Gwe, 2004-08-06 at 18:16, Jon Smirl wrote:
> fbdev is in exactly this model and it isn't causing anyone problems.
> The simple rule is that if you want to upgrade fbdev past the current
> version you have to do it in entirety. You do that for fbdev but
> pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is
> something only developers do.

And thats one of the big reasons its such a mess and doesn't work out.
Nobody is testing or reviewing it until some huge "merge point" occurs
at which point you run the risk of people saying "Actually your design
sucks", or in the 2.6 case finding out too late so that there is a patch
kit to upgrade your 2.6 to the 2.4 console driver

Re: DRM function pointer work..

[Christoph Hellwig]

On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote:
> And thats one of the big reasons its such a mess and doesn't work out.
> Nobody is testing or reviewing it until some huge "merge point" occurs
> at which point you run the risk of people saying "Actually your design
> sucks", or in the 2.6 case finding out too late so that there is a patch
> kit to upgrade your 2.6 to the 2.4 console driver

Sorry, but the reason for the fbdev mess is that James is completely unable
to do proper project managment.  The model works fine for every other kernel
subsystem.

Re: DRM function pointer work..

[Christoph Hellwig]

On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote:
> Yes, while I support the current rework and de-templatization of the code, I 
> don't support any attempt to split the drm modules to try and share code at 
> runtime - ie. I don't support a core/submodule approach.

We had that argument already in 2000/2001 when we had the big XFree 4.1 DRM
update.  There's no reason drm should be different from all other kernel
subsystems.  If you really fear this is a problem add a monotonely increasing
DRM_VERSION define for driver to check against and even better don't make any
not backwards-compatible changes unless you're doing a major version bump.

Re: DRM function pointer work..

[Dave Airlie]

[lk ppl have a look at the start of this thread in the dri-devel archives
on marc.theaimsgroup.com...]

> I guess one (unpleasant) way to make it work would be to add the version to
> all the symbols in the device-independent layer.  Instead of drm_foo you'd
> have drm_foo_100 or drm_foo_101 or whatever.  You could then have multiple
> modules loaded or a module loaded with a built-in version.  I'm not sure how
> happy that would make the kernel maintainers (not to mention how happy it
> would make us). :(  It's basically like what we have now, except the current
> code has the device's name add to all the symbols and is built into the
> device-dependent module.  Ugh, ugh.
>
> How do other multi-layer kernel modules handle this?  For example, how does
> agpgart or iptables do it?

they don't let crazy people build stuff outside the tree as far as I know
... also they make you build against the current kernel headers, so we
would have to have the drm headers in include/linux/drm or somewhere like
that, and build the modules against them, but then what happens if you
want to build a new drm module out of tree..

two things make my head hurt, 32/64 interfaces and versioning.., maybe
some more experienced kernel heads could join this and tell us the best
way to go?

Dave.

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

Re: DRM function pointer work..

[Christoph Hellwig]

On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote:
> 
> > I guess one (unpleasant) way to make it work would be to add the version to
> > all the symbols in the device-independent layer.  Instead of drm_foo you'd
> > have drm_foo_100 or drm_foo_101 or whatever.  You could then have multiple
> > modules loaded or a module loaded with a built-in version.  I'm not sure how
> > happy that would make the kernel maintainers (not to mention how happy it
> > would make us). :(  It's basically like what we have now, except the current
> > code has the device's name add to all the symbols and is built into the
> > device-dependent module.  Ugh, ugh.
> >
> > How do other multi-layer kernel modules handle this?  For example, how does
> > agpgart or iptables do it?

Just make sure the driver core and subdrivers are always in sync. That's an
entirely sensible thing and how all other subsystems with lowlevel calls work.