Messages in this thread | | | Date | Thu, 10 Feb 2000 15:46:13 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: 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/
| |