On Thu, May 22, 2014 at 12:49 AM, Luigi Rizzo <ri...@iet.unipi.it> wrote:

>
>
>
> On Wed, May 21, 2014 at 11:17 AM, Bill Yuan <byc...@gmail.com> wrote:
>
>> 1. "each table can have it's own name", I like this idea. I am also
>> working on this kind of functions, But I am in different way. In my
>> opinion. the "name" or "type" of the table, all this are utility function
>> for the user. in the kernel space. I want to keep all the things the same
>> as before. and add a translate function in the user land commands, so that
>> means we need to find a space to keep the mapping of the name<->id or
>> type<->id,
>>
>
> ​this does not work, you'd have another database to keep in sync
> and on which you have races with modifications to the ipfw config.
>
> cheers
> luigi
> ​
>
Hi Luigi,
Thanks for your reply.

That is my original idea of the implementation. I though it is good because
it can minimize the changes in existing code.

Yes, It requires to have another database to keep in sync, But it is
not necessary to mix a lot with the existing code in the userland. that
also means we dont need to make any changes in the existing code of the
kernel space.

e.g. if we support the table name in the command , it will be:
   >ipfw table 1 name sales
this type of commands to create/update the mapping databases
   >ipfw table sales add 1.2.3.4
   >ipfw table sales list
this type of commands need to call function "get_id_from_name()" and it is
in the userland command.

And if the mapping is "type-name-id" then that means it can be generic
purpose.
e.g.
tablename-sale-10    --> sale table is id 10
pipename-vip-20      --> vip pipe's id is 20
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to