Keith Whitwell wrote:
> > I suppose I'm basing my assumptions on sarea usage that is not there right
> > now (a private sarea per context system rather than the temporary copies
> > which we have now), and assuming a full featured t&l card will have
> > somewhere around 4-16k of possible state.
>
> 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>
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 bee
> Actually it doesn't acheive anything. There's no pretending that you don't
... There's no use pretending...
> have ioctls that you really do - that's all a versioning scheme can
> acheieve (ignoring the sarea snafu, of course).
Keith
___
> I suppose I'm basing my assumptions on sarea usage that is not there right
> now (a private sarea per context system rather than the temporary copies
> which we have now), and assuming a full featured t&l card will have
> somewhere around 4-16k of possible state. (WARNING: The following is
> s
On Mon, 15 Oct 2001 11:36, Daryll Strauss wrote:
> On Mon, Oct 15, 2001 at 10:14:33AM -0600, jhartmann wrote:
> > If you have demenstrated that this is the case then we should remove the
> > version system then I guess. I do want to voice my concerns though by
> > writing out my argument fully th
On Mon, Oct 15, 2001 at 10:14:33AM -0600, jhartmann wrote:
> If you have demenstrated that this is the case then we should remove the version
> system then I guess. I do want to voice my concerns though by writing out my
> argument fully though.
Having a version system is safer. If something doe
Keith Whitwell wrote:
> On Sun, 14 Oct 2001 22:39, jhartmann wrote:
> > 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 propos
On Sun, 14 Oct 2001 22:39, jhartmann wrote:
> 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:
> >
> >
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 alwa
> Actually 2.5 will see a lot of devices moving away from IOCTLs (even legacy
> ones) as Linux gains namespace support. From the Linus threads I've read,
> even older IOCTLs will be shot down. The unmaintainability and randomness
> of IOCTL numbering schemes is one of the things that brought th
* Keith Whitwell <[EMAIL PROTECTED]> on Sat, Oct 13, 2001:
>
> Instigate a rule where any released ioctl will always be supported, with the
> same semantics and interface.
>
[...]
>
> Secondly, it means no ioctls are ever removed or renamed. This was Linus'
> big concern and h
12 matches
Mail list logo
