[uClibc] mmaps for malloc should be private

David McCullough davidm at snapgear.com
Thu Apr 1 02:05:50 UTC 2004


Jivin David Howells lays it down ...
> 
> > > To make this work, uClinux's mmap() support had to be changed to work more
> > > like that on MMU linux. To summarise the way nommu mmap() works in our
> > > kernel:
> > > 
> 
> > >  (*) no file, MAP_PRIVATE: mapping shared over clone() or vfork(),
> > >	 discarded by execve().
> > > 
> > >  (*) no file, MAP_SHARED: shared over clone() or vfork(), discarded by
> > >      execve().
> > ...
> > >  (*) file, MAP_SHARED, PROT_WRITE: not supported; it would be hard to
> > >	 reflect changes to memory into the file.
> > ...
> 
> I've improved things here a little. If the file being mmapped is a chardev,
> then we do actually allow shared-writable mmaps, and the chardev driver can
> either propose a specific address at which to create the mapping (/dev/fb0
> perhaps) or can allow any old address (/dev/zero).

Sounds fine.

> With chardevs, MAP_FIXED is permitted, but currently the chardev's mmap method
> must verify that the address is valid. I should possibly reject mappings fixed
> to an address in RAM before the chardev driver sees them. I'm not sure
> though. Any thoughts?

I think it should be rejected,  to date I have yet to see a driver/HW
combo that can map something to an arbitary address (though I know there
are cases where it could be done).  I think mapping to a user process
address is just bad practice.  Better to have the kernel allocate it and
then return that address for the application to use IMO.  Which is also
how current uClinux/mmap drivers are working IIRC.

> > It doesn't.  Thus,  I think we need to have a config option in uClibc
> > to handle the current limited uClinux versions.
> 
> MAP_SHARED of MAP_ANON memory works identically to MAP_PRIVATE of MAP_ANON on
> uClinux, it's just that when you try and run it on vmlinux, where fork() may
> be an issue that it's a problem.
> 
> Of course, uClibc could always try MAP_PRIVATE first, and if that doesn't
> work, make a note in a variable to only try MAP_SHARED in future.


Sounds perfect,  no config option and still working is better :-)


> > All of this sounds pretty neat and I am sure a lot of people would like
> > to see this added to uClinux.  Do you guys base anything off the uClinux.org
> > sources ?  What kernel version are you at ?
> 
> We're currently based on linux-2.4.24-uc0 or similar downloaded from the
> uclinux.org website.

Neat,  so it's not too old.  A lot of ports lag behind and it's just a
major pain to merge them in.

> > It might be nice to try and get your support for frv (and all the other
> > general purpose bits) included into the source on uClinux.org ;-)
> 
> Yes.

Not sure it you to get any approvals etc and I understand if you do, but,
anytime you want, send in a patch (against current uclinux.org CVS is the
preferred :-) and we can get it merged,

Cheers,
Davidm

-- 
David McCullough, davidm at snapgear.com  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org


More information about the uClibc mailing list