Re: Timers and timing, was: MySQL Performance 6.0rc1

On Sat, 2005-Oct-29 00:29:10 -0700, Maxim Sobolev wrote:
>Poul-Henning Kamp wrote:
>>In message <4362BA38.1090603_at_portaone.com>, Maxim Sobolev writes:
>>>You can solve most of those issues by exporting from kernel to userland 
>>>not only page(s) with actual data, but also page(s) with code to handle 
>>>that data. Then you can turn syscalls implementation in libc into plain 
>>>function calls to addresses in that code page(s). This approach can 
>>>potentially have other interesting applications, for example it will be 
>>>possible to use processor-specific syscalls instructions without 
>>>recompiling userland, move some of the ABI code into userland (i.e. 
>>>freebsd32 layer on amd64) etc.

The data I understand - we document a struct that defines the page
contents, I'm less sure about the code.  The concept is appealing
but some more detail would be nice.

>>I'm not sure I see much difference between a shared library and this
>>solution, but I'm equally sure we'd love to se a prototype before
>>we judge it :-)
>
>Difference is that you won't have additional problems with userland and 
>kernel versions mismatch and don't need any additional complexity 
>associated with versioning/fallback logic.

I'm not sure I understand how you'll achieve this.  How would a userland
application locate the appropriate entry points?  If the exported code
looks like a automagically-mapped shared library, we'd need to embed the
ELF symbol table in the kernel as well.  How does an application compiled
for (eg) FreeBSD-6 handle the code page exported by a FreeBSD-7 kernel?

Other options would seem to be:
- hard-wire the entry-points into the application or libc (which will
  basically destroy backward/forward compatibility)
- Use explicit branch tables (ala Amiga shared libraries) - there's no
  infrastructure to support this in FreeBSD.

-- 
Peter Jeremy