1 / 22

An Extensible Choices System Interface

An Extensible Choices System Interface. Adam Boot, Weihang Jiang, Manlap Li, Rodolfo Pellizzoni, Enzhou Wang CS 523 Spring, 2006. Motivation. Choices in the beginning of semester… only runs assembly programs many sys objs, many constants to look up single-threaded programs only. Outline.

ulema
Download Presentation

An Extensible Choices System Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Extensible Choices System Interface Adam Boot, Weihang Jiang, Manlap Li, Rodolfo Pellizzoni, Enzhou Wang CS 523 Spring, 2006

  2. Motivation • Choices in the beginning of semester… • only runs assembly programs • many sys objs, many constants to look up • single-threaded programs only

  3. Outline • Proxies & Automatic Generation • Multithreading • Conclusion • Future Work

  4. Original Implementation • Export proxy classes to application space • Automatically generated by a C++ preprocessor program • Proxy methods invoked in application space trap into the kernel • Kernel dispatcher catches the call and executes the appropriate method

  5. Application Kernel Trap System Call Application Proxy Kernel Dispatcher Kernel Method

  6. Problems • Implementation was not only machine-dependent, but also compiler-dependent • Currently does not work due to compiler changes • Allowed system calls using application defined subclasses • The kernel makes calls into application defined code • We feel this is unnecessary, potentially dangerous, and bad for performance

  7. Our Implementation • Provides the same proxy and dispatcher mechanism • Does not allow subclasses to trap inside the kernel • Use an IDL compiler to generate the proxies and dispatchers • Midterm prototype interface was hand coded • Not maintainable • Repetitive to code

  8. Benefits of IDL • Compiler-independent • Allows a language-independent description of the interface • Extensible and maintainable • Automatically generate code based on kernel classes • Classes that inherit from 'ProxiableObject‘ • Methods that are marked 'proxiable' • Can fairly easily produce a system interface library for other languages

  9. Benefits of Our Design • No machine-dependent kernel code and limited amount in application code • Performance: No parameters need to be copied from application to kernel • Security: Kernel detects errors in system calls and passes exceptions back to application • Automatic garbage collection of kernel objects

  10. Tools and Design • CORBA compliant IDL compiler from omniORB • Free, licensed under GPL • Easily extensible using C++ and Python to create back-end modules for code generation • Python back-ends for the IDL compiler to produce application proxies and kernel dispatchers • Python application to parse kernel header files to produce an IDL specification file

  11. Choices Kernel Header Files IDL Specification File Parser Application Proxies OmniIDL Compiler Application Back-End Kernel Dispatchers Kernel Back-End

  12. Generated Code • Application Library Headers • Mirror the kernel classes and methods • Application Proxies • Places parameters in registers • Causes appropriate software interrupt • Retrieves return value from register • Kernel Dispatchers • Retrieve pointer to the correct kernel object • Unmarshall input parameters • Make actual system call • Marshall the return value

  13. IDL Demo

  14. Multithreading Overview • Thread lib resembles Java Thread • Relies on exceptions for error handling • Implemented inside sys lib instead of kernel

  15. Thread Class Run(): Main function for threads. Automatically called when Start is called. class Thread { public: Thread(); virtual ~Thread(); virtual void Run()=0; void Start(); void Join(); … private: AppProc *AppProcObj; … }; Start(): Puts the thread into ready queue. Join(): Returns to caller when this thread finishes. AppProcObj: Kernel object that makes threading possible.

  16. Thread Implementation • Rely on calls to IDL-gen’ed AppProc Obj class Thread { public: Thread(); void Start(); void Join(); … }; Application Process Obj Proxy Kernel Dispatcher User Kernel

  17. POSIX vs. Choices (1 of 2) void *thread_work(void *args) { // cast args to input struct // unpack args } int main() { for (i=0;i<N;i++){ // pack thread args into t_args pthread_create(…,thread_work, t_args); } } class MyThread : public Thread { MyThread(arg1, …, argM); void Run() { //Similar to thread_work } } int main() { MyThread *thrds[N]; for (i=0;i<N;i++){ thrds[N]=new MyThread(arg1, …, argM); } for (i=0;i<N;i++){ thrds[N].Start(); } } POSIX Choices

  18. POSIX vs. Choices (2 of 2) • POSIX Threads • Requires packing of args before creation • Requires unpacking of args in thread function • New thread is run right away • Choices Threads • Object-Oriented • Subclass of subclass of… threads • Args are attributes, no (un)packing • Separation of thread creation and scheduling

  19. Multithread Demo

  20. Conclusion • Compared with beginning of semester • Able to compile C++ program to run on Choices • Able to run multithreaded programs • Able to automate the system interface generation

  21. Future Work • General Exceptions: Currently have a limited number of specific exceptions that can be passed from kernel to application • Performance Measurements: Test system calls on OMAP board, currently only working in Qemu

  22. Thanks! Questions? cs523@googlegroups.com

More Related