Wolfgang Lenerz writes:
> > To to this within the device driver will be a non trivial task becauseyou> > wil have to open a filing system channel from withing the open call ofa non> > filing system device driver. > > That's what the FILTER THING would be very good for.
Probably not (?). I presume the 'thing' use call would open the channel to the filing system. If you call the thing use routine from within the PFF channel open call (which is what I see proposed), you have the same problem as you will STILL be within the channel open call when using the 'thing'!
Or skip the Thing altogether and make its fuctionality part of the PFF device driver:
On the Open call the PFF device driver's primary functions are decode the name check the details set up and configure a channel definition block If all of the above are ok then, on exiting, set the calling job's program counter to a subroutine that starts an independent job that opens any channels and keeps things moving, ie a Driver JOB, and then returns to the calling job, where it left off, with a channel ID.
Trouble is Per, that you cannot do all this within a device driver because it is running in supervisor mode.
I also understand that a non-directory device cannot open a channel to a file....
This is why the THING was envisaged
The Driver Job could then set up the appropriate Filter Program for that protocol (is this really needed?) and provide it with an input pipe which would be connected with the driver at the other end and operated like a queue via normal serial IO.
Different protocols are needed to handle different QL programs and add extra functionality. Not really too much trouble to add support for different protocols - its more a question of whether the filters are written to support them
-- Rich Mellor RWAP Services 26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
