diff options
Diffstat (limited to 'open_issues/linux_as_the_kernel.mdwn')
| -rw-r--r-- | open_issues/linux_as_the_kernel.mdwn | 195 |
1 files changed, 195 insertions, 0 deletions
diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn index f14b777e..1d84d777 100644 --- a/open_issues/linux_as_the_kernel.mdwn +++ b/open_issues/linux_as_the_kernel.mdwn @@ -40,3 +40,198 @@ Richard's X-15 Mach re-implementation: the whole talk; but they mentioned similar possibilities to what I'm envisioning here :-) + +## IRC, freenode, #hurd, 2012-03-28 + + <mel__> is there currently any work going on with respect to + Mach-alternatives? + <antrik> mel__: no + <antrik> we have other priorities to take care of :-) + <braunr> antrik: i still intend to try giving linux a "mach personality" :) + <braunr> antrik: but i don't have much time for development currently :( + <mel__> antrik: which means that the hope is that Mach can be turned into + something really well working (i.e. secure/scalable/etc.)? + <antrik> mel__: yes, that's the venue we are pursuing + <antrik> (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) + <mel__> what is this Linux Layer exactly? + <mel__> a Linux instance running on top of Mach in parallel to Hurd + serverS? + <braunr> mel__: not exactly + <braunr> mel__: it would involve adding a mach layer on top of linux + actually + <braunr> mel__: so that linux can be used as a mach kernel + <mel__> Ah! + <mel__> Running Hurd on top of Linux + <mel__> :-D + <mel__> Funny + <braunr> ironic, yes + <braunr> but very pragmatic + <mel__> and THEN + <antrik> yeah. I most like the name: Hurd Emulation Layer on + Linux... i.e. HELL :-) + <mel__> we use a device driver framework something so that we can use Linux + device drivers in Hurd! + <mel__> on top of Linux.... + <braunr> yes + <braunr> i guess a transition phase would include using in kernel drivers + directly for a while + <mel__> and somebody is working on that? + <antrik> mel__: well, for using Linux drivers we are persuing DDE, which + allows us doing that with Mach as well + <braunr> then grabbing them out of the kernel and into dde + <braunr> not yet + <antrik> (in fact we have been using Linux drivers since forever... they + just haven't been updated for ages) + <mel__> I would _guess_ that it is not that hard. + <braunr> it's not + <mel__> Basically one would need to implement the message passing interface + thing in linux I guess. + <braunr> and many exported kernel objects like tasks, threads, etc.. + <braunr> and implement all the RPCs normally implemented by the kernel + <braunr> but it's doable + <antrik> mel__: the IPC aspect is one part, but probably the less tricky + one. the external pager interface is really the crucial element + <mel__> uh + <mel__> yeah + <mel__> hooking into linux virtual memory stuff + <mel__> sounds delicate + <braunr> it's true that some interactions between the linux VM and file + systems (the linux equivalent of our pagers) is synchronous + <braunr> but i don't think it would be that hard considering the amount of + facilities available in linux + <braunr> it's just work, takes time, needs debugging, reviewing, testing, + etc.. + <lcc> hurd on top of linux. how would that work? + <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach + personality" :) + <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the + internal magic of course, and voila .. + <antrik> of course porting Mach still requires work + <mel__> that would then be GNU/Hurd/Linux + <mel__> :-) + <antrik> hehe + <braunr> eh + <antrik> braunr: BTW, are you more thinking of a userspace solution on top + of standard Linux mechanisms, or additions to Linux itself?... + <antrik> (we probably talked about it already, but I don't remember all the + details...) + <braunr> antrik: adding to linux + <antrik> do you think a pure userspace solution would be realistic at all? + (at the expense of some performance of course) + <mel__> it's probably comparable to the qemu vs. qemu/kvm thing + <antrik> yeah, I guess that pretty much sums it up... + <braunr> antrik: i don't know :/ + <antrik> OK + <lcc> how challenging is it to port mach? + <antrik> 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... + <antrik> TBH I'm not sure how much knowledge of Mach internals is required + <braunr> the pmap module is the main thing to port + <antrik> braunr: well, sartakov seemed to have most trouble with the + scheduler when he attempted the ARM port... + <braunr> that's strange + <antrik> at least there was quite a long thread where he asked about how + task switching works in Mach + <braunr> ok + <braunr> that would be interesting + <braunr> i thought intereacting with the hardclock was enough + + +## IRC, freenode, #hurd, 2012-04-05 + + <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ? + <antrik> 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 + + <youngrw> just out of curiousity, what is HELL ? + <antrik> Hurd Emulation Layer on Linux + <braunr> youngrw: it can be described in several ways + <braunr> youngrw: basically, it's a mach interface on top of linux + <youngrw> implementing I suppose both the IPC mechanism and memory + management interface? + <mel__> youngrw: basically that. more generally: implement everything in + order to let Hurd run on that layer. + <antrik> 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... + <youngrw> antrik: how might HELL operate at the slighty higher level like + you describe? + <antrik> let's call it low-level HELL and high-level HELL ;-) + <antrik> (a more descriptive name would be hurdenv... but HELL is so much + more catchy :-) ) + <antrik> 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 + <antrik> hurdish programs could run in such an environment, as long as they + aren't too low-level + <antrik> I wonder whether generic RPC interfaces could be implemented with + some side channel tunneled though the ordinary Linux FS interfaces... + <antrik> so translators would be loaded as FUSE modules for example, but + could still present generic interfaces + <youngrw> That's actually pretty different from what I was expecting + <antrik> what were you expecting? + <youngrw> maybe something where the entire kernel interface is emulated by + a running user process, like a kind of virtual machine + <youngrw> I hope that makes sense--I may be using my words incorrectly. + <antrik> youngrw: that would be in the low-level HELL category + <youngrw> antrik: right; I had the misconception that the level was defined + by how it made use of the underlying linux system + <youngrw> and that different HELL designs would always implement the mach + interface + + +## IRC, freenode, #hurd, 2012-04-06 + + <braunr> antrik: i think we have diverging ideas about how to use linux for + the hurd + <braunr> antrik: what you seem to want are really emulation componants, + like e.g. ext2fs and pfinet actually using the linux implementation + <braunr> (correct me if i'm mistaken) + <braunr> whereas my project is to make linux behave as a mach clone + <antrik> braunr: as I said, I consider both variants -- either a high-level + HELL or a low-level HELL + <braunr> ok + <antrik> (or perhaps a mix of both) + <braunr> a mix would be best imho + <antrik> yeah, probably + <braunr> 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) + <antrik> I don't think we would have emulation servers for individual Linux + filesystems. rather, a generic server interfacing with the Linux VFS + tree... + <braunr> ok + + <antrik> 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 + <braunr> antrik: :) + <braunr> we had discussions about it some time ago yes + <antrik> later I realised that it's better *not* to drop the UNIX + interfaces, but rather to keep them in parallel :-) + <braunr> antrik: for what purpose ? + <braunr> (i can imagine a few, but i'd like to know your idea) + <antrik> for the purpose of HELL :-) + <braunr> well hell would be the implementation, but what do you keep these + unix interfaces for ? + <antrik> i.e. people being able to play around with a Hurd environment + while staying with their existing system + <braunr> yes, i see + <braunr> i was considering doing that for development, yes + <braunr> uml first, and then i realized i wouldn't need it :) + <braunr> then i remembed netbsd and its syscall emulation layer + <antrik> also we might leverage some "foreign" userspace infrastructure + that way, such as udev + <antrik> (in the case of Linux that is... not sure whether NetBSD has + something similar at all ;-) ) + <braunr> i'll have to check, it's been a long time since i've really used + it + <braunr> they must use a pure devfs instance now |