On Monday, January 27, 2003, at 03:30 PM, George Andri wrote: Hi Godfrey, My problem starts inside msdosfs.kext, which is my kext. I've changed this kext to rename certain files when created. Sigh. I'm not even going to ask why :-( (when the filesystem receives close op). Using NDINIT/namei/VOP_RENAME works ok Hope you grab all the necessary vnode locks in correct locking order, yes? and does what it's supposed to, but the problems come from the following chown/chmod syscalls from the Finder. Finder does that last on a file drag & copy operation. Problem is that since I've changed the name, chown and chmod fail inside their kernel implementations and never get down to me... Yes you do get called. You should still get a VOP_LOOKUP() call chmod() -> namei() -> lookup() -> VOP_LOOKUP(). Thus, our friend the Finder puts up a nice dialog about not finding the files. One of my solutions is to send the path name to the user process and it will do the rename itself and thus defer this task. How long do you plan to "defer" this task? How do you plan to avoid that users process racing the Finder and renaming the file before Finder gets around calling chmod? How do you know others are really done using this file? Why can't you do what you want to do in *your* VOP_INACTIVE? I'm currently working on this approach: the user proc allocates mem with vm_allocate(), the it uses mach_make_memory_entry_64() and then sends the ipc_port_t to the kext thru mount args. (user proc is actually spawned by mount_msdos). This allocated memory is then vm_mapped by > the kext and there you go... memory sharing. Is this approach something that will work, or am I out chasing rabbits? Thanks, George. Why shared memory between kernel and user process? Is this going to be used to move lots of data? Seems like wrong things to do [at least to me]. But then again without knowing what you are trying to do, it's impossible to say. --Umesh Godfrey van der Linden wrote: At 21:09 +0100 03-1-27, George Andri wrote: Hi there, I am aware of user -> kernel boundary crossing, like Mach IPC, RPC, syscall, sysctl and ioctl. But I'm interested ina kernel -> user *initiated* connection, is there anything outthere? I have a kext that needs to initiate communication with an user process. I can alternatively let the user process initiate the connection in one of the above ways and then pass a data pool pointer, but that would be a lot harder. IS there anything I can do or use to initiate a kernel -> user crossing without user parts help? Not really. Do you have a user land app that you are talking to? If so it is pretty easy to emulate a kernel initiated event. What do you want to happen in user land when the kernel hits something. I guess what I'm asking is what problem are you actually trying to solve. Godfrey van der Linden _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. -- Umesh Vaishampayan Mac OS X - Kernel _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.