[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Wine speedup through kernel module

> > At the moment, the Win32 syscalls I implement require an fd to be
> > attached to a particular proc file. This fd holds the Win32 handle map.
> Huh?

Each process needs a handle map... To avoid playing with the task structure,
fork, exec, exit, signals, etc., I used an fd attached to a proc file to keep
track of the handle map (it gives me reference counting, module tracking, and
auto-cleanup on process death).

The handle map page is just attached to the private data pointer on the struct
file. It was just convenient for starting the whole thing off.

> > There are other ways to make sure the module doesn't go away, for
> > instance using personalities, but I still need to maintain the
> > refcount on the handle map fd.
> Please don't mess with personalities. I intend to use any useful
> Win32 or NT-native features in Linux software. Personalities
> would make these calls only useful for Wine.


> If a Win32 handle can be though of as a file descripter,
> then just do that. You can invent new file types and new
> filesystems as needed. These are available:
> 0x3000 0030000
> 0x5000 0050000
> 0x7000 0070000
> 0x9000 0110000
> 0xb000 0130000

I was trying to avoid using file/inode/dentry structs as much as
possible... they aren't really necessary for most of this, and are very

> If that isn't right, add a CLONE_HANDLES flag for clone() and
> add a fd-like table hanging off the task struct. Go all the way,
> rather than leaving these features as second-class citizens.

I have thought of separating the code in to separate lumps:

(1) An in-kernel resident lump, providing very basic services:

* handle/handle-map management
* object management
* some object types
* process death-knell notification
* file-change notification
* unicode string handling/conversion (steal/share from NTFS)
* simple RPC mechanism for building certain services in userspace
* Win32 syscall stub
* int 0x2e stub
* /proc view

(2) A partial basic Win32 implementation (modulable):

* basic Win32 syscalls, eg: CreateMutexA/W
* _no_ GDI calls

(3) A partial basic Native API implementation (modulable):

* basic NT syscalls
* again, no GDI calls

(4) A userspace registry service, communicating with registry stubs in the
kernel by the simple RPC mechanism.

> I'd rather not have kernel code that is _only_ good for Win32.
> I don't see much reason to have a nasty add-on that can't be
> used by regular Linux programs.


The question is, how much will Linux go for?

David Howells
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.032 / U:1.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site