Re: [PATCH 0/7] utrace/ptrace

[Roland McGrath]

> Well. I had a lot of technical discussions with Roland about utrace,
> but I never asked him why he created this thing ;) To me, utrace
> looks like vfs. Currently we have the single and very poor "filesystem",
> ptrace. Until we add the appropriate layer, we can't expect the
> further improvements is this area.

I think that is an excellent analogy, and it's one I've used before.

Oleg and I have had our hands pretty full just with the infrastructure
layer and with ptrace.  Having this layer in the kernel is what makes
it tractable for a lot of other people to collaborate on new features
in this space, and that's what we want to enable and accelerate.  
Some of those on the CC list have worked and are working on such
things, and I hope they will pipe up about those.

Given the date, I suspect we might not see much from anybody on this
(or anything) until January.  Myself, I expect to be largely offline
for the rest of the year.

As Oleg mentioned, I have a cleanup/reimplementation of seccomp using
utrace.  That is quite a trivial use--it demonstrates how easy the
utrace API makes it to do things like that, in contrast to previous
solutions with arch-specific assembly hacking and so forth.  I can
dust that patch off and post it if anybody cares.

Some other features based on utrace have been floating around for some
time, posted here before.  Those include uprobes, kmview, and the gdb
stub.  I don't which of those are quite ready for merging, but honing
and polishing them gets quite a lot more doable with utrace in the
tree instead of out.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/