minor update to ruby_evdev

So Josh looked at my code and suggested that I change my write_event function to use syswrite. Which required a tiny bit of uglyness but seems to work.

I went in and added licensing information too (GPL version 2…inherited from the evdev library itself).

Everything’s in the repository and the tarball. I think it’s time to post this bugger to the wider world.


  1. John Carrino says:

    No, why GPL, use apahe2, you get improvements integrated back but people can use it without their stuff being GPL by defaualt. Also keep in mind that most ruby libs are MIT.

  2. John Carrino says:

    Oh, it was forced upon you by other hosers, nm.

  3. By “ugliness”, are you referring to the fact that you have to create a Ruby string for your C struct? If that bothers you, you can always do what the C implementation of syswrite does. Besides catching corner cases (is the file still open?) and throwing Ruby exceptions for failures, the only important thing it does is rb_thread_fd_writable(), which will schedule another ruby thread if your fd isn’t writable.

    Also, you can always distribute your source code under whatever license you want, GPL only applies when you are distributing binaries that contain someone else’s code.

  4. buffalo says:

    Yeah, that was the ugliness I was referring to. But really, I think duplicating the syswrite code would be a lot more ugly (and a lot more prone to problems with later ruby versions).

    The reason I think that I need to use the GPL is that my library is pretty obviously a derivative work of the orginal library (which is licenced under the GPL and not the LGPL) and therefore needs to be distrubuted under the terms of the GPL. But perhaps I’m not understanding this issue properly.

    Do you think my library is not a derivative work? Or maybe I just don’t understand the way in which the GPL affects dervative works…

  5. I unfortunately can’t find a reference for this, but my understanding is that your source code is not a derivative work. You wrote it entirely — you didn’t adapt or modify the evdev code. Sure, you repeat the names of the constants and structures they define in their headers, but I don’t think that’s grounds for calling your code a “derivative work.”

    Once you compile it and link against their library, it’s a different story. At that point, you are forming a combined work, which is derived from both your source and theirs. If you distribute the combined work, it must be licensed as a whole under the GPL, which means that you must also make your source available under the GPL.

    However, this doesn’t prevent you from also releasing your source under another license of your choosing (assuming that I’m right in saying that it’s not a derivative work).

    I’ll ping Big Easy and see if he shares this interpretation.

  6. Actually, does evdev have any userspace library at all, or is it just an ioctl() interface? If your only interface to evdev is through system calls, then you never link against it and there is never a combined work. So you wouldn’t even have to release as GPL. Otherwise, every program that runs on Linux would have to be GPL, because they call Linux through system calls. But the Linux License specifically states that the system call interface is a GPL barrier:


    2 NOTE! This copyright does *not* cover user programs that use kernel
    3 services by normal system calls – this is merely considered normal use
    4 of the kernel, and does *not* fall under the heading of “derived work”.

  7. buffalo says:

    Yeah, ioctl is pretty much the main function I use.

    But the thing that is most dervative is actually codemapping.rb – which is actually a regular expression munged version of the input.h header.

  8. Oh, I should have looked at that codemapping.rb stuff earlier. For both technical and legal reasons, I think it would be a better idea to make those constant definitions part of your C extension. That is what Ruby extensions usually do when they want to use a bunch of constants that are defined in a C header. See Init_syserr() in error.c in the Ruby source for an example of this. If you did that, I think you would be pretty in the clear as far as being a “derived work” of evdev.

    BTW, I’m making progress too — I made a “Hello, World!” OS image that uses the VGA hardware to clear the screen, write “Hello, L4 World!” to the screen, and move the cursor around a bit. 🙂 It’s all built on top of L4, of course, so my part was

  9. OK, so apparently this blog software doesn’t escape HTML entities. That last comment should have ended:

    “It’s all built on top of L4, of course, so my part was <100 lines of C that twiddles VGA memory and I/O ports.”

  10. buffalo says:

    You’ll have to convince me a bit harder to pull that stuff out of the ruby side.

    It’s actually pretty handy in ruby: you can iterate over it, reverse the hash if you wanna convert the other way, dump all the values out.

    What technical reasons exist for wanting to keep it on the C side instead?

  11. buffalo says:

    Very cool with the operating system thing, BTW.

  12. Maybe I didn’t explain the strategy of putting it in the C side well enough. I’m not saying you shouldn’t expose the constants as Ruby objects — I’m just saying you should build those Ruby objects in C instead of in Ruby. For example:


    “register_constant” can add/augment whatever kind of Ruby object you want. People usually make them Ruby constants of some module (so you can say in Ruby Evdev::Constants::SOME_EVDEV_CONSTANT), but you could make them into a Ruby hash like you are now, if you want.

    Technical advantages:

    * your constants will always have the correct value, because you got the values from the canontical source (the header file).

    * the constant existing in Ruby will indicate that it exists on the user’s actual machine (since you checked it with #ifdef at compile time).

Leave a Reply