> Thats cos a million of us never knew it existed. I'd practically kill for
> that stuff ( Not quite , imagine a trail of slightly bruised people in my
> wake). Its value to authors could be huge.
I don't blame anyone. It's a world of information glut, you can't
download every demo that some unknown person brings to linux-kernel.
Plus you never know: can this unknown person actually deliver (10%
chance) or are they another town council candidate (90% chance).
Fresh Meat didn't exist back then. When I resume this project, I'll put
demos up on Fresh Meat, and that will be a good channel for people to
find out about it.
One reason I've been sitting on it is that the technology works great
in a closed-source world. It works even better if the vendor can tweak
the OS. For example, I have to jump through hoops because I can't set
ORIG_EAX through ptrace. Sun or SCO could drop this into their
operating system in one product cycle.
Questions for you: (1) do you think this would be an interesting
presentation at the Linux Bazaar. (2) Do you think it's so interesting
that I could ask them to cover part of my travel expenses.
> This is something I've been pondering - strace has the same problems -
> it does suggest their should be a single good syscall/ioctl definition
> somewhere
I worked on the strace ioctl stuff for a while. That's when I wrote
Documentation/ioctl-number.txt.
My syscall table is pretty stable. Linus does not add new syscalls
very often, and he rarely changes existing syscalls because of binary
compatibility. He changed adjtimex back in 1.3.Something.
The ioctl's kill me. Dozens of people write drivers and many of them
write little private ioctl's. I have a fairly accurate and extensive
table that's current up to Linux 2.1.117.
Also I have no support right now if the target program mmap's a device.
I can probably do something about that if I have some kernel support.
I need stuff like PTRACE_MMAP, PTRACE_MUNMAP, and PTRACE_MPROTECT so
that I can play with the target's memory map. I only need to play with
it while the target is paused for tracing.
It's been challenging to figure out ways to get what I need without any
kernel support. In some ways it's been a discipline that made me do
the write thing. But I'm ready to start writing kernel patches in 2.3.XX
for the purpose of making my trace-and-replay easier. Things like:
- Make execve() set the registers to a defined value, rather than
inheriting state from before the execve(). I know someone else
wants this for his own reasons.
- Allow PTRACE_POKEUSR to set ORIG_EAX to -1 to abort a child's
child. This requires a change to a slow-path function in entry.S.
- Figure out some way to drain the ioctl swamp. I won't mind if the
existing thousand ioctls get frozen if there is some way to handle
new ones, such as an 'nioctl' call that takes the length as the
fourth parameter.
- Minor changes to include/linux/*.h because I need to include those
files -- glibc will never be complete enough for me. I am
happy with the modern idea that I should snapshot include/linux/*.h
and include the snapshot with my source. Right now I have about
ten workarounds with #define games to use the 2.1.117 include files.
This is actually a low number, because I include *every* file that
provides part of the user-kernel ABI, and my program is written in
C++! Kernel work in this direction would probably benefit glibc
developers.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/