Custom malloc/mmap for x86_64

Sat Apr 28 20:35:00 GMT 2012

Mike Frysinger <vapier@...> writes:

> On Saturday 28 April 2012 15:08:13 Daniel wrote:
> > I am writting a custom software stack for linux and adding new
> > system calls to allow programmers to exploit my
> > logic without interfering with anything else in the system.
> > I am adding a custom mmap, which works if I use the
> > system call with its NR id:
> > 
> > #define my_map 312
> > 
> > syscall(my_map, 1024*1024, 4096, 0, 0, 0, 0, 0);
> > 
> > This executes dummy code for now, but I have gotten
> > it to invoke calls at the kernel level.
> > 
> > I am trying to add a call to my_map in glibc, I creted a c file
> >  just like mmap.c, same parameters (one extra), and that
> > method gets invoked now that I use my glibc library. The problem
> >  howerver, is that I am afraid that is not the way
> > to do this. So my question is: how do I get my_map() wrapper to
> >  be build in a similar fashion as the wrapper for
> > mmap()?
> let's take a step back.  why do you want this in glibc ?  as part of your goal 
> to "exploit my logic without interfering with anything else in the system", 
> wouldn't you just create a new library for people to link against ?
> -mike

Hi Mike,

Thank you for the reply. I am building a prototype of one of my
concept papers for a demo my advisor wants to show at a conference.

We are not making too many changes at the user level (e.g., malloc), but we
are modifying the way the kernel allocates memory. We are working with
various memory technologies (e.g., NVM, DRAM, SRAMs). Each memory type
has different characteristics, so we want to allow users to tell the kernel
the type of memory they want to allocate. We are using mmap to allocate
pages, but to tell the kernel which memory type to use, we are introducing 
new flags and the logic for mmap needs to change as well as the page
allocator. The only issue we have is getting the front-end to run as expected.

To allow programers to tell the kernel what memory type to use, we need
high-level apis (e.g., malloc), which can pass these preferences to mmap down
to the page allocator. 

I am able to get things to work if I directly invoke our mmap from a simple
test program via syscall. But we really want to get our my_malloc to call
my_mmap as malloc calls mmap since the programs we will be showing
will have mixed calls to malloc and my_malloc to show that our scheme
can co-exist with off-the-shelf libraries. 

That is why I want to know how glibc generates the wrapper for mmap
so that I too can generate a wrapper for my_mmap. 

> to "exploit my logic without interfering with anything else in the system", 
> wouldn't you just create a new library for people to link against ?

I apologize, this might sound confusing, we want to allow programmers
the option of using traditional malloc and our malloc. So we will
be using the same structures, etc., malloc uses. But if a programmer who
is not aware of the library or does not care about memory types, can
still use malloc. If he cares about the memory type, then he can use our
my_malloc. We simplify things for the programmer by enhancing glibc with
our my_malloc.

More information about the Libc-help mailing list