From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../hurd_init.mdwn | 224 +++++++++++++++++++++ 1 file changed, 224 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/hurd_init.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/hurd_init.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/hurd_init.mdwn b/service_solahart_jakarta_selatan__082122541663/hurd_init.mdwn new file mode 100644 index 00000000..cc06935c --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/hurd_init.mdwn @@ -0,0 +1,224 @@ +[[!meta copyright="Copyright © 2013 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]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# [[!message-id "20130625154749.17799.36923@thinkbox.jade-hamburg.de"]] + + +## IRC, freenode, #hurd, 2013-07-22 + + ok, so back to the drawing board for the next big issue, the + potential proc and init merge + Roland had some harsh words for that proposal, but noone else + raised concerns + noone else does not mean much + I guess only Roland actually understands the matter + so I'd tend to believe him + even though, his criticism was so superficial, he could at least + be a bit more specific... + i agree that the argument, being simply based on vague principle, + isn't very convincing + so, what should I do? + you can either keep them separate, or fight with roland + common braunr, I need a little more guidance in these kind of + social issues + a statement like this is of little use ;) + that's the best i can give you + :/ + i have one patch "fixing" HZ on the hurd, and i even get to fight + about it + I understand Roland has been around forever and keeps an eye on + stuff + but could/would he block a patch for hurd if e.g. youpi would + accept it + i.e. how much control has he in practice? + me fighting with him over a patch is of little value for anyone + and I don't care to do so + not much i suppose now + but we also have to agree with the change + with *real* arguments + (well, if it was up to me, i'd even merge exec with proc so ..) + ok, so I whip up a patch to see how it goes in practice and + present it so we could talk about the issue with something to look at + first + although maybe not ;p + you'll hit the same reaction + from Roland? + yes + and youpi said he tends to trust what roland says + so let's discuss the pros and cons a bit more + yes, but I'd honor his concerns if they were properly + presented. just telling me to hack on linux instead even though I think I + have demonstrated that I do want to work on Hurd is so childish in my + eyes that I do not consider that a valid argument at the moment + sure, shoot + well, functionally, they're unrelated + head -n1 init/init.c + /* Start and maintain hurd core servers and system run state + and thus it makes sense to make them separate, even if it does not + seem to bring anything useful now + history has shown that it makes a bed for nice things later + teythoon: that's not what proc is about + braunr: I know + braunr: that's what init is about in its own words ;) + teythoon: also, "simplifying the code" is not necessarily an + argument that would be considered + depending on the simplification + linux made it all simple by using a monolithic kernel :) + separating concerns is complex + but in the end it usually pays off on the Hurd + personally, I'd be fine with Guillem's solution, and renumbering + init's pid in Debian + there's a pending question from Roland actually: what information + is exchanged between init and proc in the end? + that's actually the point of the discussion: is that information + really big or not + I'm sorry, you lost me, where did he ask that question? + $ git grep proc_getmsgport | egrep '[0-9]' ← /hurd/init as pid 1 + is hardcoded in few places + teythoon: he didn't ask it this way, but that's the question I had + to be able to answer his + Date: Mon, 15 Jul 2013 10:36:35 -0700 (PDT) + > That's not what he said. He said there is a lot of information + > propagated from init to proc, and thus the separation is + questionable. + Are you talking about bootstrap, or what? + as I haven't investigated much, I couldn't answer this + pinotree: right. We could patch these in Debian + youpi: so, shall I refresh, test and refine Guillems patch and + resend it? + it's probably an easier way + ok, I start by doing that + + +## IRC, freenode, #hurd, 2013-07-25 + + pinotree: btw, there are two /sbin/init processes even with my + hacked up init/proc variant where /sbin/init gets to be pid 1 + never seen that + what are their parents? + pinotree: well, pid 1 is /sbin/init now, pid 13 or something has + the parent 1 + looks like init forks or something + i guess your sysvinit is compiled without INITDEBUG? + nothing in syslog either? + pinotree: it's compiled like the sysvinit shipped with debian + teythoon: do you have custom additions in inittab? + pinotree: a terminal for my serial console + *getty + are the getty started correctly for you, btw? + pinotree: yes + interesting + teythoon: back then, they were costantly respawning, with hurd's + getty's failing to start when exec'ed by (sysv)init + wonder what changed + pinotree: cool, magically went away then :) + + +## IRC, freenode, #hurd, 2013-07-29 + + youpi: I need some feedback on the not freezing translators + issue, more specifically whether I understood you correctly in your mail + from wednesday (20130724131552.GG9576@type.bordeaux.inria.fr) + oh yeah, and I had some questions yesterday too, about rpctrace + and dead-name notifications, specifically why /hurd/init is not receiving + any for the root translator and the exec server + teythoon: more details please + ok, so /hurd/init is registering for dead name notifications for + essential tasks + the rootfs and exec both register as essential tasks at init and + init requests successfully dead name notifications for them + if you e.g. kill the auth server, /hurd/init will notice and + crash the system + if you kill exec or the rootfs, /hurd/init does not get notified + I verified this with gdb and an subhurd + I'm puzzled by this, as the kernel is the one who sends the + notifications, right? + yes + teythoon: where is the problem ? + and it is not that the system is not sending any messages, it + is, I see the msgcount increase over time + braunr: dunno, as far as I can tell the kernel does not deliver + the notification for rootfs and exec + oh + those are the two processes loaded by grub, maybe they are + different somehow + is that affecting your work ? + no, not directly, I strayed around at the weekend, trying to + think of cool stuff hurd could do + youpi: I need some feedback on the not freezing translators + issue, more specifically whether I understood you correctly in your mail + from wednesday (20130724131552.GG9576@type.bordeaux.inria.fr) + teythoon: ok, now I'm available for the not-freezing-translators + thing :) + + +## IRC, freenode, #hurd, 2013-08-05 + + youpi: I'm in the process of producing a unified + sysvinit-as-pid1 and please-dont-kill-important-processes patch series + youpi: there is one issue with changing /hurd/inits pid, libcs + reboot() also assumes that it has the pid 1 + argl + that's bad, because it's then an ABI, not just an internal thing + hardcoding the pid is the worst way of getting a handle of any + server :/ + I've been thinking to make it explicit by binding it to + /servers/startup or something + that would be more hurdish than using a pid, yes + yes, and not only does it break the abi, but in a bad way + too. if the libc is updated before the hurd, the shutdown sequence is + broken in a way that the translators aren't synced :/ + youpi: as a workaround, we could make reboot() signal both pid 1 + and 2 + at worse pid 1 shouldn't get harmed by receiving a startup_reboot + RPC indeed + yes + + +## IRC, freenode, #hurd, 2013-08-16 + + grml, the procfs hardcodes the kernels pid :/ + there's always one more thing to fix... + uh, and we made pids.h a private header, so no nice constant for + the procfs translator :/ + server lookup by hardcoding the pid should be banned... + + +## IRC, freenode, #hurd, 2013-09-16 + + youpi: I'm thinking about splitting /hurd/init into /hurd/init + and /hurd/startup + that way, you could also merge the init as pid1 patches + that should be doable within the week + that would probably be better received by Roland than merging init + into proc :) + yes, I suppose so :D + perhaps you should start the discussion on the list about it + already, with just a sketch of which would do what + ok + fwiw I like the name startup b/c it speaks the startup protocol + teythoon: +1 startup + + +## IRC, freenode, #hurd, 2013-09-23 + + I've been hacking on init/startup, I've looked into cleaning it + up + + +## IRC, freenode, #hurd, 2013-10-07 + + braunr: btw, what do you think of my /hurd/startup proposal? + i haven't read it in detail yet + it's about separating init right ? + yes -- cgit v1.2.3