You can get a literal eqivalent to PEEK and POKE by mmap()ing /dev/mem. You can map the MMIO regions of a PCI device to write a userspace driver for it, for example. This is how I prodded the tl880 chip before I had a kernel module ready back when I was working on that driver.

That's pretty interesting. What are some of the limitations of an approach like that?

You don't get interrupt handlers, for one thing (though I think there are projects that do allow complete userspace drivers), and as binarycrusader mentioned, it's incredibly dangerous to give any process full access to the entire physical memory space. A single vulnerability in that process gives the attacker the ability to write to all of system memory. This can be mitigated somewhat by mmap()ing only the smallest possible region of interest, then dropping root privileges.

Yep, although most linux dists now have "/dev/mem protection" meaning that on stock distro kernels (Ubuntu, CentOS, etc), access to actual "physical memory" is disabled.

Ref: http://lwn.net/Articles/267427/

OK for driver development. If you need access to physical memory you have to compile a kernel with unrestricted /dev/mem.

> You don't get interrupt handlers, for one thing

Thanks.

It's a giant, gaping security hole that most operating system architects are desperately trying to get rid of -- at least, that's the way I view it.

Any software that uses it should be exposed to extra scrutiny and must judiciously leverage whatever privilege mechanisms an OS provides to mitigate damage.

There should be a better way to accomplish what xorg needs on *NIX systems.

Here's a recent, dramatic example about how that sort of memory use can go wrong:

http://www.androidpolice.com/2012/12/16/samsung-exynos-4-exp...

None, it works just fine for Xorg.

/s

For additional context: PEEK and POKE were commands used in the BASIC programming language for directly reading and writing to memory respectively.

There's even a Wikipedia article about them:

https://en.wikipedia.org/wiki/PEEK_and_POKE

And I even created a t-shirt from it!

http://swain.webframe.org/tshirts/ (look at the 3rd from the bottom)

The author doesn't say how upstart became deadlocked in the first place. Was this an upstart bug?

Still unknown. Could be a bug, could be a race condition in one of the pre/post/start/stop blocks. I haven't seen it since and couldn't get a reliable reproducer. I really didn't want to make this about upstart itself so that people don't get to wrong conclusions.

Were there ever really common peek and pokes that would change programs?

Yes, "poke 53280,0" would directly write address 0xd020 to 0x00 which then e.g. would turn the border black on the C-64. But those were addresses in the mapped custom chips. More like setting a pixel on a modern GFX card by poke and less changing a program.

The later development of expansion cartridges to give you more lives in games or enable a cheat-mode there would a kind of peeking and poking, but hardware based etc.

That's really cool. Another option with a stuck Upstart job is to rename the job file.

$ sudo mv /etc/init/myjob.conf /etc/init/myjob2.conf

$ sudo start myjob2