DragonFly BSD
DragonFly submit List (threaded) for 2004-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [PATCH] Suggested FreeBSD merge


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 14 Nov 2004 12:47:28 -0800 (PST)

    I think we'll implement the kernel-supplied mapped library method to
    deal with htonl and friends.

    I've done some experimentation and it looks utterly trivial.  This is
    what we do:

    * Create an ELF section containing an array of function pointers.
      e.g. __section(".klib-dragonfly01") uint32_t (*htonl)(uint32_t hostlong);

      (pointers within this section would be at fixed offsets so we might
      either need some assembly to export the symbols or otherwise be very
      careful about the order in which the support code declares the lib
      functions).

    * The program would supply default functions which the kernel would then
      be able to override.  The purpose of supplying a default function is
      multi-fold:

      - for backwards compatibility.

      - so the program will still work even on kernels that do not support 
	the particular library version requested.

      - so feature(s) (whole libraries or individual functions) can be
	disabled on the kernel-side of things via sysctls.

    * The kernel detects the ELF section when the program is exec'd and 
      automatically maps the kernel-optimized override/replacement functions
      and then modifies the appropriate vectors in the ELF section.
      
      (1) maps the kernel-supplied library into user memory or uses a 
	  permanent kernel mapping that is user accessible.

      (2) Adjusts the pointers in the ELF section as appropriate to point
	  to the kernel-supplied library.

    We can use the same mechanism to implement our new system call layer.
    The ELF section name would supply the version information to the kernel
    so the kernel knows which vector set to use.  This means:

    * No more guessing about the sysvec, the kernel is told exactly which
      sysvec the user program expects.

    * Ability to implement compatibility functions or provide a mechanism
      whereby the user program itself can execute a default function which
      loads a compatibility library if the kernel cannot supply the requested
      library / syscall set.

    * Ability to abstract and optimize vectors for threaded vs non-threaded
      programs.

    * No more need to hack system call assembly for libc.  libc is able to
      take a hands-off approach and simply assume that the system call is
      available and call it through the library vector.

    * Ability to optimize system calls that can internally use a shared memory
      interface.  For example, time(), clock_gettime(), and so forth.  e.g.
      if the kernel decides that the TSC is useable it would supply a syscall
      function that just uses the TSC instruction rather then entering into 
      the kernel.

    And much, much more.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]