From: n s. <nsc...@ya...> - 2006-04-29 16:55:09
|
Hello All, I need to start by thanking everyone involved for producing coLinux. I also need to apologize for not being a system programmer. I will never be able to undertake the task of building or implementing the items I talk about. The road map talks about knoppix/ Frame Buffer device support as a goal. What is the status of this work? I'm trying to install stock distributions of Debian, Ubuntu, and FC. I've been starting with small loads and building them up with the stock packages. The Distro wants real hardware to install on. When the package manager probes or install the X server, the kernel faults cleanly and closes as it should. I'm not trying to have colinux run X windows. I want to satisfy the installer and the X server. An Xserver that can not display anything sounds like a dumb device but it allows the system to start normally. What about a Frame buffer device that displays a text file or a 800X600 8 bit logo on VC-F7. What about a pipe to the local xserver on windows. Pass the requests from the dummy interface to the xserver running on windows. Support Xming as the Display device? Xming is small and fast? Vncviewer has a different protocol, but the listen option would make an easy install for the user. Start vncviewer in listen mode and startx. When the xserver starts, a connection to 127.0.0.1:5500 would form the display. What about the vga.bin from QEMU. Could the qemu project video hardware be reused? Booting an Iso image and installing to a cobd device from the text installers can go a long way. Most users do not have the skills required to hack the linuxrc file for every distribution. Thank you for your time, and help, Nicholas A. Schembri State College Pa, USA Produce an Autorun KNOPPIX disc for Windows, that will load coLinux on Windows and also be able to boot a machine natively. Frame buffer device. Let the native XFree86 server be used instead of using a "remote" X server provided by the host OS such as the Cygwin XFree86 server under Windows. |
From: George P B. <geo...@gm...> - 2006-04-29 19:11:14
|
On 4/29/06, n schembr wrote: > The road map talks about knoppix/ Frame Buffer device support as a goal. = What is the status of this work? It's been prototyped and we have a more or less working (not necessarily ready for general consumption) proof of concept implementation. General concensus of early folks using it is that there where some choices about the impmentation that wheren't acceptable, especially when using via remote displays. If you'd like to try it to see if it would work for you can try to get an binary of nlucas's build of colinux, or build an coLinux build environment and download from monotone.colinux.org the org.colinux.nlucas branch of code and compile it. The implementation decisions that where made that didn't go over well with the community need to be revisited and done differently.=20 The concepts for the Frame Buffer, need to be generalized and built into the coLinux API that's used for all devices, as it use a method that is much better (shared memory between guest and host) than the current method (passage pages for moving data between guest and host) and could be used to improve all devices. > What about a pipe to the local xserver on windows. Pass the requests = from the dummy interface to the xserver running on windows. Support Xmi= ng as the Display device? Xming is small and fast? Just set-up X Server with XDMCP, and set the DISPLAY to a 'remote' display that points to Xming running on the host... This has all been covered in the wiki, discussed, and help for others setting it up been covered in the mailing lists. > What about the vga.bin from QEMU. Could the qemu project video hardware = be reused? Probably not. coLinux and QEMU use different 'architectures' QEMU (as well as VMWare and VPC) attempt emulate an entire CPU. coLinux just attempts to 'time share' (so to speak) your existing/real CPU.=20 Besides if we have an implemented proof of concept Frame Buffer already, then it's probably not worth working on getting QEMU's to work. > Booting an Iso image and installing to a cobd device from the text instal= lers can go a long way. > Most users do not have the skills required to hack the linuxrc file for = every distribution. You CAN boot an iso image now with coLinux. ISO is built-in on the coLinux kernel, you don't even need an initrd.gz. Maybe the problem with ISO installers is that they are using modules that aren't accepted in main-line Linux kernel, like cloop, or squashfs, or unionfs. Those are all nice and all, but they haven't been accepted into the linux kernel proper and coLinux doesn't ship with them (imagine if you would if coLinux's limited developers chased around all over the internet keeping up with the latest versions of several popular kernel module add-ons and what it would do to coLinux development). The biggest problem with distro installers is that the coLinux cobd device doesn't support partitions, if that where fixed most installers would more or less work out of the box without a lot of fiddling (not currently the case, currently you have to skip/bypass/kill or other-wise the partition step in most installers and manually mount the target device to the right location). After that it would be better if the distro installers would recognize coLinux and know that they are work ing in an limited hardware environment and not do a lot of hardware probing, and recognize that the kernel is provided and not to try install one. -- George |