Eric Blake <eblake(a)redhat.com> wrote on 09/28/2010 03:19:42 PM:
On 09/27/2010 02:26 PM, Stefan Berger wrote:
>>> The patch below extends the XML parser and generator so that every
> protocol
>>> now can have a comment node. Comments are limited to 256 characters
> and are
>>> tested to only contain printable characters or spaces.
>>
>> Literal spaces, or generic blanks (space and tab for sure, but what
>> about newline, not to mention vertical tab, form feed, ...), all of
>> which are technically printable according to c_isprint()?
>
> I have been doing some testing using 'virsh nwfilter-edit'. I edited a
> comment and put horizontal tabs into it or newlines or a combination
of
> both. Both of these seem to automatically be converted to space,
meaning
> that when the XML is generated after the parsing, the tab or
newline
now
> are shown as simple space. I also wrote the XML into a file
using
'virsh
> nwfilter-dumpxml', added a newline in the comment, ran
unix2dos on it
to
> get '\r' and used 'virsh nwfilter-define' on it
again, and the '\r'
> disappeared. From that I took that the XML parser does the correct
> replacement already and I don't need to worry about it -- assuming it
> would do the same for vertical tab as well.
Tab seems like it would be most likely for people to want, but I'm okay
with leaving it unsupported for now until someone complains (and even
then, it depends on whether XML parsing can even preserve tabs).
Patch 1 #defines MAX_COMMENT_LENGTH 256 in nwfilter_conf.c, patch 2
#defines IPTABLES_MAX_COMMENT_SIZE 256 MAX_COMMENT_LENGTH 256 in
nwfilter_ebiptables_driver.h. Should these two values be consolidated
into a single name in a common .h file in patch 1?
I chose two independent constants to reflect that the parser and the
(iptables) driver should be somewhat loosely coupled. The iptables driver
could cut the size of the comment down to what it can handle, though in
this case the sizes match.
Stefan