[cgl_discussion] AEM in OSDL
mika at osdl.org
Fri Apr 11 08:21:58 PDT 2003
On Thu, 2003-04-10 at 16:43, Ibrahim Haddad (LMC) wrote:
> It's not just "feeling it is good" - it is needed. AEM covers
> a new and essential mechanism that is needed. It is not replacing or
> modifying an existing or a well established Linux mechanism. Rather it is adding
> a new mechanism.
> CGL without AEM from an Ericsson perspective is not really a carrier grade Linux
> since it will be missing one piece needed by some of our telecom apps. Our applications
> require AEM and the notion of light processes which are not addressed.
Well, I understand that. Unfortunately, so far I have not seen the
fellow NEP's supporting Ericsson's view that AEM is absolutely needed.
So as I noted in the PoC meeting last week, the next hurdle AEM is
facing is getting into the forthcoming v2 Clustering section as a
priority 1. If that does not happen, then PoC has lot of other projects
addressing the priority 1 requirements to worry about.
On a technical note, I am willing to agree with you that some kind of
asynchronous message delivery is needed. But as has been reiterated
over and over again, AEM at it's current state just is too invasive
to get mainlined in vanilla kernel anytime soon.
Note that does not necessary mean that AEM should be dropped out of
CGL's radar: we do have several features in our 1.1 spec that a facing
same kind of problems (one example: application pre-loading). That is
why we have defined to mean our "mainline" mean either:
a) in kernel.org
b) in 2 or more CGL compliant distros
So if Ericsson considers AEM vital, I would strongly suggest that you
start talking with distribution companies about getting them to include
> Basically, CGL's mission is to advance the case of Linux in telecom,
> and thus in theory CGL should be helping us advance the case of AEM (in this case)
> because it is part of the telecom piece Linux is missing. We can not move to Linux
> without AEM; it provides a native interface for our applications. It's that simple.
I hear you. But I also listen to the 10+ other member companies of CGL:
my _job_ as a Roadmap Coordinator is to both prioritize and on the other
hand see that no member wish is ignored if possible. That is why I spent
considerable effort to get one of the OSDL employees to evaluate AEM.
I can understand that you do not like the results of that evaluation,
but knowing Dave Olien and working with him here, I am willing to
trust his evaluation being as objective as possible. The fact is,
that in Open Source world (where CGL operates) implementations
stand on their technical merit, not on political issues (well,
most of the time ;-). AEM has been evaluated on that ground, and been
If you disagree with that evaluation, feel free to contest it here
on technical grounds, and/or take you chances with LKML people (which
you have to do anyway at some time, if you plan to get AEM into
> > OSDL suggests low probability acceptance in mainline.
> I am not happy to see that OSDL is driving (& putting efforts into) the contributions
> that have a likelihood of being accepted, and slowing down or dropping out contributions
> that have a less likelihood of acceptance (or maybe just
> an impression I have). If the person who accepts/rejects what goes into kernel has
You are as aware as I about the resource situation of our (= CGL-WG's)
PoC effort. And let me remind you that CGL-WG != OSDL, and as such
OSDL is doing lot of other things outside CGL scope. Every request for
_OSDL_ resources I make needs to have a solid reasoning behind it.
Once again I would like to point out that I have not seen any effort
from the fellow NEP's to get involved in AEM, which to me means that
maybe they do not consider AEM vital. So I think instead of complaining
about OSDL resourcing, you should turn towards your fellow NEP's and
ask why they are not doing anything.
> no idea on AEM - we have to educate him and provide him with necessary info to
> understand it and Frederic has produced a very good set of documentation (*) to help
> people know AEM and try it and even he provides a document to compare it with
> other mechanisms. On the other hand, If the person does not want to see AEM
> in - we want to why and how to change that.
Trust me, there is no "we hate AEM" league here. I think the basic
feeling I have is that AEM should probably taken as a same kind of
project as EVMS and NGPT, i.e. projects that are addressing necessary
requirement and by existing cause a competitive Open Source project
to become into existence (LVM2 & NPTL), and so in the end get the
needed functionality in the kernel.org (although it is not going to
be AEM code that gets there...).
And that is why I have repeatedly refused to remove AEM from PoC agenda
(and actually from OSDL clusters initiative); I am hoping that my
stubborness will cause somebody to create a competing and hopefully
more acceptable (to the community) solution to the problem.
> But in all cases, we as OSDL and CGL member companies need to put efforts
> into this the same way things are happening with TIPC and other contributions
> from different companies.
Once again, the start for this joint effort must come from unified (or
at least majority) NEP's. If NEP's do not agree that feature is
essential, then we run into risk of spending time and our sponsors money
on something that might not be needed after all.
> Basically I want to say that the decision of OSDL and other member companies
> investing time/efforts on AEM should not be driven by the feeling if AEM will be
> accepted or not. If should more be driven by the fact that this is a needed
> requirement to support telecom applications and we want to work on it to have
> it accepted. And it is a needed requirement.
As I pointed out above, if asynchronous message delivery (note: not
AEM!) is a needed feature, it must be a priority 1 in the upcoming
clustering section. Then it is PoC's responsibility to start figuring
out how to proceed.
> For our OSDL & CGL member companies colleagues who do not believe that AEM
> is a needed requirement, we would like to discuss why they feel like that and
> what are the reasons behind it.
Yes, please do that. Start with other NEPs.
> > OSDL may create something to address same featureset.
> > no idea when that may happen.
> I have no idea on why this is even a probability. It simply doesn't make sense to me.
> Why would OSDL go create something similar to AEM if AEM exists.
> It provides us with a mechanism that make us one step ahead close to a carrier grade
> Linux kernel. Why start from zero to build something similar and not work to enhance
> what we currently have.
I will say this once more very s-l-o-w-l-y. It is the opinion of Dave
and some other knowledgeable OSDL kernel developers (I think Randy and
Pat also), that AEM has 0, non-existent, not until hell freezes over,
chance of getting accepted by Linus into his kernel. If you do not
believe us, all you need to do is to post AEM to the LKML and see for
> Just my thoughts on that...
Well, this was my official position. If you have issues with it, raise
it to the Tech Board and/or Steering. Enough said.
More information about the cgl_discussion