On Jun 27, 2007, at 8:21 PM, Bill Stouder-Studenmund wrote:

> On Wed, Jun 27, 2007 at 11:03:10AM -0700, Bill Stouder-Studenmund  
> wrote:
>> On Tue, Jun 26, 2007 at 05:48:32PM +0200, Adam Hamsik wrote:
>>>
>>> 2) I think about dynamic ddb command/help API which could be used  
>>> for
>>> registering/unregistering ddb commands. Now all ddb commands are
>>> stored in static array db_command_table. Problem is that if every
>>> kernel component want to add some ddb_commands kernel programer have
>>> to add entry to the ddb_command_table. If we use dynamic structure
>>> like linked list we can add/remove commands in realtime.
>>
>> Sounds good.
>>
>>> Cons:
>>> I have to initialize this list when ddb is run.(lot of malloc's for
>>> every added command 2 one for command structure and second for help
>>> (not needed))
>>
>> Actually, I think if we are clever about our list creation, we  
>> don't have
>> too much of an issue.
>>
>> Make the list a list of tables. So built-in commands are in one  
>> static
>> table, and we have a static command list head. We then have a  
>> malloc'd
>> list of:
>>
>> struct ddb_command_list_entry {
>> 	TAILQ_ENTRY(ddb_command_list_entry)
>> 				ddbcl_next;
>> 	int			ddbcl_count;		/* count of cmds */
>> 	struct ddb_command	*ddbcl_commands;        /*table of commands*/
>> };
>
> Note: one thing I wasn't clear on. We have one of the above per  
> command
> table. So all the internal commands would be covered by generating  
> one of
> the above command list entries. When an lkm adds commands (say 5 of  
> them),
> we add only one list entry for the whole table of 5.
>

> The other API changes would be that you register a command table,  
> not an
> individual command.

Sounds good.
But I have some questions:)

1)How nested commands like show (contains 3 tables of commands)  
should be implemented. Another level of TAILQ_ENTRY?

2)what is default number of used groups or ddb_command_list entries  
2? (machine table and now default db_command_table)? We can group  
commands to more group like gdb does(show, crash, trace, machine,  
ffs, uvm, etc..).

3)Is struct db_command good or have I change also this in some way?
IMHO I can change cmd_arg to char **cmd_arg and use array of NULL  
terminated strigs for arguments and their description.

>
>> Yes, there will probably be a pad int in there too on LP64.
>>
>> The upshot of this is that everything other than these list  
>> entries can be
>> in text sections. We only need to malloc one of these command list  
>> entry
>> structures per table of commands.
>
> Take care,
>
> Bill

Regards
-----------------------------------------
Adam Hamsik
jabber: haad@jabber.org
icq: 249727910

Proud NetBSD user.

We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto