Thread (25 messages) 25 messages, 4 authors, 2010-12-06

Re: [PATCH RFC 1/8] Introduce dynamic clock devices

flat view

From: Richard Cochran <hidden>
Date: 2010-12-04 14:55:31
Also in: lkml

On Mon, Nov 08, 2010 at 07:38:41AM +0100, Arnd Bergmann wrote:
On Thursday 04 November 2010, Richard Cochran wrote:
quoted
+struct clock_device {
+	struct file_operations fops;
+	struct file_operations *driver_fops;
+	struct clock_device_operations *ops;
+	struct cdev cdev;
+	struct kref kref;
+	struct mutex mux;
+	void *priv;
+	int index;
+	bool zombie;
+};
You should really not need the file_operations here, neither the
struct nor the pointer. Just define a static file_operations
structure containing clock_device_open and clock_device_release,
and whatever else you might need, then add the driver's operations
to clock_device_operations, and pass the clock_device pointer
directly to them, instead of passing the file/inode pointers.
Arnd, I'm working a revision of this series, and I am not sure I
understand your comment.

The intent here was to allow clock drivers to register a character
device through the clock_device API, since some clocks (hpet, rtc)
already offer a chardev interface.

The same FD from the open character device will also be usable as a
clockid for the generic posix clock_get/settime calls. Thus, the
clock_device layer needs to hook into the file open/release functions.

Are you suggesting that I simply offer all of the functions from a
'struct file_operations' (sans file/inode) in the 'struct
clock_device_operations' too?

I wanted to avoid duplicating the file_operations functions, so that
future changes in those functions would automatically trickle down to
the clock drivers.

Thanks,
Richard
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help