From: Mike A. H. <mh...@re...> - 2001-07-19 08:34:29
|
On Thu, 19 Jul 2001, Marcelo E. Magallon wrote: >Date: Thu, 19 Jul 2001 10:14:12 +0200 >From: Marcelo E. Magallon <mar...@bi...> >To: Trond Eivind Glomsr=F8d <te...@re...> >Cc: Mike A. Harris <mh...@re...>, > DRI devel list <Dri...@li...> >Content-Type: text/plain; charset=3Diso-8859-1 >Subject: Re: [Dri-devel] Re: Versioning of kernel module names > >>> Trond Eivind Glomsr=F8d <te...@re...> writes: > > > > I must be missing something because I can't help but ask "why?". > > > You are shipping one X server with one set of DRI modules. They > > > need one (more or less) specific version of the DRM modules. Why > > > would you need to ship a whole range of DRM modules? > > > > Because we typically have one kernel for multiple versions - e.g. the > > entire 5.x and 6.x sets of RHL use the same kernel. > > But there's still one version of the X server installed at any given > time. Upgrading the X server package should upgrade the DRM modules. No, that is no good because if you upgrade the *kernel*, either yourself, or via an official update, you then no longer have a working DRM. At this point, the next answer is usually "provide the DRM source and have the user recompile it". That is unacceptable. While some users *can* compile stuff, many can not, and nobody should be required to compile anything. At this point, the next answer is usually "Have a script that does it, similar to the way VMware does". That is no good because then the user has compiled their own DRM with possibly our compiler, possibly some other compiler, possibly some other binutils, possibly some other random whatever, and there is no Quality Assurance testing done on it. We cannot support a user compiled DRM, and so if we can't ship a DRM in binary form that a user can use, we simply cannot support 3D hardware acceleration. That is not acceptable to our users, nor to us. There are many many potential solutions to these problems, yes. Many of them are acceptible in one way or another to various people. For them to be realistic for inclusion in a distribution however, any solution must satisfy the requirements set out by the distribution vendor, the packagers, the users, and the people producing the code in the first place. > In the case of distributions, the unusual situation where you have more > than one 4.x X server installed at any given time should be handled > either by the distributor or the user (one of them created the special > situation). No problem, that is not a supported situation. No problem to solve. Nonetheless, a user should be able to have 5 X releases installed if need be, and be able to run DRI on all of them without rebooting or mucking around. I think that much is pretty much agreed upon by the DRI team, Linus, and any distribution vendor's and developers here. The users benefit from this the most however, which is the most important. The end result is a better system for everyone. > I still don't see a realistic situation where you need > more than one X server installed at the same time (outside > development). In general, there isn't. And we do not support doing so in an official way. We support what we release, and our packages do not support installing say 4.0.3 and 4.1.0 at the same time, and never will. As you say, this is only for developers, hackers, etc. The idea is that a user should be able to have any release of XFree86 installed, and he should be able to freely upgrade his kernel either from a distribution supplied kernel or a Linus kernel, etc. without being forced to upgrade XFree86, or build a new DRM manually or automatically. Likewise, they should be able to upgrade XFree86 without being forced to upgrade their kernel in a stable kernel series at least. Putting DRM in a separate package means that for example, we would have to release a new DRM package for every XFree86/kernel release. With 4 kernels and 3 XFree86 releases we would need 3 * 4 DRM packages to cover whatever combination a user had installed. The solutions discussed by Linus and Jeff seem to be the proper way to go and it should work fine when implemented. Now the only question is what to do in the mean time.... ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris ---------------------------------------------------------------------- |