DRM function pointer work..
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Jon Smirl
The only case I see a problem is when drm-core is compiled into the kernel. Why don't we just change the
Makefileto 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. :(
Quoted 5 lines
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_corein kernel would not provide the symbol.drm_corecompiled as a module provides it. drm compiled out of tree requires it. drm compiled in tree doesn't care.
Quoted 8 lines · Ian Romanick
Quoted 4 lines · Jon Smirl
The only case I see a problem is when drm-core is compiled into the kernel. Why don't we just change the
Makefileto default to copying the CVS code into the kernel source tree and tell the user to rebuild his kernel?
Quoted 5 lines
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
Quoted 9 lines · --- Keith Whitwell
Quoted 8 lines · Ian Romanick
Quoted 4 lines · Jon Smirl
The only case I see a problem is when drm-core is compiled into the kernel. Why don't we just change the
Makefileto default to copying the CVS code into the kernel source tree and tell the user to rebuild his kernel?
Quoted 7 lines
Quoted 7 lines
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
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Quoted 33 lines · Jon Smirl
Quoted 5 lines · --- Keith Whitwell
Quoted 3 lines · Ian Romanick
Jon Smirl wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
The only case I see a problem is when drm-core is compiled into
the kernel. Why don't we just change theMakefileto 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.
Quoted 5 lines
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
Quoted 3 lines · --- Keith Whitwell
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.
Quoted 4 lines
Keith
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Quoted 5 lines · Jon Smirl
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
Quoted 5 lines
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
Quoted 4 lines · --- Keith Whitwell
Quoted 2 lines
The key here is that distributions release new kernels at a rapid
pace.
Quoted 1 line
This is not X where we get a new release every five years. The
Quoted 8 lines
standard
Quoted 1 line
mechanism for upgrading device drivers in Linux is to add them to
the
Quoted 1 line
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.
Quoted 8 lines
At least with windows you don't have to re-install the whole OS first...
Keith
Quoted 14 lines
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
=====
Jon Smirl
[email protected]
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
Quoted 7 lines
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 ..
Quoted 6 lines
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.
Signature · 3 lines
David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person
Quoted 3 lines · Dave Airlie
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.
Quoted 5 lines · Jon Smirl
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
Quoted 5 lines · Alan Cox
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.
Quoted 3 lines · Keith Whitwell
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.