public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* device model and character devices
@ 2006-04-04  8:12 Artem B. Bityutskiy
  2006-04-04 16:48 ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Artem B. Bityutskiy @ 2006-04-04  8:12 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel

Hello Greg,

at the moment the device model and the character devices subsystem are 
distinct and different things. I mean, if I have a device xdev, I do the 
following:

struct xdev_device {
	struct cdev cdev;
	struct device dev;
	/* xdev-specific stuff */
	...
} xdev;

I use xdev.cdev to register character device:

cdev_add(&xdev.cdev, ...);
...

I use xdev.dev functions to include my device to the device-model:

device_register(&xdev.dev, ...);
...

But why not to merge the character device stuff and the device model? 
Roughly speaking, why not to embed 'struct cdev' to 'struct device'? Why 
do driver writers have to distinguish between these things?

Thanks.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

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

* Re: device model and character devices
  2006-04-04  8:12 device model and character devices Artem B. Bityutskiy
@ 2006-04-04 16:48 ` Greg KH
  2006-04-05  7:52   ` Artem B. Bityutskiy
  0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2006-04-04 16:48 UTC (permalink / raw)
  To: Artem B. Bityutskiy; +Cc: linux-kernel

On Tue, Apr 04, 2006 at 12:12:31PM +0400, Artem B. Bityutskiy wrote:
> Hello Greg,
> 
> at the moment the device model and the character devices subsystem are 
> distinct and different things. I mean, if I have a device xdev, I do the 
> following:
> 
> struct xdev_device {
> 	struct cdev cdev;
> 	struct device dev;
> 	/* xdev-specific stuff */
> 	...
> } xdev;
> 
> I use xdev.cdev to register character device:
> 
> cdev_add(&xdev.cdev, ...);
> ...
> 
> I use xdev.dev functions to include my device to the device-model:
> 
> device_register(&xdev.dev, ...);
> ...
> 
> But why not to merge the character device stuff and the device model? 
> Roughly speaking, why not to embed 'struct cdev' to 'struct device'? Why 
> do driver writers have to distinguish between these things?

Because "struct device" generally is not related to a major:minor pair
at all.  That is what a struct class_device is for.  Lots of struct
device users have nothing to do with a char device, and some have
multiple char devices associated with a single struct device.

You need to create a struct class_device in order to export the proper
information to userspace so that udev and other tools can pick up the
fact that your device is present and it needs to create a device for it.

All that being said, yes, there is a disconnect between the driver model
parts and the char subsystem.  It's been something that I've wanted to
fix for a number of years, but never had the time to do so.  If you want
to work toward doing this, I'd be glad to review any patches.

thanks,

greg k-h

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

* Re: device model and character devices
  2006-04-04 16:48 ` Greg KH
@ 2006-04-05  7:52   ` Artem B. Bityutskiy
  2006-04-05 18:31     ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Artem B. Bityutskiy @ 2006-04-05  7:52 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel

Greg KH wrote:
> Because "struct device" generally is not related to a major:minor pair
> at all.  That is what a struct class_device is for.  Lots of struct
> device users have nothing to do with a char device, and some have
> multiple char devices associated with a single struct device.
Well, OK, but AFAIK, your long-term plan is to merge class_device and 
device, so in the long-term perspective it does not matter. And those 
who do not need a character device support may have a possibility to 
disable it.

> All that being said, yes, there is a disconnect between the driver model
> parts and the char subsystem.  It's been something that I've wanted to
> fix for a number of years, but never had the time to do so.  If you want
> to work toward doing this, I'd be glad to review any patches.
Will see. At this point my knowledge and understanding is not so deep, 
so I don't think I'm able to provide decent patches. May be in future. 
For now I'm only wondering.

Thanks.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

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

* Re: device model and character devices
  2006-04-05  7:52   ` Artem B. Bityutskiy
@ 2006-04-05 18:31     ` Greg KH
  0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2006-04-05 18:31 UTC (permalink / raw)
  To: Artem B. Bityutskiy; +Cc: linux-kernel

On Wed, Apr 05, 2006 at 11:52:57AM +0400, Artem B. Bityutskiy wrote:
> Greg KH wrote:
> >Because "struct device" generally is not related to a major:minor pair
> >at all.  That is what a struct class_device is for.  Lots of struct
> >device users have nothing to do with a char device, and some have
> >multiple char devices associated with a single struct device.
> Well, OK, but AFAIK, your long-term plan is to merge class_device and 
> device, so in the long-term perspective it does not matter. And those 
> who do not need a character device support may have a possibility to 
> disable it.

Yes, that's my goal in the long term, and I have a patch availble that
starts to do that:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-class.patch

but we have a lot of work to get there.

And even then, a struct device will be separate from a char device.  For
one example, the cdev structure is used by the kernel to look up the
device properly, which has nothing to do with struct device (or struct
class_device) at all at this time.

thanks,

greg k-h

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

end of thread, other threads:[~2006-04-05 18:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-04  8:12 device model and character devices Artem B. Bityutskiy
2006-04-04 16:48 ` Greg KH
2006-04-05  7:52   ` Artem B. Bityutskiy
2006-04-05 18:31     ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox