Brainwaves

Posts to mailing lists relating to the graphical console have increased with the growing popularity of the amd64 port. I’m not at all surprised about this. In fact, I’ve seen it coming. That’s why I started vtc(4) development many moons ago. With KGI declared dead, vtc(4) may have grown another leg to stand on: a breeding ground for future KGI development. A new leg does not mean that vtc(4) has a more viable future. The fact that vendors of graphics cards keep their hardware under NDA is a real hurdle for vtc(4) and having proper drivers for graphics hardware is central to the design and implementation. If not for getting the higher resolution, real drivers are needed to get any kind of acceptable performance out of the hardware. Good performance is another hurdle that needs to be overcome. I just ran a kernel with vtc(4) under Parallels (a virtualization package that runs on Mac OS X for Intel processors) and scrolling was painful to watch. Interestingly, Parallels simulates Intel graphics hardware and Intel has documented what which is important to vtc(4). It would be interesting to write a driver for GMCH hardware with accelerated bitblt operations and see if there’s a performance increase. That’s an interesting experiment…

Now that I have implemented the conditional long branch emulation, it’s inevitable that I need to work on the long branch call form. This, however, requires some side-tracking. Emulating the brl.call instruction requires stack unwinding because it needs to get the value of ar.ec as it was at the time of the trap. It’s also possible that the brl.call instruction writes to one of the preserved branch registers. In that case, we need to know if that branch register was saved and where. Luckily, the runtime architecture states that b0 is to be used to save the return address, so we may ignore writing to other branch registers at first. Nonetheless, stack unwinding is necessary. This, by all means, is a good thing, because we need it in other situations as well—situations we’re not correctly handling now. Maybe I should import the latest libuwx first…

I really need to finish the gctl functionality for GPT. With EFI on ia32 a reality (i.e. Mac Books) and in the hands of users, I feel I need to get this off my plate. All I need to do is have the changes actually hit the disk and provide a means to query the current configuration. Everything else is already there. Buying a Mac Book Pro may be a good trigger. I’ve been thinking about it for a while. It would also allow me to port the EFI support to ia32. The upshot of getting a Mac Book Pro is that I have my PowerBook G4 free to get scc(4) with uart(4) to work on it. Why these two unrelated things are connected to each other in my head, I don’t know…

We generally don’t use the I/O MMU on chipsets that have them. The exception is on sparc64. The I/O MMU allows us more freedom in allocating memory for DMA operations by programming the I/O MMU in such a way that the (possibly scattered fragments) appear as a contiguous block of memory that is within reach of the device that does the DMA. It seems to me that the function of the I/O MMU can be abstracted and handled by a KOBJ interface. This would allow a generic and/or machine independent busdma implementation while still being able to make use of machine dependent hardware and when no such hardware (i.e. the I/O MMU) is present or supported to fall back to bounce buffers and/or the use of contigmalloc(). Detection of I/O MMUs would happen at bus enumeration time and may in fact happen after the detection of a device that uses busdma. This may not yield the desired behaviour. Multi-pass bus enumeration may help us here and seems to be mentioned in other contexts too as a way of resolving problems. The question is whether we can get rid of the almost identical implementations of busdma that we have for the platforms that we support when we use such a KOBJ interface?

Brainwaves… There’s hardly a day I don’t think about FreeBSD. Thoughts vary from things on my plate and how I didn’t get a chance of working on them to things of such grandeur that I really must have been dreaming. And, yes. Now I feel a need to share them with you. Isn’t that just horrible…