diff options
Diffstat (limited to 'faq')
| -rw-r--r-- | faq/debugging_translators.mdwn | 2 | ||||
| -rw-r--r-- | faq/how_many_developers.mdwn | 7 | ||||
| -rw-r--r-- | faq/libpthread_dlopen.mdwn | 2 | ||||
| -rw-r--r-- | faq/old_faq.txt | 10 | ||||
| -rw-r--r-- | faq/release.mdwn | 13 | ||||
| -rw-r--r-- | faq/sata_disk_drives/discussion.mdwn | 110 | ||||
| -rw-r--r-- | faq/which_microkernel/discussion.mdwn | 203 |
7 files changed, 331 insertions, 16 deletions
diff --git a/faq/debugging_translators.mdwn b/faq/debugging_translators.mdwn index 1a9de256..3cb4a2ef 100644 --- a/faq/debugging_translators.mdwn +++ b/faq/debugging_translators.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn index da457d96..9e079852 100644 --- a/faq/how_many_developers.mdwn +++ b/faq/how_many_developers.mdwn @@ -67,3 +67,10 @@ We're an open project: any interested party (*you*!) are very welcome to start Likewise, for reaching out to new developers, we're participating in [[Google's Summer of Code program|community/gsoc]]. + +As *el_presidente* commented on +<http://lwn.net/Articles/568745/#CommAnchor568780>: + +> Developers, developers, developers, developers. +> +> They are the people that matter at this point in time. diff --git a/faq/libpthread_dlopen.mdwn b/faq/libpthread_dlopen.mdwn index a959ad37..94d091a4 100644 --- a/faq/libpthread_dlopen.mdwn +++ b/faq/libpthread_dlopen.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 diff --git a/faq/old_faq.txt b/faq/old_faq.txt index 98c605eb..e370277e 100644 --- a/faq/old_faq.txt +++ b/faq/old_faq.txt @@ -18,8 +18,8 @@ users when they are talking about, installing, using, compiling and developing the GNU Hurd as well as its binary distribution Debian GNU/Hurd. Be sure to read this before asking for help. -The GNU Hurd is under active development and a stable version has not -yet been released. Be aware that: there is a lot of work yet to be +The GNU Hurd is under active development. +Be aware that there is a lot of work yet to be completed; you will find bugs; your system will crash. That said, there is a lot of room for contributions at all levels: development of the Hurd and Mach proper, porting applications, writing documentation and, @@ -406,7 +406,7 @@ at: ?? What is OSKit-Mach? -{NHW,FH} There are two versions of GNU Mac that are in use: GNU Mach +{NHW,FH} There have once been two versions of GNU Mach developed: GNU Mach 1.x and GNU Mach 2.x, formerly known as OSKit-Mach. The former uses the drivers from Linux 2.0.x while the latter uses the University of Utah's OSKit library for drivers. You can find out more about the @@ -414,9 +414,7 @@ OSKit library at: http://www.cs.utah.edu/flux/oskit -GNU Mach 2.x is usable, but some things are still missing or not -working, like the serial port and scsi drivers. This is why GNU Mach -2.0 hasn't released yet and the two versions coexist. +The project didn't work out too well, so development has again been halted. ?? Where is the documentation? diff --git a/faq/release.mdwn b/faq/release.mdwn index 9e5cc348..6ec26925 100644 --- a/faq/release.mdwn +++ b/faq/release.mdwn @@ -12,11 +12,12 @@ License|/fdl]]."]]"""]] [[!meta title="When will the Hurd be released?"]] -0.5 was released on 2013 September 27th. +0.5 has been [[released on 2013-09-27|news/2013-09-27]]. Read about the +[[Hurd's status|hurd/status]]. -*OK, but when will it be finished?* +> OK, but when will it be finished? -Well, is Linux considered to be really "finished"? Hurd 0.5 does work, of course -it can become better, thanks for joining us to achieve that :) - -You can also read about the Hurd's [[hurd/status]]. +Well, is the Linux kernel considered to be really "finished"? Hurd 0.5 does +work, but of course it can still become better -- beginning to +[[contribute|contributing]] and [[joining us|how_many_developers]] is the best +way for you to help achieve that. :-) diff --git a/faq/sata_disk_drives/discussion.mdwn b/faq/sata_disk_drives/discussion.mdwn index e9da8560..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 @@ -238,3 +238,111 @@ License|/fdl]]."]]"""]] <braunr> i'll stick with ide for now, but at least setting sata with libvirt was quite easy to do <braunr> so we can easily switch later + + +## IRC, freenode, #hurd, 2013-10-22 + + <teythoon> youpi: do I need to do anything to enable the ahci driver? + gnumach 1.4 should include it, right? + <youpi> it should, yes + <youpi> make sure to put your board in ahci mode, not raid mode + <youpi> (and not ata mode) + <teythoon> youpi: hm, I will try to do so + <teythoon> youpi: does the driver print anything to the console? + <youpi> teythoon: yes, AHCI SATA 00:04.0 BAR 0xfebf1000 IRQ 11 + <teythoon> youpi: well, the bios has two modes of operation, 'raid' and + 'ide', I selected 'ide' + <youpi> ergl + <teythoon> youpi: hm, I think my board has no ahci controller, linux uses + the sata_via module to talk to it :/ + <youpi> ah :/ + + +# IRC, freenode, #hurd, 2014-02-05 + + <braunr> teythoon: i don't completely trust the driver + <teythoon> oh ? + <braunr> it doesn't work on my laptop, and i had a failure once on a "big" + partition of 128G + <teythoon> hm + <teythoon> my hardware does not implement ahci, but in qemu it works fine + for me + <braunr> well qemu is the only supported "hardware" + <teythoon> but then my partitions are not that big + <youpi> braunr: no, it does work on my laptop too + <braunr> ok + + +# IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: hum, sorry to ask but how do you use qemu to provide sata ? + <youpi> braunr: there's an important trick: getting it on another IRQ than + the eth0 board :/ + <youpi> -device ahci,id=ahci1 + <youpi> for nothing + <youpi> -device ahci,id=ahci2 + <youpi> -drive id=root,file=/dev/${HDA}7,cache=writeback,if=none + <youpi> -device ide-drive,drive=root,bus=ahci2.1 + <braunr> ok that's close enough to what i have + <braunr> but + <braunr> i'm using /dev/sda as the backend + <braunr> instead of a regular file + <braunr> sda already containing a regular debian linux system + <braunr> and grub2 can't boot because it seems to fail reading the + partition table + <braunr> it works perfectly when accessing it as an ide disk though + <braunr> youpi: do you see any reason why grub would fail with ahci ? + <braunr> also, why ahci2._1_ instead of 0 ? + <braunr> youpi: fyi, the cd installer always booted fine here, both on my + workstation and my laptop, i did about 50 tries on each machine + <braunr> the graphical mode doesn't seem to work though + <braunr> youpi: fyi2 the grub related issue i'm having is + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692249 + <youpi> I'm using .1 because I have a /boot .0 before the / .1 :) + <braunr> humm + <braunr> you have two drives ? + <youpi> braunr: (cd installer): you mean, even in semi-graphical mode? + <braunr> one for /boot and the other for / ? + <youpi> I have 3 actually :) + <braunr> youpi: no, xorg + <braunr> ok i se + <braunr> see + <youpi> (cd installer) I'm talking about the working ones :) + <youpi> I know xorg does not boot + <braunr> ok + <braunr> so apparently, adding ,boot=on to the -drive parameter did the + trick + <youpi> k + <braunr> and now, i have a hurd system running from /dev/sda5 (the real + disk) in qemu + <youpi> for the pseudo-graphical console, I guess his monitor is too dumb + to be able to display 640x400 + <braunr> possible + <youpi> most probably because no OS uses that any more nowadays :/ + <youpi> (and that won't get better) + <braunr> so now i can debug ahci on my laptop using that :) + + <braunr> youpi: is there a known limit to the size of an ahci drive in the + gnumach driver ? + <youpi> in the driver itself, it's simply lba48 + <youpi> but the mach interface uses 32bit sector number + <youpi> thus 2TB limit + <braunr> that's plenty :) + <youpi> I have a 2TB drive :) + <youpi> so it won't be plenty for long + <braunr> 2TB for your hurd system ? + <youpi> no, for my backups etc. + <braunr> i meant plenty for our hurd instances + <youpi> but there could have been a hurd vm there + <youpi> and not necesseraly below 2TiB + + <braunr> hm, the installer doesn't detect existing partitions on an ahci + drive :/ + + +## IRC, freenode, #hurd, 2014-02-13 + + <braunr> youpi: looks like linux has trouble handling my ahci drive without + ioapic/msi + <braunr> no wonder gnumach can't either + <youpi> 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 + + <Pete-J> 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 + <Pete-J> as i understand is that Mach is a first generation microkernel + that's very old in design and causes alot of issues + <Pete-J> that's where l4 and viengoos comes in - they are trying to be the + next generation Mach - am i correct? + <neal> l4 is not a drop in replacement for Mach + <neal> it doesn't actually do much resource management + <neal> for instance, you still have to implement a memory manager + <neal> this is where several issues are with Mach + <neal> l4 doesn't address those issues; it punts to the operating system + <Pete-J> and what about viengoos? + <neal> it's unfinished + <neal> and it implemented some untested ideas + <neal> i.e., parts of viengoos were research + <neal> there has not been a sufficient evaluation of those ideas to + determine whether they are a good approach + <Pete-J> meaning that viengoos is a research kernel that could aid Mach? + <neal> I'm not sure I understand your question + <Pete-J> 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? + <Pete-J> i am sorry for my limited english + <neal> viengoos was designed with a Hurd-like user-land in mind + <neal> in that sense it was a Mach replacement + <neal> (unlike L4) + <neal> viengoos consisted of a few experiments + <neal> one could implement them in mach + <neal> but it would require exposing new interfaces + <neal> in which case, I'm not sure you could call the result Mach + <Pete-J> 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? + <antrik> no + <antrik> having something working all the time is crucial + <antrik> it's very hard to motivate people to work on a project that might + be useful, in a couple of years, perhaps... + <Pete-J> 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 + <Pete-J> *if Mach is meant to be replaced + <antrik> 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 + <Pete-J> as i understand man power is something you need - and by spreading + out the developers just makes the progress more slow + <antrik> but even if it *were* to be replaced one day, it doesn't change + the fact that we need it *now* + <antrik> all software will be obsolete one day. doesn't mean it's not worth + working on + <antrik> the vast majority of work is not on the microkernel anyways, but + on the system running on top of it + <Pete-J> ahh i see + <antrik> manpower is not something that comes from nowhere. again, having + something working is crucial in a volunteer project like this + <antrik> 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... <antrik> 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 + + <bwright> Is hurd still using the Mach Microkernel? + <bwright> I am assuming the L4 port failed? + <teythoon> yes / yes, i believe so + <bwright> I am currently working as an intern on seL4 a verified + microkernel variant of L4. + <bwright> I was sort of interested as to why the port failed if there are + any old mailing list posts etc. + <bwright> Obviously if it is too much trouble to dig them up that is + understandable. + <teythoon> most interesting, i'm interested in software verification as + well :) + <teythoon> there's some stuff in the wiki + <bwright> (I am writing a multiserver atm on top of it) + <teythoon> + http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html + <bwright> Awesome thanks. + <braunr> bwright: iirc, l4 lacked some important asynchronous stuff + <braunr> the all synchronous model proved insufficient for an efficient + posix conforming system + <bwright> Yep, posix can get very annoying in places. + <bwright> Variants of l4 have async stuff that could probably work. + <braunr> okl4 is the only one i know of that does this + <braunr> but it may not have been the only issue + <bwright> That is the one I am working with :p + <braunr> the l4-hurd mailing list archives should tell you more about this + <bwright> Great :D + <bwright> Going to read through them and look into it. + <braunr> there was also an attempt on coyotos which failed for other + reasons related to the overall security mechanisms of the system iirc + <braunr> enjoy ;p + <bwright> On a side note I am also very interested in Multiservers. + <braunr> so are we :) + <bwright> I wouldn't mind hacking on hurd for fun in my spare time. + <braunr> it would probably be appreciated + <bwright> 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 + + <antrik> 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 + <antrik> 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 + <antrik> 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 + <antrik> (this is in fact the same reason why the original Hurd on Mach + turned out so problematic...) + <cluck> 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 + + <cusement> 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. + <braunr> 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 + <cusement> i was recently reasearching for alternatives, since i am simply + fed up with the chaotic situation with the Linux kernel + <cusement> like Mach, XNU , ... + <cusement> well, im still doing my research on alternatives, ATM i simply + found L4 to have more future potential than Mach + <braunr> cusement: can i ask you why you think that ? + <cusement> 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 + <braunr> 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 ? + <cusement> 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 + <braunr> cusement: i agree, but the part of the system it covers is so + small it requires more justification + <braunr> cusement: any other main reason ? + <braunr> (we're not going to debate the merits of sel4 right now :)) + <azeem> cusement: if you are experienced in Linux device drivers, maybe you + want to check out DDE? + <cusement> 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. + <braunr> ok + <cusement> 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. + <braunr> cusement: the hurd design is focused on quite more than that + <braunr> cusement: it's a property of practically all multiserver systems + out there to isolate each other + <braunr> other properties makes the hurd apart + <cusement> braunr: i know, but there also hybrids like XNU where drivers + are still in kernel space + <braunr> i don't consider xnu to be a multiserver system + <cusement> braunr: well, xnu also runs various fundamental services as + separate tasks / servers + <braunr> cusement: let me check + <cusement> xnu is mach based, and every mach derivative uses a multiserver + design, doesnt it? + <braunr> no + <braunr> practically all mach based systems were monoliths in userspace + <cusement> you mean kernel space + <azeem> cusement: certainly at least the NeXT/OS X Mach-based setup is not + very multiserver + <braunr> cusement: no i mean userspace + <braunr> darwin and mac os x are good examples of such systems + <cusement> braunr: so you mean individual fundamental OS tasks on XNU are + actually just processed by one server + <cusement> havent really digged too deep in XNU, because of its monolithic + driver concept + <braunr> cusement: yes + <braunr> it's basically a bsd server on top of mach + <cusement> ok, got it + <antrik> braunr: OS X actually runs the UNIX server in kernel space as well + AFAIK + + +## IRC, freenode, #hurd, 2014-02-10 + + <antrik> 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... |