POSIX Option Groups

Description:

This is a bunch of more or less (un)related functions. posix_fadvise() and posix_madvise() help the OS to optimize access to files and memory mapped using mmap(). posix_fallocate() allows to pre-allocate disk space which can be a performance optimization (since the storage can be allocate sequentially. It is also a method to ensure that enough memory is available right away. Normally files, set to a certain size using ftruncate(), are allocate sparsely, i.e., without actually allocating disk space for all the blocks. The last function, posix_memalign(), allows allocating memory with a given alignment. A function with this semantics was widely available as memalign(). Its functionality can be implemented by the user with only malloc() but this can waste resources.

Affected interfaces:

• posix_fadvise()
• posix_fallocate()
• posix_memalign()
• posix_madvise()

Status:

posix_fadvise() is implemented in the 2.5 kernel and used in recent glibc versions. posix_madvise() is mostly implemented but the implementation is based on the older BSD madvise() interface. posix_fallocate() is implemented entirely at user level by writing blocks of zeros. According to Stephen Tweedie it makes not much sense to move this functionality into the kernel. I don't know whether this is true. posix_memalign() is completely implemented.

Description:

Asynchronous I/O serves two purposes: first it allows the program to continue doing what is has to do without waiting for I/O to complete. If it is determined that the I/O results are not anymore needed the I/O request can be canceled. Second, it provides the OS the opportunity to optimize the I/O processing multiple requests at once.

Affected interfaces:

• aio_cancel()
• aio_error()
• aio_fsync()
• aio_read()
• aio_return()
• aio_suspend()
• aio_write()
• lio_listio()

Status:

Linux has for some time an almost 100% compliant implementation of AIO. The implementation is entirely at user-level. This means it is not taking advantage of all the possibilities the use of AIO provide.

For the 2.5 kernel Ben LaHaise implemented a kernel implementation. The kernel interface does not correspond to the POSIX AIO interface so there is significant effort at the user-level necessary. The result is very much better since the kernel gets complete control over the I/O.

Red Hat Enterprise Linux comes with a kernel-supported AIO implementation which is based on the functionality in the 2.5 kernel. RHEL3 even supports AIO on pipes and sockets. Due to changes in the 2.6 kernel the support in RHEL4 is reduced to file descriptors which bypass filesystem caching.

This option is mandatory in IEEE 1003.1-2008.

Description:

If this option is defined changing the owner of filesystem objects is restricted. Normally only the super user is allowed to do this.

Affected interfaces:

• chown()
• lchown()

Status:

Linux defined this option since day one.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

This options lumps together three different groups of functions. Basically, they all add support for clocks other than the normal realtime clock. The latter is what is used implicitly everywhere time is measured unless explicitly stated otherwise. But this clock might have limitations such as precision.

The pthread_condattr_getclock() and pthread_condattr_setclock() allow to specify the clock which is used in pthread_cond_timedwait(). clock_nanosleep() is a superset of nanosleep(). It allows using alternative clocks but it also allows to specify absolute timeouts. clock_settime() is the interface to set any of the clocks which can be set.

Affected interfaces:

• pthread_condattr_getclock()
• pthread_condattr_setclock()
• clock_nanosleep()
• clock_settime()

Status:

Update: The Linux kernel version 2.5.64 and later provide the necessary support. glibc 2.3.3 with NPTL supports this option.

This option is mandatory in IEEE 1003.1-2008.

Description:

Some architectures provide user-level access to a very high-resolution clock the processor implements. Normally this simply a counter of cycles the chip is driven by. To be useful for this option the clock must not turn around often. For this reason Alpha does not have this option available although the architecture has a CPU cycle counter available. But its 32-bit size limit the usefulness.

Other processors, IA-32, IA-64 and perhaps more in future, do have a cycle counter register. The interfaces of this option provide support to use these registers without resorting to architecture specific code. The information is provided in nanoseconds and not in cycle counts.

Warning: Before the 2.6.10 kernel the CPU clock implementation we use might not be what other people want. The clocks basically measured wallclock time using CPU registers. This changed in 2.6.10 when new system calls were added and now scheduling can be taken into account. Now the clocks show the time which the system actually spent on the process/thread. Just like ru_utime/ru_stime info in struct rusage but available at all times.

Affected interfaces:

• clock_getcpuclockid()
• clock_getres()
• clock_gettime()
• clock_nanosleep()
• clock_settime()
• timer_create()

Status:

Before the 2.6.10 kernel some support was available for processors with easy access to CPU cycle counters. For some architectures, like PPC, the great variety of CPU implementations based on the architecture complicate things and nothing has be done to solve the issue.

Update: After 2.6.10 support for all architectures and the correct semantics is available. The precision might vary between the architectures.

Description:

This option marks the fsync() interface which might not be useful or implementable on some system but Linux had it forever.

Affected interfaces:

• fsync()

Status:

Is implemented since the very early days.

Description:

This option is signals support for the IPv6 protocol in addition to IPv4. To support IPv6 a number of new interfaces were introduced and some existing interfaces extended. It also means that a number of interfaces which were used with IPv4 cannot be used anymore in protocol-independent code.

Affected interfaces:

• accept()
• bind()
• connect()
• freeaddrinfo()
• gai_strerror()
• getaddrinfo()
• gethostbyaddr()
• getnameinfo()
• getpeername()
• getsockname()
• getsockopt()
• inet_ntop()
• inet_pton()
• recvfrom()
• sento()
• setsockopt()

Status:

IPv6 is usable in Linux since at least the Linux 2.4 days.

This option is mandatory in IEEE 1003.1-2008.

Description:

This option is another remembrance of the old days of very simple system. Job control was always available on Linux. Processes could always be sent to the background etc.

Affected interfaces:

• setpgid()
• tcdrain()
• tcflush()
• tcgetpgrp()
• tcsendbreak()
• tcsetattr()
• tcsetpgrp()

Status:

Is implemented since the very early days.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

Mapping file contents in the address space allows the OS to optimize the handling of the needed memory by loading the data only when really needed and evacuate portions of already loaded data when the memory is needed otherwise. If delay associated with the overhead to load the data on demand is not acceptable the data can be forced to stay in memory. This feature is also available for all currently support kernel versions.

Affected interfaces:

• mlockall()
• munlockall()

Status:

Is implemented since the very early days.

Description:

A bit more flexible than the functionality of _POSIX_MEMLOCK this options allows to lock parts of a file in memory. This feature is also available in all supported Linux kernel versions.

Affected interfaces:

• mlock()
• munlock()

Status:

Is implemented since the very early days.

Description:

Changing the access protection of mapped memory regions is useful for many purposes. A reliable implementation of shared libraries requires it and therefore this feature is available in all support kernel versions.

Affected interfaces:

• mprotect()

Status:

Is implemented since the very early days.

This option is mandatory in IEEE 1003.1-2008.

Description:

The monotonic clock was introduced to allow the user to implement relative timeouts. The problem with the realtime clock which normally is used is that it can be reset with the consequence that timeouts maybe be lengthened or shortened depending on the direction of the clock adjustment. But the availability of this option also means that all interface which normally would use the realtime clock by default now use the monotonic clock which can lead to problem since this is not expected by most of the code written up to this day.

Affected interfaces:

• clock_getres()
• clock_gettime()
• clock_nanosleep()
• clock_settime()
• timer_create()

Status:

Update: glibc 2.3.3 has support for the functions governed by this option based on support in the 2.5 kernel. Older glibc versions had a userlevel implementation of limited quality and only for CLOCK_REALTIME..

Description:

This feature was a bad compromise for some broken systems. Long filenames were silently truncated generating surprising effects and security holes. Fortunately support for this option is now required.

Affected interfaces:

Every interface handling file names.

Status:

Linux always supported this option.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

Raw sockets were a disputed socket type when the discussion was made about including them in the POSIX standard. The problem is that not much can be specified generally without consideration of the kind of socket which is manipulated.

Affected interfaces:

• getsockopt()
• setsockopt()

Status:

The Linux kernel implements raw sockets for all kinds of socket types. The standard behavior is implemented as are many more features.

Description:

Standard Unix signals have several drawbacks. First, they do not queue. If one signal of a kind is pending new ones are simply discarded. Second, the signal cannot carry any information which requires either the use of several different signals to transmit information or some mechanism outside the signal handler has be used (e.g., global variables) which has its own set of problems.

Realtime signals do queue and can transmit information. They also solve problems related to existing signals. E.g., the SIGSEGV can now transmit all the information to locate the reason of the segmentation fault.

Affected interfaces:

• sigqueue()
• sigtimedwait()
• sigwaitinfo()

Status:

Realtime signals are implement for many years and are in wide use.

This option is mandatory in IEEE 1003.1-2008.

Description:

Regular expressions were one of the big inventions of the original POSIX standard and although some people prefer other regular expression implementations the POSIX version prevailed in most situations. It provides all the necessary features and is widely available.

Affected interfaces:

• regcomp()
• regerror()
• regexec()
• regfree()

Status:

Regular expressions were always available in glibc. The quality of the implementation is another issues. Until glibc 2.3 there were issues with some border cases but internationalization features were available (unlike in most other implementations). Starting with glibc 2.3 a new implementation is available and it should fix the remaining problems with compliance to the standard. Full internationalization support is included as well.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

A process having effective and normal user and group IDs are a mean to increase security. Early POSIX standards didn't require support because some systems at that time didn't provide the feature. The alignment of the latest POSIX standard with FIPS makes this feature mandatory.

Affected interfaces:

• geteuid()
• getegid()
• getgid()
• getuid()
• seteuid()
• setegid()
• setgid()
• setuid()

Status:

Linux always support saved IDs. The kernel even provides finer-grained IDs which functions which determine the access rights to files.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

POSIX shared memory could theoretically be implemented without special kernel support but the implementation wouldn't be optimized and it would, depending on the setup, be a security problem. The 2.2 series of the kernel introduced a special filesystem type to support shared memory (refined in the 2.4 series) which allowed creating files without backing them with space on a device.

Affected interfaces:

• mmap()
• munmap()
• shm_open()
• shm_unlink()

Status:

Starting with glibc 2.1 support for POSIX shared memory was available. But each system must be configured to provide the necessary filesystem.

Description:

This option was introduced to allow creating profiles for embedded systems which don't need shells and command lines. Non-embedded systems always have a shell.

The POSIX standard requires that system() is usable in multi-threaded applications but this is hardly ever implemented correctly since the implementation has to change global state.

Affected interfaces:

• system()

Status:

Normal Linux setups always have a shell and this option defined. glibc 2.3.2 with NPTL support should even implement the multi-threaded application requirement correctly.

This option is mandatory in IEEE 1003.1-2001 and later.

Description:

To support multiple processes on systems without MMU support something other than the fork() and exec POSIX model is needed. The solution is the spawn family of functions. The functions can be implemented in the kernel. This way the kernel can avoid the fork() step. For systems which do support fork() the functions can be implemented at user-level.

Affected interfaces:

• posix_spawn()
• posix_spawn_file_actions_addclose()
• posix_spawn_file_actions_adddup2()
• posix_spawn_file_actions_addopen()
• posix_spawn_file_actions_destroy()
• posix_spawn_file_actions_init()
• posix_spawnattr_destroy()
• posix_spawnattr_getsigdefault()
• posix_spawnattr_getflags()
• posix_spawnattr_getpgroup()
• posix_spawnattr_getsigmask()
• posix_spawnattr_init()
• posix_spawnattr_setsigdefault()
• posix_spawnattr_setflags()
• posix_spawnattr_setpgroup()
• posix_spawnattr_setsigmask()
• posix_spawnp()

Status:

Starting with version 2.2 glibc has a user-level implementation of these interfaces.

Description:

Spinlocks are a form of synchronization primitive which can be used only in carefully chosen situation. If programs which use threads with different priorities every use of a spinlock in a thread which does not have the highest priority is a gamble. But if spinlocks are usable they provide significant speed advantages.

Affected interfaces:

• pthread_spin_destroy()
• pthread_spin_init()
• pthread_spin_lock()
• pthread_spin_trylock()
• pthread_spin_unlock()

Status:

Spinlocks are implemented since glibc 2.2. Even the inter-process variant is available since it does not require kernel support.

This option is mandatory in IEEE 1003.1-2008.

Description:

To create a consistent state when it comes to disk I/O it is necessary to force all output from the buffers the kernel uses to the underlying device. With this option the POSIX standard provide a number of different ways to make this possible.

Affected interfaces:

• fcntl()
• open()
• msync()
• fdatasync()

Status:

At least with the 2.4 kernels all the necessary support is in place. All the interfaces and functionality required by POSIX are available.

Description:

Each new thread has to have its own stack and all the stacks of the different threads in a process are in the same address space. Where the stacks are allocated is by default the thread libraries issue. If the use of the address space is an issue, as it sometimes is on 32-bit machine, the application can make the decision by determining the stack address explicitly. The stack is in this case allocated by the user.

Affected interfaces:

• pthread_attr_getstack()
• pthread_attr_getstackaddr()
• pthread_attr_setstack()
• pthread_attr_setstackaddr()

Status:

This option is implemented since glibc 2.1 for those architectures which provide a thread register. Since a thread register is a prerequisite for NPTL these functions are always supported for this thread library.

Description:

Each new thread has to have its own stack and all the stacks of the different threads in a process are in the same address space. This can create two kinds of problems:

• The default stack size is too small. The thread will terminate at some point with an error or it will create wrong results because it reads from and write to invalid memory.
• The default stack size is too large. Every stack size is too large if the number of threads is very high.

Affected interfaces:

• pthread_attr_getstack()
• pthread_attr_getstacksize()
• pthread_attr_setstack()
• pthread_attr_setstacksize()

Status:

This option is implemented since glibc 2.1 for those architectures which provide a thread register. Since a thread register is a prerequisite for NPTL these functions are always supported for this thread library.

Description:

This option can lead to better handling of threads with different priorities. If a high-priority thread is waiting on a mutex which is held by a lower-priority thread the latter is continuing to use its own priority although it blocks a thread with a higher priority. If this option is defined the user can define a mutex which automatically adjusts the priority of the thread holding the mutex based on the priority of the waiters.

Affected interfaces:

• pthread_mutexattr_getprotocol()
• pthread_mutexattr_setprotocol()

Status:

The 2.6.18 kernel has the necessary support to implement this option. PI futexes are enabled in (almost?) all configurations. The thread library changes are in version 2.5 which starts to be available in Fedora Core 6 and RHEL5.

Description:

This option can lead to better handling of threads with different priorities. If a high-priority thread is waiting on a mutex which is held by a lower-priority thread the latter is continuing to use its own priority although it blocks a thread with a higher priority. If this option is defined the user can define a mutex which always increases the priority to a given level regardless of whether there are waiters or not.

Affected interfaces:

• pthread_mutex_getprioceiling()
• pthread_mutex_setprioceiling()
• pthread_mutexattr_getprioceiling()
• pthread_mutexattr_getprotocol()
• pthread_mutexattr_setprioceiling()
• pthread_mutexattr_setprotocol()

Status:

This option is implemented for NPTL since August 2006. FC6 and RHEL5 will have this option. It is a userlevel implemention but it is believed to be compliant. The implementation does not support priority protection for robust mutexes. But since robust mutexes are not (yet) part of POSIX this has no effect on this option.

Description:

Some of the interfaces in the POSIX standard are not thread-safe and some are changed noticeably in complexity and performance. For some but not all not thread-safe functions the POSIX standard defines variants if this option is present. The functions which were changed greatly speed-wise by the introduction of threads include the standard I/O function for which POSIX defines variants which can be implemented just like the functions in pre-thread times.

Affected interfaces:

• readdir_r()
• getgrgid_r()
• getgrnam_r()
• getpwnam_r()
• getpwuid_r()
• flockfile()
• ftrylockfile()
• funlockfile()
• getc_unlocked()
• getchar_unlocked()
• putc_unlocked()
• putchar_unlocked()
• rand_r()
• strerror_r()
• strtok_r()
• asctime_r()
• ctime_r()
• gmtime_r()
• localtime_r()

Status:

All the mentioned functions (and more) are implemented in glibc.

This option is mandatory in IEEE 1003.1-2008.

Description:

If this option is defined the functions to provide basic support for POSIX threads are available.

Affected interfaces:

• pthread_atfork()
• pthread_attr_destroy()
• pthread_attr_getdetachstate()
• pthread_attr_getschedparam()
• pthread_attr_init()
• pthread_attr_setdetachstate()
• pthread_attr_setschedparam()
• pthread_cancel()
• pthread_cleanup_push()
• pthread_cleanup_pop()
• pthread_cond_broadcast()
• pthread_cond_destroy()
• pthread_cond_init()
• pthread_cond_signal()
• pthread_cond_timedwait()
• pthread_cond_wait()
• pthread_condattr_destroy()
• pthread_condattr_init()
• pthread_create()
• pthread_detach()
• pthread_equal()
• pthread_exit()
• pthread_getspecific()
• pthread_join()
• pthread_key_create()
• pthread_key_delete()
• pthread_mutex_destroy()
• pthread_mutex_init()
• pthread_mutex_lock()
• pthread_mutex_trylock()
• pthread_mutex_unlock()
• pthread_mutexattr_destroy()
• pthread_mutexattr_init()
• pthread_once()
• pthread_rwlock_destroy()
• pthread_rwlock_init()
• pthread_rwlock_rdlock()
• pthread_rwlock_tryrdlock()
• pthread_rwlock_trywrlock()
• pthread_rwlock_unlock()
• pthread_rwlock_wrlock()
• pthread_rwlockattr_destroy()
• pthread_rwlockattr_init()
• pthread_self()
• pthread_setcancelstate()
• pthread_setcanceltype()
• pthread_setspecific()
• pthread_testcancel()

Status:

All the mentioned functions are available. The current implentation (NPTL) is, as far as it is known today, fully POSIX compliant. The same cannot be said for the now obsolete LinuxThreads implementations.

This option is mandatory in IEEE 1003.1-2008.

Description:

Initially only the conditional variable API had the functionality of a timeout for the operations which might block. But this is a generally needed functionality.

Affected interfaces:

• mq_timedreceive()
• mq_timedsend()
• pthread_mutex_timedlock()
• pthread_rwlock_timedrdlock()
• pthread_rwlock_timedwrlock()
• sem_timedwait()
• posix_trace_timedgetnext_event()

Status:

The last interfaces to be added were the POSIX message queue functions which are available in the 2.6.6 kernel and 2.3.4 glibc.

This option is mandatory in IEEE 1003.1-2008.

Description:

The asynchronous creation of timeouts (one-time and interval) in early Unix version was limited to the setitimer() function which sends a signals. Users demanded more flexibility and the result was the introduction of POSIX timers which not only allow sending arbitrary signals. The full functionality of realtime signals is available and instead of sending signals the functions could also create threads.

Affected interfaces:

• clock_getres()
• clock_gettime()
• clock_settime()
• nanosleep()
• timer_create()
• timer_delete()
• timer_gettime()
• timer_getoverrun()
• timer_settime()

Status:

A user-level implementation of the interfaces is available in glibc 2.2. The overall performance is not the best, the clocks to use are restricted to only the realtime clock, and because of that the resolution is limited. With a 2.5 kernel and glibc 2.3.3 or up kernel support is available which also includes support for CLOCK_MONOTONIC.

This option is mandatory in IEEE 1003.1-2008.

Description:

POSIX tracing is a mechanism to collect information about a running process and eventually all the children. Events are generated by the user-program itself, the system, or other processes.

Affected interfaces:

• posix_trace_attr_destroy()
• posix_trace_attr_getclockres()
• posix_trace_attr_getcreatetime()
• posix_trace_attr_getgenversion()
• posix_trace_attr_getmaxdatasize()
• posix_trace_attr_getmaxsystemeventsize()
• posix_trace_attr_getmaxusereventsize()
• posix_trace_attr_getname()
• posix_trace_attr_getstreamfullpolicy()
• posix_trace_attr_getstreamsize()
• posix_trace_attr_init()
• posix_trace_attr_setmaxdatasize()
• posix_trace_attr_setname()
• posix_trace_attr_setstreamsize()
• posix_trace_attr_setstreamfullpolicy()
• posix_trace_clear()
• posix_trace_create()
• posix_trace_event()
• posix_trace_eventid_equal()
• posix_trace_eventid_get_name()
• posix_trace_eventid_open()
• posix_trace_eventtypelist_getnext_id()
• posix_trace_eventtypelist_rewind()
• posix_trace_flush()
• posix_trace_get_attr()
• posix_trace_get_status()
• posix_trace_getnext_event()
• posix_trace_shutdown()
• posix_trace_start()
• posix_trace_stop()
• posix_trace_trygetnext_event()

Status:

The functionality of this option isn't implemented as of glibc 2.3. Any implementation requires kernel support which is unlikely to be added.

This option has been obsoleted in IEEE 1003.1-2008.

Description:

This option is defined on top of _POSIX_TRACE. If set the user can register functions which discard some of the information which normally would be written into the trace file.

Affected interfaces:

• posix_trace_eventset_add()
• posix_trace_eventset_del()
• posix_trace_eventset_empty()
• posix_trace_eventset_fill()
• posix_trace_eventset_ismember()
• posix_trace_get_filter()
• posix_trace_set_filter()
• posix_trace_trid_eventid_open()

Status:

The functionality of this option isn't implemented as of glibc 2.3. Any implementation requires kernel support which is unlikely to be added.

This option has been obsoleted in IEEE 1003.1-2008.

Description:

This option is defined on top of _POSIX_TRACE. It allows to define how programs started from a traced program behave.

Affected interfaces:

• posix_trace_attr_getinherited()
• posix_trace_attr_setinherited()

Status:

The functionality of this option isn't implemented as of glibc 2.3. Any implementation requires kernel support which is unlikely to be added.

This option has been obsoleted in IEEE 1003.1-2008.

Description:

This option is defined on top of _POSIX_TRACE. It allows to log to trace output.

Affected interfaces:

• posix_trace_attr_getlogfullpolicy()
• posix_trace_attr_getlogsize()
• posix_trace_attr_setlogfullpolicy()
• posix_trace_attr_setlogsize()
• posix_trace_close()
• posix_trace_create_withlog()
• posix_trace_open()
• posix_trace_rewind()

Status:

The functionality of this option isn't implemented as of glibc 2.3. Any implementation requires kernel support which is unlikely to be added.

This option has been obsoleted in IEEE 1003.1-2008.

Description:

Typed memory objects are similar to shared memory but there is no requirement that they are backed by a device. Instead typed memory objects are identified by names which can mean everything. It would for instance useful to provide the video memory of a system a symbolic name and then access it with this name.

Affected interfaces:

• posix_mem_offset()
• posix_typed_mem_get_info()
• posix_typed_mem_open()

Status:

The functionality of this option isn't implemented as of glibc 2.3.

Description:

If this option is available the crypt() function family is available. Even though the standard implementation is based on DES; a real encryption mechanism, the functions cannot be used for this purpose. They are only useful for password verification.

Affected interfaces:

• crypt()
• encrypt()
• setkey()

Status:

These functions are available and since the lifting of the export restrictions they are available in the default package. The functions implement the DES encryption method as well as a non-standard implementation based on MD5.

Description:

This option was introduced in XPG4.2 to enable various variants of functions which were improved for use in internationalized applications. Since then this option was folded into XSI.

Affected interfaces:

• catclose()
• catgets()
• catopen()
• nl_langinfo()
• setlocale()

Status:

All the functions which were defined by this option are available in glibc.

Description:

If it is decided to discontinue an interface in Unix/POSIX the interface first has to be declared as legacy. Only after being legacy for at least one release can the interface be removed. The set of legacy interfaces therefore changes with every release. None of the interfaces in this category should be used in newly written code.

Affected interfaces:

• bcmp()
• bcopy()
• bzero()
• ecvt()
• fcvt()
• ftime()
• gcvt()
• getwd()
• index()
• mktemp()
• rindex()
• utimes()
• wcswcs()

Status:

All these interfaces are and will be available in glibc.

Description:

The System V network code used the more structured STREAMS support instead of the more basic use of socket. Due to misdesign of the STREAMS interfaces (not the basic concept) STREAMS become more and more impractical. In addition do many OSes not provide a STREAMS implementation.

Affected interfaces:

• isastream()
• getmsg()
• getpmsg()
• ioctl()
• putmsg()
• putpmsg()
• fattach()
• fdetach()

Status:

The standard Linux kernel does not provide support for STREAMS. But there are third-party kernel modules which implement the behavior. glibc is prepared to take advantage of the eventually available kernel module. If the module is not present the functions defined in glibc always fail..

This option has been obsoleted in IEEE 1003.1-2008.