On Mon, 2007-03-19 at 20:05 -0500, Matt Mackall wrote: > On Tue, Mar 20, 2007 at 01:42:46AM +0100, Thomas Gleixner wrote: > > On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote: > > > This is exactly the same problem as booting on a desktop PC. But > > > somehow LILO manages. My first Linux box had a hell of a lot less disk > > > than the platform I bootstrapped (and wrote NAND drivers for) last > > > month had in NAND. > > > > No, it is not. You get the absolute sector address of your second stage > > and this is a complete nobrainer. The translation is done in the DISK > > device. > > LILO and friends manage to boot systems that use software RAID and > LVM. There are multiple methods. Some use block lists, some use tiny > boot partitions, etc. All of them are applicable to controllerless NAND.
Yes, by using fixed addresses, which is not what I want. > > You simply ignore the fact, that inside each disk, USB Stick, CF-CARD, > > whatever - there is a more or less intellegent controller device, which > > does the mapping to the physical storage location. There is _NO_ such > > thing on a bare FLASH chip. > > How many times do I have to tell you that I wrote a driver for > controllerless NAND just last month? Wow. I'm impressed because I'm pulling my opinion out of thin air. > > How exactly does device mapper: > > > > A) across device wear levelling ? > > The same way UBI does, but encapsulated in a device mapper layer. Does the device mapper do that ? > > B) dynamic partitioning for FLASH aware file systems ? > > See above. Does the device mapper do that ? > > C) across device wear levelling for FLASH aware file systems ? > > See above. Look at your own drawing. > > D) background bit-flip corrections (copying affected blocks and recylce > > the old one) ? > > See above. Repeating patterns do not impress me. Your drawing tells otherwise > > E) allow position independent placement of the second stage bootloader ? > > See way above to my LILO response. Neither LILO nor GRUB have search capabilities for randomly located second stage loaders. > > > > You need to implement a clever journalling block device > > > > emulator in order to keep the data alive and the FLASH not weared out > > > > within no time. You need the wear levelling, otherwise you can throw > > > > away your FLASH in no time. > > > > > > And that's why it's in my picture. > > > > Yes, it is in your picture, but: > > > > 1) it excludes FLASH aware file systems and UBI does not. > > 2) your picture does still not explain how it does achive the above A), > > B), C), D) and E) > > > > Your extra path for partitioning(4) and JFFS2 is just a weird hack, > > which makes your proposal completely absurd. > > No, it's just there to show the flexibility of device mapper. But I have > the sneaking suspicion you have no idea how device mapper works. Sigh. Layering violation == flexibility. > In brief: device mapper takes one or more devices, applies a mapping > to them, and returns a new device. For example, take various spans of > /dev/hda1 and /dev/sda3 and present them as new-device1. Take > new-device1 and transform it with dm-crypt to get new-device2. The > kernel doesn't decide how to do this, any more than it decides where > to mount your filesystems. Userspace does. I know how it works. But your blurb does not answer any of my questions. > > > > > 5. We don't reimplement higher pieces of the stack (dm-crypt, > > > > > snapshot, etc.). > > > > > > > > Why should we reimplement that ? > > > > > > So that you can get encryption and snapshot, etc.? > > > > 1. On top of a clever block device. > > > > 2. UBI can do snapshots by design. > > Oh, so you HAVE reimplemented it. No, it already works > > 3. Encryption should be done on the VFS layer and not below the > > filesystem layer. Doing it inside the block layer or the device mapper > > is broken by design. > > That's highly debatable and not a topic for this thread. I see, you define, what has to be discussed. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/