On Sat, 25 May 2002, José Fonseca wrote: > On 2002.05.25 20:36 Frank C. Earl wrote: > > On Saturday 25 May 2002 11:48 am, José Fonseca wrote: > > > > > So if you can't secure it in the end, your extra effort will be in > > vain. > > > > I just thought of something to try to change the nature of the test case > > problem. What happens if you have a second descriptor of commands that > > merely resets the DMA engine settings to what they should be for the > > third > > descriptor? I'd say it'd depend on what the chip was actually doing- > > what do you guys think? > > You mean, setting the descriptor to the right value in between? > > hmm... I doubt that it in the middle works because as Leif noticed, the > changes that we make to BM_GUI_TABLE only affect the descriptor that is > two entries ahead, so it would be too late... > > ..but your idea in principal is quite ingenious! What if we just fill the > last 8 bytes of each 4K block with that command to reset the value of > BM_GUI_TABLE? So even if the client tries to mess things up, we would put > it right in the end. Of course that it would be a pain [to code for] to > reserve 8 bytes on the end of each 4k block, but it's doable [It would > also be a pain to code the kernel unmap/verification routine] > > This means that not only the client can't mess up the descriptor table, > but they can't tamper with BM_GUI_TABLE, so we can also still use it as a > progression meter [in both implementations].
This had crossed my mind too. The only problem is that there could still be a short period of time where BM_GUI_TABLE isn't accurate, so it still leaves the problem of being able to trust the contents of BM_GUI_TABLE for buffer aging and adding descriptors to the ring. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
