On 03/31/2014 10:00 AM, Julio Faracco wrote: Welcome to the community. I'd suggest starting off by reading http://libvirt.org/hacking.html and http://libvirt.org/governance.html to get more of a feel for what contributions involve. Among other things, we prefer working in the open (keep the list in the loop), which is why Daniel was right to redirect your 1-on-1 email back to the list instead of answering you outright. And if something didn't make sense, point it out - you aren't the only new person, so we'd like to fix it to make it easier for the next reader! Sure. There's plenty of bugs out there, but it may be easiest to start with one that you can personally reproduce. Feel free to ask on the list for some beginner project ideas. I personally find it helpful to try documentation patches first - as a newcomer, your perspective is quite valuable in comparison to some of us that overlook things "because they've always been that way"; plus, documenting things can help you learn what the code is doing. Unfortunately, that's going to be true of any high-volume list (it only gets worse as you move on to larger projects like the kernel). I can't personally commit to time as a mentor, based on other assignments I have, but in general if you ask on the list, someone will try to respond (and if you go more than 48 hours without a response, we don't mind a ping to kick us into action). The #virt IRC channel on OFTC is also a good resource, particularly for real-time questions. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On 03/31/2014 03:43 PM, Eric Blake wrote: Here's an idea for a beginner's project. Very grunt work, but you mostly need time and patience, and not much understanding of the code base (I'd do it myself, if I had the time): We are inconsistent on how we declare enums. In our public headers, we made it a point to do: typedef enum { ... } virName; as it allows clients to use just 'virName' instead of 'enum virName' when referring to a variable holding an enum value. However, we also explicitly use 'int' instead of 'virName' for any API where an enum is passed in; this is intentional, because some compilers have flags that can change ABI if you pass enum types (if all values of an enum fit in a char, then the compiler can expose options to treat it as either a char or as an int, where the width chosen then affects how other code must link to that struct/function), whereas using 'int' leaves us with a stable ABI regardless of whether the client code played with those compiler flags. Besides, the C language is fairly lax about conversion in either direction between int and enum, unlike C++. Meanwhile, in our internal headers, we often have: enum virName { ... }; which means we HAVE to use 'enum virName' when referring to a variable holding one of those values. What's more, we have tended to carry over the public header notion of using 'int' instead of the enum type, so in util/ and conf/ you'll see lots of headers with struct members such as 'int type; /* enum virName */'. But this is stupid - our internal headers are NOT tied by ABI compatibility issues. And when seeing a function prototype, foo(int type) is a lot less instructive than foo(virName type), where type is supposed to be an enum value. Plus, we have lately been using the coding style of 'switch ((enum virName)expr) {...}' with no default: clause, to let the compiler enforce that we've covered all the enum values; but the cast in that switch is redundant if expr already has the proper enum type to begin with (and I'm a fan of removing redundant casts). I'd really like to see this cleaned up to use the typedef declaration style throughout our codebase, cleaning up internal headers to directly use enum types in both struct declarations and function declarations (where _only_ the public headers are forced to remain with int for ABI reasons), and checking that switch statements that try to cover all possible enum values use a consistent style that best aids the compiler. Ideally, we'd also implement some syntax check rules to enforce the style in the future; that part is trickier for a newcomer, but I don't mind helping on that front (and to some degree, tasks like this are sometimes easier if you write the checker first then hack the codebase until the checker no longer warns, then rebase the code into small enough patches with the checker last). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

Eric, I changed the enum structures to typedef structures. Specially the structures from util/ and conf/ dirs that have a big number of enum structures. To keep a stable release, I didn't change the attributes of the structs. Most of them still keep the old type: 'int type; /* enum virName */' I will submit a patch with the typedef changes first. Thanks! *--* *Julio Cesar Faracco*