lkml.org 
[lkml]   [2000]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4 Features
   Date:   Thu, 10 Feb 2000 15:07:19 +0000 (GMT)
From: Riley Williams <rhw@MemAlpha.CX>

The basic point is this: If, as a result of experience after the
e2comp subsystem is folded into the kernel, the decision is taken to
depreciate a particular compression method, MY opinion is that the
CORRECT way to do so is as follows:

Well, my suggestion would be to try to figure out if you have enough
information to deprecate some compression methods *before* e2compr gets
folded into the kernel. That makes life so much simpler for all
concerned. Once e2compr does get folded into the kernel (especially
once it hits a stable kernel release, or has been in a development
kernel for more than a few revisions) then yes, we have to go through
the fairly long and careful process which you outlined.

That's why it's better to deprecate features/formats before they go into
kernel....

> Peter Moulder has lately folded together the 0.3 and 0.4 e2compr
> utilities, I believe. I had mail from him over new year. Do
> these now get around the problem of needing one kernel to
> decompress with and another to compress with? How far off a
> userspace solution are we?

I'm dealing strictly with the 0.4 version, so will leave comments
regarding this to Peter...

How many people are using 0.3 e2compr? If it's not many, then maybe we
don't even need to bother with a user-space conversion tool.

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.107 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site