On 2002.05.25 21:50 Leif Delgass wrote: > On Sat, 25 May 2002, Leif Delgass wrote: > > > On Sat, 25 May 2002, José Fonseca wrote: > > > > ... > > > > 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. >
I see... I had the [wrong] impression that the value wasn't actually changed in the process since it was preincremented... have you tested if this actually happens? Anyway, this doesn't prevent to use the buffer aging. On the end of processing a buffer we still end up with the correct value of BM_GUI_TABLE and we can use the last bit of BM_COMMAND to know if it's processing the last entry or not. The only draw back is that we aren't able to reclaim the buffers so soon, so we would need a scratch register to know which buffers were free or not. But then, what damage can a client do by tampering BM_COMMAND? Even if it can mess with BM_COMMAND, we can still work without it. We just let the card go on, but when it stops we just need to see wich was the last processed buffer and go on. But probaby there are more registers that the client can mess and damage... probably is not just BM_GUI_TABLE and BM_COMMAND, but a bunch more of them, and we're effectively reducing the card communication bandwith asking to reset so much thing in the end of _each_ 4kb buffers. > It just occurred to me that resetting BM_GUI_TABLE could put the card > into > a loop. You might have to put in an address two descriptors away. We'd > need to test this. Yes. Unfortunately I don't have the time to do it myself, so it will have to wait in what concerns me. In any event, I think what these issues must be really addressed only when the DMA is complete. Our knowledge of the card behavior is constantly changing, and it would be waste of time to make such an effort to make things work out and discover later on that it was hopeless. In fact, although I try to stay impartial and have an open mind about this, I can't stop thiking that we aren't going to accomplish nothing with circunveining the card's security drawbacks like this. It's like covering the sun with that-thing-full-of-holes-which-I-dont-recall-the-name... I'm getting more and more inclined towards a robust implementation, like unmapping buffers, which probably won't have a significant performance impact, and which will give us much freedom to control the card properly. Well, time will answer this... José Fonseca _______________________________________________________________ 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
