Re: [libposix-development] Warm-up task

[Henrique A. <hd...@gm...>]

2009/5/28 Chris Forbes <ch...@fa...>

>  OK, have fixed those few tags.
>
> Will do another chunk later.
>
>
>
> Do we have a plan for how we’re going to arrange this code? Testing plan?
>

 Yes. The library will be split in two main parts. The first part of the
library consists of functions that can be implemented in standard ISO C. The
second part of the library consists of functions that need some special
support. The first part is subdivided into the mandatory functions and
optional functions. The second part is divided into system dependent
functions, compiler dependents functions and functions that require
hand-written optimizations.

 Besides the avobe, which represents our source code, we also have source
code that will be available to end users, for example, the "include"
directory, with all the header files. We also need a test directory, which
will include unit tests for all the functions we implement and also some
integration tests too. Finally, we'll need a directory for our build system,
which needs to be cross platform.

 So the basic directory structure is like this:

 mandatory/
 optional/
 system/
 compiler/
 optimized/
 include/
 tests/
 build/

 Subdirectories may be created on demand, if the directories become too big.

 Testing plan: it's still open. I think our best choice is to adopt a test
driven development using both real applications and unit tests as test
cases. For example, if we use "Hello world" as a starting point, we'll begin
developing only functionality to make "Hello world" to correctly output the
string. We can evolve from supporting "Hello world" to supporting, say,
"ls", then the all the software from GNU coreutils that don't use
extensions, etc.

>
>
> Also, an area I’m a bit fuzzy on is the syscall side of the libc. I assume
> this would vary somewhat between kernels?
>

 This part goes on the system dependent part of the library (the "system"
directory). We have to define an interface that our cross platform code can
call. For example, one function of the interface will be "system_write",
which writes a string to a file. For each platform we support, there must be
an implementation of "system_write".

 I'm writing a "hello world" version of our library that shows how to make
system calls in linux. I hope to post it to the source repository in the
weekend.

 We'll also need a page for our "bookshelf", so that we have documents
available to explain such things. I have a post about making system calls
under x86 linux at:


http://hdante.blogspot.com/2007/02/new-style-system-call-in-linux-x86-ref.html
 http://hdante.blogspot.com/2007/02/getting-vsyscall-address-from-elf.html

 I think the full set of system calls in linux are documented in man pages,
but I could only find the 2.4 version online. The latest manpages are
available at kernel.org.


>
>
> --Chris
>
>
>
> *From:* Henrique Almeida [mailto:hd...@gm...]
> *Sent:* Friday, 29 May 2009 9:50 a.m.
> *To:* Chris Forbes; lib...@li...
> *Subject:* Re: Warm-up task
>
>
>
>
>  Ok, that was FAST. :-D Chris, there are some tags that don't describe
> options. "OB" just means obsolescent. asctime and asctime_r are obsolescent,
> but MANDATORY. Also, "CX" just mean "C extension", it's safe to omit that.
> Please fix the tags. Also, you don't seem to have joined the mailing list,
> please join, so that I don't need to forward the messages to you.
>
>  The full option list is available at:
>
>  http://www.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
>
>  For anyone that has spare time, you can get more 50 functions to classify.
> ;-) Just send a note to the list, so that there's no overlap.
>
> 2009/5/28 Chris Forbes <ch...@fa...>
>
> Hi All
>
> There's only 41 functions in the standard starting with A, but here they
> are :)
>
> --Chris
>
>
> -----Original Message-----
> From: Henrique Almeida [mailto:hd...@gm...]
> Sent: Friday, 29 May 2009 2:37 a.m.
> To: lib...@li...; Chris Forbes
> Subject: Warm-up task
>
>  First of all, I hope the message reaches everyone, I'm not sure if
> the mailing list is working well, so please reply to this post if
> you've received it.
>
>  We'll start the project with a simple task. During the project we'll
> need to mantain the list with the status of each function in the
> project (that is, if it has been implemented, tested, etc.). We have a
> little more than 1.000 functions to implement. The standard
> distinguishes mandatory and optional functions and, for optional
> functions, to which option group they belong. Let's start with the
> following: classify 50 functions as either mandatory or optional, and,
> if optional, take note of which option group the function belongs.
> Also, for each function you classify, attribute an expected difficulty
> grade (easy, medium, hard) for its implementation. Finally, take note
> if the function is classified as obsolescent (tagged as "OB") or not.
>
>  You can see if the function is mandatory or optional by looking at
> its prototype. If there's no remark in the prototype, or if there's a
> remark that doesn't have an option group tag, it's mandatory.
> Mandatory functions may have extra optional functionality in its
> description, but they're mandatory anyway. If there's a remark with an
> option code in the function prototype, the function is optional and
> the tag represents the option group.
>
>  For example, the "atoi" function is mandatory and has an easy
> implementation, while the "crypt" is optional, belongs to the XSI
> option group and has a medium implementation. "dprintf" has a "CX" tag
> which is not optional, so dprintf is mandatory and has a hard
> implementation.
>
>  The full function list is on the "System Interfaces" volume of the
> standard.
>
>  Chris Forbes, take 50 functions starting with letter A
>  David Rocamora, take 50 functions starting with letter F
>  Guillermo Freschi, take 50 functions starting with letter K
>  Guilherme Mazzela, take 50 functions starting with letter P
>  I'll take 50 functions starting with letter U.
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>
>
>
>
> --
> Henrique Dante de Almeida
> hd...@gm...
>



-- 
Henrique Dante de Almeida
hd...@gm...