This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Kernel objects and eCos


    As I understand it the NULL functionality does not exist because eCOS
isn't smart enough to locate the heap on it's own and so it requires the
user to create memory pools before it can get at memory. After the pools
have been created only the user may access them anyways. The other issue is
that not all of the eCOS objects have a concept of a "destructor" so they
wouldn't know when to deallocate the memory. This implementation is
braindead and I don't like it either. I don't however understand why you
"need" the functionality in the kernel. You could simply use malloc before
create the object, and free when you were done with it. Or you could make
some functions which wrapped the eCOS functions and did the malloc and free
inside. It's inconvienient and it's inconsistant with other OS'es but it
works just the same. In a Real-time system where the application and the
kernel are on the same level it is usually preferable to use static
allocation anyways because you lose the overhead you have with other OS's
which hide the memory managment completely.

	-Neils

-----Original Message-----
From: Michael Klock [mailto:mklock@omegaband.com]
Sent: Tuesday, April 24, 2001 3:41 PM
To: ecos-discuss
Subject: [ECOS] Kernel objects and eCos



I'm looking at porting a virtual embedded OS API to eCos. It appears that
for eCos the user must allocate the space for some kernel objects
(cyg_thread, cyg_alarm, cyg_mempool_var, etc.) before calling eCos. The user
then never uses the kernel object and it is solely managed by the kernel.
The virtual embedded OS API assumes that the kernel manages the kernel
objects inside the kernel.

My question is: some of the kernel calls (like cyg_thread_create) note that
passing NULL for these kernel objects (in this case cyg_thread) will cause
the kernel to allocate the space themselves (which in my opinion is the way
to do it). But it also says that the "NULL" functionality is not yet
supported. Is anyone working on this "NULL" capability support? For my port,
I need the "NULL" functionality real bad...

Thanks,
Mike.

-------------------------------------------
  Michael Klock, OmegaBand Inc.
  (formerly Seagull Semiconductor)
  9020-I Capital of Texas Hwy N., Suite 270.
  (512)401-8208 x145
-------------------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]