> > 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
