Archive for July, 2007|Monthly archive page

Bleepin’ Beeps!

Ok, here you go. I looked into the mystery that is devc-con, and I found a way to modify the beep.

The unfortunate side is that it only works if you are running devc-con in QNX mode, so you will either have to do that (by passing the -Q option) or suffer with the loud beeps (for now)

Ok, so go change your build file, and make sure your TERM env var is qnx

So we need to emit an escape sequence, which can be done thusly…

# printf “%cs%c%c%c” 0x1b, <c1>, <c2>, <c3>

Where c1 c2 and c3 are the parameters…

Here’s a snippet of the state machine…

case STATE_QNX4_11:     /* esc_beep_set */
s->beep_ticks = (c <= ' ') ? 6 : c - ' ';
s->esc_flag = STATE_QNX4_12;
case STATE_QNX4_12:
s->xpos = c - ' ';
s->esc_flag = STATE_QNX4_13;
case STATE_QNX4_13:
n = (s->xpos % 192) + ((c - ' ') % 192) * 192;
s->beep_counter = 0x0606;
s->beep_counter = (n &lt; 19) ? 0xffff :
(unsigned)(1193180L / (long)n);

The default values for beep_ticks and beep_counter are 6 and 0x0606, respectively.

I haven’t quite worked out the optimimum, but basically if you screw it up, the beep is gone anyways, so I’m alright with that. You guys can have fun playing.

I’ll try and work a nobeep facility into the next version of devc-con.

Sorry this is brief, I’m running out of time today. I’ll try and elaborate more on exactly WHAT these things mean later (or maybe Thomas will…)




Dog days of summer …

So weeks go by and you’re probably thinking

What is up with those send receive reply guys? They haven’t posted anything in weeks!

True … it has been a few weeks, but we haven’t been idle.  There are exciting things a brew at QNX during the summer heat … air conditioning being one of them that tends to only make sporadic appearances unfortunately.

One of the more interesting features that is has worked its way into the Neutrino kernel for the next release (slated for the not too distant future) is going to be the ability to report out the mapping of physical memory of a system to virtual addresses used by individual processes. 

“But we live in a virtual address world“,  you say “why would we want a physical map of a systems memory?”

That was certainly my first impression.  Particularly with the fact that you can get a complete virtual address mapping for a process using the /proc filesystem and the appropriate devctl() and the entries for <sys/procfs.h> and <sys/debug.h>, you should be able to paint a fairly complete memory story all using virtual address information.

Turns out that that isn’t quite the case.  You can get close, but there are still some missing details when it comes to how particular shared libraries and executables are mapped within other mapped areas (for example using execute in place within secondary image file systems).  Getting access to the physical address allows you to resolve that ambiguity quite nicely.

Also, while I mentioned in the article on fragmentation (yes … we will get back to that issue =;-) that the OS nominally hands out memory uniformly in ~4K chunks, it does have the ability to fragment over time.  In general this isn’t a problem since the MMU for the processor provides the mapping giving you virtual continuity over fragmented physical memory.

Unless you need (or want) physically contiguous memory.  This can lead to improved performance in some device drivers that can leverage DMA and direct IO data transfers.  It is also a requirement by some tooling like the instrumented kernel, that arranges its data buffers as one contiguous ring.

The interface for extracting this additional memory information will be through the /proc interface and is a multi-stage procedure, but the fact that the information is now available is great news.  

Now all we need is a tool to showcase this new information … nothing like writing a handy utility to help beat the heat!