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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core