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

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/

\
 
 \ /
  Last update: 2006-06-14 16:30    [W:0.101 / U:0.072 seconds]
©2003-2011 Jasper Spaans. Advertise on this site