Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Mon, 18 Sep 2000 14:52:48 +0100 | From | David Howells <> |
| |
> > 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.
Agreed.
> 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 heavyweight.
> 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.
Agreed.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |