On Mon, Aug 3, 2009 at 3:51 AM, Brandon Barker<brandon.bar...@gmail.com> wrote: > Brandon Barker > Phone: (607) 262-6009 > brandon.bar...@gmail.com > http://brandon.barker.googlepages.com/home > > > > On Mon, Aug 3, 2009 at 3:29 AM, Alan > Coopersmith<alan.coopersm...@sun.com> wrote: >> Or those that involve a change of the defined arguments to a function call, >> or similar ABI changes. I believe the cases for individual code changes >> to Solaris would be similar. >> >> Where this really breaks down is the patch model - what Linux kernel >> developers >> think of as a patch is a diff to the kernel sources to fix an issue - >> something >> you apply with the "patch" (or on Solaris "gpatch") commands and then >> rebuild. >> >> Solaris kernel patches on the other hand are distributed as a set of all the >> binaries that changed since the last baseline (either the release of the OS, >> such as Solaris 10 in 2005, or the last "rejuvenation" round, when a kernel >> patch series was declared frozen, and a new one started that required you >> have the last one from the old series installed first as your baseline). >> >> If 12% of kernel changes require hand-tuning, and every Solaris kernel patch >> before long ends up with a hundred or more kernel changes, then you've got at >> least 12 kernel changes in each patch that require hand-tuning, and you've >> got >> a variety of previous versions that they could be patching up from, so you >> end >> up with 100% of Solaris kernel patches requiring hand-tuning to support hot >> patching, plus a complex test matrix to verify it correctly patches in from >> the >> various states you could patch from, resulting in longer, slower, more >> expensive >> test cycles before customers can get their fixes. > > Thanks for the clarification. Seeing as the kernel is open source > now, I suppose the model for patch distribution could be changed in > the future, though that might be a lot of work. > > Having the option of doing a hot-patch versus a reboot may be one > route (and I suppose this is how linux currently works for ksplice > enabled systems), but as you said this would still involve the same > increase in testing. Its not really something I need, and I guess if > there isn't demand for it, it remains one of those cool but > unnecessary technologies that is just too much work to be practical. > >> In the end, Sun found in practice that using Live Upgrade to install patches >> to >> another boot environment and limiting downtime to just long enough to reboot >> into that, was good enough, and a good deal less risky, for most customers. >> (Less risky, since not only do you avoid changing the running kernel, but you >> have the old boot environment to rollback if something goes wrong, without >> having to double the effort by having "hot-unpatching", and know that if >> there >> is a need to reboot/power failure/panic/etc., you'll be running the same >> code/state without wondering if the installed image exactly matches the >> hot-patched in every single way.) > > > I think this is a good argument for server usage, and it is almost > always a better strategy for desktop users. In any case, at least I > don't have to reboot after I install an update to adobe reader (cough > cough, windows xp) ;-)
Also, remember that now with fast reboot, the outage window is even shorter. I think between the two, you're going to have a solution that's 'good enough' while far less complex. > > >> -Alan Coopersmith- alan.coopersm...@sun.com >> Sun Microsystems, Inc. - X Window System Engineering >> >> >> Brandon Barker wrote: >>> Nice, I hadn't seen that in my quick google searches. >>> >>> My understanding was that 88% of the tested patches in linux could be >>> applied without additional code being written; only those that require >>> a change in data structures or boot-time initiliazation code would >>> require code. >>> >>> Brandon Barker >>> Phone: (607) 262-6009 >>> brandon.bar...@gmail.com >>> http://brandon.barker.googlepages.com/home >>> >>> >>> >>> On Sun, Aug 2, 2009 at 4:16 PM, Alan >>> Coopersmith<alan.coopersm...@sun.com> wrote: >>>> >>>> Brandon Barker wrote: >>>>> Is there a Solaris equivalent to ksplice in linux? See >>>>> http://en.wikipedia.org/wiki/Ksplice >>>> Sun developed similar technology years ago, but it never got deployed, >>>> since it required hand crafted kernel bits for each deployment to ensure >>>> you got bits that were compatible with the alreadyloaded kernel modules. >>>> >>>> http://blogs.sun.com/jimmo/entry/the_fate_of_hot_patching is the best >>>> public description I see of it. >>>> >>>> -- >>>> -Alan Coopersmith- alan.coopersm...@sun.com >>>> Sun Microsystems, Inc. - X Window System Engineering >>>> >>>> >> > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
