On Tue, 6 Feb 2007, Roland McGrath wrote: > > So for the sake of argument, let's assume that debug registers can be > > assigned with priority values ranging from 0 to 7 (overkill, but who > > cares?). By fiat, ptrace assignments use priority 4. Then kwatch callers > > can request whatever priority they like. The well-behaved cases you've > > been discussing will use priority 0, and the invasive cases can use > > priority 7. (With appropriate symbolic names instead of raw numeric > > values, naturally.) > > Sure. Or make it signed with lower value wins, have ptrace use -1 and the > average bear use 0 or something especially unobtrusive use >0, and > something very obtrusive use -many.
I wonder where this convention of using lower numbers to indicate higher priorities comes from... It seems to be quite prevalent even though it's obviously backwards. > Unless you are really going to pack it > into a few bits somewhere, I'd make it an arbitrary int rather than a > special small range; it's just for sort order comparison. Bottom line, I > don't really care about the numerology. Just so "break ptrace", "don't > break ptrace", and "readily get out of the way on demand" can be expressed. > We can always fine-tune it later as there are more concrete users. Okay; I'm not fixated on any particular size. > > Or maybe that's too complicated. Perhaps all userspace assignments should > > always use the same priority level. > > No, I want priorities among user-mode watchpoint users too. ptrace is > rigid, but newer facilities can coexist with ptrace on the same thread and > with kwatch, and do fancy new things to fall back when there is debugreg > allocation pressure. Future user facilities might be able to do VM tricks > that are harder to make workable for kernel mode, for example. All right. However this means thread_struct will have to grow in order to hold each task's debug-register allocations and priorities. Would that be acceptable? (This might be a good reason to keep the number of bits down.) Another question: How can a program using the ptrace API ever give up a debug-register allocation? Disabling the register isn't sufficient; a user program should be able to store a watchpoint address in dr1, enable it in dr7, disable it in dr7, and then re-enable it in the expectation that the address stored in dr1 hasn't been overwritten. As far as I can see, ptrace-type allocations have to be permanent (until the task exits or execs, or uses some other to-be-determined API to do the de-allocation.) Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/