[Xenomai-core] RTDM problems with structures in headers
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM problems with structures in headers
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM problems with structures in headers
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
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
