[Libre-soc-bugs] [Bug 1169] Add ELF and mmap support to ISACaller -- no dynamic linking

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1169

--- Comment #24 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #23)
> 
> no, we get *exactly the same money* even if the scopevs increased!
> come on for god's sake jacob GET A GRIP. we are UNDER TIME PRESSURE

no matter how much time pressure we're under, if we do too little work for the
amount being paid the auditors will likely complain...so, we need to justify
why EUR 6000 is appropriate for the scope we end up with.

One possible way to justify that is to increase the monthly rate we're asking,
since some other NLNet-funded projects ask for a lot more ($57/hr here):
https://socialhub.activitypub.rocks/t/forgefed-nlnet-grant-application/2598/7
but, unless we apply that new rate for all future budget estimations, it will
look suspicious...

If you want to reduce the scope, then we can drop the stuff specifically needed
for dynamically linked binaries, but that only decreases the scope by like 30%,
see comment #16.

Also, being under time pressure is a good reason to let me keep working on the
parts we know we need (mmap and then ELF loading, they were in the original
plan and in the revised version) while we figure out what else we need.

> (In reply to Jacob Lifshay from comment #22)
> > (In reply to Luke Kenneth Casson Leighton from comment #21)
> > > (In reply to Jacob Lifshay from comment #19)
> > > 
> > > > Oh, i just thought of this while writing this comment, since it tracks page
> > > > permissions for safety reasons (so python doesn't segfault),
> > > 
> > > this was NOT part of the scope of work.
> > 
> > page permissions for safety reasons were already added in bug #1173, because
> > if we mmap a file as read-only (remember we're calling mmap on the host to
> > replace part of the mmap.mmap block of memory), we need to not try to write
> > to that memory, otherwise python *will* segfault
> 
> *great*! not our problem!
> 
>  instead of properly
> > reporting a test error, majorly messing up all other test cases that that
> > pytest worker is trying to run.
> 
> so what?
> 
> >  therefore I think this is necessary.
> 
> why am i only just learning that you have MASSIVELY increased the
> scope and not even told me or consulted me?

because adding page permissions isn't MASSIVELY increasing the scope, the page
permissions code (on master) is 1 flags enum and a dict containing the flags
for each page and 4 lines of code checking the flags -- imo pretty minor.

(I'm not counting the code to speed up iterating (for debug logging and test
cases) through the memory by tracking what's changed which we would need anyway
since it is several orders of magnitude faster.)

> i am getting seriously pissed off that you are threatening our promise
> to NLnet that the work will be 100% completed.

based off the budget estimate, if we included everything I most recently
proposed, I should finish by around the end of Dec if I start working now.
Probably sooner if you let me just work on it, since that time estimate is
based on including lots of emailing back and forth.

If we remove dynamically linked binaries from the scope, then I estimate I'll
be done by the middle of Dec if I start working now based off the EUR 3300 left
in the budget estimate.

Since iirc this task is the last thing I have to do for this grant, that should
leave enough leeway, since iirc David asked that we finish in Dec to leave time
for NLNet to process stuff and if anything unexpected comes up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.