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:
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 does
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 though.
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 tl card will have
somewhere around 4-16k of possible state. (WARNING: The following is
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
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
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 tl card will have
somewhere around 4-16k of possible state.
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
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
* 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 he was
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 this
11 matches
Mail list logo
