[cgl_discussion] SCL1.0 discussion continued

Fan, Ardelle ardelle.fan at intel.com
Thu Jul 10 19:23:01 PDT 2003


Hi Julie,
Thanks for summarize them into tracking sheet.
Add a little point upon Louis' comments
The point 4. Provide Linux kernel with ...
The system with such capability is needed to ensure upper solutions work. AEM do it in kernel, epoll do it partly in kernel, user library can do the rest part (event handler activation).
Changing the requirment discription to "Provide system with the capability to ..." will have no conflicts to both Poc.

Regards/Ardelle Fan

These are my opinions and absolutely not official opinions of Intel Corp.


-----Original Message-----
From: Fleischer, Julie N 
Sent: 2003?7?11? 0:55
To: Fan, Ardelle; Zhuang, Louis; cgl_discussion at osdl.org; ibrahim.haddad at ericsson.com
Cc: Andre Beliveau (QB/LMC)
Subject: [cgl_discussion] SCL1.0 discussion continued


Ardelle/Louis -
I'm trying to put all the great details you've been discussing into the POC project tracking sheet.  Can you tell me if my summary below is accurate?  (I'm really pretty ignorant about the details here, so I may have things recorded incorrectly.)
- Julie

1.  System scalability for large number of events.
- 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 as well as AEM

3.  Events on multiple channels
- NEEDS WORK - AEM only supports timer and socket; work needed for SCTP
- MAYBE OKAY - supports multiple channels, only read event (this may be OK)

4.  Provide Linux kernel with the capability to handle such kind of events
=> According to Andre Beliveau, this is needed to ensure any user-space solutions work.  Not sure what this means to AEM/epoll.


**These views are not necessarily those of my employer.**

_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
http://lists.osdl.org/mailman/listinfo/cgl_discussion




More information about the cgl_discussion mailing list