* Re: Porting from vxworks to linux
2002-03-21 16:40 ` Porting from vxworks to linux David Brown
@ 2002-03-21 18:07 ` Richard B. Johnson
0 siblings, 0 replies; 2+ messages in thread
From: Richard B. Johnson @ 2002-03-21 18:07 UTC (permalink / raw)
To: David Brown; +Cc: Amol Kumar Lad, linux-kernel
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.
^ permalink raw reply [flat|nested] 2+ messages in thread