[lkml]   [2006]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectPassing references to kobjects between userland and kernel


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


Daniele "Vihai" Orlandi
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-14 16:30    [W:0.087 / U:0.224 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site