Dr. Dobb's Journal - May 2008 - (Page 41)

d05gor_p3db 3/18/08 8:30 AM Page 41 File access from any user-level process User-mode access control application Database access request via exdbmod ioctrl • The kernel-mode stack is a limited storage area that is often used for information that is passed between functions, as well as for local variable storage. Running out of stack space causes the OS to crash. Therefore, the database runtime integrated with the kernel module and other drivers must watch stack usage. It must never allocate large aggregate structures on the stack, and avoid deeply nested or recursive calls. If recursion must be used, the number of recursive calls must be strictly limited. • Not all of the standard libraries (C and especially C++) are present in kernel mode. Moreover, versions of standard libraries for use in kernel mode are not necessarily the same as those in user mode, as they are written to conform to kernel-mode requirements. Kernel-mode implementations of standard libraries usually have limited functionality and are constrained by other properties of kernel mode. (The eXtremeDB-KM database runtime does not use the C runtime. For instance, instead of relying on the C runtime for memory management, the database replaces those functions with custom allocators.) File I/O ioctrl User address space eACmod — ﬁle system “ﬁlter” module exdbmod — database module File access authorization request Kernal address space In-memory database Figure 2: Sample app components. struct ACL { uint4 uid; // user id uint4 access; // access allowed for some user id }; class File { char name; // file name uint4 inode; // file inode uint4 device; // device uint4 owner; // owner of the File uint4 defaccess; vector acls; // access control lists hash hname[4096]; hash hfile[4096]; }; Sample Application To illustrate, the sample application we present here implements a basic access-control system, using eXtremeDB-KM to create and maintain the access-control database in the kernel space. The database maintains file-access rules, and the runtime provides drivers and user-level applications with high-performance access to the storage. The example code uses UNIX-like notations. The application in Figure 2 contains three major components: • The database kernel module, responsible for storage, maintains database access logic. • A user-mode application that utilizes a user-mode database API. • The “filter” or kernel module that intercepts filesystem calls and provides a file access authorization mechanism to the system. The database kernel module implements kernel-mode data storage and provides the API to manipulate the data. The module is integrated with the eXtremeDB database runtime, which is responsible for providing “standard” database functionality such as transaction control, data access coordination and locking, lookup algorithms, and the like. Example 1 presents the data layout using eXtremeDB Data Definition Language syntax. The class File describes a file object that is identified by the file’s name, and the inode and device on which it is located. The rest of the fields (owner, defaccess, and acl vector) define file-access rules. The database maintains two hash-based indices that facilitate fast data access. Because the database could grow large, the database pool is allocated in virtual memory. To use the allocated memory pool, it is mapped to the physical page (Examples 2 and 3). Once memory is allocated, the in-memory database is created and supports connections using standard database runtime functions. The module exports two types of interface: the “direct” API available to other kernel modules and drivers, and the “indirect” API that implements eXtremeDB-KM’s ioctl interface to the database module. The direct API is not available for user-mode processes, but is efficient because it maintains only kernel-space references and eliminates expensive (in performance terms) Example 1: Database schema. /* allocate the database memory pool */ mem_ua_ptr = (char*)vmalloc( arg+PAGE_SIZE*2 ); if ( mem_ua_ptr == 0 ) { return -ENOMEM; /* error allocating memory */ } Example 2: Allocating virtual memory for the database pool. May 2008 l www.ddj.com l Dr. Dobb’s Journal 41 http://www.imagix.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - May 2008

Dr. Dobb's Journal - May 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Software Development Goes to the Movies Cat: A Functional Stack-Based Little Language Mojax: Mobile Ajax Framework Kernel-Mode Databases Getting Better Search Results Effective Concurrency The Agile Edge

Dr. Dobb's Journal - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.