-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 9, 2007, at 11:23 PM, Adam Hamsik wrote:

>
> On Jun 27, 2007, at 8:03 PM, 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.
>>
>>> API:
>>>
>>> int
>>> db_reg_command(struct cmd_list *cmd_list, struct cmd_list  
>>> **cmd_command,
>>> char *cmd_name,*cmd_func);
>>>
>>> db_reg_help(*cmd_command,char* descr, char** cmd_func_arg);
>>>
>>> db_unreg_command(*cmd_list, char* cmd_name);
>>>
>>> struct cmd_list*
>>> db_search_command(struct cmd_list*, char* cmd_name);
>>>
>>> /*this function will create default list of commands*/
>>> db_init(struct cmd_list**);
>>>
>>> (db_get_help,db_get_func,db_get_cmd) ??
>>>
>>> Pro:
>>>
>>> LKM and other parts of kernel can register/unregister ddb  
>>> commands in
>>> easy way.
>>>
>>> more useable ddb.
>>>
>>>
>>> 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;
>> };
>>
>> 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
>
> Hi
>
> This is first review of my ddb command api. After some of list  
> comunication with @wrstunden I decided to use 2 lists. One list for  
> base commands and another for show subcommands(show registers). I  
> do it this way because only show command has it's own subcommands.  
> Difference between old ddb behavior and
> pathched are:
>
> 1) added help command help {command} print command description and  
> arguments.
> 2) I moved show all * commands one level up so from show all  
> processes is show processes. (I'm looking for way to implement way  
> to keep old interface behavior here. But everything looks to me too  
> hackish :(. )
>
I have implemented all missing functions (ddb user interface compat.  
and I have moved all architectures to new ddb command api). Can some  
body review this code?

I have to remove some debug printfs and apply KNF, but it works  
really great.
I have to probably write some test lkm also.

> How to use this api.
>
> in subsystem/lkm you have to include db_command_extr.h file
> define array or one struct db_command's with proper values.
>
> call db_add_command_tbl(type,*db_array);
>
> type can be DDB_BASE_CMD or DDB_SHOW_CMD.
>
> removing commands from list is done with
>
> db_rem_command_tbl(type,*db_array);
> Q: is here type needed or I have to search all lists and check  
> there if *db_array address is present.
>
> <db_cmd.diff>
> 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
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFGl22ElIxPgX3Go0MRAnw8AJ0Z+PIxkmzUJ5OhgUGEs74glAHKIwCgpmbD
I5pJmFa/PrYC2hrHkIhOnNQ=
=1ZIz
-----END PGP SIGNATURE-----