El vie, 04-07-2008 a las 16:09 +0200, Robert Millan escribió: > On Fri, Jul 04, 2008 at 02:00:34PM +0200, Javier Martín wrote: > > In the nearly eight years from ext2 release to the merge of ext3 into > > the kernel, some incompatible features were introduced in ext2 proper, > > like filetype and compression. Even now, with ext4 in development and > > merged into the kernel less than five years after ext3, incompatible > > features are being backported to ext2 like the lazy inode initializing I > > mentioned earlier. Those can hit us HARD. > > So you're saying we should make our decisions based on the assumption that > Linux developers could be jeopardizing our efforts by introducing incompatible > features by surprise, without any coordination with us, and that distributors > are going to pass those features down to stable releases, knowing that they > break GRUB, and again without any coordination with us? > I'm not saying that they will _consciously_ try to break us, just that new flags can be introduced "just like that" and that, while ext4 is definitely making quite a fuss, the real danger is in flags like EXT2_FEATURE_INCOMPAT_META_BG, the lazy inode writing flag I mentioned to Bean, since a "best-effort" reader that ignores it can (with a very high probability) read old metadata, since if the same partition is re-formatted with ext2 the inodes will be on the same places. Thus, files from the old FS could "resurrect" (with their data in unknown state) and other nasty things.
These kind of flags don't make a lot of noise in developer circles outside LKML, they are introduced without long times in "development" state and then our driver becomes "broken" in a way that will be very difficult to bugtrace. That's why I said that the bootloader should adopt a conservative stance WRT incompatible feature flags too, but the user override should be present in order to give informed users a choice without having to rebuild GRUB from source.
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
