Re: Porting from vxworks to linux

Re: Porting from vxworks to linux

[David Brown]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

Hi:

I haven't actually played with it, but the 'MM Shared Memory Library' at
http://www.engelschall.com/sw/mm/ looks like a starting point.

According to the manual:
 "The MM library is a 2-layer abstraction library which simplifies the
  usage of shared memory between forked (and this way strongly related)
  processes under Unix platforms. On the first layer it hides all platform
  dependent implementation details (allocation and locking) when dealing
  with shared memory segments and on the second layer it provides a
  high-level malloc(3)-style API for a convenient and well known way to
  work with data-structures inside those shared memory segments."

BSD-style license and all that good stuff.

Regards,
- Dave
  dave@codewhore.org


On Thu, Mar 21, 2002 at 04:09:51PM +0530, Amol Kumar Lad wrote:
> Hi ,
>   Sorry for posting this to wrong list. But you can help me out.
> 
> I am porting some code from Vxworks to Linux (application level, not
> kernel). 
> THe problem is , in Vxworks as there is a single address space so a 'malloc'
> done by one process is visible to other process also, i.e. all the global
> data is shared in Vxworks across processes.
> 
> This is not true in linux, as every process has its own address space. 
> What could be done so that I can use same 'malloc' like interface and have
> all my 'global data'
> shared across process. 
> 
> I can understand that i have to use shared memory for this. Is there any
> library available
> that provides me a 'malloc' type interface for shared memory.
> 
> All processes are unrelated processes ( fork -> exec)
> 
> Thanks
> Amol
> 
> -- please CC me..
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Porting from vxworks to linux

[Richard B. Johnson]

On Thu, 21 Mar 2002, David Brown wrote:

> Hi:
> 
> I haven't actually played with it, but the 'MM Shared Memory Library' at
> http://www.engelschall.com/sw/mm/ looks like a starting point.
> 
> According to the manual:
>  "The MM library is a 2-layer abstraction library which simplifies the
>   usage of shared memory between forked (and this way strongly related)
>   processes under Unix platforms. On the first layer it hides all platform
>   dependent implementation details (allocation and locking) when dealing
>   with shared memory segments and on the second layer it provides a
>   high-level malloc(3)-style API for a convenient and well known way to
>   work with data-structures inside those shared memory segments."
> 
> BSD-style license and all that good stuff.
> 
> Regards,
> - Dave
>   dave@codewhore.org
> 
> 
> On Thu, Mar 21, 2002 at 04:09:51PM +0530, Amol Kumar Lad wrote:
> > Hi ,
> >   Sorry for posting this to wrong list. But you can help me out.
> > 
> > I am porting some code from Vxworks to Linux (application level, not
> > kernel). 
> > THe problem is , in Vxworks as there is a single address space so a 'malloc'
> > done by one process is visible to other process also, i.e. all the global
> > data is shared in Vxworks across processes.
> > 
> > This is not true in linux, as every process has its own address space. 
> > What could be done so that I can use same 'malloc' like interface and have
> > all my 'global data'
> > shared across process. 
> > 
> > I can understand that i have to use shared memory for this. Is there any
> > library available
> > that provides me a 'malloc' type interface for shared memory.
> > 
> > All processes are unrelated processes ( fork -> exec)
> > 
> > Thanks
> > Amol
> > 
> > -- please CC me..
> > -


You don't need any special shared-memory library. All you need is
already present in the 'C' runtime libraries.

Basically, a task tries to attach some shared memory using a
key-word ID that you define. If it works, you get a pointer to
the existing shared memory. If it fails, your task is the
first to attempt it, so you create a shared memory area and
return a pointer. Easy. You don't use malloc() and friends
for shared memory. You use it for private memory.

If you want to contact me off-line, I can mail you a procedure
you can use as a template.

You may want to re-think a lot of stuff that was written for
VXWorks. Unix/Linux has many ways for tasks to communicate
including pipes and sockets. In many cases, shared memory is
not the way to go. Also, I note that a lot of stuff written
for linear-global address space, like VXWorks, ends up using
very poor design techniques like a big global trash-heap for
every variable. This is not the way to design something if
it needs to be tested and maintained.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.