From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- faq/sata_disk_drives/discussion.mdwn | 92 ++++++++++++++- faq/which_microkernel/discussion.mdwn | 203 +++++++++++++++++++++++++++++++++- 2 files changed, 293 insertions(+), 2 deletions(-) (limited to 'faq') diff --git a/faq/sata_disk_drives/discussion.mdwn b/faq/sata_disk_drives/discussion.mdwn index d05566b6..0b56f235 100644 --- a/faq/sata_disk_drives/discussion.mdwn +++ b/faq/sata_disk_drives/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 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 @@ -256,3 +256,93 @@ License|/fdl]]."]]"""]] youpi: hm, I think my board has no ahci controller, linux uses the sata_via module to talk to it :/ ah :/ + + +# IRC, freenode, #hurd, 2014-02-05 + + teythoon: i don't completely trust the driver + oh ? + it doesn't work on my laptop, and i had a failure once on a "big" + partition of 128G + hm + my hardware does not implement ahci, but in qemu it works fine + for me + well qemu is the only supported "hardware" + but then my partitions are not that big + braunr: no, it does work on my laptop too + ok + + +# IRC, freenode, #hurd, 2014-02-12 + + youpi: hum, sorry to ask but how do you use qemu to provide sata ? + braunr: there's an important trick: getting it on another IRQ than + the eth0 board :/ + -device ahci,id=ahci1 + for nothing + -device ahci,id=ahci2 + -drive id=root,file=/dev/${HDA}7,cache=writeback,if=none + -device ide-drive,drive=root,bus=ahci2.1 + ok that's close enough to what i have + but + i'm using /dev/sda as the backend + instead of a regular file + sda already containing a regular debian linux system + and grub2 can't boot because it seems to fail reading the + partition table + it works perfectly when accessing it as an ide disk though + youpi: do you see any reason why grub would fail with ahci ? + also, why ahci2._1_ instead of 0 ? + youpi: fyi, the cd installer always booted fine here, both on my + workstation and my laptop, i did about 50 tries on each machine + the graphical mode doesn't seem to work though + youpi: fyi2 the grub related issue i'm having is + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692249 + I'm using .1 because I have a /boot .0 before the / .1 :) + humm + you have two drives ? + braunr: (cd installer): you mean, even in semi-graphical mode? + one for /boot and the other for / ? + I have 3 actually :) + youpi: no, xorg + ok i se + see + (cd installer) I'm talking about the working ones :) + I know xorg does not boot + ok + so apparently, adding ,boot=on to the -drive parameter did the + trick + k + and now, i have a hurd system running from /dev/sda5 (the real + disk) in qemu + for the pseudo-graphical console, I guess his monitor is too dumb + to be able to display 640x400 + possible + most probably because no OS uses that any more nowadays :/ + (and that won't get better) + so now i can debug ahci on my laptop using that :) + + youpi: is there a known limit to the size of an ahci drive in the + gnumach driver ? + in the driver itself, it's simply lba48 + but the mach interface uses 32bit sector number + thus 2TB limit + that's plenty :) + I have a 2TB drive :) + so it won't be plenty for long + 2TB for your hurd system ? + no, for my backups etc. + i meant plenty for our hurd instances + but there could have been a hurd vm there + and not necesseraly below 2TiB + + hm, the installer doesn't detect existing partitions on an ahci + drive :/ + + +## IRC, freenode, #hurd, 2014-02-13 + + youpi: looks like linux has trouble handling my ahci drive without + ioapic/msi + no wonder gnumach can't either + erf diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn index ffdc6720..338da7d8 100644 --- a/faq/which_microkernel/discussion.mdwn +++ b/faq/which_microkernel/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011, 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 @@ -13,6 +14,65 @@ License|/fdl]]."]]"""]] [[!toc]] +# IRC, freenode, #hurd, 2011-01-12 + + Hello i am just curious of the development of Hurd - what's the + current mission on the microkernel i see projects like l4 and viengoos, + will one of these projects replace Mach? or will you stick with Mach + as i understand is that Mach is a first generation microkernel + that's very old in design and causes alot of issues + that's where l4 and viengoos comes in - they are trying to be the + next generation Mach - am i correct? + l4 is not a drop in replacement for Mach + it doesn't actually do much resource management + for instance, you still have to implement a memory manager + this is where several issues are with Mach + l4 doesn't address those issues; it punts to the operating system + and what about viengoos? + it's unfinished + and it implemented some untested ideas + i.e., parts of viengoos were research + there has not been a sufficient evaluation of those ideas to + determine whether they are a good approach + meaning that viengoos is a research kernel that could aid Mach? + I'm not sure I understand your question + Well is viengoos trying to be a replacement for Mach, or will + viengoos be an experiment of new ideas that could be implemented in Mach? + i am sorry for my limited english + viengoos was designed with a Hurd-like user-land in mind + in that sense it was a Mach replacement + (unlike L4) + viengoos consisted of a few experiments + one could implement them in mach + but it would require exposing new interfaces + in which case, I'm not sure you could call the result Mach + Well as i understand you develop two microkernels side by side, + wouldnt it be more effective to investigate viengoos more and maybe move + the focus to viengoos? + no + having something working all the time is crucial + it's very hard to motivate people to work on a project that might + be useful, in a couple of years, perhaps... + Well Mach is meant to be replaced one day - i see no reason to + keep on developing it just because it works at this moment + *if Mach is meant to be replaced + it's not at all clear that it will be replaced by something + completely different. I for my part believe that modifying the existing + Mach is a more promising approach + as i understand man power is something you need - and by spreading + out the developers just makes the progress more slow + but even if it *were* to be replaced one day, it doesn't change + the fact that we need it *now* + all software will be obsolete one day. doesn't mean it's not worth + working on + the vast majority of work is not on the microkernel anyways, but + on the system running on top of it + ahh i see + manpower is not something that comes from nowhere. again, having + something working is crucial in a volunteer project like this + there are no fixed plans + + # Olaf, 2011-04-10 This version mixes up three distinct phases: rewrite from scratch; redesign; @@ -118,3 +178,144 @@ please discuss them... Xnu implements a few improvements that might be helpful; but it doesn't address the really fundamental issues that matter for a true multiserver system... + + +# IRC, freenode, #hurd, 2014-02-04 + + Is hurd still using the Mach Microkernel? + I am assuming the L4 port failed? + yes / yes, i believe so + I am currently working as an intern on seL4 a verified + microkernel variant of L4. + I was sort of interested as to why the port failed if there are + any old mailing list posts etc. + Obviously if it is too much trouble to dig them up that is + understandable. + most interesting, i'm interested in software verification as + well :) + there's some stuff in the wiki + (I am writing a multiserver atm on top of it) + + http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html + Awesome thanks. + bwright: iirc, l4 lacked some important asynchronous stuff + the all synchronous model proved insufficient for an efficient + posix conforming system + Yep, posix can get very annoying in places. + Variants of l4 have async stuff that could probably work. + okl4 is the only one i know of that does this + but it may not have been the only issue + That is the one I am working with :p + the l4-hurd mailing list archives should tell you more about this + Great :D + Going to read through them and look into it. + there was also an attempt on coyotos which failed for other + reasons related to the overall security mechanisms of the system iirc + enjoy ;p + On a side note I am also very interested in Multiservers. + so are we :) + I wouldn't mind hacking on hurd for fun in my spare time. + it would probably be appreciated + Currently porting a fuse implementation to L4 which is taking all + my time. But might hang out in the chat and mess around where I can. + + +## IRC, freenode, #hurd, 2014-02-06 + + bwright: the original l4hurd was abandoned because original L4 + didn't have any capability support, and implementing them in userspace + turned out too complex and too much overhead + capability-enhanced L4 variants were only emerging at that time; + and while they were evaluated briefly, the Hurd/L4 initiators turned to + other ideas instead. the feasability of a Hurd port on a modern L4 + variant was never evaluated deeply + ultimately, the conclusion was that system design and microkernel + design are interwoven very tightly, and it doesn't make sense to try to + build something as complex as the Hurd on top of a microkernel not + specifically designed for it + (this is in fact the same reason why the original Hurd on Mach + turned out so problematic...) + antrik: fwiw i agree with what you said but it's a good idea to + keep stuff like genode in mind, in fact i'd go as far as saying that in a + microkernel it's a good thing to have interchangeable modules that can be + easily swapped :) + + +# IRC, freenode, #hurd, 2014-02-09 + + braunr: would you share your negative opinions about + disadvantages of the existing L4s? A link to a dicussion is also fine of + course. I know my questions might be annoying, since im not deeply into + the materia yet. But Im interested in working on a open source kernel & + OS alternative suitable for mid/long term requirements, after I was + struggling with many deficits of monolithic kernels for years. + cusement: there are two i know of: 1/ many of them are purely + synchronous, a property that makes it hard to provide some async unix + facilities like signals or select and 2/ they don't implement + capabilities, merely thread-based messaging, so capabilities would have + to be implemented in user space + i was recently reasearching for alternatives, since i am simply + fed up with the chaotic situation with the Linux kernel + like Mach, XNU , ... + well, im still doing my research on alternatives, ATM i simply + found L4 to have more future potential than Mach + cusement: can i ask you why you think that ? + for example i like the fact that there is (at least one) L4 + variant that is proofen "right" on theoretical basis, since i am very + interested in creating a system with high security + cusement: what do you think does the formal proof bring to a piece + of code that is, by definition, small enough to be easily audited ? + braunr: statistics. i could also write a small piece of parser + manually, but when it comes to security, i rather prefer a parser + generator, since it ensures that it will actually create a parser that + will be secure, no metter with which grammar definition i feed it + cusement: i agree, but the part of the system it covers is so + small it requires more justification + cusement: any other main reason ? + (we're not going to debate the merits of sel4 right now :)) + cusement: if you are experienced in Linux device drivers, maybe you + want to check out DDE? + braunr: well, i first actually have to check what the precise + scope of the L4 proof was to judge about its importance. I actually just + started to re-spawn my interest in micro kernels after years where i + abondened it for myself as being not practical relevant. + ok + azeem: that was actually one of the biggest reasons for me to + look at HURD. Because i am very unhappy about the chaotic driver + situation in Linux, with no isolation whatsoever. + cusement: the hurd design is focused on quite more than that + cusement: it's a property of practically all multiserver systems + out there to isolate each other + other properties makes the hurd apart + braunr: i know, but there also hybrids like XNU where drivers + are still in kernel space + i don't consider xnu to be a multiserver system + braunr: well, xnu also runs various fundamental services as + separate tasks / servers + cusement: let me check + xnu is mach based, and every mach derivative uses a multiserver + design, doesnt it? + no + practically all mach based systems were monoliths in userspace + you mean kernel space + cusement: certainly at least the NeXT/OS X Mach-based setup is not + very multiserver + cusement: no i mean userspace + darwin and mac os x are good examples of such systems + braunr: so you mean individual fundamental OS tasks on XNU are + actually just processed by one server + havent really digged too deep in XNU, because of its monolithic + driver concept + cusement: yes + it's basically a bsd server on top of mach + ok, got it + braunr: OS X actually runs the UNIX server in kernel space as well + AFAIK + + +## IRC, freenode, #hurd, 2014-02-10 + + braunr: I believe all the "modern" L4 variants have some kind of + capability support -- though they differ in the details, and when Marcus + and Neal did the initial evaluation of the first two of them, it was not + yet clear yet whether it would suffice for the needs of the Hurd... -- cgit v1.2.3