http://blog.gmane.org/gmane.os.hurd.l4 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.hurd.l4/6019 <pre>FOSDEM 2012 - Multiserver, microkernel-based operating systems devroom *CALL FOR PARTICIPATION* http://fosdem.org/2012 (apologies for cross-posting) The developers of several free and open-source multiserver and/or microkernel-based operating systems will meet at FOSDEM 2012 in Brussels, Belgium and will share a developer room. The devroom is currently looking for content in the form of talks related to the area of multiserver and/or microkernel-based operating systems. Possible topics include, but are not limited to: OS introduction to developers of other OS Subsystems and architecture Hardware and device drivers Tools and languages Release engineering and testing Experience and learning from mistakes Technical challenges Community and life with an OS-project Academia and education Please send your talk proposal(s) to: microkernel-devroom&lt; at &gt;lists.fosdem.org no later than by 2011-12-31. Make sure to include the following in your proposal: - title of your talk (will be printed in the FOSDEM booklet) - your full name (will be printed in the FOSDEM booklet) - your short bio giving us some idea of who you are and what is your relation to and qualification for the subject of your talk - number of 15-minute slots that you need for the talk (talks longer than 45 minutes are discouraged) The final devroom schedule (along with accepted talks) will be announced on 2012-01-9 (Jan 9) in: microkernel-devroom&lt; at &gt;lists.fosdem.org and the speakers will be notified via e-mail. The schedule will be also published on the FOSDEM web and in the FOSDEM booklet after 2012-01-21. If you do not want to or cannot give a talk yourself, you may still send suggestions for what else you would like to see/hear/do in the devroom. Please send your suggestions to the above mailing list. The devroom is scheduled for Sunday of February 5, room K.3.201. The seating capacity of the room is 85 seats. Any changes will be announced in the above mailing list. Jakub Jermar </pre> Jakub Jermar 2011-11-22T22:29:48 http://comments.gmane.org/gmane.os.hurd.l4/6018 <pre>Hi! I was contacted by jermar on IRC, a developer of HelenOS, which is another multiserver microkernel based OS, &lt;http://www.helenos.org/&gt;. He and also some folks from the MINIX3 group were thinking whether to propose a developer room for the upcoming FOSDEM 2012. The idea is for having a devroom dedicated to [multiserver] microkernels, or a generic alt-OS room as a fallback. The deadline for applications is in three days already. Are we interested in this? I said we generally are, but that I have no idea how many of us will make it to FOSDEM next year. Then, our group will need to find things to do in the devroom, provide a portion of the content. This can be (but is not limited to): presentations, brainstorming, coding sessions. Please answer quickly. Are you interested in this? Can you already forsee whether you'll make it to FOSDEM next year, 4th/5th February 2012, &lt;http://fosdem.org/2012/&gt;. Grüße, Thomas </pre> Thomas Schwinge 2011-10-24T17:01:01 http://comments.gmane.org/gmane.os.hurd.l4/6017 <pre>Hi, The NOVA project is happy to announce that there is a new prerelease of the NOVA microhypervisor available for download at http://www.hypervisor.org/ under the terms of the GNU General Public License version 2. NOVA is based on a modern microhypervisor written in C++ and assembler. The current implementation runs on multi-core x86 machines that support ACPI, under QEMU (including VM support), and as a microkernel in a virtual machine on top of itself. NOVA makes use of hardware virtualization features such as Intel VT-x/VT-d or AMD-V, and facilitates running unmodified guest operating systems in virtual machines with near-native performance. Among other things, the new prerelease improves the security of device- and interrupt assignment by using capabilities for these operations. There is also a new hypercall for interacting with the scheduler. At the same time, we've released a new version of the NOVA Userland (NUL). While there are few user-visible changes, a lot has changed under the hood. We have integrated a central admission server that is going to implement global policies for CPU time distribution in a future release. Another notable development is rudimentary libvirt support, which will eventually replace the old configuration syntax. Cheers, - Udo </pre> Udo A. Steinberg 2011-07-28T18:04:47 http://comments.gmane.org/gmane.os.hurd.l4/6013 <pre>Today I got the source again from (git.savannah.gnu.org/hurd/viengoos.git ) then switch to viengoos-on-bare-metal Got the cross-compiler and so. As i'd trying to fix some of my problems i saw at the file i named bellow some mistake might occurred. /libviengoos/t-addr.c line 67 &gt; l4_uint64_t used ,but doesn't declared! even at &lt;l4/type.h&gt; Does uint64_t mistyped as l4_uint64_t? (uint64_t had declared at hurd/addr.h) -Naghizodeh </pre> Naghizodeh,T.A-H 2011-04-07T15:52:57 http://comments.gmane.org/gmane.os.hurd.l4/6012 <pre>Opps, I forgot to send the original message to the mailing list. Here it is: Try using the instructions here: http://www.gnu.org/software/hurd/microkernel/viengoos/building.html Viengoos only builds on x86_64 IIRC. Following those instructions should atomatically build the cross-compiler that you need. It worked for me, on PPC Debian Squeeze. -Andrew </pre> Andrew Engelbrecht 2011-04-06T23:01:39 http://comments.gmane.org/gmane.os.hurd.l4/6011 <pre>Has anyone gotten viengoos to boot using GRUB2 v. 1.99~rc1? I get the following errors in qemu when try to boot Viengoos: error: invalid offset in section header. error: you need to load the multiboot kernel first Looking at the date of the patch recommended for GRUB at http://www.gnu.org/software/hurd/microkernel/viengoos/building.html , I figured that v. 1.97 would be the closest tried and tested version of GRUB and therefore might work with viengoos. Unfortunately, v1.97, v1.97.1, v1.97.2 and v1.98 don't cross-compile on my PPC computer. Here are the errors I get when compiling v1.97: gcc -Iutil/i386/pc -I../util/i386/pc -I. -I./include -I../include -Wall -W -DGRUB_LIBDIR=\"/home/sudoman/src/gnuhurd/failedgrub/7/build/../install/lib/`echo grub/i386-pc | sed 's&amp;^&amp;i386-pc-linux-gnu-&amp;'`\" -g -O2 -DGRUB_UTIL=1 -MD -c -o grub_setup-util_i386_pc_grub_setup.o ../util/i386/pc/grub-setup.c ../util/i386/pc/grub-setup.c:38: error: initializer element is not constant ../util/i386/pc/grub-setup.c:38: error: (near initialization for ‘grub_gpt_partition_type_bios_boot.data1’) ../util/i386/pc/grub-setup.c:38: error: braced-group within expression allowed only inside a function ../util/i386/pc/grub-setup.c:38: error: braced-group within expression allowed only inside a function ../util/i386/pc/grub-setup.c:38: warning: missing initializer ../util/i386/pc/grub-setup.c:38: warning: (near initialization for ‘grub_gpt_partition_type_bios_boot.data1’) make: *** [grub_setup-util_i386_pc_grub_setup.o] Error 1 It looks like I'm not the only one running into similar problems on a PPC machine: http://www.mail-archive.com/grub-devel&lt; at &gt;gnu.org/msg16467.html I figure going back to 1.96 or older would be going back too far. Compatibility with PPC is bound to be worse in the past, as they have been adding support for booting PPC over time. So building the tools on PPC will probably be fruitless as well, which is where the above failures have been occurring. I also tried using the sources for v1.98, provided by Debian with patches and all, but I still ran into the same error. I know the cross-compiler's not at fault, since it's the regular gcc that's being used above. Another thing is that when I start qemu, I get an "error: file not found" error after a "Welcome to GRUB" message, but before the GRUB menu. Since the "Viengoos" option loads, I am assuming that my config file was loaded. In the off chance that my grub.cfg is the problem, i've attached it. Also, I 've attached the diff file that I used to get v1.99~rc1 to load the config file with the following command: bin/i386-pc-linux-gnu-grub-mkrescue -o boot.img --configpart='(hd0,msdos1)' --modules='*.mod' I guess that was mostly a rant, but if anyone has any tips, tries booting viengoos using version 1.99~rc1 of GRUB2 themselves, or sends a patched build of v1.97 my way, that would greatly be appreciated. ;-) -Andrew </pre> Andrew Engelbrecht 2011-04-06T22:43:54 http://comments.gmane.org/gmane.os.hurd.l4/6009 <pre>Hi,there as i following building instruction, faced some problems: $ autoreconf -i $ mkdir test build $ cd test/ $ ../configure --enable-l4 --host=i686-pc-viengoos-gnu \ --enable-tests // this configuration successfully finished with two warning // warning - Unrecognized Options : --enable-tests $make check // first the compilations process got terminated , // compile process stopped since it couldn't find one header file // at ../../libviengoos/viengoos // i temporary fix this problem but there are still some problems // the i found that in directory="test/libviengoos" // at Makefiles , there has been used variable $(INCLUDES) but never // assigned value . $cat &lt;dir&gt;/test/libviengoos/Makefile | egrep '^INCLUDES' // but no result founded //after i called '$make check' the process show this messages on // screen make[2] : Leaving direcotry '&lt;DIR&gt;/test/libviengoos' make check-TESTS make[2] : Entering directory '&lt;DIR&gt;/test/libviengoos' Checking VG_ADDR.. ok. t-addr: ../../libviengoos/t-addr.c:52: main: Assertion '(P_ &amp; (( 1 &lt;&lt; (63 - d_)) - 1)) == 0' faild. checking vg_addr_extend.. /bin/sh: line 5: 3406 (core dumped) ${dir}$tst FAIL: t-addr Checking VG_CAP_ADDR_TRANS_SET_GUARD_SUBPAGE... ok PASS: t-addr-trans Checking RPC... ok PASS: t-rpc ================================ 1 of 3 tests failed Please report to l4-hurd&lt; at &gt;gnu.org ================================ //As i saw the &lt;dir&gt;/test/libviengoos/Makefile , //At Line 470 : if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \ // I searched for TEST_ENVIRONMENT , but it didn't assigned value before. i didn't know what goes wrong , I'm using fedora Linux and standard i686 stabled programs. give me some tips, thanks, Naghizodeh ,T.A-H ---------------- NTL.IR </pre> Naghizodeh,T.A-H 2011-04-06T17:54:58 http://comments.gmane.org/gmane.os.hurd.l4/6007 <pre>Hi there, I used qemu and Grub Legacy (floppy disk image) for running kernel with it's modules I follow mostly from the instruction on README when i try to boot on grub i saw this , it's seem the kernel going to starting , but ,it doesn't . system stop by give me this log file on the screen (i'd typed them) laden (ff0720ff):kip_fixup:54: Booting an x2 Kernel. laden (ff0720ff):kip_fixup:70: Sigma0: Low 0x20000, Hight 0x29524, IP 0x20000, SP 0x0 laden (ff0720ff):kip_fixup:75: Root: Low 0x400000, Hight 0x4d40cc, IP 0x400000, SP 0x0 laden (ff0720ff):kip_fixup:93: Memory Map 1: Type shared(4)/0, Low 0x0, Hight 0xfffffffffffffc00 laden (ff0720ff):kip_fixup:93: Memory Map 2: Type conventional(1)/0, Low 0x0, High 0x9f000 laden (ff0720ff):kip_fixup:93: Memory Map 3: Type arch(15)/2, Low 0x9f400, High 0x9fc00 laden (ff0720ff):kip_fixup:93: Memory Map 4: Type arch(15)/2, Low 0xf0000, High 0xffc00 laden (ff0720ff):kip_fixup:93: Memory Map 5: Type conventional(1)/0, Low 0x100000, High 0x7ffcc00 laden (ff0720ff):kip_fixup:93: Memory Map 6: Type arch(15)/2, Low 0x7ffd000, High 0x7fffc00 laden (ff0720ff):kip_fixup:93: Memory Map 7: Type arch(15)/2, Low 0xfffffffffffc0000, High 0xfffffffffffffc00 laden (ff0720ff):kip_fixup:93: Memory Map 8: Type shared(4)/0, Low 0xa0000, High 0xefc00 laden (ff0720ff):kip_fixup:93: Memroy Map 9: Type reserved(2)/0, Low 0x800000, High 0x23ffc00 laden (ff0720ff):main:205:Entering kernel at address 0x15a050... i'm new to your OS, and not read sources till now. help me figure this out , give me some tips . thanks, Naghizodeh ,T.A-H ---------------------------------------------------------------------------- NTL (Null Thought List) Group -www.ntl.ir </pre> Naghizodeh T.,A-H 2011-04-05T16:51:44 http://comments.gmane.org/gmane.os.hurd.l4/6004 <pre>Hi, The NOVA project is happy to announce that there is a new prerelease of the NOVA microhypervisor available for download at http://www.hypervisor.org/ or http://os.inf.tu-dresden.de/~us15/nova/ under the terms of the GNU General Public License version 2. NOVA is based on a modern microhypervisor written in C++ and assembler. The current implementation runs on multi-core x86 machines that support ACPI, under QEMU (including VM support), and as a microkernel in a virtual machine on top of itself. NOVA makes use of hardware virtualization features such as Intel VT-x/VT-d or AMD-V, and facilitates running unmodified guest operating systems in virtual machines with near-native performance. The new release brings virtual-machine support to QEMU and older AMD CPUs, both of which lack nested paging. Furthermore, the microhypervisor can now translate related capabilities during message passing. Cheers, - Udo </pre> Udo A. Steinberg 2011-02-16T21:55:10 http://comments.gmane.org/gmane.os.hurd.l4/5988 <pre>Hi, I'd like to know the status of the Viengoos project. Is it still active? Looking at git: last changeMon, 19 Jan 2009 22:34:13 +0000 The last change was made almost a year. The question is: Is there still a project for a new GNU microkernel aside GNU Mach? Is Viengoos it or are there new projects blooming? Thank You </pre> Dok Sander 2010-12-04T03:54:19 http://comments.gmane.org/gmane.os.hurd.l4/5987 <pre>Hi! I would like to help in any way I can this project. To give you an overview of my skills I am a fairly good c,c++ programmer and I have some basic understanding Operating Systems and hardware architecture. Please let me know If I can help in any way. Thank you! </pre> TDTwister Gmail 2010-08-10T20:57:01 http://comments.gmane.org/gmane.os.hurd.l4/5983 <pre>Hi, A while back in some discussion here the idea was mentioned to automatically give "foreground" applications more priority. Someone just brought up an old paper, which -- if I'm reading the abstract right -- seems to be about doing precisely that: http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/evans.txt -antrik- </pre> olafBuddenhagen< at >gmx.net 2010-06-16T19:00:54 http://comments.gmane.org/gmane.os.hurd.l4/5981 <pre>Hello, I recently ported the slab implementation in viengoos to Hurd. It seems that the refcount field of hurd_slab isn't initialized when it is created in grow(). here is the patch to fix it. Best regards, Zheng Da </pre> Da Zheng 2010-05-31T13:26:49 http://comments.gmane.org/gmane.os.hurd.l4/5973 <pre>Hello, I am looking for the licenses/licensing or links to the licenseslicensing of the Hurd, the Viengoos microkernel and the Coyotos microkernel. Thanks, Steve. </pre> steve paesani 2010-04-23T00:37:13 http://comments.gmane.org/gmane.os.hurd.l4/5966 <pre>I want to contribute my programming skills to complete GNU system. Since Hurd is the only part thats is incomplete in whole GNU system, I want to work on it. I went to this page and found there are 3 ways to contribute: http://www.gnu.org/s/hurd/contributing.html 1. Documentation 2. The System Itself 1. Hurd on Mach 1. Porting Packages 2. Open Issues 2. Hurd on a modern microkernel I chose the "Hurd on modern microkernel" as the path to walk on as I am neither interesting in web-side nor in outdated Mach. Any directions to start ? </pre> arnuld uttre 2010-04-20T10:13:36 http://comments.gmane.org/gmane.os.hurd.l4/5965 <pre>Hello, I would like to announce that Codezero v0.3 release is out and we have added support for ARMv7 architecture and SMP Cortex-A9 cpus in this release. The ARMv7 support has been tested on a Versatile Express Cortex A9 platform which contains four cores. Beagleboard support is also going to be available soon - due to omap3 non-conformity to ARMv7 a few issues left for fixing. Finally, we have preliminary support for the Genode OS Framework from Genode labs. We are improving on this and plan to show a demo of their application stack in multi-core expo next month: http://www.multicore-expo.com http://esc-sv09.techinsightsevents.com/ I would be happy to demo the software to anyone attending. Thank you, </pre> Bahadir Balban 2010-03-25T22:26:18 http://comments.gmane.org/gmane.os.hurd.l4/5964 <pre>Hello, For those going to FOSDEM, I would like to invite you to a talk I'll be giving about Iris, my new kernel. It's currently targeted at the Ben NanoNote, a very small handheld computer. For that reason, the talk is scheduled in the embedded devroom (Lameere). It's on saturday at 18:00. As you probably know, Olaf is also giving two talks, both on Sunday in the alt-OS devroom (AW1.105). Unfortunately, I will not be at the first one, because it is at the same time as the talk about RepRap, which sounds so extremely cool, I have to go there. See you this weekend, Bas </pre> Bas Wijnen 2010-02-01T14:52:09 http://comments.gmane.org/gmane.os.hurd.l4/5962 <pre> Hi I'm trying to build viengoos but am getting an error, I have followed the documentation and successfuly built the cross compiler but when I run make again to actually build viengoos itself I get: libtool: Version mismatch error. This is libtool 2.2.4, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.4 libtool: and run autoconf again. make[4]: *** [alter.lo] Error 63 make[4]: Leaving directory `/home/chris200x9/viengoos/build/benchmarks/sqlite/build' make[3]: *** [all-local] Error 2 make[3]: Leaving directory `/home/chris200x9/viengoos/build/benchmarks/sqlite' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/chris200x9/viengoos/build/benchmarks' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/chris200x9/viengoos/build' make: *** [all] Error 2 Any help would be much appriciated. </pre> chris200x9< at >aol.com 2010-01-19T16:31:25 http://comments.gmane.org/gmane.os.hurd.l4/5910 <pre>Hi All, I would like to share with you the current status of Codezero development as we make the 0.2 release. I am looking into feedback on various design issues, particularly on capabilities. I think I have understood Hurd requirements to a good extent, and Codezero has different final goals compared to the ideal kernel that Hurd needs. That said, Codezero has a lot of common grounds with Hurd kernel requirements, and I would like to focus discussion on these common areas. What I need is your opinion on our existing capability design, in any aspect. Security, usability, applicability ... We have implemented capabilities in Codezero to a good extent, and the design requires feedback (details to follow on my next email). What this will bring back to you is that you have the chance to see a live kernel that has a capability implementation with resources reduced to a useful small set (e.g. kernel resources), and one that is attempting to apply it to real practice. You will see your feedback being implemented in short periods of time, and have the opportunity to see how it behaves in real. Potentially the same work can be extended, or copied over to your _desired_ Hurd kernel later on. Think of it as a small pilot project for your future capability-based Hurd kernel. If you believe that you already have explored capability-based design to the extent that you don't need to see any further experimentation, well, you might just be interested to help. OK, so here are some final disclaimers: - The design is very rigorous, i.e. fully covering kernel resources, system calls, but only those. I think this is very useful even for Hurd, you can experiment on a small set of sample data, improve your design, and extend it. - The user API has been purposefully simplified, i.e. the capabilities are hidden as much as possible from the userspace. The average programmer need to know as little as possible about capability design. For example you don't pass a capid to a system call. You pass resource ids directly, but they get cap-checked internally. Once you want to manipulate resource allocation in the system, you then need to manipulate (unavoidably) capabilities and need to know what's going on at that level. - No protection from covert channels. This is because covert channels cannot be completely eliminated, and they are less of a focus for current discussion. I am more interested in tackling elegant resource management at this time. - The approach I took is probably different to what you have seen before on capabilities. I tried to make things as practical as possible. Please see my release email for sources and guides on the API. Thanks, </pre> Bahadir Balban 2009-12-07T12:59:38 http://comments.gmane.org/gmane.os.hurd.l4/5909 <pre>I would like to announce that Codezero Microkernel v0.2 has been released. On this release, the microkernel is now fully capability checked, and we introduced the notion of containers to provide isolated execution environments. Please see below for a brief description. 1.) Containers In Codezero containers provide the architectural infrastructure for isolation of execution environments. Each container is allocated with a set of address spaces, threads, and any other resource that would otherwise be globally available on the platform, such as virtual and physical memory. Using the simple notion of containers, it is possible to build any type of software design hierarchy. A hierarchical client/server design, or multi-threaded standalone applications are both possible scenarios. 2.) Capabilities Capabilities protect all resources maintained by the kernel. Currently, all system calls are protected by capabilities, except a few trivial ones that have been left out. Physical and virtual memory, typed memory pools, and inter-process communication are among other resources that are protected by capability checking. Capabilities build upon the foundation of containers, providing a fine-grained security architecture, inside and among container boundaries. We also introduced a capability control system call, by which the capabilities may be shared, granted and modified in different ways, enabling a highly flexible and configurable security architecture. 3.) Configuration We attempted to present the above two notions in an easily manageable kernel configuration system. Containers, their parameters and capabilities may be adjusted easily at configuration time, using our CML2-based kernel configuration system. We are aiming to evolve the L4 API into the future by feedback, hence this email post. Codezero Project is open with a GPLv3 license. If you are interested to learn more, download by: git-clone git://git.l4dev.org/codezero.git A useful jump-start guide: http://www.l4dev.org/doku.php?id=getting_started_quick API reference man pages: man -M codezero/docs/man pagename Thanks, -- Bahadir Balban </pre> Bahadir Balban 2009-12-07T13:01:38 http://comments.gmane.org/gmane.os.hurd.l4/5840 <pre>Since no one else has mentioned it yet, let me present, The Barrelfish Operating System: http://barrelfish.org/ As described in this paper: http://barrelfish.org/barrelfish_sosp09.pdf "We investigate a new OS structure, the multikernel, that treats the machine as a network of independent cores, assumes no inter-core sharing at the lowest level, and moves traditional OS functionality to a distributed system of processes that communicate via message-passing." This paper describes the use of DSLs and DSL -&gt; C compilers written in Haskell to generate low-level kernel code: http://www.barrelfish.org/fof_plos09.pdf The aim is to be able to build provably correct DSLs and compilers fast enough that you would actually prefer to use them as part of the development process instead of just doing the low-level C code by hand. - jeremy </pre> Jeremy Shaw 2009-10-02T15:33:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.hurd.l4