26 Jun, 2019

1 commit

  • A Reed-Solomon code with minimum distance d can correct any error and
    erasure pattern that satisfies 2 * #error + #erasures < d. If the
    error correction capacity is exceeded, then correct decoding cannot be
    guaranteed. The decoder must, however, return a valid codeword or report
    failure.

    There are two main tests:

    - Check for correct behaviour up to the error correction capacity
    - Check for correct behaviour beyond error corrupted capacity

    Both tests are simple:

    1. Generate random data
    2. Encode data with the chosen code
    3. Add errors and erasures to data
    4. Decode the corrupted word
    5. Check for correct behaviour

    When testing up to capacity we test for:

    - Correct decoding
    - Correct return value (i.e. the number of corrected symbols)
    - That the returned error positions are correct

    There are two kinds of erasures; the erased symbol can be corrupted or
    not. When counting the number of corrected symbols, erasures without
    symbol corruption should not be counted. Similarly, the returned error
    positions should only include positions where a correction is necessary.

    We run the up to capacity tests for three different interfaces of
    decode_rs:

    - Use the correction buffers
    - Use the correction buffers with syndromes provided by the caller
    - Error correction in place (does not check the error positions)

    When testing beyond capacity test for silent failures. A silent failure is
    when the decoder returns success but the returned word is not a valid
    codeword.

    There are a couple of options for the tests:

    - Verbosity.

    - Whether to test for correct behaviour beyond capacity. Default is to
    test beyond capacity.

    - Whether to allow erasures without symbol corruption. Defaults to yes.

    Note that the tests take a couple of minutes to complete.

    Signed-off-by: Ferdinand Blomqvist
    Signed-off-by: Thomas Gleixner
    Link: https://lkml.kernel.org/r/20190620141039.9874-2-ferdinand.blomqvist@gmail.com

    Ferdinand Blomqvist
     

21 May, 2019

1 commit


07 Nov, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds