Re: What to do about shared files and drm-core?
Jon Smirl wrote: On Fri, 01 Oct 2004 10:49:14 -0700, Ian Romanick [EMAIL PROTECTED] wrote: Jon Smirl wrote: Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6 before it drifts too far from being able to run on 2.4. I suspect linux-core would compile on 2.4 right now with minor changes. Or is it better just to declare 2.4 finished as is? That sounds like a good option to me. I'm sure some people will still have 2.4 boxes around for awhile longer. I suspect we'll deprecate 2.4 faster than we did 2.2, but I think we need to keep it on the active support list for a bit longer. Which sounds good: 2.4 core, or declaring it finished and patching the old code as needed? Sorry for not being more clear. I meant 2.4 core. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
Jon Smirl wrote: I haven't moved anything out of shared, it's all paralleled in shared-core. 90% of the changes are from DRM() macro removal. I did eliminate one header file for each device since I kept deleting things until they were empty. 2.4 is a bigger question to me. For example 2.6 is adding the idr_xxx support for dealing with dynamic minors. 2.6 also has a new system for /proc files. Another one is the cdev support for partially reserving minors. There are lot's of sysfs changes needed too. Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6 before it drifts too far from being able to run on 2.4. I suspect linux-core would compile on 2.4 right now with minor changes. Or is it better just to declare 2.4 finished as is? That sounds like a good option to me. I'm sure some people will still have 2.4 boxes around for awhile longer. I suspect we'll deprecate 2.4 faster than we did 2.2, but I think we need to keep it on the active support list for a bit longer. That said, I've been running the core stuff on a couple boxes for most of the week, and I like it. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
On Fri, 01 Oct 2004 10:49:14 -0700, Ian Romanick [EMAIL PROTECTED] wrote: Jon Smirl wrote: Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6 before it drifts too far from being able to run on 2.4. I suspect linux-core would compile on 2.4 right now with minor changes. Or is it better just to declare 2.4 finished as is? That sounds like a good option to me. I'm sure some people will still have 2.4 boxes around for awhile longer. I suspect we'll deprecate 2.4 faster than we did 2.2, but I think we need to keep it on the active support list for a bit longer. Which sounds good: 2.4 core, or declaring it finished and patching the old code as needed? -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
What to do about shared files and drm-core?
What do we want to do about drm-core vs the old build model? There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. If the choice is to declare 2.4 finished then there is a lot of cruft that can be removed from the 2.6 linux-core code. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
On Thu, 2004-09-30 at 16:52, Jon Smirl wrote: What do we want to do about drm-core vs the old build model? There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. If the choice is to declare 2.4 finished then there is a lot of cruft that can be removed from the 2.6 linux-core code. When I get some time, I'll probably move the BSD stuff to the core model. I'm not a huge fan of it, but it's ok. The one concern I had was unconditional dependency on AGP, but I've talked it over and we can do some reworking in the kernel that we've been saying was necessary anyway and avoid unconditionally requiring AGP. I would prefer to see the changes for the core live in shared/ like always and have the current directories disappear, but it's not a big deal. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
I would prefer to see the changes for the core live in shared/ like always and have the current directories disappear, but it's not a big deal. Merging the shared dirs is not a major undertaking, you could do it with some static inlines in the platform directories to deal with the lack of DRM() macros... I might get time later (I never tire of saying that...), am trying to track down why doublebuffering don't work in solo at the moment, I've tracked it down to the cliprects but my hangover is working against me not to mention my lack of knowledge of GLX... 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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What to do about shared files and drm-core?
I haven't moved anything out of shared, it's all paralleled in shared-core. 90% of the changes are from DRM() macro removal. I did eliminate one header file for each device since I kept deleting things until they were empty. 2.4 is a bigger question to me. For example 2.6 is adding the idr_xxx support for dealing with dynamic minors. 2.6 also has a new system for /proc files. Another one is the cdev support for partially reserving minors. There are lot's of sysfs changes needed too. Maybe we should fork linux-core into linux-core-2.4 and linux-core-2.6 before it drifts too far from being able to run on 2.4. I suspect linux-core would compile on 2.4 right now with minor changes. Or is it better just to declare 2.4 finished as is? -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel