Alexandre Julliard wrote:
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
Basically event, mutex, section, timer, etc can go there with minor
changes to code. Named pipes, mail slots and winstations with desktops
are a bit different. They have their own name space, that I'm planning on
using current namespace mechanism for. With the sample code I've sent to
you some days ago to show how that would work with named pipes.
find_object_dir worked perfectly on named pipes. The problem is object
creation. Actually not a creation itself, but insertion into the local
name space. I need to call different functions to insert an object into
directory or local name space (struct namespace). To do that I will need
to know what object type are we creating and what object type is the
parent.
Sorry, but that's wrong. You should *never* check the object type
explicitly. You need a generic function to insert an object into a
directory, and a generic directory type that can implement the various
types of directories.
I think there is a bit of a communication problem here. Vitaliy isn't
proposing different types of directories. There will only every be one
type - one that holds zero or more objects of any type. I also don't see
any problem with what Vitaliy is doing with the object ops. Am I right
in think this function is the one that you are commenting on:
+/* open a new handle to an existing object */
+obj_handle_t open_object_dir( const struct object_attr *attr, const struct
object_ops *ops,
+ unsigned int access )
+{
+ obj_handle_t handle = 0;
+ struct unicode_str name_left;
+ struct object *obj;
+
+ if ((obj = find_object_dir( attr, &name_left )))
+ {
+ if (name_left.len) /* not fully parsed */
+ set_error( STATUS_OBJECT_PATH_NOT_FOUND );
+ else if (ops && obj->ops != ops)
+ set_error( STATUS_OBJECT_TYPE_MISMATCH );
+ else
+ handle = alloc_handle( current->process, obj, access, attr->attributes
& OBJ_INHERIT );
+
+ release_object( obj );
+ free_unicode_str( &name_left );
+ }
+ return handle;
+}
If so, I don't see much of a problem with it. Maybe we shouldn't return
a handle, but instead return a "struct object *" or a "void *", but
passing in struct object_ops * into the function isn't doing anything
other than eliminating common code in most of the objects. It doesn't
force anything to be exported outside of the implementation of the object.
--
Rob Shearman
