[[!meta copyright="Copyright © 2012, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] Instead of attempting a [[history/port_to_another_microkernel]], or writing an own one, an implementation of a Hurd system could use another existing operating system/kernel, like [[UNIX]], for example, the Linux kernel. This is not a [[microkernel]], but that is not an inherent hindrance; depending on what the goals are. There has been an attempt for building a [[Mach_on_top_of_POSIX]]. # IRC, freenode, #hurd, 2012-02-08 Richard's X-15 Mach re-implementation: and in case you didn't notice, it's stalled actually i don't intend to work on it for the time being i'd rather do as neal suggested: take linux, strip it, and give it a mach interface (if your goal really is to get something usable for real world tasks) braunr: why would you want to strip down Linux? I think one of the major benefits of building a Linux-Frankenmach would be the ability to use standard Linux functionality alongside Hurd... we could have a linux x86_64 based mach replacement in "little" time, with a compatible i386 interface for the hurd antrik: well, many of the vfs and network subsystems would be hard to use BTW, one of the talks at FOSDEM was about the possibility of using different kernels for Genode, and pariticularily focused on the possibilities with using Linux... unfortunately, I wasn't able to follow the whole talk; but they mentioned similar possibilities to what I'm envisioning here :-) ## IRC, freenode, #hurd, 2012-03-28 is there currently any work going on with respect to Mach-alternatives? mel__: no we have other priorities to take care of :-) antrik: i still intend to try giving linux a "mach personality" :) antrik: but i don't have much time for development currently :( antrik: which means that the hope is that Mach can be turned into something really well working (i.e. secure/scalable/etc.)? mel__: yes, that's the venue we are pursuing (and IMHO the right one... though the Linux layer mentioned by braunr is also one of my favourite projects, that we should pursue *in parallel* to the existing Mach-based implementation) what is this Linux Layer exactly? a Linux instance running on top of Mach in parallel to Hurd serverS? mel__: not exactly mel__: it would involve adding a mach layer on top of linux actually mel__: so that linux can be used as a mach kernel Ah! Running Hurd on top of Linux :-D Funny ironic, yes but very pragmatic and THEN yeah. I most like the name: Hurd Emulation Layer on Linux... i.e. HELL :-) we use a device driver framework something so that we can use Linux device drivers in Hurd! on top of Linux.... yes i guess a transition phase would include using in kernel drivers directly for a while and somebody is working on that? mel__: well, for using Linux drivers we are persuing DDE, which allows us doing that with Mach as well then grabbing them out of the kernel and into dde not yet (in fact we have been using Linux drivers since forever... they just haven't been updated for ages) I would _guess_ that it is not that hard. it's not Basically one would need to implement the message passing interface thing in linux I guess. and many exported kernel objects like tasks, threads, etc.. and implement all the RPCs normally implemented by the kernel but it's doable mel__: the IPC aspect is one part, but probably the less tricky one. the external pager interface is really the crucial element uh yeah hooking into linux virtual memory stuff sounds delicate it's true that some interactions between the linux VM and file systems (the linux equivalent of our pagers) is synchronous but i don't think it would be that hard considering the amount of facilities available in linux it's just work, takes time, needs debugging, reviewing, testing, etc.. hurd on top of linux. how would that work? 15:30 < braunr> antrik: i still intend to try giving linux a "mach personality" :) lcc: 7 system calls and a few hundreds of RPCs on top, the internal magic of course, and voila .. of course porting Mach still requires work that would then be GNU/Hurd/Linux :-) hehe eh braunr: BTW, are you more thinking of a userspace solution on top of standard Linux mechanisms, or additions to Linux itself?... (we probably talked about it already, but I don't remember all the details...) antrik: adding to linux do you think a pure userspace solution would be realistic at all? (at the expense of some performance of course) it's probably comparable to the qemu vs. qemu/kvm thing yeah, I guess that pretty much sums it up... antrik: i don't know :/ OK how challenging is it to port mach? lcc: it requires good low-level knowledge of the platform in question. having that, I guess it shouldn't be too hard to add the necessary code in Mach... TBH I'm not sure how much knowledge of Mach internals is required the pmap module is the main thing to port braunr: well, sartakov seemed to have most trouble with the scheduler when he attempted the ARM port... that's strange at least there was quite a long thread where he asked about how task switching works in Mach ok that would be interesting i thought intereacting with the hardclock was enough ## IRC, freenode, #hurd, 2012-04-05 antrik: don't you think HELL is worth a try for the GSoC btw ? braunr: definitely. I haven't managed to rework the project ideas list at all this year... but it's something I wanted there for a long time just out of curiousity, what is HELL ? Hurd Emulation Layer on Linux youngrw: it can be described in several ways youngrw: basically, it's a mach interface on top of linux implementing I suppose both the IPC mechanism and memory management interface? youngrw: basically that. more generally: implement everything in order to let Hurd run on that layer. well, it's slightly more complicated in my view... it's basically anything that allows running a Hurdish environment on top of GNU/Linux. it might be simply an implementation/emulation of Mach mechanisms; but it also *might* work on a slightly higher level... antrik: how might HELL operate at the slighty higher level like you describe? let's call it low-level HELL and high-level HELL ;-) (a more descriptive name would be hurdenv... but HELL is so much more catchy :-) ) so, high-level HELL... basically, the idea would be not to emulate the kernel facilities and run all the real Hurd servers; but instead to use special servers implementing the Hurd interfaces, but on top of standard Linux facilities hurdish programs could run in such an environment, as long as they aren't too low-level I wonder whether generic RPC interfaces could be implemented with some side channel tunneled though the ordinary Linux FS interfaces... so translators would be loaded as FUSE modules for example, but could still present generic interfaces That's actually pretty different from what I was expecting what were you expecting? maybe something where the entire kernel interface is emulated by a running user process, like a kind of virtual machine I hope that makes sense--I may be using my words incorrectly. youngrw: that would be in the low-level HELL category antrik: right; I had the misconception that the level was defined by how it made use of the underlying linux system and that different HELL designs would always implement the mach interface ## IRC, freenode, #hurd, 2012-04-06 antrik: i think we have diverging ideas about how to use linux for the hurd antrik: what you seem to want are really emulation componants, like e.g. ext2fs and pfinet actually using the linux implementation (correct me if i'm mistaken) whereas my project is to make linux behave as a mach clone braunr: as I said, I consider both variants -- either a high-level HELL or a low-level HELL ok (or perhaps a mix of both) a mix would be best imho yeah, probably so we have the real hurd, the real mach interface, and a set of native translators (e.g. ext2fs) along some emulating their functionality using linux code (e.g. a hypothetical ext4fs) I don't think we would have emulation servers for individual Linux filesystems. rather, a generic server interfacing with the Linux VFS tree... ok braunr: BTW, I think I mentioned a couple of years ago that the most realistic route towards a modern Mach in my opinion would be taking a modern BSD (or Linux), and redo what the original Mach developers did -- i.e. add the Mach-specific features, and drop the unnecessary UNIX stuff antrik: :) we had discussions about it some time ago yes later I realised that it's better *not* to drop the UNIX interfaces, but rather to keep them in parallel :-) antrik: for what purpose ? (i can imagine a few, but i'd like to know your idea) for the purpose of HELL :-) well hell would be the implementation, but what do you keep these unix interfaces for ? i.e. people being able to play around with a Hurd environment while staying with their existing system yes, i see i was considering doing that for development, yes uml first, and then i realized i wouldn't need it :) then i remembed netbsd and its syscall emulation layer also we might leverage some "foreign" userspace infrastructure that way, such as udev (in the case of Linux that is... not sure whether NetBSD has something similar at all ;-) ) i'll have to check, it's been a long time since i've really used it they must use a pure devfs instance now # IRC, freenode, #hurd, 2014-02-23 so crazy idea: would it be possible to have mach as a linux kernel module? ie: some new binfmt type thing that could load mach binaries and implement the required kernel ABI for them and then run the entire hurd under that.... desrt: that's an idea, yes and not a new one * desrt did a bit of googling but didn't find any information about it desrt: but why are you thinking of it ? we talked about it here, informally braunr: mostly because running hurd in a VM sucks if we had mach-via-linux, we'd have: - no vm overhead - no device virtualisation - 64bit (physical at least) memory support - SMP - access to the linux drivers, natively and maybe some other nice things yes we talkbed about all this but i still consider that to be an incomplete solution i don't consider it to be running "the hurd" as your OS... but it would be a nice solution for development and virtualisation we probably don't want to use drivers natively, since we want them to run in their own address space, with their own namespace context it would, certainly but it would require a lot of effort anyway right