Jonathan Adams wrote: > On Tue, Sep 15, 2009 at 04:18:14PM -0400, James Carlson wrote: >> Jonathan Adams wrote: >>> I've written up the following ARC case for my ::whatis rewrite, and wanted >>> to see if there were any comments before I submit it for PSARC review. >>> >>> What do you all think? >> A level-0 question: is this a needed ARC case at all? I don't quite see >> where there's system architecture here. >> >> Given that what ::whatis reveals and the arguments it takes are all >> essentially system implementation details, it seems unlikely to me that >> anyone could (or _should_) write any separate program that depends on these. >> >> It's just a debug feature ... right? > > Yes, but the commitment level of all of the 'mdb'-level interfaces is reported > in MDB as "Evolving", v.s. "Unstable" for all of the other dmods. I > understand > that these names have changed, but since the "Evolving" moniker is equivalent > to "Committed", I thought an ARC case would be necessary. If not, I'll > just putback.
We haven't really been treating it that way. Dcmds and walkers in mdb are frequently modified to match the kernel's private details without bothering with ARC review, on the theory that mdb is essentially much more like "syslog" than it is like "libc." In other words, it's a debugging feature of the system that exposes private implementation details for humans (or at least developers ;-}), and not something that anyone would reasonably use as a foundation for another application. Dtrace straddles that line, but I think mdb is well over it, and the "stability" notes in the dcmd help strings seem a bit baroque (and not really enforced by anything). If there's architecture here, it's in the way mdb is put together. Adding new functions to the core of mdb, or new ways for commands or subsystems to plug in, or new sorts of arguments for them to handle -- those things could (I think) reasonably benefit from ARC review. If someone were to have asked me (when I was an ARC member) whether it made sense to embed ARC nomenclature into applications, I would have said "no." The focus of the ARC is on documentation (again, for people), and on mechanisms. Thus, something that clearly delineates "should use" from "should not use" -- as with linker map files -- is a helpful mechanism to have, and can be put in service to help with documented boundaries. Something that duplicates or holds out to be equivalent to primary system documentation (man pages) is likely not so helpful. > As an ARC case, I was going to submit it Closed-Approved-Automatic. OK. I can't say I feel strongly about it, so file if you want, but I think the review in this community alone is more than enough. It seems unlikely that ARC members would have much useful to add. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
