On Wed, 30 Jan 2002, Daryll Strauss wrote:
> On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote:
> > Regardless of the way it is merged the driver major version will need to
> > be bumped. GATOS drivers does this but only minor - as I did not want to
> > upload a mesa radeon driver just because of the version change.
>
> I'm afraid I haven't been following this discussion closely enough, but
> I found this statement sort of odd, so I thought I'd comment.
>
> Version numbers for kernel interfaces are rather different than those
> for normal software packages. In normal software packages they are more
> of a vanity thing. A minor version number bump means small things
> changed, and a major one means hey we did big things. In kernel drivers
> they are really important as they describe the API between the kernel
> and the user space application. There are very strict rules about which
> version numbers are changed when.
>
> The major version of a driver should be incremented if and only if there
> are incompatible changes to the driver that prevent older versions from
> working. You obviously want to minimize these sorts of changes, so that
> you don't break compatability. For example, lets say we found a big
> security hole in an IOCTL. The first thing we'd try to do is rewrite the
> function so avoid the hole. Maybe even in a way that's really slow. As
> long as the interface remains the same that's fine. We might add a new
> interface that's fast again, but keep the old one around for backward
> compatability. If that's completely impossible then we remove the IOCTL
> and bump the major version number.
>
> If you add or change functionality, but the old drivers still work, then
> a minor version number should be bumped. Drivers will check for a
> matching major number and minor number that is greater than or equal to
> the one they need. So, again if we go back to that security problem. If
> we rewrote the old IOCTL to be slow but secure and added a new one that
> is safe and fast, the minor number would be bumped.
>
> If you just fix a bug or make some really small change that doesn't
> impact the interface, then you bump the third digit. Third digits are
> ignored by the software and are really just documentation.
I completely agree with you.. but I did not give you details :))
What happens is that if you try to use older drm driver with GATOS 2d
driver the GATOS driver will notice and complain. But if you use GATOS drm
driver with older 4.2.0 2d driver you will get a lockup.
The reason is that the changes involve programming Radeon's memory
controller to place AGP aperture after the end of the framebuffer and not
at the start of PCI space as it is done currently. Both 2d driver and drm
driver have to agree on this - which is why a bump in major version is
necessary.
The reason I did not do it is that the mesa driver checks major version as
well. Hence it will complain if it is bumped. Since I did not want to open
a new CVS module just for changing version in mesa driver I decided to go
the "slightly" broken way under assumption that few people with install
GATOS drm-kernel but will forget to install GATOS 2d driver.
Does this make sense ?
Vladimir Dergachev
>
> (These paragraphs might be good for a FAQ/Doc somewhere)
>
> So, the thing that struck me as odd, is that you said you only bumped
> the minor version because you didn't want to break Mesa. If your changes
> do work with Mesa, than bumping the minor version is the right thing to
> do. We're trying REALLY hard not to change the kernel interfaces. Linus
> kicked our asses pretty severely about not being careful with kernel
> version numbers. (Rightfully so) Weve been told in no uncertain terms
> that if we didn't get this stuff under control it would be removed from
> the kernel tree. So we should be very careful about how this Gatos
> functionality is added. It sounds like it should be possible to do it
> without breaking the API if we put our thinking caps on.
>
> - |Daryll
>
>
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
