> As an admitted neophyte to this space, you can tell me to go to my > corner and be quiet, but I can't help asking why configuration data, > which is what the pin info is all about - startup setup information that > can get stored locally in the driver once received - why this needs to > be atomic.
I think you might have a point there. Perhaps not the point you think you have, but still a point. HAL makes a distinction between "pins" that are links between modules and "parameters" which are one-eay data into a module (or, in some cases, out to Userspace) HAL string _pins_ are likely to cause problems, but hal string _parameters_ could be a real boon for config (and re-config) work. In practice I am not sure how important atomicity is anyway. The problems only arise when a base-thread function tries to read a HAL pin while a servo-thread function is writing to it. I can't think of many examples of a servo-thread pin that might be linked to a base-thread pin, except perhaps for some parallel-port IO and it is hard to see how bit-type values can have an atomicity problem. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
