From: Dave A. <ai...@gm...> - 2008-08-27 00:15:13
|
Okay I've put some thoughts up at: http://dri.freedesktop.org/wiki/DRMProcess and I've pasted it in below this for discussion. some other points: a) People are pushing for a process change, we will have something change, however this isn't a who shouts loudest competition, so more than likely you'll end up compromising, deal with the fact that nirvana for you may be hell for others. b) BSD developers do exist now, giving out that they didn't exist in the past or aren't adding features is pointless. Would you seriously start developing features before getting the code caught up?. So live with the fact that we should help the BSD guys *if* its practical. So we shouldn't do anything major that alienates their further development. (personally I care little for BSD, the license or the OSes, however I'm attempting to be some way fair). c) We get testers from drm master, we get better testers using drm master for features than a separate kernel tree. We get better regression tests from getting stuff upstream. However upstreaming stuff to Linus is not how to find regressions, it helps but its suboptimal in that he will eventually ignore us if the regression rate gets too high. So upstreaming is great for features like GEM, however it would suck for something like vblank-rework. This appears to point at, upstream is great if you touch one driver and exist in your own world, however if you want interfaces that all drivers can use like vbl-rework you need to work somewhere else or carry two interfaces until everyone is ported. So lets see if we can improve this for everyone... Dave. DRM Development Process (Proposed) 1. Master branch in Linux tree style with links for BSD etc. 2. Always compatible with current release Linux kernel + with backwards compat *where* practical for older kernels. We should probably limit the back compat to like 6 kernel revisions or something. 3. Macros for BSD compat to wrap Linux APIs. So we minimise the nightmare of macros in driver code. no more DRM_ if they can be avoided. Patches 1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. Upstream first policy This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. Note: Do not expect because your code works that you won't have to re-write it all for upstream. So upstream ideas early esp when you interface to other kernel components. Development 1. For large features or new drivers create a new branch in drm tree. Stay in the branch, these branches will never ever get merged ever. ever. When the developers feel the branch is suitable for upstream, they need to create a clean set of patches following the rules above. All API additions need to be reviewed and feedback taken on board. If this involves another round of development, nuke the old branch and/or start a new one from the patchset. Repeat cycle. When patches are approved by anyone who cares they will get merged into the drm master and into the upstream drm-next queue. Backwards compat patches will be merged into drm master. 2. For minor cleanups and fixes, patches should be sent to dri-devel. 3. If a patch gets reverted from upstream kernel for a regression it will also be reverted from the drm master branch. 4. If someone gets in the queue and you conflict you get to keep the mess. DRM tree layout (plans) 1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2. Add backwards compat cleanly on top of this tree with some patches. 3. Add BSD compat in places that need it. 4. Migrate BSD to using the upstream src files instead of the shared-core ones. 5. Evict all non-upstream patches to branches, currently * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface. Suggestions + help needed In the future we may find we need a transitory drm-testing branch that merges all the currently in development branches. This might help in resolving conflicts before they happen. It would be nice to tinderbox build the drm mainline and drm-testing against the last 6 released kernels. |
From: Jesse B. <jb...@vi...> - 2008-08-27 01:08:18
|
On Tuesday, August 26, 2008 5:15 pm Dave Airlie wrote: > DRM Development Process (Proposed) > > 1. Master branch in Linux tree style with links for BSD etc. > > 2. Always compatible with current release Linux kernel + with > backwards compat *where* practical for older kernels. We should > probably limit the back compat to like 6 kernel revisions or > something. How will these patches be managed? Will they only live in DRM master? Or will they be upstream as well? > Patches > > 1. All patches to be sent to the mailing list with S-O-B, no patches > to be committed to master branch. Nothing goes upstream or into master > without Signed-off-by and maintainers Signed-off-by. 2. Do not mix > cleanup and developement ever. If you move a bunch of registers or > code into a separate file, do just that in one patch. 3. Backwards > compat patches in separate patches. So first patch should be > upstreamable, backwards compat patches should be in sequence. > > Upstream first policy > > This policy places a restriction on users of the drm, i.e. Mesa, DDX, > X server. No upstream release should include code that hasn't been > included in a Linux kernel release cycle. Upstream can use a > --enable-experimental-kernel-api type flag but default build should > never require any unreleased kernel/drm API to build or run. Distros > should not enable experimental APIs in releases, unless they are > willing to version their kernel and other components against each > other and deal with the fallout of API changes. > > All userspace APIs need to be submitted to dri-devel and to the Linux > kernel list, also all patches which need exports or use new non-drm > kernel functionality should be reviewed by both lists. > > Note: Do not expect because your code works that you won't have to > re-write it all for upstream. So upstream ideas early esp when you > interface to other kernel components. This sounds great. Sure it'll probably slow things down, but it should also ensure that features actually get out into distributions and that the APIs are relatively sane. > DRM tree layout (plans) > > 1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2. > Add backwards compat cleanly on top of this tree with some patches. 3. > Add BSD compat in places that need it. 4. Migrate BSD to using the > upstream src files instead of the shared-core ones. 5. Evict all > non-upstream patches to branches, currently > > * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface. Yay! This means I'll have to do a bit of archeology to port stuff forward, but it's well worth it, imo. > Suggestions + help needed > > In the future we may find we need a transitory drm-testing branch that > merges all the currently in development branches. This might help in > resolving conflicts before they happen. It would be nice to tinderbox > build the drm mainline and drm-testing against the last 6 released > kernels. On Linux at least, some subsystems do this with their linux-next branch. They pull in all the various topic branches that may or may not get into the next Linus release in order to get build & (some) test coverage. Overall this looks really good to me; it seems like it will address the weaknesses I've seen with the current model. -- Jesse Barnes, Intel Open Source Technology Center |
From: Robert N. <rn...@2h...> - 2008-08-27 03:03:04
|
On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote: > Okay I've put some thoughts up at: > http://dri.freedesktop.org/wiki/DRMProcess > > and I've pasted it in below this for discussion. > > some other points: > > a) People are pushing for a process change, we will have something > change, however this isn't a who shouts loudest competition, so more > than likely you'll end up compromising, deal with the fact that > nirvana for you may be hell for others. > > b) BSD developers do exist now, giving out that they didn't exist in > the past or aren't adding features is pointless. Would you seriously > start developing features before > getting the code caught up?. So live with the fact that we should help > the BSD guys *if* its practical. So we shouldn't do anything major > that alienates their further development. > (personally I care little for BSD, the license or the OSes, however > I'm attempting to be some way fair). We all have our religions. ;) This is the most fair of any of the proposals I've seen or heard. I am certainly willing to compromise, but even this proposal converts the project from what has historically been a collaborative effort (yes, I know) into a linux project that merely tolerates renting a subdirectory in the repo to BSD. I'm honestly about ready to throw in the towel. While I have been slowly raising awareness in FreeBSD circles with my frequent pleas for help, I just don't have enough voices to influence the outcome. I have been getting some attention from far more qualified developers than myself lately, but no commitments for substantial work have yet been made. I already know better than to commit infrastructure changes that impact linux, even if they fix obvious bugs. The linux side of the house is not held to the same standards obviously. Jesse and I, have a reasonably good track record of collaborating early enough that we have been able to commit working code at very near the same time. I am having a really difficult time seeing what benefit I get from continuing to work in drm.git with this proposed model. While all commits to master going through the mailing list, I don't anticipate that I have any veto power or even delay powers until I can at least prevent imports from breaking BSD. Then once I do get it squared away, I'm still left having to send those to the ML and wait for approval to push the fixes. I can just save myself that part of the hassle and work privately. If I'm going to have to hand edit and merge every change, I don't see how it is really any harder to do that in my own repo, where I'm only subject to FreeBSD rules. That way, if I need to make a change to infrastructure to fix issues, all I have to worry about is maintaining ABI/API compatability. We all want nice pretty pristine code in our kernels and if I can't easily import the shared code it just isn't worth it. I can get testing on our -CURRENT branch, at least for things that aren't inherently sketchy. I'm probably more likely to attract other developers attention if I'm working in our tree anyway. Generally, most everyone has always been helpful and I do really appreciate that and hope that continues to be the case. Thanks, robert. > c) We get testers from drm master, we get better testers using drm > master for features than a separate kernel tree. We get better > regression tests from getting stuff upstream. However upstreaming > stuff to Linus is not how to find regressions, it helps but its > suboptimal in that he will eventually ignore us if the regression rate > gets too high. So upstreaming is great for features like GEM, however > it would suck for something like vblank-rework. This appears to point > at, upstream is great if you touch one driver and exist in your own > world, however if you want interfaces that all drivers can use like > vbl-rework you need to work somewhere else or carry two interfaces > until everyone is ported. > > So lets see if we can improve this for everyone... > > Dave. > > > DRM Development Process (Proposed) > > 1. Master branch in Linux tree style with links for BSD etc. > > 2. Always compatible with current release Linux kernel + with > backwards compat *where* practical for older kernels. We should > probably limit the back compat to like 6 kernel revisions or > something. > > 3. Macros for BSD compat to wrap Linux APIs. So we minimise the > nightmare of macros in driver code. no more DRM_ if they can be > avoided. > > Patches > > 1. All patches to be sent to the mailing list with S-O-B, no patches > to be committed to master branch. Nothing goes upstream or into master > without Signed-off-by and maintainers Signed-off-by. 2. Do not mix > cleanup and developement ever. If you move a bunch of registers or > code into a separate file, do just that in one patch. 3. Backwards > compat patches in separate patches. So first patch should be > upstreamable, backwards compat patches should be in sequence. > > Upstream first policy > > This policy places a restriction on users of the drm, i.e. Mesa, DDX, > X server. No upstream release should include code that hasn't been > included in a Linux kernel release cycle. Upstream can use a > --enable-experimental-kernel-api type flag but default build should > never require any unreleased kernel/drm API to build or run. Distros > should not enable experimental APIs in releases, unless they are > willing to version their kernel and other components against each > other and deal with the fallout of API changes. > > All userspace APIs need to be submitted to dri-devel and to the Linux > kernel list, also all patches which need exports or use new non-drm > kernel functionality should be reviewed by both lists. > > Note: Do not expect because your code works that you won't have to > re-write it all for upstream. So upstream ideas early esp when you > interface to other kernel components. > > Development > > 1. For large features or new drivers create a new branch in drm tree. > Stay in the branch, these branches will never ever get merged ever. > ever. When the developers feel the branch is suitable for upstream, > they need to create a clean set of patches following the rules above. > All API additions need to be reviewed and feedback taken on board. If > this involves another round of development, nuke the old branch and/or > start a new one from the patchset. Repeat cycle. When patches are > approved by anyone who cares they will get merged into the drm master > and into the upstream drm-next queue. Backwards compat patches will be > merged into drm master. > > 2. For minor cleanups and fixes, patches should be sent to dri-devel. > > 3. If a patch gets reverted from upstream kernel for a regression it > will also be reverted from the drm master branch. > > 4. If someone gets in the queue and you conflict you get to keep the mess. > > DRM tree layout (plans) > > 1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2. > Add backwards compat cleanly on top of this tree with some patches. 3. > Add BSD compat in places that need it. 4. Migrate BSD to using the > upstream src files instead of the shared-core ones. 5. Evict all > non-upstream patches to branches, currently > > * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface. > > Suggestions + help needed > > In the future we may find we need a transitory drm-testing branch that > merges all the currently in development branches. This might help in > resolving conflicts before they happen. It would be nice to tinderbox > build the drm mainline and drm-testing against the last 6 released > kernels. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Dave A. <ai...@gm...> - 2008-08-27 03:35:42
|
On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <rn...@2h...> wrote: > On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote: >> Okay I've put some thoughts up at: >> http://dri.freedesktop.org/wiki/DRMProcess >> >> and I've pasted it in below this for discussion. >> >> some other points: >> >> a) People are pushing for a process change, we will have something >> change, however this isn't a who shouts loudest competition, so more >> than likely you'll end up compromising, deal with the fact that >> nirvana for you may be hell for others. >> >> b) BSD developers do exist now, giving out that they didn't exist in >> the past or aren't adding features is pointless. Would you seriously >> start developing features before >> getting the code caught up?. So live with the fact that we should help >> the BSD guys *if* its practical. So we shouldn't do anything major >> that alienates their further development. >> (personally I care little for BSD, the license or the OSes, however >> I'm attempting to be some way fair). > > We all have our religions. ;) This is the most fair of any of the > proposals I've seen or heard. I am certainly willing to compromise, but > even this proposal converts the project from what has historically been > a collaborative effort (yes, I know) tbh it wasn't really a collaborative effort ever, apart from anholt, the BSD sharing stems from the days of the r100/r200 Weather channel stuff, they wanted to run it all on FreeBSD at the time if memory serves. > tolerates renting a subdirectory in the repo to BSD. I'm honestly about > ready to throw in the towel. While I have been slowly raising awareness > in FreeBSD circles with my frequent pleas for help, I just don't have > enough voices to influence the outcome. I have been getting some > attention from far more qualified developers than myself lately, but no > commitments for substantial work have yet been made. I already know > better than to commit infrastructure changes that impact linux, even if > they fix obvious bugs. The linux side of the house is not held to the The thing is you can't expect equality, its just not possible, there are about 10-15 Linux developers, and 1 Free and 1 Open BSD developer working on DRM stuff at any one time, so you cannot expect the Linux developers to know what the BSD requirements are. If you do checkin a major feature that is BSD only, I'd be quite happy for it to break the Linux build until I got around to fixing it. The thing is we end up with a tree where you symlink from a different place. If we can setup some tinderboxes, I'd be happy to hold up patches on minor BSD breakages, however things like GEM etc I can't see the point of holding up until BSD catches up. At the moment there is no way for a Linux developer to know they have broken the BSD build. > same standards obviously. Jesse and I, have a reasonably good track > record of collaborating early enough that we have been able to commit > working code at very near the same time. I am having a really difficult > time seeing what benefit I get from continuing to work in drm.git with > this proposed model. While all commits to master going through the > mailing list, I don't anticipate that I have any veto power or even > delay powers until I can at least prevent imports from breaking BSD. > Then once I do get it squared away, I'm still left having to send those > to the ML and wait for approval to push the fixes. I can just save > myself that part of the hassle and work privately. If I'm going to have > to hand edit and merge every change, I don't see how it is really any > harder to do that in my own repo, where I'm only subject to FreeBSD > rules. That way, if I need to make a change to infrastructure to fix > issues, all I have to worry about is maintaining ABI/API compatability. > We all want nice pretty pristine code in our kernels and if I can't > easily import the shared code it just isn't worth it. I can get testing > on our -CURRENT branch, at least for things that aren't inherently > sketchy. I'm probably more likely to attract other developers attention > if I'm working in our tree anyway. You could also have a bsd-master branch that you regularly pull from the master, and send the fixes back to the list, You can point your testers at that tree. but I'm not seeing a major difference between shared-core symlinks and drivers/gpu/drm/ symlinks, even removing a lot of the macros won't make life any harder, they will just have different names. So at no point have I mentioned you won't be able to re-use the shared files. However I am sure that we will see more of a push towards using Linux constructs in dri drivers, things like idr, list.h, locking constructs are too much of a pain to reinvent for every driver.. It may be that sharing the code is a dumb model, and you are better off working on a patch level, just porting each patch to your own tree, I'm not sure, shared-core may in fact cause more problems than it solves. Dave. |
From: Robert N. <rn...@2h...> - 2008-08-27 19:58:02
|
On Wed, 2008-08-27 at 13:35 +1000, Dave Airlie wrote: > On Wed, Aug 27, 2008 at 1:02 PM, Robert Noland <rn...@2h...> wrote: > > On Wed, 2008-08-27 at 10:15 +1000, Dave Airlie wrote: > >> Okay I've put some thoughts up at: > >> http://dri.freedesktop.org/wiki/DRMProcess > >> > >> and I've pasted it in below this for discussion. > >> > >> some other points: > >> > >> a) People are pushing for a process change, we will have something > >> change, however this isn't a who shouts loudest competition, so more > >> than likely you'll end up compromising, deal with the fact that > >> nirvana for you may be hell for others. > >> > >> b) BSD developers do exist now, giving out that they didn't exist in > >> the past or aren't adding features is pointless. Would you seriously > >> start developing features before > >> getting the code caught up?. So live with the fact that we should help > >> the BSD guys *if* its practical. So we shouldn't do anything major > >> that alienates their further development. > >> (personally I care little for BSD, the license or the OSes, however > >> I'm attempting to be some way fair). > > > > We all have our religions. ;) This is the most fair of any of the > > proposals I've seen or heard. I am certainly willing to compromise, but > > even this proposal converts the project from what has historically been > > a collaborative effort (yes, I know) > > tbh it wasn't really a collaborative effort ever, apart from anholt, > the BSD sharing stems from the days of the r100/r200 Weather channel > stuff, they wanted to run it all on FreeBSD at the time if memory > serves. > > > tolerates renting a subdirectory in the repo to BSD. I'm honestly about > > ready to throw in the towel. While I have been slowly raising awareness > > in FreeBSD circles with my frequent pleas for help, I just don't have > > enough voices to influence the outcome. I have been getting some > > attention from far more qualified developers than myself lately, but no > > commitments for substantial work have yet been made. I already know > > better than to commit infrastructure changes that impact linux, even if > > they fix obvious bugs. The linux side of the house is not held to the > > The thing is you can't expect equality, its just not possible, there > are about 10-15 Linux developers, > and 1 Free and 1 Open BSD developer working on DRM stuff at any one > time, so you cannot expect the Linux developers > to know what the BSD requirements are. I don't expect equality, all I've ever asked for is a little consideration. 99% of the driver code is shared, at least for drivers that have ever worked on BSD. We share none, or almost none of the drm_* code. But for most all of the drivers, the only thing that currently isn't shared is xxx_drv.c, and that primarily only holds the probe and attach bits. I don't expect the linux developers to know the BSD kernel, what I would ask, is that if your committing something to shared code, please don't use linux specific code when a reasonable alternative exists. If we rearrange the tree, such that it matches a linux kernel tree, with all the real files in that structure the entire concept of shared code will vanish. I anticipate that it will pretty rapidly degenerate to the point where much of the code is unuseable, at least for drivers that are actually getting worked on. I'm fine with fixing the occasional issue, but if it becomes gratuitous, it's just painful. As long as the shared-code directory exists, you at least have to git add shared-core/blah.c. I hope to have more help as time goes on, but right now, it comes back to a point you made on irc yesterday. linux has far more available resources than bsd for the time being and taxing what little resources I have even further, isn't helpful. > If you do checkin a major > feature that is BSD only, I'd be quite happy for it > to break the Linux build until I got around to fixing it. The thing is > we end up with a tree where you symlink from a different place. > If we can setup some tinderboxes, I'd be happy to hold up patches on > minor BSD breakages, however things like GEM etc I can't see > the point of holding up until BSD catches up. At the moment there is > no way for a Linux developer to know they have broken the BSD > build. I hope that I can get to that point someday, as I can rally more developers to help out. I've only been in the picture here for about a year and a half now and I wish that I could say that this is my day job, but it isn't... I'm just trying to do damage control as best I can, with the occasional clean-up and feature matching. I don't expect for a feature like GEM to be held up while I develop all of the backend code, I'd just like the opportunity to try and keep the build from being broken for extended periods. How many commits have I logged, where the commit message is "fix build on FreeBSD". Granted, most of the time they aren't a big deal and a day or two is usually more than adequate for me to be able to do damage control. I do however think that it reasonable to expect a linux developer to know that they are using a linux specific feature when they do it. Just like I know that I can't use bus_dmamap in shared code. C'mon you know generally what is and isn't portable. I know that I'm the minority, but how would you feel if the tables were turned and I wanted to move everything into a BSD tree and use all BSD syntax and style. > > same standards obviously. Jesse and I, have a reasonably good track > > record of collaborating early enough that we have been able to commit > > working code at very near the same time. I am having a really difficult > > time seeing what benefit I get from continuing to work in drm.git with > > this proposed model. While all commits to master going through the > > mailing list, I don't anticipate that I have any veto power or even > > delay powers until I can at least prevent imports from breaking BSD. > > Then once I do get it squared away, I'm still left having to send those > > to the ML and wait for approval to push the fixes. I can just save > > myself that part of the hassle and work privately. If I'm going to have > > to hand edit and merge every change, I don't see how it is really any > > harder to do that in my own repo, where I'm only subject to FreeBSD > > rules. That way, if I need to make a change to infrastructure to fix > > issues, all I have to worry about is maintaining ABI/API compatability. > > We all want nice pretty pristine code in our kernels and if I can't > > easily import the shared code it just isn't worth it. I can get testing > > on our -CURRENT branch, at least for things that aren't inherently > > sketchy. I'm probably more likely to attract other developers attention > > if I'm working in our tree anyway. > > You could also have a bsd-master branch that you regularly pull from the master, > and send the fixes back to the list, You can point your testers at that tree. > > but I'm not seeing a major difference between shared-core symlinks and > drivers/gpu/drm/ symlinks, > even removing a lot of the macros won't make life any harder, they > will just have different names. So at > no point have I mentioned you won't be able to re-use the shared files. I realize that and I think you have always been pretty reasonable about not intentionally brain-damaging shared code. I don't like the macro renaming primarily from the perspective that it makes it very difficult to identify what is a macro vs a native command, as well as the fact that at least in some cases, we have features that are compatible, but require different arguments. Whichever one of us doesn't need the extra arguments just throws them away. So, I don't like the macro renaming, but it isn't a deal breaker, at least not as long as we can continue to be halfway reasonable about it. The biggest problem with this really is that there will be no concept of shared code anymore... It will just be a free-for-all and I will have to try and pick up the pieces. The excuse I will get is "Oh, didn't realize that was shared code, sorry". > However I am sure that we will see more of a push towards using Linux > constructs in dri drivers, things like > idr, list.h, locking constructs are too much of a pain to reinvent for > every driver.. Honestly, I don't think our locking constructs are that different anymore... We both use mutex all over the place and often times it's just a difference of mutex_lock() vs mtx_lock(). idr, is a bit more problematic. Many cases are fine and we can deal with it with a macro, but some cases using a linux specific feature when a perfectly reasonable portable solution will suffice is just not polite. I guess in the end it is mostly up to each specific vendor/driver developer whether they choose to be friendly to / value BSD users. If they don't want to put out the effort to write reasonably portable code, then maybe I have time to make it work, or maybe not. Infrastucture bits are rarely the issue, like I said we share don't share any of drm_*. It's the drivers that I'm concerned about. > It may be that sharing the code is a dumb model, and you are better > off working on a patch level, just porting each patch to your own > tree, I'm not sure, shared-core may in fact cause more problems than > it solves. Perhaps... Doing things in a semi-portable fashion keeps developers from having to write multiple drivers for each OS that they care to support. Sure, it might take slightly more forthought, but you get more users, which at least for a hardware vendor, I would think is a good thing. robert. > Dave. -- Robert Noland <rn...@2h...> 2Hip Networks |
From: Thomas H. <th...@tu...> - 2008-08-28 10:12:55
|
Dave, This process looks ok to me, but I think some clarifications are needed: Dave Airlie wrote: > Okay I've put some thoughts up at: > http://dri.freedesktop.org/wiki/DRMProcess > > and I've pasted it in below this for discussion. > > some other points: > > a) People are pushing for a process change, we will have something > change, however this isn't a who shouts loudest competition, so more > than likely you'll end up compromising, deal with the fact that > nirvana for you may be hell for others. > > b) BSD developers do exist now, giving out that they didn't exist in > the past or aren't adding features is pointless. Would you seriously > start developing features before > getting the code caught up?. So live with the fact that we should help > the BSD guys *if* its practical. So we shouldn't do anything major > that alienates their further development. > (personally I care little for BSD, the license or the OSes, however > I'm attempting to be some way fair). > > c) We get testers from drm master, we get better testers using drm > master for features than a separate kernel tree. We get better > regression tests from getting stuff upstream. However upstreaming > stuff to Linus is not how to find regressions, it helps but its > suboptimal in that he will eventually ignore us if the regression rate > gets too high. So upstreaming is great for features like GEM, however > it would suck for something like vblank-rework. This appears to point > at, upstream is great if you touch one driver and exist in your own > world, however if you want interfaces that all drivers can use like > vbl-rework you need to work somewhere else or carry two interfaces > until everyone is ported. > > So lets see if we can improve this for everyone... > > Dave. > > > DRM Development Process (Proposed) > > ... > 1. All patches to be sent to the mailing list with S-O-B, no patches > to be committed to master branch. Nothing goes upstream or into master > without Signed-off-by and maintainers Signed-off-by. 2. Do not mix > cleanup and developement ever. If you move a bunch of registers or > code into a separate file, do just that in one patch. 3. Backwards > compat patches in separate patches. So first patch should be > upstreamable, backwards compat patches should be in sequence. > > Let's say we rework a driver completely, including DDX, to support GEM / TTM or whatever. The driver is, in effect, a "new" driver and there are no intermediate versions of drm that could be of interest really, since they wouldn't work with any of the user-space clients. So no bisecting is possible. Would it be OK to treat such work as a new driver and post it as a (URL to) single patch? > Upstream first policy > > This policy places a restriction on users of the drm, i.e. Mesa, DDX, > X server. No upstream release should include code that hasn't been > included in a Linux kernel release cycle. Upstream can use a > --enable-experimental-kernel-api type flag but default build should > never require any unreleased kernel/drm API to build or run. Distros > should not enable experimental APIs in releases, unless they are > willing to version their kernel and other components against each > other and deal with the fallout of API changes. > > All userspace APIs need to be submitted to dri-devel and to the Linux > kernel list, also all patches which need exports or use new non-drm > kernel functionality should be reviewed by both lists. > Are driver-specific IOCTL interfaces included in this? Regards, Thomas |
From: Dave A. <ai...@gm...> - 2008-08-28 11:01:31
|
On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström <th...@tu...> wrote: > Dave, > > This process looks ok to me, > but I think some clarifications are needed: > > Dave Airlie wrote: >> >> Okay I've put some thoughts up at: >> http://dri.freedesktop.org/wiki/DRMProcess >> >> and I've pasted it in below this for discussion. >> >> some other points: >> >> a) People are pushing for a process change, we will have something >> change, however this isn't a who shouts loudest competition, so more >> than likely you'll end up compromising, deal with the fact that >> nirvana for you may be hell for others. >> >> b) BSD developers do exist now, giving out that they didn't exist in >> the past or aren't adding features is pointless. Would you seriously >> start developing features before >> getting the code caught up?. So live with the fact that we should help >> the BSD guys *if* its practical. So we shouldn't do anything major >> that alienates their further development. >> (personally I care little for BSD, the license or the OSes, however >> I'm attempting to be some way fair). >> >> c) We get testers from drm master, we get better testers using drm >> master for features than a separate kernel tree. We get better >> regression tests from getting stuff upstream. However upstreaming >> stuff to Linus is not how to find regressions, it helps but its >> suboptimal in that he will eventually ignore us if the regression rate >> gets too high. So upstreaming is great for features like GEM, however >> it would suck for something like vblank-rework. This appears to point >> at, upstream is great if you touch one driver and exist in your own >> world, however if you want interfaces that all drivers can use like >> vbl-rework you need to work somewhere else or carry two interfaces >> until everyone is ported. >> >> So lets see if we can improve this for everyone... >> >> Dave. >> >> >> DRM Development Process (Proposed) >> >> > > ... >> >> 1. All patches to be sent to the mailing list with S-O-B, no patches >> to be committed to master branch. Nothing goes upstream or into master >> without Signed-off-by and maintainers Signed-off-by. 2. Do not mix >> cleanup and developement ever. If you move a bunch of registers or >> code into a separate file, do just that in one patch. 3. Backwards >> compat patches in separate patches. So first patch should be >> upstreamable, backwards compat patches should be in sequence. >> >> > > Let's say we rework a driver completely, including DDX, to support GEM / TTM > or whatever. > The driver is, in effect, a "new" driver and there are no intermediate > versions of drm > that could be of interest really, since they wouldn't work with any of the > user-space > clients. So no bisecting is possible. Would it be OK to treat such work as a > new driver > and post it as a (URL to) single patch? Yes I'd be happy with that, of course I'd also like the development to occur in the open. If someone else were to start working on something in the open that others were working on under contract or in secret, then I'd expect the contracted group to merge to the open stuff.... > >> Upstream first policy >> >> This policy places a restriction on users of the drm, i.e. Mesa, DDX, >> X server. No upstream release should include code that hasn't been >> included in a Linux kernel release cycle. Upstream can use a >> --enable-experimental-kernel-api type flag but default build should >> never require any unreleased kernel/drm API to build or run. Distros >> should not enable experimental APIs in releases, unless they are >> willing to version their kernel and other components against each >> other and deal with the fallout of API changes. >> >> All userspace APIs need to be submitted to dri-devel and to the Linux >> kernel list, also all patches which need exports or use new non-drm >> kernel functionality should be reviewed by both lists. >> > > Are driver-specific IOCTL interfaces included in this? Yes, any userspace API, anything we need to support for ever and ever. Dave. |
From: Thomas H. <th...@tu...> - 2008-08-28 11:32:58
|
Dave Airlie wrote: > On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström > <th...@tu...> wrote: > >> Dave, >> >> This process looks ok to me, >> but I think some clarifications are needed: >> >> Dave Airlie wrote: >> >>> Okay I've put some thoughts up at: >>> http://dri.freedesktop.org/wiki/DRMProcess >>> >>> and I've pasted it in below this for discussion. >>> >>> some other points: >>> >>> a) People are pushing for a process change, we will have something >>> change, however this isn't a who shouts loudest competition, so more >>> than likely you'll end up compromising, deal with the fact that >>> nirvana for you may be hell for others. >>> >>> b) BSD developers do exist now, giving out that they didn't exist in >>> the past or aren't adding features is pointless. Would you seriously >>> start developing features before >>> getting the code caught up?. So live with the fact that we should help >>> the BSD guys *if* its practical. So we shouldn't do anything major >>> that alienates their further development. >>> (personally I care little for BSD, the license or the OSes, however >>> I'm attempting to be some way fair). >>> >>> c) We get testers from drm master, we get better testers using drm >>> master for features than a separate kernel tree. We get better >>> regression tests from getting stuff upstream. However upstreaming >>> stuff to Linus is not how to find regressions, it helps but its >>> suboptimal in that he will eventually ignore us if the regression rate >>> gets too high. So upstreaming is great for features like GEM, however >>> it would suck for something like vblank-rework. This appears to point >>> at, upstream is great if you touch one driver and exist in your own >>> world, however if you want interfaces that all drivers can use like >>> vbl-rework you need to work somewhere else or carry two interfaces >>> until everyone is ported. >>> >>> So lets see if we can improve this for everyone... >>> >>> Dave. >>> >>> >>> DRM Development Process (Proposed) >>> >>> >>> >> ... >> >>> 1. All patches to be sent to the mailing list with S-O-B, no patches >>> to be committed to master branch. Nothing goes upstream or into master >>> without Signed-off-by and maintainers Signed-off-by. 2. Do not mix >>> cleanup and developement ever. If you move a bunch of registers or >>> code into a separate file, do just that in one patch. 3. Backwards >>> compat patches in separate patches. So first patch should be >>> upstreamable, backwards compat patches should be in sequence. >>> >>> >>> >> Let's say we rework a driver completely, including DDX, to support GEM / TTM >> or whatever. >> The driver is, in effect, a "new" driver and there are no intermediate >> versions of drm >> that could be of interest really, since they wouldn't work with any of the >> user-space >> clients. So no bisecting is possible. Would it be OK to treat such work as a >> new driver >> and post it as a (URL to) single patch? >> > > Yes I'd be happy with that, of course I'd also like the development to > occur in the open. > If someone else were to start working on something in the open that > others were working on under contract or in secret, then I'd expect > the contracted group to merge to the open stuff.... > Yes, that sounds fair. I guess at least the very least should be a common understanding with the people actively working on the open stuff on what to keep and what not to keep. > >>> Upstream first policy >>> >>> This policy places a restriction on users of the drm, i.e. Mesa, DDX, >>> X server. No upstream release should include code that hasn't been >>> included in a Linux kernel release cycle. Upstream can use a >>> --enable-experimental-kernel-api type flag but default build should >>> never require any unreleased kernel/drm API to build or run. Distros >>> should not enable experimental APIs in releases, unless they are >>> willing to version their kernel and other components against each >>> other and deal with the fallout of API changes. >>> >>> All userspace APIs need to be submitted to dri-devel and to the Linux >>> kernel list, also all patches which need exports or use new non-drm >>> kernel functionality should be reviewed by both lists. >>> >>> >> Are driver-specific IOCTL interfaces included in this? >> > > Yes, any userspace API, anything we need to support for ever and ever. > That's really the point that this may or may not be the same thing. The old drm model placed a driver's user space interface under versioning, and any app using that interface would need to monitor the major version number to check for compatibility, although major bumps were strongly discouraged. /Thomas > Dave. > |
From: Dave A. <ai...@gm...> - 2008-08-28 11:45:45
|
On Thu, Aug 28, 2008 at 9:32 PM, Thomas Hellström <th...@tu...> wrote: > Dave Airlie wrote: >> >> On Thu, Aug 28, 2008 at 8:12 PM, Thomas Hellström >> <th...@tu...> wrote: >> >>> >>> Dave, >>> >>> This process looks ok to me, >>> but I think some clarifications are needed: >>> >>> Dave Airlie wrote: >>> >>>> >>>> Okay I've put some thoughts up at: >>>> http://dri.freedesktop.org/wiki/DRMProcess >>>> >>>> and I've pasted it in below this for discussion. >>>> >>>> some other points: >>>> >>>> a) People are pushing for a process change, we will have something >>>> change, however this isn't a who shouts loudest competition, so more >>>> than likely you'll end up compromising, deal with the fact that >>>> nirvana for you may be hell for others. >>>> >>>> b) BSD developers do exist now, giving out that they didn't exist in >>>> the past or aren't adding features is pointless. Would you seriously >>>> start developing features before >>>> getting the code caught up?. So live with the fact that we should help >>>> the BSD guys *if* its practical. So we shouldn't do anything major >>>> that alienates their further development. >>>> (personally I care little for BSD, the license or the OSes, however >>>> I'm attempting to be some way fair). >>>> >>>> c) We get testers from drm master, we get better testers using drm >>>> master for features than a separate kernel tree. We get better >>>> regression tests from getting stuff upstream. However upstreaming >>>> stuff to Linus is not how to find regressions, it helps but its >>>> suboptimal in that he will eventually ignore us if the regression rate >>>> gets too high. So upstreaming is great for features like GEM, however >>>> it would suck for something like vblank-rework. This appears to point >>>> at, upstream is great if you touch one driver and exist in your own >>>> world, however if you want interfaces that all drivers can use like >>>> vbl-rework you need to work somewhere else or carry two interfaces >>>> until everyone is ported. >>>> >>>> So lets see if we can improve this for everyone... >>>> >>>> Dave. >>>> >>>> >>>> DRM Development Process (Proposed) >>>> >>>> >>>> >>> >>> ... >>> >>>> >>>> 1. All patches to be sent to the mailing list with S-O-B, no patches >>>> to be committed to master branch. Nothing goes upstream or into master >>>> without Signed-off-by and maintainers Signed-off-by. 2. Do not mix >>>> cleanup and developement ever. If you move a bunch of registers or >>>> code into a separate file, do just that in one patch. 3. Backwards >>>> compat patches in separate patches. So first patch should be >>>> upstreamable, backwards compat patches should be in sequence. >>>> >>>> >>>> >>> >>> Let's say we rework a driver completely, including DDX, to support GEM / >>> TTM >>> or whatever. >>> The driver is, in effect, a "new" driver and there are no intermediate >>> versions of drm >>> that could be of interest really, since they wouldn't work with any of >>> the >>> user-space >>> clients. So no bisecting is possible. Would it be OK to treat such work >>> as a >>> new driver >>> and post it as a (URL to) single patch? >>> >> >> Yes I'd be happy with that, of course I'd also like the development to >> occur in the open. >> If someone else were to start working on something in the open that >> others were working on under contract or in secret, then I'd expect >> the contracted group to merge to the open stuff.... >> > > Yes, that sounds fair. I guess at least the very least should be a common > understanding with > the people actively working on the open stuff on what to keep and what not > to keep. > >> >>>> >>>> Upstream first policy >>>> >>>> This policy places a restriction on users of the drm, i.e. Mesa, DDX, >>>> X server. No upstream release should include code that hasn't been >>>> included in a Linux kernel release cycle. Upstream can use a >>>> --enable-experimental-kernel-api type flag but default build should >>>> never require any unreleased kernel/drm API to build or run. Distros >>>> should not enable experimental APIs in releases, unless they are >>>> willing to version their kernel and other components against each >>>> other and deal with the fallout of API changes. >>>> >>>> All userspace APIs need to be submitted to dri-devel and to the Linux >>>> kernel list, also all patches which need exports or use new non-drm >>>> kernel functionality should be reviewed by both lists. >>>> >>>> >>> >>> Are driver-specific IOCTL interfaces included in this? >>> >> >> Yes, any userspace API, anything we need to support for ever and ever. >> > > That's really the point that this may or may not be the same thing. The old > drm model placed a > driver's user space interface under versioning, and any app using that > interface would need to > monitor the major version number to check for compatibility, although major > bumps were > strongly discouraged. Major bumps once stuff went into the kernel weren't allowed at all. You'd need to fork the driver in any case. So we did this once or twice on drivers in devel trees like mach64. However upstream first policy should avoid this need. I'd also prefer to see getparam for new features instead of version checks. The linear version check sucks. Dave. |
From: Keith W. <ke...@tu...> - 2008-08-28 12:23:56
|
> Major bumps once stuff went into the kernel weren't allowed at all. > You'd need to fork the driver in any case. So we did this once or > twice on drivers in devel trees like mach64. > However upstream first policy should avoid this need. I'd also prefer > to see getparam for new features instead of version checks. The linear > version check sucks. This is an interesting concept that opens up some ideas for dealing with feature deprecation, etc. Think about opengl's extension mechanism -- features can be exposed through that mechanism without ever providing a guarantee of future availability -- in fact there is no guarantee of any availability outside the current session. Future versions of a GL driver might add or remove extensions as desired, within the constraints of the GL version number advertised. What we could see is something similar for the DRM interface -- a base level of functionality specified by the Major/Minor numbers, but additional extensions that may be advertised according to the whim of the kernel module that the driver can take advantage of if present, but which it must otherwise function correctly without... Extensions that don't work out can be dropped, those that do can be incorporated into the next increment of the minor number, a la GL1.5 Keith |
From: K. H. <kr...@bi...> - 2008-08-28 14:16:34
|
On Thu, Aug 28, 2008 at 8:23 AM, Keith Whitwell <ke...@tu...> wrote: >> Major bumps once stuff went into the kernel weren't allowed at all. >> You'd need to fork the driver in any case. So we did this once or >> twice on drivers in devel trees like mach64. >> However upstream first policy should avoid this need. I'd also prefer >> to see getparam for new features instead of version checks. The linear >> version check sucks. > > This is an interesting concept that opens up some ideas for dealing > with feature deprecation, etc. > > Think about opengl's extension mechanism -- features can be exposed > through that mechanism without ever providing a guarantee of future > availability -- in fact there is no guarantee of any availability > outside the current session. Future versions of a GL driver might add > or remove extensions as desired, within the constraints of the GL > version number advertised. > > What we could see is something similar for the DRM interface -- a base > level of functionality specified by the Major/Minor numbers, but > additional extensions that may be advertised according to the whim of > the kernel module that the driver can take advantage of if present, > but which it must otherwise function correctly without... Yep, it works a lot better to advertise the features available directly rather than just exposing an incrementing version number. This is how I redid the DRI driver interface - everything is an extension that may or may not be exposed by the driver. I would suggest to use a hybrid where we advertise individual features as suggested, but also version them. For example, if we find out that GEM needs another domain bit or something, it's nicer to be able to advertise GEM version 1.1 rather than GEM and GEM_WITH_THAT_NEW_DOMAIN_BIT. cheers, Kristian |
From: Tomas C. <to...@db...> - 2008-08-28 16:38:26
|
Keith Whitwell wrote: >> Major bumps once stuff went into the kernel weren't allowed at all. >> You'd need to fork the driver in any case. So we did this once or >> twice on drivers in devel trees like mach64. >> However upstream first policy should avoid this need. I'd also prefer >> to see getparam for new features instead of version checks. The linear >> version check sucks. > > This is an interesting concept that opens up some ideas for dealing > with feature deprecation, etc. > > Think about opengl's extension mechanism -- features can be exposed > through that mechanism without ever providing a guarantee of future > availability -- in fact there is no guarantee of any availability > outside the current session. Future versions of a GL driver might add > or remove extensions as desired, within the constraints of the GL > version number advertised. Would you want to have the ioctl numbers dynamically allocated, like the event and error bases in the xserver? Otherwise you could run out of them if you statically allocate numbers for extensions which are then later removed. Or would you rather create a single entry point for the extension commands and the multiplex everything through that? Also, you'll have to distinguish between extensions supported by the kernel and userspace (like GLX server and client side extensions), and provide drm_get_proc_address() to get the userspace library entry points. I think the extension mechanism that OpenGL/GLX uses is much better then simple linear versioning. If the userspace code is properly written, you can deprecate and remove extensions without breaking anything (at worst the driver will simply refuse to work, but no crashes etc). No more 5 years waiting to remove old features - take that Linus! :) tom |