[LITMUS^RT] Announcing PGM^RT!

Björn Brandenburg bbb at mpi-sws.org
Mon Feb 24 20:27:52 CET 2014


Hi Glenn,

thanks for the detailed explanation. Again, this looks like a really nice project.

On 24 Feb 2014, at 16:47, Glenn Elliott <gelliott at cs.unc.edu> wrote:

> 1) PGM^RT uses C++ under the hood, even though it has a very C-style API.  I know that liblitmus has a C-only policy.  I used C++ for the sake of expediency: boost C++ provides very nice abstractions for managing shared memory and dealing with the file system.  However, I limited myself to a C-style API in case PGM^RT ever had to be C-only.  With some effort, we could eliminate the dependence on C++.  Note: I don’t use boost’s IPCs.  I use the POSIX interfaces for these.

I think the actual PGM stuff is best kept in a separate library/framework. The liblitmus repo should stay fairly minimal. (In fact, we could probably split out some of the tools into a separate repository.)

> 
> 2) There are two patches needed in litmus to support PGM^RT as I designed it:
> 	(a) A recompilation of deadline upon task wakeup.  Specifically, before a task blocks for tokens/data, it sets a “waiting” flag in the control page.  Upon task wake-up, litmus recomputes the task’s deadline based upon the current time (abs deadline = wake-up time + rel. deadline). I think we could generalize this to support truly sporadic tasks in litmus.

This is the one I’m most interested in. Support for flexible sporadic releases is something that I’ve wanted in LITMUS^RT for quite a while. How difficult do you think this would be to generalize?

> 	(b) Lazy priority boosting.  Producers enter a non-preemptive section while they pass data over the IPCs and wake consumers.  However, I made this non-preemption a little more robust.  After entering the np section, producers set a “pgm-signalling” flag in the control page. If an attempt is made to deschedule this task, the priority of the task is automatically boosted, and the scheduling decision is re-evaluated.  The pgm-signalling flag is cleared, and base priority restored, when the task exits the np section.

This is also interesting. Roy is working on a similar interface to support locking protocols that require priority boosting.

> 3) PGM^RT is currently released under the BSD license.  I did this because we’re trying to court limited participation from industry partners.  (I want to be able to use it in their proprietary code.)  GPL is generally very scary to them.  However, since there has only been one contributor (me), it would be pretty easy to change the licensing scheme.  We could perhaps do LGPL, or use a dual licensing scheme.  I really have no idea how all this licensing stuff works.  I just picked a license known to be industry-friendly.

In this case it should definitely stay in a completely isolated project. liblitmus is GPL so that we can freely swap code to and from the kernel. If you need to stay clear of the GPL, then the best way forward is to never mix the codebases. Also, I think there are no good technical reasons to merge PGM^RT into liblitmus.

Thanks,
Björn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140224/5c53c8e3/attachment.html>


More information about the litmus-dev mailing list