Muli Ben-Yehuda's journal

Creative Thinking – A Tale of Seven Hats

Yesterday at work we had a “creative thinking” workshop. It wasn’t
nearly as bad enough as I expected it to be, and I actually
enjoyed bits and parts of it. We learned techniques for
facilitating constructive discussion, how to do proper
brainstorming, how to come up with creative solutions to
problems and how to distill problems into their essence. I
particularly enjoyed the ‘provocation’ method. For example, when
discussing extreme
programming, we took the sentence “in XP you write the
tests first”, and ended up with the provocative statement “never
write tests”. That led me to contemplate systems that are never
tested, and thus are expected to fail quite often, and thus must
learn to cope with their failures gracefully, which leads to
completely different ways of thinking about designing software
systems. Fun stuff.

syscalltrack – another bug that wasn’t squashed[0]

We support two methods of communication with the kernel in
syscalltrack. The first and oldest is via sysctl, and is fairly
ugly. The second is via a device file. While I was testing the
previously mentioned build fix to get it to build with Linux
2.4, I noticed that loading and unloading rules via the device
file was failing with -EBADF, while sysctl was
working. Yesterday I checked and figured out what was
happening (quoted here because it doesn’t show up in the
archives yet).

 
On Sat, Feb 21, 2004 at 11:57:18PM +0200, Muli Ben-Yehuda wrote:
> tea:/hydra/home/muli/src/syscalltrack-head# tests/stress/tester -d 
-t simple_syscall_usage
> starting test 'simple_syscall_usage' (subsystem module(1)) []
> 'dev_file_do_request': failed to send the request, with error 'Bad
> file descriptor'

-EBADF is returned in only one place, when someone tries to write to
the log device. Why would we be trying to write to the log device,
when we're actually trying to write to the control device?

Answer: because the major numbers on the device files /dev/sct_ctrl0
and /dev/sct_log0 are messed up?

Indeed, because I loaded the modules manually rather than via
sct_load, the device files had the wrong major numbers, and
/dev/sct_ctrl0 actually had the major number of the log
device. Oops. Fixing the device numbers for the /dev/sct_* files based
on the output from /proc/devices solved the problem.

On a side note, I think we should move to netlink for
communicating with the kernel, as that seems to be the standard
way to do it.
relayfs could also be interesting, if and when it ever makes
it into the vanilla kernel.

[0] This title reminds me of the closing slide in the Creative
Thinking workshop. The slide said “opportunityisnowhere”, and
you could parse it either as “opportunity is no where” or
“opportunity is now here”, depending on your general outlook on
life. FWIW, It’s the bug that wasn’t, not the bug that wasn’t
squashed.