On Fri, Apr 23, 2010 at 1:16 AM, Tony Harminc <t...@harminc.net> wrote:
> On 22 April 2010 14:19, Sam Siegel <s...@pscsi.net> wrote: > > > The requirements exists because I'm trying to write something that will > be > > Ziip enabled and leased as a product. > > > > Prior to passing the buffer to a work queue for the SRB, there is the > > possibility that the user (which can be a normal programmer) will need to > > modify the data in the buffer or provide additional data once the data > > source has been drained. > > > > I don't want the to impose a requirement of authorized code for the exit > as > > most shop will not allow application programmers to put code in an > > authorized library. > > Is there a true requirement that your end users/application > programmers supply assembler language (or C or similar) code to do > this buffer changing? I ask because another approach may be to > interpret something the user supplies - whether a control language of > your own invention, or something more general like REXX, for which > interpreters are already available - that does not have the ability to > execute arbitrary code on the metal. (Yes, I realize that REXX can > write to storage, but that sort of thing can be controlled quite > tightly.) > > In theory you could interpret compiled assembler code, but what would > be the point? > > Since you mention a data source, and the possibility of its being > "drained" and needing refilling, yet another approach may be to treat > this as a pipe that gets filled by an unauthorized program from > another address space. You can use UNIX piping techniques, or any of > various shared memory schemes. Or even TCP/IP or SNA... How usable > this will be depends largely on throughput vs latency issues. Of > course it's hard to understand what you are really trying to > accomplish, and I appreciate you don't want to give a full description > for presumably commercial reasons, but if you can explain a bit more, > I'll bet there will be good ideas here. > Hi Tony, I see your point about shared memory etc. I will spend some time this weekend writing up some more details in the hopes of getting additional feedback. All of the feedback so far has been great. And has been very useful in term of evaluating the various high level design choices. All of which are so much easier to change before the code is written. Thanks, Sam > > Tony H. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
