Messages in this thread |  | | | From | Daniele orlandi <> | | Subject | Passing references to kobjects between userland and kernel | | Date | Wed, 14 Jun 2006 16:26:38 +0200 |
| |
Hello,
I'm trying to figure out what is the correct way to pass references to kobjects between userland and kernel space.
I have my big object hierarchy of kobjects representing a TDM interconnect graph with channels, crossconnectors, physical ports and so on. The main objects are nodes and archs; archs connect two nodes together.
The hierarchy is exported to sysfs.
From userland I want to tell the kernel "Connect node X to node Y".
The first problem is deciding what interface to use; currently I'm using an ioctl() but I'm open to suggestions.
The other issue is how to identify objects X and Y in the ioctl() request, here are the possible ways I've examined:
1- Path ------- Every kobject registered in sysfs has its own path. I can use path_lookup() and lookup the object by its kobj.dentry.
Pros: In userland it's easy to identify kobjects by their path in sysfs. The path is unambiguous and already available.
Cons: Passing the pathname to the kernel requires a big ioctl() body (theoretically at least 2*MAX_PATH using a fixed-length structure).
Doing the reverse mapping (from kernel to userspace) is not easy since you need to know from which vfsmount to generate the path with d_path().
2- Relative path ---------------- Pros: No need to consider where sysfs is mounted and would also work if the kobjects are not registeres in sysfs.
Cons: There should be specific functions to parse/generate a pathname that is specific to kobject hierarchy.
3- Unique ID ------------ A unique ID, probably a integer value can be assigned to each object.
Pros: much more compact, do not need parsing
Cons: Needs an 'id' attribute in sysfs for every object and a reverse mapping (done with symlinks?) to allow an userland application to map IDs to paths and vice-versa. Unique ID allocation needs an allocator (list, bitmap, etc) either global or for every namespace.
4- kobject's pointer ------------------ The kobject's pointer could opaquely be seen as a unique identifier. Pros: Compact, no need for storage.
Cons: Probably insane, exposes kernel internals to the userland, a developer may be tempted to deference the user-provided value directly :)
So, are there any other ways? If not, which one would be advisable among these?
Bye,
-- Daniele "Vihai" Orlandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |