[cgl_discussion] Revised "Top 10" projects list

Fleischer, Julie N julie.n.fleischer at intel.com
Mon Jun 30 16:44:33 PDT 2003

Here's a revised top 10 projects list based on comments received today.  Since it's no longer 10, one thought is to bubble in some of the security requirements to ensure we agree on the solutions to those.

Of course, the potential priority changes will also affect this list, so I'll update it again after that is finalized.

Any comments I received have also been reflected in the POC project list at http://www.osdl.org/docs/poc_cgl_20_priority_1_solutions.xls (not the PDF, though).

- Julie

Top Tier
Persistent Device Naming (a.k.a HDI) -> Neither project listed appears to implement full requirement.  One is being worked on, but isn't listed yet.

Software Remote Update -> Appears to have distro-specific requirements tied to it.  Unclear which option is available for distros that implements full requirement.

Soft Realtime Support Performance -> Need to understand how we will implement this (or if it already is implemented).

Asynchronous Events -> AEM is the only one designed to meet full requirement, but it is invasive.  Others need work to implement requirement.

Bottom Tier
POSIX Message Passing -> We do have implementations, but don't have distro input on which will be used, if either.

Multipath Access to Storage -> There are two projects, but both need work to implement requirement.

Cluster Node Failure Detection -> Sounds like Linux-HA, at least, is okay for CGL 2.0.

Communication Service/Logical Addressing and Fault Handling ->  Sounds like Linux-HA, at least, is okay for CGL 2.0.

IPSec for IPV4/Support for IKE -> Current implementations implement requirement in kernel space.  User space may still need stability, but CGL is comfortable a solution will exist in the CGL 2.0 timeframe without needing CGL assistance.

IPMI 1.5 -> User library needs help getting stable, but is included by distros already.  Kernel pieces are stable for 2.5 and also exist for 2.4.

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

More information about the cgl_discussion mailing list