> Richard L. Hamilton writes: > > minimal part being disabling writes to /dev/*mem), > my main interest is if > > that would make it possible to install more kernel > and driver patches safely in multi-user mode, > > without having to worry about an inconsistent set > of modules getting loaded prior to reboot. > > Given that interest, I don't think you want to use > something like > modflags, because that'd make deferring the reboot > too painful. > Instead, we would need a run-time blacklist of > modules that shouldn't > be loaded. The prepatch script would then add an > entry to the > blacklist so that the driver can't be loaded (behaves > as ENOENT) until > the system is restarted.
More complicated, but less restrictive; sufficient perhaps for expanded safe online patching _if_ the prepatch files consistently get it right. (Just locking down to the currently loaded modules would be far more restrictive but proof against human error.) > That seems like a fairly reasonable RFE to me, though > ... > > > Of course in the long run, something like a > combination of LiveUpgrade with a cloneable, > > promotable ZFS root would let any maintenance from > minor patches through upgrades be > > ... yes, a ZFS root likely invalidates the whole > scheme. > > > deferred until relatively convenient. But let's > face it, a lot of folks are going to drag > > their feet on reloading (esp. if they don't have > space on their typically dinky pair of internal > > drives for a spare partition for LiveUpgrade) to > such a configuration. I would think this could > > I don't understand that part. Regardless of what you > do at this > point, the user must suffer a reboot in order to > switch out the kernel > bits. Either that reboot causes the run-time > blacklist to get > discarded (option A) or it causes us to pick up the > modified ZFS root > (option B). > > I think both answers are equivalent in terms of > feet-dragging. A lot of systems have two internal drives, on which the OS lives; and perhaps more stuff if there's room. Changing the module loading functionality is a patch or at worst an upgrade; but switching to a zfs root in a lot of cases would probably only get done as a full-blown backup of non-OS data (and of config files) and reload, which takes a lot more down time. Plenty of systems simply weren't initially set up with space for an alternate boot environment, esp. with older small disks. So I think it would take a lot longer to get widespread use of a really modern approach to safe online upgrades than it would to do some relatively minor things to make the existing mechanisms safer online in more cases. (this from seeing a lot of systems that are still chugging along running Solaris 8 and with a pair of dinky little mirrored boot drives) This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
