[cgl_discussion] RE: SCL1.0 discussion continued

Ibrahim Haddad (QB/LMC) ibrahim.haddad at ericsson.com
Fri Jul 11 13:41:25 PDT 2003


Julie,
We will give you our feedback on below on Monday.
Thanks,
Ibrahim

-----Original Message-----
From: Fleischer, Julie N [mailto:julie.n.fleischer at intel.com]
Sent: Friday, July 11, 2003 4:44 PM
To: Zhuang, Louis; Fan, Ardelle; cgl_discussion at osdl.org; Ibrahim Haddad
(QB/LMC)
Cc: Andre Beliveau (QB/LMC)
Subject: RE: SCL1.0 discussion continued


Thanks, Louis and Ardelle.  I've written below what I've put in the POC
sheet.  In addition, I'll make a note to bring the potential rewrites of
requirement SCL1.0 so that both AEM and epoll can satisfy the
reuqirement at the CGL specs meeting Monday (It may end up getting more
formally discussed at the F2F the following Monday instead.).

- Julie

1.  System scalability for large number of event channels
- YES - AEM does this with forked event handlers
- YES - epoll plus a user library to support event handling does this

2.  Soft real-time responsiveness for essentially simultaneous events
- YES - AEM plus RT patch does
- YES - epoll does; TBD if AEM resolves better than epoll or not
(Andre/Ibrahim would know better)

3.  Events on multiple types of channels
- NEEDS WORK - AEM only supports timer and socket; work needed for SCTP
- MAYBE OKAY - supports multiple channels, only read event (others
dependent on implementation), but accept/read/write/exception on socket,
so OK

4.  Provide Linux kernel with the capability to handle such kind of
events
- AEM does in kernel
- epoll does partly in kernel, user-space library can do the rest (event
handler activation in #1)**
**Should change requirement to replace "Linux kernel" with "system" and
both fulfill.
**These views are not necessarily those of my employer.**



More information about the cgl_discussion mailing list