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"