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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
