Packing a pointer (memory address) onto an IO pin

This may be the worst idea ever, but as I am trying to write things to tie neatly into my generic spi bus driver, I am struggling with pin overload. I have buffers that I am considering making an array of bytes (unsigned char) and passing the address of that buffer (a pointer) to an output (buffer_address). This pointer (buffer_address) would then be used by other fuctions to directly read and write to that buffer memory space. I have a pin called bufflock that signals that somewhere someone is trying to write to the buffer and that it is not safe to read or write the buffer. My user of the data will probably live in the servo thread and the spibus driver will live in the base thread. This would make connecting two functions that talk over these buffers as easy as adding one net. I would initialize the pin to 0 (a null pointer) and anyone that would use it would need to wait until the pointer was initialized before the fun could start.

QUESTIONS:
1) Can I assume that the addresses of per instance variables created with the "variable" declaration will have a constant address from call to call?
2) Will attempting to write to the variable from another function work? (I plan to try it anyway).
3) Are there other dangers I should consider?
4) In all of my code, I am assuming that it can be pre-empted before the function finishes. Is that true? Is it true of both base thread and servo thread functions/components?

You might have better luck asking your questions on the developers email list.
lists.sourceforge.net/lists/listinfo/emc-developers

Thank you for the links -- I have noticed they are all .c files and not using the component generator. I have been trying to use the component generator to try and take advantage of its abstraction from the intimate details of HAL RTAPI calls, etc.

** Should I abandon the .comp approach? ***

I have written a few programs and attached them. The first is an UNFINISHED spibus.comp. It does work (at least to send -- I have not tested receiving yet.) I lock the buffer, put some stuff in it, change the buffer pointer (count really) to the number of elements that should go out the port, and then chug-chug-chug they wiggle the pins. The other two files illustrate how I attempted to share a buffer. I'm kind of glad it didn't work, because the idea of ANYBODY'S crazy program being able to change variables belong to someone else is a recipe for severed limbs when working with machine tools.

zool.comp creates the buffer and twiddles some bits in it.
the keymaster.comp connects to zool and tries to read and modify the contents of the buffer, with kernel corrupting goodness.

Andy -- I have been successful at writing to memory space allocated by one component by passing a pointer to that memory through a pin and casting that back to a pointer. I am both happy and terrified that it has worked. I think this will allow me to:
1) Create any kind of buffer structure/data type I choose
2) Tie components that use this space together by publishing the pointer to shared space via a pin
3) Keep the net list tidy and limited to just a few pointers instead of passing every byte of every buffer as a separate pin (image 32 input bytes, 32 output, 32 slave addresses, 32 slave select pin config flags).
4) Open the door to whole new level of bugs and pain.

To see the insanity in action, watch debug on halmalloctest.0.debug. It is being changed in halpoker.comp.

I have been able to operate within the ecosystem of the component generator thus far; although I may not be far from abandoning it. The passing of memory addresses via pins changes everything.

Please see attached some code that works to have one program twiddle the bits in another private variable space.
I think this is the part where the dev's step in and delete this post so noone uses my template for insanity for future development.

I got tired of the huge list of nets between my spibus driver and my spiclient. Spiclient is a driver template for writing individual chip spi drivers. For example, one could have an analog to digital converter chip, an IO expander, and a SPI LCD all hanging on the spi bus. In the future, each of these will talk to my spibus driver and the driver will hadle generating the clocks and jiggling the chip select lines. Each of the chip drivers is oblivious to the presence of the others using the same spi bus.
SPIBUS.COMP:
- Allocates the buffers and initializes them.
- publishes a pointer to them
- manages the information it gets from the buffers

SPIBUSCLIENT.COMP:
- Checks to see when the spibus has come up
- Receives the pointers to the buffers and checks to see that they are not null
- Generates the byte commands needed to run a chip
- Writes these directly into the hal memory allocated by the spibus.comp driver and pointed to by the pointers it has been given.

THINGS THAT WILL CAUSE A KERNEL PANIC:
Passing some other goofy numbers in on the address_byte_low and address_byte_high pins.

Next to do:
- Find a "not crazy" way to pass the allocated memory handles to the spiclients (EXPORT KERNEL SYMBOLS?)
- Modify the proof of principle code to handle more than one client chip
- Modify the MAX7219DS LED driver I wrote to work with the new buffer architecture.
- Maybe test running parport.update method directly from within my driver to increase the bitrates?