[LITMUS^RT] Job Quantity Issue

[Björn Brandenburg]

> On 04 Sep 2015, at 22:48, Geoffrey Tran <gtran at isi.edu> wrote:
> 
> 
> Thanks for this. After giving it more thought, I've gone ahead
> with coming up with my own definitions of what I'm interested
> in.  To do so, I've added some utility syscalls to LITMUS.
> 
> They are pushed to my fork of litmus-RT on github. I'm not
> sure if they fit in with the general project, but there is
> a pull request if you feel like it should be included.

Hi Geoffrey,

thanks a lot for the pull request. I’m in favor of supporting the functionality, but as discussed on Github I think the implementation needs some tweaks. I’ve actually had a patch for something similar in my RTSS’14 branch, which I’ve been working on cleaning up for some time. I’ve pushed this patch to the ‘prop/get-budget’ branches in the liblitmus and LITMUS^RT repositories. 

	LITMUS^RT: https://github.com/LITMUS-RT/litmus-rt/commits/prop/get-budget
	
	liblitmus: https://github.com/LITMUS-RT/liblitmus/commits/prop/get-budget

Everyone, please have a look. If there are no objections, I’ll merge this into master soonish.

> Also, this may be inappropriate for the mailing list, but in 
> the future, what is the best way to move my fork between
> different versions of litmus-rt? When trying to pull from 
> your master, it just left an incredible amount of merge 
> conflicts, so I just restarted my fork. 

This is due to the fact that we rebase on top of a current Linux version whenever we release a new LITMUS^RT version. As far as I know, the best way to deal with this is to use git-rebase, and, when all else fails, git-cherry-pick.

I typically try to use git-rebase, but for the 2015.1 release had to resort to git-cherry-pick and a lot of manual editing because the underlying Linux version simply had changed to much.

This is a bit of a hassle, but unfortunately the only way to deal with a fast-moving base such as Linux.

Thanks,
Björn