On Saturday 25 May 2002 04:27 pm, you wrote: > 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.
We're just going to have to play with it. As far as I'm concerned, we're going forward with things as they are at this point. I'm just spending a little of what little time I do happen to have exhausting all possible ways of avoiding doing unneeded operations- as long as my branch is mostly in lock-step with the functionality that you're providing I'll be happy. I'll not spend too much more time trying this stuff, but I want to know. If something comes of all of it, great. If not, well, it was my time to waste and it's not really wasted- we'll have answers when someone else comes along and asks if that's the best we can do with this chip. I'm just not liking having to "secure" the path the way that it's being thought of. Not because I'm against doing the work- there is a bottleneck in doing this stuff that way. Some of the things we would do to secure things don't consume a lot of resources CPU-wise. Some of the things we would do if we can't just ignore the path would consume a lot of resources. If the books covering the design of the Linux kernel are to be believed, there's a decent number of operations done by mapping or unmapping memory to/from userspace- it really wasn't designed with the kinds of stuff we're asking of it (namely doing a LOT of it and doing it quickly and often...) in mind. > Yes. Unfortunately I don't have the time to do it myself, so it will have > to wait in what concerns me. I'm planning on setting things up this evening to see if any of this is worth bothering with as a continuing conversation. > 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. Indeed. That's why I intend on tinkering a little while longer with this but only so much so. As for knowlege of the card behavior changing and whatnot. I'd believe that not everything is known about any of the other cards out there. > 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... That's my take on things... -- Frank Earl _______________________________________________________________ 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
