On Sat, Jul 14, 2012 at 03:31:06PM -0700, Guy Harris wrote:
>
> On Jul 14, 2012, at 8:26 AM, Jakub Zawadzki wrote:
>
> > It'd be great if we have some abstract and pure (no C/assembly inline) language to write dissectors.
>
> Or "to describe protocols and the way packets for those protocols are displayed" - the languages in question wouldn't be as procedural as C/Lua/etc, they'd be more descriptive.
>
> > We could invent yet another protocol desciption language,
>
> ...but, as you suggest, we probably shouldn't.
http://imgs.xkcd.com/comics/standards.png ;-)
> I'm not sure it has to be a choice, though - we could implement both, resources permitting, of course. (And, of course, given that there are many already-existing languages that describe protocols - ASN.1, {OSF IDL/MIDL/PIDL} for DCE RPC, rpcgen for ONC RPC, CORBA IDL, xcb for X11 - we will probably never have the One True Protocol Description Language.)
I'd rather support one, and later have some compiler from language A to B.
> > I'm bigger fan of NPL (...) but there might exists some legal (patents for grammar/implementation?!) issues.
>
> That would be one concern - even having "our own" language, such as wsgd, runs the risk of infringing a patent, but, well, *writing software of just about any sort* runs the risk of infringing a patent;
> however, we're dealing with a large corporation in the case of NPL, so there's probably a greater risk that some or all of it is covered by patents.
> Were Microsoft to explicitly state that there are no patents on NPL-the-language or that they're granting a royalty-free license for all implementations (perhaps with a "mutual assured destruction" clause,
> so that were we to patent some feature of Wireshark and sue Microsoft for violating that patent, our license for their patents would terminate), and the same applied to any patents they hold on their
> implementation of NPL that would block independent useful implementations, that might help.
I'm not sure if it was covered by recent Oracle vs Google lawsuits.
Maybe Riverbed could help us with it? Gerald?
> > With wsgd we could reuse some existing code of plugin.
>
> ...and we also have more freedom to extend the language, e.g. to support preferences for a protocol
or support for columns/expert info.
> Were there an "Open NPL Consortium" of some sort where multiple implementers of NPL could propose extensions, and perhaps a way an implementation could offer private extensions without worrying about colliding with other implementations or future standards, that might help.
It'd also clear legal status of NPL language.
> (It also raises the question of whether interpreted execution of that "machine code" or translation to C or machine language will be faster - interpreted execution *could* result in a smaller cache footprint if the interpreter is small enough and the code "high-level" enough to be fairly dense, although it does involve difficult-at-best-to-predict branches in the interpretive loop.)
I was thinking to use LLVM. For built-in dissectors we could compile dissectors to object file/ assembly, for user dissectors we'll benefit from LLVM JIT.
But anyway we need compiler to C. For prototype (does it work?) and later as fallback for people who don't have LLVM.
... Or can LLVM libraries be strong dependency?