To better understand the existing behavior, here's the commit that introduced this (specifically with regards to conn_id): https://github.com/bro/bro/commit/38a1aa5a346d10de32f9b40e0869cdb48a98974b
> The &log keyword now operates as discussed: > > - When associated with individual record fields, it defines them > as being logged. > > - When associated with a complete record type, it defines all fields > to be logged. > > - When associated with a record extension, it defines all added > fields to be logged. > > Note that for nested record types, the inner fields must likewise > be declared with &log. Consequently, conn_id is now declared with > &log in bro.init. > > I think the discussion this is referring to is here: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2011-March/001107.html On Sat, Nov 3, 2018 at 7:34 PM Vern Paxson <v...@corelight.com> wrote: > (2) This makes me wonder about adding an operator to *remove* an > attribute if present. For example, you could imagine wanting > to now do something like: > > type my_conn_info: record { > id: conn_id -&log; > ... > }; > > as a way of specifying "if conn_id's have a &log attribute, > I don't want to inherit it". > I've found myself wishing to remove an attribute recently, so this train of thought is relevant. I had imagined something slightly different, which was to maintain &log as it currently exists, but to also be able to explicitly set it to T or F, e.g.: > id: conn_id &log=F; That would allow me to also be able to use redefs to configure whether or not I want to log something: > const log_conn = T &redef; > ... > id: conn_id &log=log_conn; I think that if we add something like this for &log, it might make sense to add it for other keywords too. --Vlad
_______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
