Date: Thu, 5 Jun 2014 17:54:02 +0200 From: 'Luigi Rizzo' <rizzo@iet.unipi.it> To: bycn82 <bycn82@gmail.com> Cc: "'Alexander V. Chernikov'" <melifaro@ipfw.ru>, 'FreeBSD Net' <net@FreeBSD.org> Subject: Re: [CFT]: ipfw named tables / different tabletypes Message-ID: <20140605155402.GA81905@onelab2.iet.unipi.it> In-Reply-To: <000001cf80cd$5dc1d9b0$19458d10$@gmail.com> References: <20140521204826.GA67124@onelab2.iet.unipi.it> <537E1029.70007@FreeBSD.org> <20140522154740.GA76448@onelab2.iet.unipi.it> <537E2153.1040005@FreeBSD.org> <20140522163812.GA77634@onelab2.iet.unipi.it> <538B2FE5.6070407@FreeBSD.org> <539044E4.1020904@ipfw.ru> <000c01cf80be$41194370$c34bca50$@gmail.com> <20140605134256.GA81234@onelab2.iet.unipi.it> <000001cf80cd$5dc1d9b0$19458d10$@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 05, 2014 at 10:49:27PM +0800, bycn82 wrote:
> Hi Luigi,
> Yes, use string instead of integer for the ID of table, but the same method cannot apply to the feature `set type of table`. And in the kernel, compare string will cause more than compare an integer. In my opinion, actually they are just alias name for the object. Users already accept that every object has an integer ID.
Bill,
I appreciate your enthusiasm on contributing to the project, but
before starting to code, you (and everyone else, including myself)
should spend some time at the drawing board, question your assumptions,
and consider possible implementations.
Also the fact that previous implementations had bugs or restrictions
does not imply that we should repeat the same mistakes now.
Specifically:
- comparing strings in the kernel is perfectly fine, we do it all the
time (sysctl names, filenames, interfaces and whatnot).
What would be terribly wrong is having to do, on every packet,
an expensive string or number lookup (note- it's the entire lookup
process, not a string comparison) to locate the table.
However, this is not the case.
The way to implement named objects (tables etc.) is to accept strings
as object names, and when the rule is added the string is checked
and converted to a pointers or an integer which permits direct
access to the table.
This is as fast as it can be at runtime, which is all what matters.
- at the moment tables and pipes have a single ID, which happens to be a
sequence of digits for mostly historical reasons (you can read it
as laziness of the original authors; i can take the blame for pipes).
If we extend the namespace to include strings we improve the user's
experience and remain compatible with the existing user interface.
Instead, if we require users to create a mapping before using
alphanumeric names, not only we add a step that was not there before,
but also create two names for the same object which makes it harder
to reason about the rulesets, and there is also the issue of how
to handle references to non-existing tables (which are trivially
supported now or with the approach i suggested, and would instead
require rescanning the ruleset whenever a name-number association
is added or deleted.
Another troubles with that approach is that you opening a race
window between the creation of the name-number mapping and its use,
and this is also something you don't want in a security-related tool.
We have had a similar discussion about your 'pps' extension for ipfw:
useful feature, but your various implementations have issues (even
the final one), and we have only so much time for reviewing patches;
please do not burn it.
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140605155402.GA81905>