> On Mar 29, 2015, at 15:56, Warner Losh <[email protected]> wrote: > >> On Mar 29, 2015, at 2:29 PM, Craig Rodrigues <[email protected]> wrote: >> >> On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh <[email protected]> wrote: >> >> If we built a UFS1-only boot2, that would fit in the 7.5k we have left >> to play with. We could then build a UFS2-only boot2 that would easily >> fit in the like 32k limit that UFS2 has. >> >> The only reason we went to supporting both was to have something >> universal. Since it requires a reformat to go from UFS1 -> UFS2 we >> wanted the transition to be as smooth as possible so you didn’t have >> to add boot blocks into the mix. >> >> Now the only people that use UFS1 are people with really old systems >> that are never going to upgrade, or people building new systems with >> UFS1 because they are space constrained (for whatever reasons that >> we’re not going to debate here: they are still real). >> >> In the past 5 years, I have worked on some embedded systems where UFS1 was >> chosen because of very low memory and disk space requirements. >> So those systems are real and out there. >> >> Just out of curiousity, what is it about newer compilers that cause >> the size of boot2 to increase so much? >> >> Could we do some silly things like removing/reducing the use of printf() >> to save some more bytes, in order to buy us more time, before having >> to rewrite everything? :) > > Removing printf isn’t going to save us. It usually compiles to 80-120 bytes. > > I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe > some safety belts in the boot block splatter programs to prevent > brickification.
Since the proposal to split up the code by filesystems is on the table, would it make sense to do something similar for zfs? Thanks! _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
