From: Jeff H. <jha...@va...> - 2001-07-18 22:48:46
|
Linus Torvalds wrote: > On Wed, 18 Jul 2001, Mike A. Harris wrote: > >> Jeff, please hold off on locking this in stone just yet. I like >> the idea so far, but I would like to bounce it off our kernel >> team and see what they think. The more eyes that see this >> before the decision is final, the better IMHO. > > > Actually, as far as the kernel is concerned, this is REALLY easy. > > Either the DRM interfaces maintain backwards compatibility, or they get > dropped from the kernel source tree. > > End of story. There's a single exception on the grounds of "anybody can > mess up once by not just thinking about it", but that's it. > > So right now, I'm perfectly willing to accept two DRM trees or something > else, on the theory that hey, it's really hard to get right the first > time, and nobody was even THINKING about backwards compability because > everybody was so focused on just getting it working in the first place. > > But that is not something that people can continue doing forever. > > The kernel tree cannot have 15 different versions of DRM. This is not > something we discuss - this is a FACT. > > Which means that when people add new interfaces, they had damn better make > sure that the old interfaces still work, and are 100% backwards > compatible. That way the kernel DRM version can be incremented, without > breaking old X servers. > > What does this mean? > > - When you add an ioctl, you MAKE A NEW NUMBER. You NEVER EVER re-use an > old one, like DRM did between 4.0.x and the CVS tree. > > - When you change a user-exported structure argument in incompatible > ways, THAT IS A NEW IOCTL. Same way that when the "stat" structure > changes in the kernel, we have to make a new sytem call for it. > > - When the X server starts up, it queries the version number of the > particular driver, and will refuse to run with a version "too old". But > there is no need for fancy version number schemes, because they are all > backwards compatible. Thus, if the X server wants version 7, it should > be happy with version 9. It's not about DRM version or XFree86 version, > it's _only_ about the version of the particular video driver interface. > > So in the same tree, the Radeon driver may be at version 4, while the > i810 driver is at version 9. Don't get stuck with global versions - why > should you tie things up more than they deserve? > > Now, we already have one case where this broke, which is why we probably > should have a major version number too, which indicates that things start > from a clean slate. So the old 4.0.x DRM should be called version 0.0, and > the new 4.1 DRM should be called 1.0. > > And everybody should strive for never ever even having a 2.x release. Add > new functionality, but don't break old stuff. And realize that when a > completely new card comes out, you just start from 1.0 for that card. You > don't make a new DRM version for everybody else. They DO NOT CARE. This makes sense, and is where I guess we have to go. I don't want the DRM to be removed from the kernel on my watch. I do have a concern right now though: Currently the 4.1 drm has no notion of which version the XServer is expecting. This is a very significant problem because the ioctl interface is actually the least of my concern. We should have been handling that part correctly from the beginning. The kernel modules interface with the 3D driver very tightly using a shared memory area. The layout of the shared memory area is nearly impossible to keep constant. What we need is some sort of mechanism to communicate the version the XServer is expecting, so we can insure that the sarea is laid out correctly. This will require that each revision of the sarea in a driver will have to have to duplicate code (at least the final binary will, most of this can be handled by templating) for each function which accesses the sarea. This can potentially become a huge amount of duplicate code, and I want to bring that to your attention. I would imagine that we are going to have to overload the entire driver dependant on the version number at runtime. This is probably not the design you had in mind but it is the only one I can think of right now. We already have changes in the works which drastically change the layout of the sarea for all the dma drivers. This vastly improves performance but it breaks compatibility currently. The only way we can make these changes is if we duplicate large portions of code. Since we have to go this way, I suppose the DRM kernel module will have to assume if it doesn't get this special ioctl telling it what version it should use, that it should assume that it is running on a 4.1 XServer. Other revisions of the XServer must send this ioctl down to the kernel module for it to function correctly. > > Note that this really is not negotiable as far as the kernel is concerned. > If the DRM team cannot bother with backwards compatibility, then the DRM > tree from the kernel just gets dropped. There's no point to having it at > all, and that means that when the kernel changes, there will be version > skew, and people will be unhappy. But that's better than having confusion > about fiver different versions and having to compile in the right one. > > And if the DRM stuff only works as modules, and only works when combined > with the right version of XFree86, then what's the point of having it in > the kernel tree AT ALL? > > I want to have one Radeon driver, compiled into the kernel, and I want it > to work with both the new X server and the old one. But it's ok if that > means that the kernel driver has to be the _newest_ one. It's _not_ ok if > it means that I have to have two different kernels. > > I hope that this can happen. I hope that the people working on DRM will > realize that the ioctl's they use aren't just temporary random numbers, > they are driver-specific system calls. This shouldn't have happened, however look at my comments on the sarea. The sarea is really the changing interface between the kernel and the device driver that I worry about. The ioctl's should have never been a problem, but go reused because we didn't have strict guidelines in place. > And the same way the kernel still > supports the old-style 32-bit "lseek()" system call while at the same time > _also_ supporting the new 64-bit llseek(), you have to do the same thing. > > Does this mean that you need to actively _think_ about forwards > compatibility before adding an ioctl? Hell yes. Does it mean that some > things have to be designed up-front a bit more sometimes? Oh, yes. Does it > mean somewhat more work? Sure it does. > > But does everybody agree that it is worth it? I personally sure hope we > do. Because I'm not in the least interested in seeing many different DRM > versions in the kernel tree. I can take two. If I have to see three, I'll > just say "f*ck those incompetent bastards", and let you keep track of your > own damn mess. > Agreed. -Jeff |