All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Reiser <jreiser@BitWagon.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/7] inflate pt1: clean up input logic
Date: Sat, 25 Feb 2006 14:25:10 -0800	[thread overview]
Message-ID: <4400D946.4090200@BitWagon.com> (raw)
In-Reply-To: <20060225214704.GN13116@waste.org>

Matt Mackall wrote:
> On Sat, Feb 25, 2006 at 09:22:48PM +0000, Russell King wrote:
> 
>>init/do_mounts_rd.c:#include "../lib/inflate.c"
>>init/initramfs.c:#include "../lib/inflate.c"
>>
>>for these your arguments that halting is fine is _NOT_ correct nor is it
>>desirable.
> 
> 
> If you have an argument for why we shouldn't halt on failed
> init{rd,ramfs} decompression, I look forward to hearing it.

It depends on the nature of the error, and which parts were decompressed
successfully.  Gzip has optional "re-sync" capability, and ideally a
decompression failure might invoke some kind of bad-block tagging
for the output instead of halting the machine.  Some init{rd,ramfs}
have all the network drivers, all the SCSI drivers, all the sound
drivers, etc., but the user may care only about those for the current
machine.  Other init{rd,ramfs} contain only "essential" pieces.
Even then, the pieces that are deemed more important can be at the
beginning.  It might be possible to work without a sound driver,
but perhaps not without a SCSI driver.

> In my mind, being unable to decompress init* is every bit as fatal as
> being unable to mount root.

It may be possible to recover, at least partially, from one error
more than from another.  It would be nice if the decompressor itself
was a minor influence instead of a major one.

-- 

  parent reply	other threads:[~2006-02-25 22:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0.399206195@selenic.com>
2006-02-24 20:12 ` [PATCH 2/7] inflate pt1: kill legacy bits Matt Mackall
2006-02-24 20:12 ` [PATCH 1/7] inflate pt1: lindent and manual formatting changes Matt Mackall
2006-02-24 20:12 ` [PATCH 3/7] inflate pt1: clean up input logic Matt Mackall
2006-02-24 22:19   ` Russell King
2006-02-25  6:51     ` Matt Mackall
2006-02-25  8:49       ` Russell King
2006-02-25  8:55         ` Russell King
2006-02-25  9:04           ` Andrew Morton
2006-02-25  9:09             ` Russell King
2006-02-25 14:54         ` Matt Mackall
2006-02-25 18:05           ` Russell King
2006-02-25 21:04             ` Matt Mackall
2006-02-25 21:22               ` Russell King
2006-02-25 21:47                 ` Matt Mackall
2006-02-25 21:58                   ` Russell King
2006-02-25 22:37                     ` Matt Mackall
2006-02-25 22:57                       ` Russell King
2006-02-27  1:18                         ` Johannes Stezenbach
2006-02-27  8:32                           ` Russell King
2006-02-27 12:07                             ` Johannes Stezenbach
2006-02-27 15:47                               ` Russell King
2006-02-27  9:06                         ` Matt Mackall
2006-02-25 22:25                   ` John Reiser [this message]
2006-03-07 23:26                 ` H. Peter Anvin
2006-03-10 18:55                   ` Matt Mackall
2006-02-24 20:12 ` [PATCH 4/7] inflate pt1: start moving globals into iostate Matt Mackall
2006-02-24 20:12 ` [PATCH 6/7] inflate pt1: internalize CRC calculation, cleanup table calculation Matt Mackall
2006-02-24 20:12 ` [PATCH 7/7] inflate pt1: eliminate memzero usage Matt Mackall
2006-02-24 20:12 ` [PATCH 5/7] inflate pt1: cleanup Huffman table code Matt Mackall
2006-02-24 21:52   ` John Reiser
2006-02-24 22:06     ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4400D946.4090200@BitWagon.com \
    --to=jreiser@bitwagon.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.