On Wed, 30 Jan 2002, Keith Whitwell wrote:
> Vladimir Dergachev wrote:
> >
> > 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.
>
> This will never be accepted by Linus, Alan or any of the kernel people. You
> need to find a way to make existing (distributed) clients work with the new
> kernel modules. Major number bumps are essentially illegal - we've promised
> not to do this. I don't know how to achieve your changes under that
> restriction...
Is there a way to check from within drm module which 2d driver is
accessing it ? Because otherwise we'll need to bump the major version.
At the moment 4.2.0 radeon driver will happily work with any drm driver as
long as major is the same and minor is not less than what we currently
have.
The change is not only to make GATOS drivers work, it is needed to make
any kind of busmaster PCI access work with AGP Radeons. In particular,
scratch register image will not be reliably updated without it.
The reason GATOS driver needs it is to perform video capture.
Vladimir Dergachev
>
> Keith
>
> _______________________________________________
> 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
