All of lore.kernel.org
 help / color / mirror / Atom feed
* Passing references to kobjects between userland and kernel
@ 2006-06-14 14:26 Daniele orlandi
  2006-06-16 23:58 ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Daniele orlandi @ 2006-06-14 14:26 UTC (permalink / raw)
  To: linux-kernel


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-06-20  7:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-14 14:26 Passing references to kobjects between userland and kernel Daniele orlandi
2006-06-16 23:58 ` Greg KH
2006-06-19 23:48   ` Daniele Orlandi
2006-06-19 23:53     ` Greg KH
2006-06-20  7:17       ` Daniele Orlandi

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.