Mac OS X Internals: The Book

[zahadum]

a suggestion/question for an interactive/visualization companion to the book:

what would be the best representation for diagramming the kernel?

a simple procedural abstraction? ....

or full-on UML like state-charts, use-cases etc? ... (would the guts of a live UML boil down to Action Sematics + Object Containment Language?) ... Note: UMI (uml over xml) is conceived as supporting the exchange of design information - so should there not be an intermediate step that could communicate operations/control issues which would feature prominently in a procedural abstraction of a kernel?

or maybe some kickass CSS + xml (which implies that some thought would have to be given to the namespace & the XSLT).

no matter how it is done, wouldn't it be way cool to be able to 'see' the kernel/xnu/etc in action?!

The underlying tree/graph structure used by such a diagramming system might have a deeper use - namely, ability to generate formally queries into the graph and return depencies (which is not necessarily not the same thing as validate - that would be an LTL explosion even for the likes of SPIN ).

this approach would be an awesome tool for advanced helpdesk & debugging (and just learning).

there already are some java-based visualizations for automata, so applying them to a kernel would be the next step, correct?

crazy idea?

[amit]

The idea seems sound -- not crazy, I'd say

Function-level diagramming of large systems is pretty useful, and can indeed be automated to some extent. There are several examples of such diagrams (albeit manually derived/drawn by the author) in "Mac OS X Internals".

One thing though: even for a given kernel subsystem -- say, the scheduler -- the sheer number of functions, their dependencies, and use cases, can lead to a visually complex picture that may be "too complex for humans". In such cases, human understanding is probably better served by manual analysis with some assistance by such diagrams.

IMO the needs of debugging, QA, and /purely learning/ might seem diabolically overlapping to a large extent, but do have enough distinct aspects that one system to serve these needs equally well might be rather hard to implement, and a really interesting problem to solve.

[zahadum]

glad to know that you think it is a good idea.

i agree that a full-on simulation would have wicked complexity (ie completely capable of running an LTL validator like SPIN).

but at the reasonable level of granularity, it could start higher-up & work its way down (over time).

would you consider starting some of the uml diagrams now as a pilot (and bridge product for 2nd edition of the book ... maybe it could be a joint project with opendarwin?

what do you think>

xheers: dlf