Christine Tran writes:
> Here it is. This version did not get reviewed by the SMF team. Thanks
> to those who sent corrections and additions.
Sorry. I thought you had received extensive enough comments that we'd see
another set of diffs. I've reviewed the sections you marked in your
original mail as changed and new, but reviewed them in this version.
That probably means I've missed some stuff.
* 1.5 I'd explicitly declare that if you want run-levels, use init
to continue getting the behaviour you always did before.
Milestones are a new mechanism (not analagous) that are utilized
in the implementation of compatibility with the existing
run-levels.
The milestones used in that implementation are those you
described (single-user, etc.). Other milestones are available
for use as dependencies.
* 2.13 'milstone' should be milestone
* 2.14 Suggest using the init command first. Most people didn't
want the effects that "svcadm milestone" gives them. In general,
suggesting "svcadm milestone" to anyone who isn't just exploring
the system tends to lead to tears, so I really try to avoid it.
Or, put a different way, if you used "svcadm milestone" or "boot
-m milestone=" to get there, svcadm milestone gets you out. If
you used init to get there, use init to get out. init and run-
levels aren't going away, so there's no need to stop using them.
* 2.15 I'm not a big fan of "you can't" (as it's only accurate
within the context of the svcadm milestone command, and boot -m),
but guess if other people think it's more clear than a more
accurate phrasing, you can leave it.
* 2.19 I'd prefer to actually give a solution here rather than
talking about slim chances. How about using the workaround
I just documented in 6517270?
* 4.1 Is the developer intro useless enough to not deserve a
pointer? (If it is, I'd like to hear comments on what a
useful quick-start would look like.)
* 4.10 Don't you need the user= setting?
There's nothing factually incorrect that I've pointed out, though, so
I'd be OK with a push as long as my comments made it to a version not
too long in the future.
> I yanked the old 3.12. This was CR 5107648, fixed in s10_73, a while
> ago. I did a quick search and doesn't look like anyone else (outside
> the people who found the bug) ran into this particular problem.
Good.
> How would we like fixed bugs to be handled? 3.3 and 3.4 fix are
> integrated in snv_21, and fixed in 118833-36. Leave them there and let
> people look up the fix? Or yank them after a while to keep the FAQ trim?
At least I'd like to see the (sparc & x86) patch numbers attached.
thanks!
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
