cluts priorities [was: New daily reports - nothing]

cluts priorities [was: New daily reports - nothing]

[Rich Felker]

On Mon, Aug 15, 2011 at 04:14:12PM +0200, Luka Marčetić wrote:
> On 08/14/2011 10:00 PM, Rich Felker wrote:
> >On Wed, Aug 10, 2011 at 12:59:33AM -0400, Rich Felker wrote:
> >>As I see it, what you've got (in varying stages of completeness) is
> >>categories 1, 2, 3, 6, 8, and 9, from the project description here:
> >>
> >>http://openwall.info/wiki/musl/unit-tests
> >>
> >>Here are the things I would like you to focus on right now, roughly in
> >>order of priority:
> >>[...]
> >>1. Fixing issues with test validity, like the buffer overflow/heap
> >>[...]
> >>2. Documenting the tests you have: what assertions they test. As
> >>[...]
> >>3. Cleaning up the build system and source to make sure it builds
> >>[...]
> >>4. Finish testing additional areas in the categories you're already
> >>[...]
> >>5. Test categories 4 and 5. I think it would be nice to pull in some
> >Luka, could you please reply with an estimate on how many hours of
> >work you think each of these areas will take you and an intended
> >schedule for how and when you plan to accomplish them?

I really need to ask that you to prioritize the work that remains. As
an example, adding additional EINTR tests falls under number 4 (finish
testing additional areas...) while 1-3 remain to be done. Speaking of
EINTR, as we spoke about before, a number of these interfaces have no
reason to block, and some of them even have no reason to make syscalls
at all. If more work still needs to be done testing cases that would
not fail except on an intentionally-broken implementation, that should
be a project for *after* GSoC, not taking up your time when we're
nearing the deadline.

Rich

Re: cluts priorities [was: New daily reports - nothing]

[Luka Marčetić]

On 08/16/2011 05:42 PM, Rich Felker wrote:
> I really need to ask that you to prioritize the work that remains. As
> an example, adding additional EINTR tests falls under number 4 (finish
> testing additional areas...) while 1-3 remain to be done. Speaking of
> EINTR, as we spoke about before, a number of these interfaces have no
> reason to block, and some of them even have no reason to make syscalls
> at all. If more work still needs to be done testing cases that would
> not fail except on an intentionally-broken implementation, that should
> be a project for *after* GSoC, not taking up your time when we're
> nearing the deadline.
>
> Rich

When we spoke about this, afai can remember, you said that the ones that 
block are of higher priority, which implies others should also be tested 
ultimately, so I went ahead and made tests of all of those that I knew 
about at the time. Are you saying functions that return EINTR but do not 
block aren't even part of the task?
Ok, can you please tell me which of the functions I've linked on IRC I 
should test then? I can find out which one of those block, but I don't 
know about syscalls. Can you tell me how I could discern betwen them?
Thanks.
Luka

Re: cluts priorities [was: New daily reports - nothing]

[Rich Felker]

On Tue, Aug 16, 2011 at 06:56:14PM +0200, Luka Marčetić wrote:
> On 08/16/2011 05:42 PM, Rich Felker wrote:
> >I really need to ask that you to prioritize the work that remains. As
> >an example, adding additional EINTR tests falls under number 4 (finish
> >testing additional areas...) while 1-3 remain to be done. Speaking of
> >EINTR, as we spoke about before, a number of these interfaces have no
> >reason to block, and some of them even have no reason to make syscalls
> >at all. If more work still needs to be done testing cases that would
> >not fail except on an intentionally-broken implementation, that should
> >be a project for *after* GSoC, not taking up your time when we're
> >nearing the deadline.
> >
> >Rich
> 
> When we spoke about this, afai can remember, you said that the ones
> that block are of higher priority, which implies others should also
> be tested ultimately, so I went ahead and made tests of all of those
> that I knew about at the time.

There's nothing wrong about that in itself, but I asked you just the
other day to prioritize, and expanding the existing tests was
relatively low priority.

> Are you saying functions that return
> EINTR but do not block aren't even part of the task?

No, but you can't spend days on a test area that's mostly done adding
tests that are just for completeness' sake when there's a whole lot
else left to do.

> Ok, can you please tell me which of the functions I've linked on IRC
> I should test then? I can find out which one of those block, but I
> don't know about syscalls. Can you tell me how I could discern
> betwen them?

In the future please post things like this to the list. A pastebin
link on IRC is not going to get my attention, and it makes it hard to
follow up discussion. Please don't use pastebins as a replacement for
email.

(Here is the link for reference: http://paste.debian.net/126277/)

Any function with "attr" in its name surely only deals with modifying
userspace data structures. The whole point of spinlocks is to be
completely userspace. Init functions almost surely don't involve
syscalls, and destroy functions almost surely don't either except
possibly in certain contention cases where the caller must wait for
another thread before it can complete destruction of the object. By
and large, the list in the pastebin looks very low-priority for
testing.

In any case, please prioritize.

Rich