On Tue, Mar 17, 2009 at 7:33 PM, Dave Miner <Dave.Miner at sun.com> wrote: >> It is the way to go, but needs time and consideration, agreed. >> Moinak has done amazing work (not only) in that field. >> > > Maybe that's something you can spend some time looking into? ?I've only > managed an hour here and there and haven't made much progress.
Yep, ok. But it takes indeed more than just a few hours until one has a chance of understanding it. Moinak admitted this himself during his talk on OSDEVCON 2007 (Berlin), when he explained his initial read-only lofi-zlib-compression approach (partially derived from KnoppiX). According to him it took a month++'s time until he got the initial prototype working for the first time. It is a massive job what he has delivered. >> But how do you think about splitting sun4u and sun4v kernels into separate >> mini (or micro-) roots? >> Either in a per iso fashion, or with the need to specify the desired >> miniroot on the OBP command line? >> > > I wouldn't be opposed to splitting them, and indeed I'm having to consider > something like this for x86 as well (64- vs. 32-bit) to get 512 MB installs > working again. That's funny, we had the same idea also on x86 vs. x64. Who holds the patent now? One of my other upcoming distros drops IA32 alltogether. (exactly as when the sun4d and sun4m support got removed from Solaris 10 build 9 [circa] on). I mean all reasonably performing chips feature AMD64 / Intel's clone already. It is only a question of time, when nobody (except for a few enthusiasts) will have 32bit-only chips. So you guys will drop 32bit kernels yourself, in a few years time. The question is, what should be done with userland then. Because unlike on RISC, on x64 the performance may be increased if compiled for 64-bit. And the filesize does not increase so dramatically. I guess we will have 32-bit backward compatibility then (important libs available in both wordsize formats). And all other things in userland may be 64-bit by default, then?? I ship such a distro very soon, just as a test. But right now I'm still merging my auto-build tool with the DC. I also decided to drop the Natamar-Distro-Generator and to re-implement it from scratch. It was inefficient and broken. Time flies. > ?I'd much rather not have to specify it on the command line, > though. ?Usability drops greatly when you have to know what flavor of SPARC > you have in order to even try to boot it. That's true, and at first I wanted to put this thought into the same sentence after a comma, but then I was on the run and didn't recall from memory how exactly we can implement this, so I omitted that sub-sentence. But we can implement this functionality, the only question is how. I'm not sure if any OBP call delivers back the "sun4?" string. If not we must maintain a platforms table in order the automate this decision, where all supported platform names would be listed, each as a Tupel associating to it either "sun4u" or "sun4v". And then the corresponding flags would be set. >> This significantly reduces the archive's size. And when done in >> addition to dcfs, Moinak's solution or what Eremin has done, it will >> reduce boot time (reading the archive into memory and different ways >> of uncompressing) and physical mem-requirements to an acceptable >> level. >> >> What is your opinion about it? >> > > I'm in favor of faster booting and lower memory usage ;-) Makes sense to me )) %martin
