libk  Check-in [93014cedbc]

Modified libk.md from [7cef1da779] to [d834bc0082].

    53     53   libk uses the concept of "atoms" (small, regular strings of text) to standardize common references, such as operating systems or processor architectures.
    54     54   
    55     55   #### operating systems
    56     56   
    57     57   these atoms will be used to reference operating systems.
    58     58   
    59     59    * Linux: `lin`
    60         - * Haiku: `haiku`
    61         - * Android: `android`
           60  + * Haiku: `hai`
           61  + * Android: `and`
    62     62    * FreeBSD: `fbsd`
    63     63    * NetBSD: `nbsd`
    64     64    * OpenBSD: `obsd`
    65         - * Darwin/Mac OS X: `dar`
           65  + * Darwin/Mac OS X/iOS: `dar`
    66     66    * MS-DOS: `dos`
    67     67    * FreeDOS: `fdos`
    68     68    * Windows: `win`
    69     69   
    70     70   #### file extensions
    71     71   
    72     72    * C function implementations: `*.c`
................................................................................
    92     92   
    93     93   ## repository structure
    94     94   
    95     95   libk uses a strict directory structure for code, and deviations from this structure will not be tolerated without extremely good reason.
    96     96   
    97     97   all libk code is dispersed into modules: `kcore` for internals, `kio` for I/O, `kgraft` for binary packing, etc. each module has a folder in the root directory. (libk does not have submodules.) inside each module's directory should be a header with the same name as the module (see **naming conventions** above).
    98     98   
    99         -each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.haiku.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
           99  +each function should be kept in a separate file within its module's directory. when OS or architecture-specific code is needed, the file's name should be a list of one or more of the fields [arch, OS, bits, format] separated by a `.` -- for instance, the 32-bit x86 haiku version of a function called `write` defined in assembly would be named `write.x86.hai.32.s`. however, if a function has an extraordinarily large number of versions, they may instead be stored in a folder with the same name as the function.
   100    100   
   101    101   each module should have a header named the same thing as the module except without the `k` prefix. (e.g. the header for `kio` is `kio/io.h`) located in its folder. this is the header that the end-user will be importing, and should handle any user-defined flags to present the API the user has selected.
   102    102   
   103    103   each module directory should contain a makefile that can build that module. see **makefiles** below. all makefiles should be named `makefile` (**not** `Makefile`).
   104    104   
   105    105   each module should contain a markdown file. this file's name should be the name of the parent directory suffixed with `.md`; for instance, `kterm` should contain the file `kterm/kterm.md`. this file should document the module as thoroughly as possible 
   106    106