ESA SOCIS - Porting the Monkey HTTP Server

Sebastian Huber sebastian.huber at embedded-brains.de
Tue May 3 05:30:41 UTC 2016



On 03/05/16 07:26, Chris Johns wrote:
> On 03/05/2016 15:23, Sebastian Huber wrote:
>> On 03/05/16 04:27, Chris Johns wrote:
>>
>> What are these issues with kqueue?
>>
>
> The Monkey kqueue uses a pipe so it was pipe. I had forgotten.
>
>>
>> The socket pairs are supported in the new network stack.
>>
>
> Oh, sorry it was not socket pairs, it was a pipe and the 
> implementation in RTEMS is not great.
>
>>
>> What is the issue here? Maybe we should add tickets for all of these
>> problems.
>>
>
> It would be to make pipes better. There may even be one.
>
> Chris

Ok, pipes... Yes, they are quite useless on RTEMS although they are so 
useful in general. In principle they could also support kqueue on RTEMS. 
The kqueue handler is part of the normal RTEMS file system infrastructure:

/**
  * @brief File system node operations table.
  */
struct _rtems_filesystem_file_handlers_r {
   rtems_filesystem_open_t open_h;
   rtems_filesystem_close_t close_h;
   rtems_filesystem_read_t read_h;
   rtems_filesystem_write_t write_h;
   rtems_filesystem_ioctl_t ioctl_h;
   rtems_filesystem_lseek_t lseek_h;
   rtems_filesystem_fstat_t fstat_h;
   rtems_filesystem_ftruncate_t ftruncate_h;
   rtems_filesystem_fsync_t fsync_h;
   rtems_filesystem_fdatasync_t fdatasync_h;
   rtems_filesystem_fcntl_t fcntl_h;
   rtems_filesystem_poll_t poll_h;
   rtems_filesystem_kqfilter_t kqfilter_h;
   rtems_filesystem_readv_t readv_h;
   rtems_filesystem_writev_t writev_h;
};

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list