WineFS Proposal

In order to reduce the frequency of wineserver calls, as well as to simplify certain operations on NT kernel objects, it is proposed that a Linux kernel module be developed that supports the following NT kernel objects:

Handles

Description

In order for a process to use an object, it must possess a handle to it. Handles are valid within the context of a single process. (Threads share the handle table.)

Handles can be transferred from one process to another by using DuplicateHandle.

Implementation

NT handles will be implemented as file descriptors. The NT handle table will be implemented using the unix file descriptor table.

DuplicateHandle will not be supported directly. Process that wish to transfer file descriptors can do so by sending them over a unix socket or by opening the other process's fds directly in /proc.

Namespace

Description

Mutexes, events, semaphores and waitable timers can optionally be given names when they are created. Threads and processes have a name (a TID or PID) assigned by the NT kernel.

Those objects that are named can be opened later by using the appropriate per-object-type open function.

Mutexes, events, semaphores and waitable timers share a single namespace. I believe that threads and processes also share a single namespace among the two of them. (Window Terminal Server has the concept of global and local object names, but that will not be supported here.)

When the last handle referring to a mutex, event, semaphore or waitable timer is closed, the object and its name are deleted. Process and thread objects stay alive as long as there is an open handle, the process has at least on live thread object, or the thread is still running.

Implementation

WineFS will provide a filesystem that will implement the namespaces. Each object type will have its own directory containing the named objects of that type. (Anonymous objects will not be represented in the filesystem.)

Security

Description

Implementation

No support for NT security. (Unix UID/GID security instead.) (Except for inheritability of handles.)

Synchronisation

Description

WFSO can wait for the following objects: change notification (not supported), console input (not supported), events (supported), jobs (not supported), mutex (supported), processes (supported), semaphores (supported), threads (supported), waitable timers (supported). (CE does not support semaphores, change notification, console input or timers. (Or jobs presumably?))

Implementation

WFMO's AND semantics will be handled by providing another object (anonymous only) that takes a list of file descriptors, and successfully polls only when all those file descriptors successfully poll. (This object will have to detect which descriptors are for CreateProcess can refrain from inheriting inheritable handles. This will have to be handled in user space.
Andrew Lewycky
Last modified: Thu Nov 29 19:21:35 EST 2001 Relevant APIs: CancelWaitableTimer CreateWaitableTimer OpenWaitableTimer SetWaitableTimer CreateEvent OpenEvent PulseEvent ResetEvent SetEvent CreateMutex OpenMutex ReleaseMutex CreateSemaphore OpenSemaphore ReleaseSemaphore MsgWaitForMultipleObjects MsgWaitForMultipleObjectsEx SignalObjectAndWait WaitForMultipleObjects WaitForMultipleObjectsEx WaitForSingleObject WaitForSingleObjectsEx DebugActiveProcess? OpenProcess GetCurrentProcess? GetCurrentProcessId? GetExitCodeProcess TerminateProcess? WaitForInputIdle? ReadProcessMemory WriteProcessMemory FlushInstructionCache? ContinueDebugEvent? ResumeThread? SuspendThread? TerminateThread? GetThreadSelectorEntry? GetThreadContext? SetThreadContext? Irrelevant APIs: DeleteCriticalSection, EnterCriticalSection, GetOverlappedResult InitializeCriticalSection InitializeCriticalSectionAndSpinCount Interlocked* LeaveCriticalSection QueueUserAPC SetCriticalSectionSpinCount TimerAPCProc TryEnterCriticalSection (Overlapped IO and APCs are outside the scope of this module. Critical sections can be implemented without kernel support. Interlocked operations can be implemented without kernel support.)