All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] LTP API documentation
@ 2018-03-07  5:43 Tim Bird
  2018-03-07 10:52 ` Cyril Hrubis
  0 siblings, 1 reply; 5+ messages in thread
From: Tim Bird @ 2018-03-07  5:43 UTC (permalink / raw)
  To: ltp

Hey LTP developers,

Where is the API documentation, for stuff like tst_* and SAFE_*
and 'struct tst_test'

I looked in ltp/docs and on the wiki, but couldn't seem to find it.

I'm including a quick introduction to LTP in a talk I'm giving at ELC
next week, and would like to refer people to the API docs.

Thanks,
 -- Tim Bird
Senior Staff Software Engineer, Sony Corporation
Architecture Group Chair, Core Embedded Linux Project, Linux Foundation

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [LTP] LTP API documentation
  2018-03-07  5:43 [LTP] LTP API documentation Tim Bird
@ 2018-03-07 10:52 ` Cyril Hrubis
  2018-03-07 14:01   ` Tim Bird
  0 siblings, 1 reply; 5+ messages in thread
From: Cyril Hrubis @ 2018-03-07 10:52 UTC (permalink / raw)
  To: ltp

Hi!
> Where is the API documentation, for stuff like tst_* and SAFE_*
> and 'struct tst_test'
> 
> I looked in ltp/docs and on the wiki, but couldn't seem to find it.

It's named test-writing-guidelines, which arguably is a bit confusing
but its there:

ltp/doc/test-writing-guidelines.txt or
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines

And we also have nice C testcase tutorial:

doc/c-test-tutorial-simple.txt or
https://github.com/linux-test-project/ltp/wiki/C-Test-Case-Tutorial

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [LTP] LTP API documentation
  2018-03-07 10:52 ` Cyril Hrubis
@ 2018-03-07 14:01   ` Tim Bird
  2018-03-07 14:38     ` Cyril Hrubis
  0 siblings, 1 reply; 5+ messages in thread
From: Tim Bird @ 2018-03-07 14:01 UTC (permalink / raw)
  To: ltp

On Wed, Mar 7, 2018 at 2:52 AM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
>> Where is the API documentation, for stuff like tst_* and SAFE_*
>> and 'struct tst_test'
>>
>> I looked in ltp/docs and on the wiki, but couldn't seem to find it.
>
> It's named test-writing-guidelines, which arguably is a bit confusing
> but its there:
>
> ltp/doc/test-writing-guidelines.txt or
> https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
>
> And we also have nice C testcase tutorial:
>
> doc/c-test-tutorial-simple.txt or
> https://github.com/linux-test-project/ltp/wiki/C-Test-Case-Tutorial

OK.  I actually had found both of these, but didn't realize that
these were intended as API documentation.  I was expecting
to see something more formal describing each routine
(maybe in an alphabetical list).  For the SAFE_ macros,
it says to look at the source for a complete list, so for these
and possibly other APIs these docs don't appear to be
comprehensive.

Would you be OK with me writing up some more formal
documentation for the APIs, and contributing them to the
project?  I probably won't get to it for a few weeks, as
I'm busy getting ready for a conference.  But it might
be nice to document these more formally and comprehensively.

 -- Tim Bird
Senior Staff Software Engineer, Sony Corporation
Architecture Group Chair, Core Embedded Linux Project, Linux Foundation

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [LTP] LTP API documentation
  2018-03-07 14:01   ` Tim Bird
@ 2018-03-07 14:38     ` Cyril Hrubis
  2018-03-13 15:35       ` Richard Palethorpe
  0 siblings, 1 reply; 5+ messages in thread
From: Cyril Hrubis @ 2018-03-07 14:38 UTC (permalink / raw)
  To: ltp

Hi!
> OK.  I actually had found both of these, but didn't realize that
> these were intended as API documentation.  I was expecting
> to see something more formal describing each routine
> (maybe in an alphabetical list).  For the SAFE_ macros,
> it says to look at the source for a complete list, so for these
> and possibly other APIs these docs don't appear to be
> comprehensive.

Well we kept it this way for several reasons the main was that we barely
had manpower to maintain the documentation along with all the changes in
the codebase since the library API haven't been stable in the past. We
had major rewrite of the library API in the middle of 2016 by the way,
but it has been stable since with occasional additions.

We also have quite a lot of documentation in form of a header comments
so maybe it would be best just to transform it into a parseable format
and generate the formal API documentation from that. That would probably
mean changing all the comments into doxygen format and making sure every
piece of public API is documented, what do you think about that?

> Would you be OK with me writing up some more formal
> documentation for the APIs, and contributing them to the
> project?  I probably won't get to it for a few weeks, as
> I'm busy getting ready for a conference.  But it might
> be nice to document these more formally and comprehensively.

Better documetation is always welcomed, the hard part is keeping it in
sync with the code :-).

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [LTP] LTP API documentation
  2018-03-07 14:38     ` Cyril Hrubis
@ 2018-03-13 15:35       ` Richard Palethorpe
  0 siblings, 0 replies; 5+ messages in thread
From: Richard Palethorpe @ 2018-03-13 15:35 UTC (permalink / raw)
  To: ltp

Hello,

Cyril Hrubis writes:

> Hi!
>> OK.  I actually had found both of these, but didn't realize that
>> these were intended as API documentation.  I was expecting
>> to see something more formal describing each routine
>> (maybe in an alphabetical list).  For the SAFE_ macros,
>> it says to look at the source for a complete list, so for these
>> and possibly other APIs these docs don't appear to be
>> comprehensive.
>
> Well we kept it this way for several reasons the main was that we barely
> had manpower to maintain the documentation along with all the changes in
> the codebase since the library API haven't been stable in the past. We
> had major rewrite of the library API in the middle of 2016 by the way,
> but it has been stable since with occasional additions.
>
> We also have quite a lot of documentation in form of a header comments
> so maybe it would be best just to transform it into a parseable format
> and generate the formal API documentation from that. That would probably
> mean changing all the comments into doxygen format and making sure every
> piece of public API is documented, what do you think about that?
>
>> Would you be OK with me writing up some more formal
>> documentation for the APIs, and contributing them to the
>> project?  I probably won't get to it for a few weeks, as
>> I'm busy getting ready for a conference.  But it might
>> be nice to document these more formally and comprehensively.
>
> Better documetation is always welcomed, the hard part is keeping it in
> sync with the code :-).
>
> -- 
> Cyril Hrubis
> chrubis@suse.cz

That sounds good to me include/tst_fuzzy_sync.h should already be in a
doxygen compatible format. I don't particularly like Doxygen though, but
there are plenty of compatible frameworks.

-- 
Thank you,
Richard.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-03-13 15:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-07  5:43 [LTP] LTP API documentation Tim Bird
2018-03-07 10:52 ` Cyril Hrubis
2018-03-07 14:01   ` Tim Bird
2018-03-07 14:38     ` Cyril Hrubis
2018-03-13 15:35       ` Richard Palethorpe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.