Bootloader

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> "dynparts" rides again :-(  I wonder if we steadily regenerate
>> everything we wanted to discard.
> 
> Naw, for booting that would just be a block of data at a well-known
> location in memory. The boot loader has to skip bad blocks anyway,
> so it can do this for the parameter block as well.

Yep, dynamic generation of kernel commandline has managed to exist based
on bad blocks :-)

>> Thing that bothers me about initramfs is you have to sit there while you
>> pull the whole thing before the kernel boots.
> 
> Aah, now I understand ! Yes, that's true. However, it should be fairly
> small, maybe a couple of MB. So I'm not sure you'd really notice much
> of a difference. We'll have to try it. If it's too slow, we can always
> optimize later.

We need to decide about that based on the max size allocated for this
recovery system, not the minimum and "optimize later".  What max size
are you thinking of here for recovery kernel and rootfs / initrd?

>> But it is pretty ugly if we expose the block devices in linux bad blocks
>> and all, with no OOB in there to even figure out if they are bad, that
>> doesn't sound right.
> 
> Bad blocks are still marked in their OOB areas. The only thing that
> would be missing is the bad block table, i.e., the ability to tell
> whether a block is bad without actually accessing it. The way the
> MTD code looks, this is supposed to work just fine.

No, I mean if you open the block device for dd or whatever, there is no
"out of band" information in that device node.  You just get
dysfunctional blocks.  If we didn't summarize it in a bad block table
mtd won't help if I understood it, that sounds like it would surprise
and unpleasantly amaze people when they found dd died with IO errors or
whatever on the first bad block, it acts different on each device, etc.
   Don't we need to deal with that crap?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4aigOjLpvpq7dMoRApABAJ95yQCmryqagogZaa8A4rjRARnYyACeLzkc
+n5ny4C+WEFCq8hQOkaJ8WM=
=ELIx
-----END PGP SIGNATURE-----