lkml.org 
[lkml]   [2000]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: 2.4 Features
    Date
    "A month of sundays ago Theodore Y. Ts'o wrote:"
    > [Riley wrote]
    > The only 'backwards compatibility' code that I'm interested in seeing
    > in the kernel would be code that decompresses depreciated compression

    Well, I've never quite got what the problem really is. One wants to
    decompress under a kernel that supports 0.3 and compress again under
    a kernel that supports 0.4. If 0.4 grows a 0.3 decompression routine,
    then that's the best of all worlds. But does one need the kernels
    for this?

    > I wouldn't even do that much. Take the code out of the kernel entirely,
    > and then provide a user-mode utility that goes through the filesystem,
    > and converts the files compressed with a depcreated algorithm to either
    > being uncompressed or compressed with a better format. The goal here is
    > to keep the kernel as long-term maintainable as possible.

    Can this be done in user space? ... e2fsck does things at that level!
    It's just playing on the raw device.

    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?

    Peter

    -
    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:3.192 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site