Right, you can do it that way...

Posted Nov 22, 2011 8:25 UTC (Tue) by khim (subscriber, #9252)
In reply to: Protobuffers are not ideal for this, sadly... by dashesy
Parent article: That newfangled Journal thing

It seems you know better, but skimming through the docs (for my own validation) it seems there are extensions, so the log reader can have access to a generic definition (that comes with kernel) and independent programs can extend it. Sysadmins can install and (keep updated possibly through repos) the definitions for programs they care most.

Well, it should be possible, I'll grant you that. It'll require some scheme to keep all that in sync. Google itself does not have anything like that because they don't need it (centralized repo have it's advantages).

Another extension that would be interesting is a reverse .proto generator, where I can supply in my protocol structures header file and .proto is generated/updated based on the last release.

Not sure what you meant by that. Why will you want to reverse-engineer .proto file? ProtoBuffers are intentionally limited, you can not just shove arbitrary structure in them...

to post comments

Right, you can do it that way...

Posted Nov 22, 2011 17:02 UTC (Tue) by dashesy (guest, #74652) [Link]

I guess many will object to the idea of ProtoBuffers (specially in kernel) because of its reliance non-mainstream compiler/binutils. Anything that requires more than gcc will probably not get a lot of support, specially if/when it is used only for the logging backend.

Maybe I should have rephrased my wish this way:
A gcc plugin that compiles .proto files directly will be very interesting.
Having Qt in mind, C lovers do not like to see not-exactly-C syntax in their code. Therefore a combination of limited (yes non-arbitrary) C structures and compiler pargmas (for example to specify that a field is optional, and what is the default) instead of .proto syntax, along with the above mentioned plugin will be even more attractive, and likely to be taken into kernel. Here I assumed kernel hackers love C, and I should confess I do not know how powerful gcc plugins are.