trem wrote: > Jan Kiszka wrote: >> trem wrote: >> >>> Hi >>> >>> I've written a very simple example for rtdm. And I would be pleased to >>> get a feedback about it. You can found it here : >>> >>> http://zarb.org/users/svn/trem/trem/kernel/xenomai/rtdm/ >>> >>> >> >> Looks good and (almost) clean. A few remarks and some suggestion: >> >> o Use kernel coding style for the driver (linux/scripts/Lindent + >> manual tweaking) >> >> > I don't know this kernel coding style for driver. I only know kernel coding > (Documentation/CodingStyle). But I'll apply this coding style as soon as > I found them.
That script should actually implement the documented style. >> o Put your driver under RTDM_CLASS_EXPERIMENTAL, TESTING is for >> benchmarks and regression test drivers. And you don't need >> rttesting.h. >> >> > yes, done. >> o As RTDM is mainly about "RT", why not switching to .read_rt and >> .write_rt? That means of course creating a shadow thread in >> read_simple_rtdm. >> >> > I supose that it needs to add a rt task in read_simple_rtdm, > and all read/write will be done in this task. My goal was to > do a as simple as possible example, but this idea add some > code. Is this added code really usefull for a simple example ? Well, the complication consists of a rt_task_shadow() in read_simple_rtdm's main. But as I said later, you may also come to this topic incrementally. > >> o Once you are real-time with read/write, you could demonstrate >> synchronisation. One FAQ is "How do I wait with my application on >> something inside a driver?" You could do rtdm_sem_up on write and >> rtdm_sem_[timed]down on read. >> >> > Same answer that former. I prefer to keep a really simple example. >> Alternatively: >> >> o What about creating a small series of RTDM examples, consisting of >> two demos so far: the first one a reduced version of you current >> code, just showing device registration and handler invocation, the >> second one about read/write and synchronisation. And if you feel like >> doing more, one could certainly continue this series with further >> aspects... >> >> > Could you stop to read my mind ? ;) Oops, sorry, couldn't resist. > I like this idea, and I'm ready to work on a series of example. > > I propose to write an example per concept (synchronisation, task, clock, > ....). > Of course, each example should have a lot of comment that explain everything. > With the idea, that the series could be used as a tutorial. Perfect! That's what I had in mind as well. > >> Are you interested that we merge your example(s) into the Xenomai repos >> (examples/rtdm/driver-api)? I would welcome this and support your effort! >> >> > I think it's the logical behaviour of the previous question (and answer). > So if you think that this example is good enough, I'll be pleased to see > it added in the repository. Then please post your demo in form of a patch against Xenomai trunk. You could pick a regular naming scheme for driver and userspace sources (e.g. "tut01-sceleton-drv.c" and "tut01-sceleton-app.c"), put them into the driver-api folder, and extend the Makefile. See the wiki on how to generate patches [1]. TiA for your effort! Jan [1] http://www.xenomai.org/index.php/Xenomai:Contributing_Patches
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
