Matthew Fleming wrote:
I'm working on BSD 6.x and of course the set of ddb commands is static
to whatever is in the kernel at compile. I see that BSD 7.1 has dynamic
commands using sysinits and sysuninit's to call a new
db_[un]register_cmd.
I see this, though, only after I have spent a day or so adding a
linker_file_[un]register_ddb() that works similarly to how sysinits are
merged for the boot-time modules (malloc and copy pointers). It seems
to me that this solution (have the linker look for db_set and db_cmd_set
and, if there are any entries, malloc and save pointers to commands) is
more efficient in terms of space than adding a LIST to the command
structure and then forcing sysinits to run.
I haven't looked at your approach so not sure how to respond. The
existing code was simple.
I'm curious as to why the current method was chosen when something
lighter-weight was available... or so it seems from my perspective
looking at the 6.x code base.
As another side note, lexicographic order for the commands doesn't seem
to add anything, except that command insert/delete are O(n/2) instead of
O(n). It can make it harder to use ddb to debug ddb, though. If, e.g.
there's a pointer problem somewhere in the command list, if the most
basic commands are up front like examine and write, then at least those
can be used to possibly repair ddb so a debug session can continue.
If I recall it was painful to find entries in the help listing w/o sorting.
Feel free to propose an alternative implementation; noone's wed to
what's in the tree.
Sam
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
