Re: [driver] New life for Serial mice

2001-06-08 Thread Mike Coleman
ter than > exponentially (base 2). I haven't been able to stop that fast. Put a big brick on your desktop and *ram* it with your mouse. :-) -- Mike Coleman, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - To unsubscribe from this list: send the li

Re: PTRACE_ATTACH breaks wait4()

2001-06-08 Thread Mike Coleman
ugging interface would be a starting point: http://docs.sun.com:80/ab2/coll.40.6/REFMAN4/@Ab2PageView/42351?Ab2Lang=C&Ab2Enc=iso-8859-1 -- Mike Coleman, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - To unsubscribe from this list: send the lin

Re: gdb/ptrace problem

2001-06-04 Thread Mike Coleman
attaching to it. Does it work? Also, check for operator error. :-) --Mike -- Mike Coleman, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMA

Re: Software Mestizo Manifesto

2001-02-21 Thread Mike Coleman
Pavel Machek <[EMAIL PROTECTED]> writes: > You may say "please don't drop nuclear weapon". You may *not* say "you > must not drop nuclear weapon", that would violate GPL. I can see the headline/FUD now: FREE SOFTWARE FANATICS REFUSE TO DISAVOW USE OF NUCLEAR WEAPONS :-) -- [O]ne of the fe

[ANNOUNCE] SUBTERFUGUE 0.2

2001-02-21 Thread Mike Coleman
SUBTERFUGUE 0.2 is available. It's been updated to work with the new 2.4 kernel and also includes a few other bug fixes and improvements. It's available in source or Debian package form. As always, feedback is welcome. --Mike ===

Re: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit (and ioctl must die!)

2000-12-14 Thread Mike Coleman
Alexander Viro <[EMAIL PROTECTED]> writes: > ioctl() is avoidable. Proof: Plan 9. They don't _have_ that system call. > It doesn't mean that we should (or could) remove it. It _does_ mean that > new APIs do not need it. *I* sure wish we could. From the standpoint of trying to trace system calls,

Re: Pthreads, linux, gdb, oh my! (and ptrace must die!)

2000-12-13 Thread Mike Coleman
Mark Kettenis <[EMAIL PROTECTED]> writes: > However, the "zombie problem" is caused by the way ptrace() interacts > with clone()/exit()/wait(), which I consider to be a kernel bug. [insightful analysis omitted] I think you've hit the nail on the head, and I'm a bit frustrated that I never noticed

Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

2000-11-09 Thread Mike Coleman
Alexander Viro <[EMAIL PROTECTED]> writes: > RMS had repeatedly demonstrated what he's worth as a designer > and programmer. Way below zero. You may like or dislike his ideology, > but when it comes to technical stuff... Not funny. Huh? *Hello*? GNU gcc? GNU emacs? Way below zero? *Hello*

[ANNOUNCE] SUBTERFUGUE 0.1.99a (bugfix)

2000-10-30 Thread Mike Coleman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This mini-release just fixes a bug that could allow processes to escape tracing under certain circumstances. If you plan to make use of 'sf', you should upgrade. - --Mike See http://subterfugue.org for info on SUBTERFUGUE. -BEGIN PGP SIGNATUR

[PATCH] TracerPid in /proc//status is wrong

2000-10-30 Thread Mike Coleman
Linus, This patch fixes the bogus value of the TracerPid field in /proc//status. (I thought was patched several months back, but I guess it wasn't, or it got mistakenly backed out.) --Mike --- fs/proc/array.c-distFri Sep 1 16:32:17 2000 +++ fs/proc/array.c Mon Oct 30 08:02:35 200

[PATCH] fix ambiguous PTRACE_SYSCALL tracing

2000-10-28 Thread Mike Coleman
Linus, This patch allows a (ptrace) parent to unambiguously distinguish between a child ptrace stop following a PTRACE_SYSCALL due to a system call and a ptrace stop due to delivery of a SIGTRAP. Currently, when PTRACE_SYSCALL is being used, it's not possible to tell for certain why a particular

Re: If loadable modules are covered by Linux GPL?

2000-08-29 Thread Mike Coleman
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > Even M$ doesn't require that I give proprietary information away. > If Linux wants to become the new standard for the computing industry, > GPL or whatever can't claim any ownership of the work a company > has done while using it. This almost see