[Xenomai-core] RTDM problems with structures in headers

[Xenomai-core] RTDM problems with structures in headers

[NZG]

Background
-------------------------
I'm developing an rtdm for some simple io inside a PLD.
This io is detected by a standard linux driver and used to register kobject 
classes in the main driver.
This in turn results in the registration of a named rtdm driver with the same 
name as the class, which calls down into the classes standard low level 
methods using and RTDM atomic lock around the actual memory mapped 
manipulation.
In this way I hope to create a standard, kernel detected,  interface to 
standard user space and rtdm for simple io devices.

The RTDM device has no "private data" pointer for pointing to outside data 
structures. I would like to avoid modifying it's basic structure to maintain 
compatibility with future releases, and in general to avoid modifying the 
real time core whenever possible.

To get around I have an rtdm device inside the standard class structure, and 
then use the 2.6 "container of" macro from the rtdm driver to get access to 
the original class.  

Problems 
-------------------------
Placing the rtd device inside the standard structure results in the need to 
add extra flags (-Iinclude/xenomai) to every Makefile which contains a device 
including the header file reference to xenomai in it.

Question
------------------------
Essentially, what is the recommended way to:

Pass pointers to a rtdm driver from regular kernel space, which can be 
maintained into the rtdm fops (without resorting to global variables).

Allowing for the assumption that the standard kernel process holding the data 
is responsible for registering the real time driver.

thx,
NZG

Re: [Xenomai-core] RTDM problems with structures in headers

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

NZG wrote:
> Background
> -------------------------
> I'm developing an rtdm for some simple io inside a PLD.
> This io is detected by a standard linux driver and used to register kobject 
> classes in the main driver.
> This in turn results in the registration of a named rtdm driver with the same 
> name as the class, which calls down into the classes standard low level 
> methods using and RTDM atomic lock around the actual memory mapped 
> manipulation.
> In this way I hope to create a standard, kernel detected,  interface to 
> standard user space and rtdm for simple io devices.
> 
> The RTDM device has no "private data" pointer for pointing to outside data 
> structures. I would like to avoid modifying it's basic structure to maintain 
> compatibility with future releases, and in general to avoid modifying the 
> real time core whenever possible.
> 
> To get around I have an rtdm device inside the standard class structure, and 
> then use the 2.6 "container of" macro from the rtdm driver to get access to 
> the original class.  
> 
> Problems 
> -------------------------
> Placing the rtd device inside the standard structure results in the need to 
> add extra flags (-Iinclude/xenomai) to every Makefile which contains a device 
> including the header file reference to xenomai in it.
> 
> Question
> ------------------------
> Essentially, what is the recommended way to:
> 
> Pass pointers to a rtdm driver from regular kernel space, which can be 
> maintained into the rtdm fops (without resorting to global variables).
> 
> Allowing for the assumption that the standard kernel process holding the data 
> is responsible for registering the real time driver.

Not claiming that I fully understood your problem yet - code talks:

What about putting the rtdm_device and your standard device structure
into a "meta" structure. The type of the latter then only has be known
to those parts that access data "across" the two structure.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] RTDM problems with structures in headers

[NZG]

> Not claiming that I fully understood your problem yet - code talks:
From your recommendation think you got the jist of it.

here's the problematic parts:

/**********************
 * gpio class structure
 */
typedef struct gpio_s{
	const char *name;
	int subclass;
	void *ddr;
	void *data;
	gpio_data shadow;
	gpio_data (*data_read)(struct gpio_s *gpio);
	int (*data_write)(struct gpio_s *gpio,gpio_data data);
	gpio_data (*ddr_read)(struct gpio_s *gpio);	
	int (*ddr_write)(struct gpio_s *gpio,gpio_data data);
#ifdef CONFIG_GPIOCLASS_RTDM
	struct rtdm_device rtd;
#endif 
}gpio_t

/***************************************************************************
* class instantiation
*/
struct class_device *gpio_register_class_device(gpio_t *gpio){		
	struct class *gpio_master = gpio_declare();
	struct class_device *dev = class_device_create(gpio_master, NULL, MKDEV(0, 
0), NULL, gpio->name);
	dev->class_data = gpio;

#ifdef CONFIG_GPIOCLASS_SYSFS	
if((gpio->ddr_write)&&(gpio->ddr_read))class_device_create_file(dev,&class_device_attr_ddr);	
if((gpio->data_write)&&(gpio->data_read))class_device_create_file(dev,&class_device_attr_data);
#endif	 
	 
#ifdef CONFIG_GPIOCLASS_RTDM
	rt_gpio_device_create(gpio->rtd);
#endif 
	return dev;			
}


struct class_device *rt_gpio_device_create(rtdm_device *dev){
		gpio_t *gpio = container_of(dev,gpio_t,rtd);
		memcpy(dev, &device_tmpl, sizeof(struct rtdm_device));
		strncpy(dev->device_name, gpio->name, RTDM_MAX_DEVNAME_LEN);
		dev->device_sub_class = gpio->subclass;
		dev->peripheral_name = name;//used to back up and find the original 
structure.		
}

> What about putting the rtdm_device and your standard device structure
> into a "meta" structure. The type of the latter then only has be known
> to those parts that access data "across" the two structure.
Good idea!,
 So were on the same page, you mean like :?

struct rtdm_ meta{
	gpio_t  *gpio;
	struct rtdm_device rtd;
}

static int rt_gpio_ioctl(struct rtdm_dev_context *context,
                   rtdm_user_info_t *user_info, int request, void *umem){
    
struct rtsm_meta *meta = container_of(context->dev,rtdm_meta,rtd);
gpio_t  *gpio = meta->gpio;


That sounds good, then the user space layer wouldn't have to be aware of the 
Xenomai side at all, with the exception of the atomic locks, which could be 
localized to a single module and defined away as a macro.

clever, thx Jan,
NZG