RE: [ECOS] Kernel objects and eCos

RE: [ECOS] Kernel objects and eCos

[Neils Nesse]

    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
-------------------------------------------

RE: [ECOS] Kernel objects and eCos

[Michael Klock]

Hi Neils,

Thanks for the response. "Need" should have really been "too damn lazy to do
it myself". Looks like I'll have to do the mallocs/frees at my porting level
like you discuss. I was just kind of hoping to get this done in a day or
two. Looks like it might take a bit longer.

Thanks again,
Mike.

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


-----Original Message-----
From: Neils Nesse [ mailto:Neils.Nesse@GluonNetworks.com ]
Sent: Tuesday, April 24, 2001 6:12 PM
To: 'Michael Klock'; ecos-discuss
Subject: RE: [ECOS] 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
-------------------------------------------

Re: [ECOS] Kernel objects and eCos

[Jonathan Larmour]

Neils Nesse wrote:
> 
>     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.

It's plenty smart enough just to call malloc() and use the default heap. We
don't want to introduce that dependency by default (not all people want to
have heaps). It could well be an option (default disabled), but adding such
a feature would encourage lazy programming and increase the risk of
difficult-to-trace memory leaks. You give the rationale yourself:

> 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.

You also lose the accountability of memory usage.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] Kernel objects and eCos

[Michael Klock]

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
-------------------------------------------