[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9912.0. "mmap, mmap, whose got mmap?" by NNTPD::"[email protected]" (John McDonald) Wed May 21 1997 15:07

I'm trying to get a better understanding of the source code to help
me when I do crash dump analysis, and I'm a bit confused about
something. Could someone tell me what file the kernel routine
mmap() is in? The libc call xlates into an assembly language
syscall to mmap(), but all I can find in the kernel code is
smmap() and mmmap(). I can't find any translation from mmap()
to either one of those either.

Any pointers would be appreciated.

John McDonald
Atlanta CSC

[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name		DateLines
9912.1smmap() in bsd/kern_mman.cRHETT::PARKERWed May 21 1997 15:2610
    
    Hi, John.
    
    It's in kern_mman.c and it's smmap(). Now, I hope you don't have
    a lot more questions about it because I'm not an expert! :-)
    
    Hope this helps!
    
    Lee
9912.2Thanx.NNTPD::"[email protected]"John McDonaldWed May 21 1997 15:498
thanx, Lee - I should have asked you first!

Actually, do you know how the mmap() in the libc gets xlated into
smmap()? It's not a big deal, but I hate not knowing.

John

[Posted by WWW Notes gateway]
9912.3First guess :-)RHETT::PARKERWed May 21 1997 16:1128
    
    Hi, John. 
    
    Well, I think it switches through spec_vnops.c - the spec_mmap()
    routine. Since it could be a driver's mmap instead of the
    sysdev_mmap().
    
    From vfs/spec_vnops.c :
    
    spec_mmap(register struct vnode *vp,
    
    ....
    
            if (vp->v_type != VCHR) return ENODEV;
            ap->a_mapfunc = cdevsw[major(vp->v_rdev)].d_mmap;
    
    If it's the system call (not a driver's mmap rtn) it will find :
    
    { sysdev_open,  sysdev_close,   nodev,          nodev,      /*15*/
            nodev,          nodev,          nulldev,        0,
            nodev,          sysdev_mmap,    DEV_FUNNEL_NULL, NULL, NULL },
     
    in cdevsw[] / devsw[] or something like that. I'm sure someone will
    correct me if I'm a little off here! ;-)
    
    Hope this helps!
    
    Lee
9912.4I forgot the first partRHETT::PARKERWed May 21 1997 17:0913
    
    Hi, John.
    
    I looked into it a little more - since it's a syscall, # 71, it
    switches through the syscall_sw.c & syscall_subr.c - routine
    map_fd(), which winds up calling smmap(). This happens before
    the htg(honest to god)_unix_syscall() stuff. That's about as far
    as I can (wanna) take it! :-) htg
    
    Hth, 
    
    Lee
9912.5SMURF::SCOTTWed May 21 1997 18:2314
Perhaps this will help. 

Your mmap call gets translated in libc to SYS_mmap, which is 71.  The 71st
entry in the syscall table references the function which is actually named
"smmap".  (See init_sysent.c, which is a file generated at kernel build
time, based on syscalls.master.)

  (dbx) sysent[71].sy_call/i
    [smmap:590, 0xfffffc0000262ef0]       lda     r16, 16383(r31)

The entries in syscall_sw.c are actually for mach traps.


Hope this helps.
9912.6Crystal clear now!RHETT::PARKERThu May 22 1997 09:1623
    
    Thanks Larry, that does help clear it up for me at least. I was
    kinda fuzzy on the syscall switch stuff and the mach factor makes
    it a little harder to follow. 
    
    I also didn't know that the init_sysent.c gets generated at build
    time based on syscalls.master - cool!
    
    Should have looked at the Makefile :
    
    init_sysent.c syscalls.c syscall.h: conf/makesyscalls.ksh \
                    conf/syscalls.master
            ksh conf/makesyscalls.ksh \
                    -hk . conf/syscalls.master
            rm -f ../include/sys/syscall.h
            mv ./syscall.h ../include/sys/syscall.h
    
    That's really good to know.
    
    Thanks, 
    
    Lee
9912.7Thanx...NNTPD::"[email protected]"John McDonaldThu May 22 1997 13:117
Thanx for all of the info. It's been a while and the system call
switching completely slipped my mind. Thanx for all the info.

John McDonald
Atlanta CSC

[Posted by WWW Notes gateway]