Keith Whitwell wrote:
>
> On Mon, 15 Oct 2001 07:00, Jens Owen wrote:
> > Keith,
> >
> > Thanks for addressing this issue. I think it's an important area to our
> > success. I do have a few questions. They are inline below.
> >
> > Keith Whitwell wrote:
> > > Jeff, Others,
> > >
> > > I've been reviewing the work in the 3.5 branch for backwards
> > > compatibility and to me it looks like we can do it with a lot less
> > > effort. Here's what I'm proposing, in one simple sentence:
> > >
> > > Instigate a rule where any released ioctl will always be
> > > supported, with the same semantics and interface.
> > >
> > > This sounds simple and has a few consequences. First and foremost is
> > > that the use of the sarea for passing parameters is deprecated.
> >
> > I can understand needing stricter policies for how we manage the SAREA,
> > but I construe the lack of parameter passing to be the equivelent of not
> > using it at all for the kernel module. I can see some strong cases for
> > using it, especially from the kernel module which can't easily query the
> > X server. For example, if I needed to add clipping functionality to my
> > kernel module, I would want to put clip rect information in the SAREA.
> > The kernel module would gather it from there when needed and know that
> > it was always current.
>
> > > Any new ioctl
> > > will take all its parameters through the ioctl struct, even if that means
> > > some performance issues. I don't think it will however.
> > >
> > > Secondly, it means no ioctls are ever removed or renamed. This was
> > > Linus' big concern and he was right. If new functionality or a varient
> > > is required, it will always be a new ioctl.
> > >
> > > There's no need for a versioning ioctl under this scheme, because all it
> > > could do is turn off some ioctls that are never going to be used anyway,
> > > so what's the point. Under this scheme all 'versions' are just subsets
> > > of the full functionality, setting a version doesn't alter the behaviour
> > > of any ioctl, so there's no point in setting a version.
> >
> > Is there some way of determining which IOCTLs are supported? For
> > example, let's say I add a new IOCTL to a kernel DRM module, and utilize
> > the IOCTL from my client side direct rendering library. Would I be able
> > to query whether this IOCTL is present at run time so that I don't have
> > problems should a user have the latest client side driver, but an older
> > kernel module?
>
> The existing version *querying* inferface remains. What we don't have is the
> ability to *set* the version of the kernel module. Mainly because it isn't
> needed: All the functionality from previous versions remain, so as long as
> the module you see is new enough, it will work.
Great, the clarifies things. I think your proposal is right on. In
addition, we still need to emphasize the use of the version "querying*
interface. Perhaps stating policies like, you bump the version number
at the same time you check in code which extends the interface. Waiting
till the code is released to bump the versions just improves the chances
by an order of magnitude of forgeting to bump the version.
> The only real difficulty with this was the fact that we were putting a bunch
> of things that should be ioctl parameters into the sarea. (This was mainly
> my idea, and it was wrong.) Any change to the sarea would break backwards
> compatibility, so you end up in a stupid situation where you basically have
> an ioctl to tell the kernel what the sarea should look like...
>
> I'd rather put the effort into getting a clean interface to work fast than
> getting adding bandaid ioctls to a fast but rotten interface.
Okay, and given that we could use the SAREA if we *had* to, I'm on
board.
> > > So, the 3.5 branch kernel component now looks identical to the trunk with
> > > a small number of new ioctls.
> > >
> > > I think this is closest to how the kernel people expect interfaces to be
> > > treated, and after coding it up it really makes a lot of sense.
> >
> > Is it likely that two different hardware data flow policies could NOT be
> > supported at the same time? For example, a DMA vs PIO mode that
> > required significant overhead and flushing to switch.
>
> There's nothing precluding that. All that this policy means is that we can't
> take an old ioctl and change it's meaning in a newer module - there's nothing
> to stop you adding new ioctls that have new meanings.
I like your thinking. If you really try, you can almost always preserve
backwards compatability. The code can get uglier as you try and
preserve version after version with fixes in some places and bug
compatability in others--but still the idea of preserving compatability
is more important.
> > What I interpreted Linus to be recommending was very similary to what
> > you are. With a few minor caveats...
> >
> > Instigate a rule where any released ioctl will always be
> > supported, with the same semantics and interface. When new ioctl's are
> > added the minor number is bumped. Should ioctl backwards compatability
> > ever be broken you will be VIRTUALLY whipped and beaten; in addition,
> > you will be PHYSICALLY whipped and beaten if you forget to bump the
> > major number when breaking backwards compatability:-)
>
> No - there's never an excuse to break backwards compatibility. That was
> Linus' point. The rule is "Never break backwads compatibility".
I can live with words like almost never. In fact, I can live with
having to get permission from a broader group of developers, or from the
X core team, or Linus. However, there may come a time where it's
needed. I hope it's not soon because we've already used up our
compatabililty karma for the next few years. Even Linus pointed out a
major version number should be used to control this:
Linus wrote:
LT> Now, we already have one case where this broke, which is why we
probably
LT> should have a major version number too, which indicates that things
start
LT> from a clean slate. So the old 4.0.x DRM should be called version
0.0, and
LT> the new 4.1 DRM should be called 1.0.
LT>
LT> And everybody should strive for never ever even having a 2.x
release. Add
LT> new functionality, but don't break old stuff. And realize that when
a
LT> completely new card comes out, you just start from 1.0 for that
card. You
LT> don't make a new DRM version for everybody else. They DO NOT CARE.
> > He actually said it in a more polite way, but I do think it addresses
> > the need for a query to know which IOCTL's are present at run time, and
> > allows for a completely new incompatable modes to be supported when the
> > beating^H^H^H^H^H^Hchange is absolutely necessary.
>
> It should never be necessary. Any new functionality goes in new ioctls. Old
> functionality must be supported even if at a performance cost. That way
> upgrading a kernel will never break an old xfree.
Yes, let's stand on our hands to preserve compatability, but let's not
loose the only mechanism we have to pick up the pieces should we
fall...the major number in the *query* version.
> Is there a reason this isn't cc'd to dri-devel?
My mistake, just an oversight.
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
