Re: The disappearing sys_call_table export.

[Terje Eggestad]

On Tue, 2003-05-06 at 11:21, Eric W. Biederman wrote:
> Terje Eggestad <[e-mail]> writes:
> 
> > 
> > > I believe the answer on how to do a clean safe interface is
> > > to allocate the memory and tell the card about it in the driver,
> > > and then allow user space to mmap it.  With the driver mmap operation
> > > informing the network card of the mapping.
> > > 
> > 
> > You can't mmap() a buffer every time your going to do a send/recv, it's
> > way to costly. 
> 
> Definitely not.  But if the memory malloc returns is originally
> from a mmaped buffer area (mmaped from your driver) it can be useful.
> I assume somewhere your card has the smarts to transform virtual to
> physical addresses and this is what the mmap sets up.
> 

The problem I've got happen when an app registers the memory with the
driver, releases the memory back to the kernel thru sbrk(-n) or
munmap()s it. Then get new memory thru sbrk(+n) or mmap() which then get
the same vaddr. 

mapping from vaddr to phys addr happen at the registration point. 

Querying the kernel for a vaddrs  phys addr every time it's used is too
costly. There is a better explanantion in a earlier post. 

> That can be handled in user space by querying the mmaped region.  But
> if the card does not have the smarts to do the virtual to physical
> translation, or at the very least limit the set of physical pages a
> user space a do DMA to/from that is a fundamental security issue and
> means all of the optimizations are not safe.  And you must enter/exit
> the kernel to send a DMA transaction.
> 

send/recv don't need kernel interaction on high perf interconnects. 

> > The two used approaches are 1) replace malloc() and friends, which break
> > with fortran 90 compilers 2) tell glibc never to release alloced memory
> > thru sbrk(-n) or munmap() which also break with f90 compilers, and run
> > the risk of bloating memory usage. 
> 
> Actually there is a third.  Hack the vm layer and require a highly
> patched kernel.  That is the approach quadrics was using last time I
> looked although they promised something different in their next major
> rev.
> 
> Is it pgi or intels f90 compilers that break, and how do they break.
> Replacing malloc and friends should be well defined if you simply
> replace or wrap the symbols glibc provides.
> 
> Quite possibly the answer is to call those compilers ABI
> non-conformant and get them fixed.  Especially given that they are not
> compatible with g77 in fortran mode there is a good case for this.  By
> default the native compiler is correct. 
> 
> So far the only fortran issues I have seen that could affect malloc
> are adding extra under scores.  What issue are you running into?
> 

Some don't use (g)libc, but do syscalls directly.

> 
> Eric
-- 
_________________________________________________________________________

Terje Eggestad                  mailto:[e-mail]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    [phone] (OFFICE)
P.O.Box 150, Oppsal                     [phone]  (MOBILE)
N-0619 Oslo                     fax:    [phone]
NORWAY            
_________________________________________________________________________