Passing references to kobjects between userland and kernel

[Daniele orlandi <daniele@orlandi.com>]

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