Re: Kernel -> user boundary
Re: Kernel -> user boundary
- Subject: Re: Kernel -> user boundary
- From: George André <email@hidden>
- Date: Tue, 28 Jan 2003 17:41:05 +0100
- Organization: Intelligraphics, Inc.
Umesh Vaishampayan wrote:
Sigh. I'm not even going to ask why :-(
File renaming depending on file contents. Customer requirement.
Therefore I can only do this at VOP_CLOSE time or later, since
that's when I know about the file contents.
Hope you grab all the necessary vnode locks in correct locking order, yes?
Yeh, I guess so, I've took the kernel implementation of rename()
syscall and changed it to fit my needs and it works correctly (called
from inside my VOP_CLOSE. The other one of my solutions was to defer
this renaming till a VOP_GETATTR was received on "", but my
rename-wannabe panicked inside namei() (lockmgr: locking against myself)
Obviously a recursive lock which I spent time debugging, but couldn't
figure out exactly which one it was. That's why I wanted to try a user
process approach quickly to see if it's feasible that way before I come
back to this.
Yes you do get called. You should still get a VOP_LOOKUP() call
chmod() -> namei() -> lookup() -> VOP_LOOKUP().
Humm, yes, you're absolutely right, I missed this one.
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?
Not too long so that user starts messing with the file and not too short
so that the user process renames the file before the Finder calls
chmod/chown. Also, all operations would be blocked till the rename was
done.. (except VOP_REMOVE, LOOKUP and related..)
Why can't you do what you want to do in *your* VOP_INACTIVE?
Here you lost me, honestly. As far as I know, VOP_INACTIVE is called
when a vnode is not active, but even so, are you proposing to fake
vnodes for a period of time or something like that? PLease elucidate...
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.
As said, the user process approach is an alternative to the in-kernel
VOP_GETATTR on filename "". Both approaches are kind of shaky IMHO,
so please, if you know of a better solution (in-kernel or not) I would
be glad to hear about it. All I want to do is rename a vnode at or after
VOP_CLOSE... (I do know the name/path of the file to rename).
Thanks,
George.
--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 | email@hidden
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.