Re: DRM function pointer work..
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 --- 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
Re: DRM function pointer work..
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. --- 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
Re: DRM function pointer work..
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. --- 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
Re: DRM function pointer work..
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. --- 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
Re: DRM function pointer work..
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. --- 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
Re: DRM function pointer work..
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 --- 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
Re: DRM function pointer work..
On Thu, Aug 05, 2004 at 04:19:55PM -0700, Ian Romanick wrote: module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module .. I think thats the way to go. Try and get things in the mainline kernel quick enough, or maybe even do the work there (Its the reason we have things like CONFIG_EXPERIMENTAL). If you reduce the incentive for folks to grab bits from another source, this problem goes away. 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. Ugh is putting things very politely 8-) Whilst I realise we don't live in a perfect world, and getting interfaces right first time is hard, I'd really like to warn about the horrors of versioned ioctl's and the like. How do other multi-layer kernel modules handle this? For example, how does agpgart or iptables do it? For agpgart it hasn't really been an issue as all the development there in the last year or two has been done in tree. Yes, there has been some work on things like i915 out-of-tree, but that stuff has been merged up pretty quickly. Dave --- 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
Re: DRM function pointer work..
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. --- 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
Re: DRM function pointer work..
Dave Jones wrote: On Thu, Aug 05, 2004 at 04:19:55PM -0700, Ian Romanick wrote: module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module .. I think thats the way to go. Try and get things in the mainline kernel quick enough, or maybe even do the work there (Its the reason we have things like CONFIG_EXPERIMENTAL). If you reduce the incentive for folks to grab bits from another source, this problem goes away. It goes away, but it's replaced by other, equally annoying, problems. 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. Ugh is putting things very politely 8-) Whilst I realise we don't live in a perfect world, and getting interfaces right first time is hard, I'd really like to warn about the horrors of versioned ioctl's and the like. Yeahwe already deal with various varieties of user-kernel interface versioning. Having to version kernel-kernel interfaces is the stuff that makes a developer want to become a monk or something. How do other multi-layer kernel modules handle this? For example, how does agpgart or iptables do it? For agpgart it hasn't really been an issue as all the development there in the last year or two has been done in tree. Yes, there has been some work on things like i915 out-of-tree, but that stuff has been merged up pretty quickly. agpgart also has the advantage of there being only one AGP controller in the system. The issue I'm stating to worry more and more about is the user with multiple graphics cards... --- 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
Re: DRM function pointer work..
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 --- 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
Re: DRM function pointer work..
--- Keith Whitwell [EMAIL PROTECTED] 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 [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- 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
Re: DRM function pointer work..
Jon Smirl wrote: --- Keith Whitwell [EMAIL PROTECTED] 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 --- 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
Re: DRM function pointer work..
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 --- 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
Re: DRM function pointer work..
--- Keith Whitwell [EMAIL PROTECTED] 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 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail --- 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
Re: DRM function pointer work..
--- Keith Whitwell [EMAIL PROTECTED] 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 [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 --- 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
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 09:38:10AM -0700, Ian Romanick wrote: For agpgart it hasn't really been an issue as all the development there in the last year or two has been done in tree. Yes, there has been some work on things like i915 out-of-tree, but that stuff has been merged up pretty quickly. agpgart also has the advantage of there being only one AGP controller in the system. The issue I'm stating to worry more and more about is the user with multiple graphics cards... Not entirely true. On AMD64, you get an AGPGART per-cpu, though these all need to be kept coherent so you effectively have one. But... some enterprising folks have also put GARTs on their K8 chipsets, so in the case of some VIA boards, we *could* use the on-CPU GART for IOMMU uses, and the chipset gart for graphics, instead of sharing the on-CPU GART for both purposes. I had actually looked into writing a driver for the VIA K8 GART at one point, but it was around the time I left my previous employer, and so lost access to the hardware to play with. Maybe one to revisit at some point. Dave --- 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
Re: DRM function pointer work..
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 --- 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
Re: DRM function pointer work..
Dave Airlie wrote: The only thing I can think off is maybe adding this stuff to another C file per driver but that probably isn't necessary ... the other idea I've had is to perhaps separate the function table when we get the full table done, then we can have tables per functionality group, i.e. adding the dma flush just for the gamma to that table makes it a bit ugly... Okay I've just checked in this idea to the branch, and I've finished all the other drivers off and BSD (this is untested it built though..) I'll look to what could be my next step now .. I looked at the code currently in CVS. Is it the most recent? I know CVS commits to X.org servers are toast right now. I do have a couple comments. Instead of having all the code like: if ( dev-fn_tbl.foo ) def-fn_tbl.foo(); I'd rather have drivers init all the functions to some generic, noop function. I think that makes the code a lot cleaner to read. Also, I think it might be better to embed a pointer to the function table in the device's data structure rather than the table itself. If (when?) we go to a setup where we have a generic base structure that each of the drivers embeds and expands in it's structure, a pointer should be easier to work with. Actually, it might not matter much. That type of thing was a *big* deal for the libGL / *_dri.so re-work that I did, so I might just paranoid. You can't mix-and-match compiled kernel modules, so it may not matter. Other than that, the changes look great! --- 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
Re: DRM function pointer work..
I looked at the code currently in CVS. Is it the most recent? I know CVS commits to X.org servers are toast right now. I've another bunch of changes pending on my PC at home, these get rid of the kernel context switch stuff for the sparc and the context ctor/dtor macros... if ( dev-fn_tbl.foo ) def-fn_tbl.foo(); I'd rather have drivers init all the functions to some generic, noop function. I think that makes the code a lot cleaner to read. I've thought about this and wasn't sure how acceptable adding a load of NOP function calls would be.. I'm not sure too many of the current ptrs are in any fast paths, my preference was to use a macro which wrap the above but that may be the old way of thinking :-), Also, I think it might be better to embed a pointer to the function table in the device's data structure rather than the table itself. If (when?) we go to a setup where we have a generic base structure that each of the drivers embeds and expands in it's structure, a pointer should be easier to work with. At the moment each driver has its own dev_private portion that is adds to so the central structure shouldn't change that often once the cleanups are done ... You can't mix-and-match compiled kernel modules, so it may not matter. I really don't want to have to introduce versioning between the drm kernel module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: DRM function pointer work..
Dave Airlie wrote: I'd rather have drivers init all the functions to some generic, noop function. I think that makes the code a lot cleaner to read. I've thought about this and wasn't sure how acceptable adding a load of NOP function calls would be.. I'm not sure too many of the current ptrs are in any fast paths, my preference was to use a macro which wrap the above but that may be the old way of thinking :-), Since very few (any?) of the functions have a return value, couldn't you just use the same function for all of them? Also, I think it might be better to embed a pointer to the function table in the device's data structure rather than the table itself. If (when?) we go to a setup where we have a generic base structure that each of the drivers embeds and expands in it's structure, a pointer should be easier to work with. At the moment each driver has its own dev_private portion that is adds to so the central structure shouldn't change that often once the cleanups are done ... You can't mix-and-match compiled kernel modules, so it may not matter. I really don't want to have to introduce versioning between the drm kernel module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module .. I'm now starting to recall some of the other arguments against a generice DRM library layer. Versioning like this in user-mode is yucky enough, but in the kernel it's yucky * 10. We really want to have device-independent code API version X only try to run with device-dependent code API version X. Even with the device-independent layer as a module this is non-trivial. The user might have another device-dependent module that matches the existing device-independent code. Ugh. 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? --- 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
Re: DRM function pointer work..
[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 --- 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
Re: DRM function pointer work..
Since very few (any?) of the functions have a return value, couldn't you just use the same function for all of them? hmm at the moment 8 of them do return values, 5 don't .. not sure if all the returns are necessary but I think they are... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: DRM function pointer work..
On Thu, Aug 05, 2004 at 11:44:48PM +0100, Dave Airlie wrote:
if ( dev-fn_tbl.foo )
def-fn_tbl.foo();
I'd rather have drivers init all the functions to some generic, noop function.
I think that makes the code a lot cleaner to read.
I've thought about this and wasn't sure how acceptable adding a load of
NOP function calls would be.. I'm not sure too many of the current ptrs
are in any fast paths, my preference was to use a macro which wrap the
above but that may be the old way of thinking :-),
static inline int
drm_func_foo(*dev, ...)
{
if (dev-fn_tbl.foo)
return dev-fn_tbl.foo(dev, ...);
else
return 0;
}
error = drm_func_foo(dev);
(Use _func_ or something consistently so it's obvious it's an
indirection)
-J
---
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
Re: DRM function pointer work..
The only thing I can think off is maybe adding this stuff to another C file per driver but that probably isn't necessary ... the other idea I've had is to perhaps separate the function table when we get the full table done, then we can have tables per functionality group, i.e. adding the dma flush just for the gamma to that table makes it a bit ugly... Okay I've just checked in this idea to the branch, and I've finished all the other drivers off and BSD (this is untested it built though..) I'll look to what could be my next step now .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
DRM function pointer work..
Okay I've created a drm branch drmfntbl-0-0-1 and I've commited the work I've done so far, i830, mach64, radeon and gamma should be working, I've only tested the radeon really, I don't even own a gamma (but it causes a lot of the issues :-) The current patch is at http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff Ian, if you want to remove any more macros can you do it on that branch, I don't intend that branch to live very long we should pull it back onto the trunk when we are happy with it ... The only thing I can think off is maybe adding this stuff to another C file per driver but that probably isn't necessary ... the other idea I've had is to perhaps separate the function table when we get the full table done, then we can have tables per functionality group, i.e. adding the dma flush just for the gamma to that table makes it a bit ugly... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
