[00:00:53] <buffyg_laptop> npx: There is a clang build for OI pending publication. What changes did you want?

[00:00:56] *** relling has quit IRC [00:01:20] <npx> buffyg_laptop, is it self-hosting? [00:01:24] <buffyg_laptop> And, yes, the gcc builds for OI should now be available in /experimental. [00:02:07] <buffyg_laptop> npx: So far I've only bootstrapped it with gcc, but AFAIU clang can be self-hosting thereafter. [00:02:40] <buffyg_laptop> clang 3.1 is due out shortly, so I'll certainly have a chance to check at that point. [00:03:13] <npx> i'm assuming you used gcc4.4 to boostrap, thus avoiding the spawn.h bug? [00:03:41] <npx> (i'm asking because i want to file a bug report that's actually relevant to the software that's going to ship with OI) [00:03:55] <ssilva> wesolows: is this a problem specific to illumos? [00:04:23] <buffyg_laptop> npx: Yes. gcc 4.4 was the bootstrap compiler for the clang 3.0 build I did. [00:04:33] *** relling has joined #illumos [00:05:43] <buffyg_laptop> npx: I don't know I did it specifically to avoid that bug, but I read the bootstrap compiler notes to make sure that there weren't any known issues. [00:06:27] <buffyg_laptop> There were a handful of issues with the test harness, and I briefly touched base with the upstream about those. They seem keen to do the bug fixes. [00:06:56] <dre2kse> are there any shared compiler boxes like opensolaris.org used to have? [00:07:16] *** neophenix has quit IRC [00:08:59] <buffyg_laptop> dre2kse: Not really. Closest thing might be opencsw. [00:09:23] *** marsell has quit IRC [00:09:49] *** ekix has quit IRC [00:11:27] *** marsell has joined #illumos [00:12:09] *** arethusa has quit IRC [00:13:07] *** arethusa has joined #illumos [00:13:41] *** esproul has quit IRC [00:18:47] *** rlaager has quit IRC [00:18:56] *** gmason_ has quit IRC [00:25:06] *** ryao_ has quit IRC [00:25:06] *** ryao_ has joined #illumos [00:25:36] *** raichoo has quit IRC [00:30:41] <wesolows> ssilva: The problem with the compiler is not specific to illumos; the difference seems to be that we actually care about the correctness and reliability of what we ship. [00:32:06] *** ira has joined #illumos [00:32:50] *** ryao_ is now known as ryao [00:34:08] <ryao> wesolows: How do you do this correctness testing? [00:38:40] *** ira has quit IRC [00:38:51] *** kdavyd1 has joined #illumos [00:40:35] <wesolows> ryao: Historically, it was done by a combination of extensive use during development, PIT, and beta. By only allowing compiler changes at the beginning of a release, we have some hope of finding stuff. The stuff in PIT included a lot of stuff that would identify ABI compatibility issues and other highly nitty regressions. [00:40:43] <wesolows> Some of that stuff we actually have access to now, others not. [00:41:00] *** kdavyd has quit IRC [00:41:07] <ryao> What is PIT? [00:41:19] <bcantrill> "Pre-integration testing."

[00:41:24] <bcantrill> It's a Solaris-ism. [00:41:52] <bcantrill> It was the testing done before the OS/Net consolidation (ON ? the OS, essentially) integrated into the broader Solaris (the "WOS" or "wad of stuff"). [00:42:17] <bcantrill> Aside: the most useless standing meeting at Sun was that of the WOS Integration Team ? the WIT. [00:42:21] *** freakazoid0223 has quit IRC [00:42:48] <eschrock> @bcantrill: that is a bold statement [00:43:05] <bcantrill> eschrock: I' [00:43:10] <bcantrill> m here to defend it. [00:43:19] <eschrock> :-) [00:43:31] <jamesd> bcantrill, may have bad memories from trying to get dtrace into Solaris back in the day ;-) [00:44:03] <bcantrill> Actually, that's what made them so useless ? they didn't make decisions of that nature. [00:44:14] <bcantrill> That was the C-team (the "consolidation team"). [00:45:12] *** gwr_netbook_ has joined #illumos [00:47:07] *** proberts has quit IRC [00:47:11] <wesolows> I dunno, the Solaris P-team in the Jeff Jackson era was giving it a run for its money -- deliberately not allowed to make decisions, but containing a proper superset of the team that was allowed to do so, and meeting after it. [00:48:36] *** proberts has joined #illumos [00:48:41] *** gwr_netbook has quit IRC [00:49:02] <pijewski> gwr: any gotchas with mounting a smbfs share in a zone? [00:49:47] <danmcd> Don't get me started on JeffJ... [00:50:33] <jamesd> is that what happened to Solairs they ran out of letters for teams, and refused to do AA-Team ;-p [00:53:15] <ssilva> wesolows: interesting points. I still find it hard to believe that the risks you describe are as significant as you say, so please pardon my questions as I dissuade myself of the skepticism. [00:54:13] <ssilva> naturally, compilers have bugs that get fixed. is it not a problem for correctness and reliability to have everything compiled with a version of a compiler that still contains those bugs? [00:55:43] <rmustacc> ssilva: If there are bugs discovered, then there would be a rev of the compiler used to one that did not have those bugs, but had no other changes. [00:56:25] *** relling has quit IRC [00:57:14] *** mohamed has joined #illumos [00:57:16] <ssilva> so what about all of the bugs found since gcc 3.3? [00:57:59] <mohamed> Hi there, [00:58:28] <rmustacc> Right, you have to pick some place to stop more or less and backport as apporpriate in that world. What happens when you're on 4.4.4 and 4.4.5 introduces a regression. [00:59:18] <rmustacc> You have to stop at some point. [00:59:33] <Alasdairrr> Building the whole OS and doing a reasonable amount of testing will flush out the worst bugs [00:59:42] <eschrock> also, not all bugs apply to illumos-gate - witness the correctly functioning code build by our ancient compilers today [00:59:44] <rmustacc> And you want to be able say that for a given two invocations of the build system that you should get the same bits. [01:00:38] <ssilva> is that currently the case (same bits)? [01:00:52] <mohamed> I am a system administrator with 3+ years exper in Solaris. I truly enjoy dtrace, mdb and such stuff especially when it comes to understanding the behavior of my systems. Recently I have used openindiana and compiled illumos there, I just like this stuf too much, even I bough Solaris Systems Programming/ Solaris kernel Internals and I am spending time reading illumos source.

[01:01:20] <rmustacc> ssilva: Yes. If you don't have a reproducible build, that's a little frightening for what you're shipping to customers. [01:01:48] <mohamed> My question is, what kind of good job I may find to support me if I became a good in illumos especially in a devloping country like here. [01:02:50] <Alasdairrr> mohamed: There is plenty of opportunity for remote working, where a US or European company pays you to work on things from afar [01:03:04] *** ryancnelson1 has joined #illumos [01:03:07] <Alasdairrr> There's plenty of demand for Solaris/Illumos skills [01:04:27] <ssilva> rmustacc: how do you guys currently verify this? is it part of the buildbot infrastructure? [01:04:49] <wesolows> Actually, we don't have a reproducible build, relative to build machines. We should have one relative to time if invoked on the same system, modulo some macros that change with each invocation. [01:05:15] <richlowe> and dtrace's ftok() use. [01:05:19] <LeftWing> danmcd: You pinged? [01:05:23] <richlowe> scourge of the wsdiffer. [01:05:48] *** voidcoder has quit IRC [01:06:25] *** npx has quit IRC [01:07:51] *** npx has joined #illumos [01:08:18] *** voidcoder has joined #illumos [01:09:38] <ssilva> so this build reproducibility is more an ideal rather than a real requirement? [01:10:20] <richlowe> It's something which should be a requirement, but from which there has been drift. [01:10:23] *** andy_js has quit IRC [01:10:28] <richlowe> it's something which should only ever be made better, I guess you'd say. [01:10:48] <richlowe> above anything else, it's a real pain in the ass when you hit a bug, rebuild to test your fix, and the bug goes away because you rebuilt, not because you fixed it. [01:11:20] <ssilva> has that ever actually happened? [01:11:38] <LeftWing> Rich doesn't make things up. [01:11:39] <richlowe> actually, yes, there was a ksh93-ish bug of that nature. [01:12:30] <ssilva> but nonetheless, this has no bearing on where this discussion came from, which was about the need to use only one "blessed" compiler version. [01:12:46] <richlowe> quite possibly two, actually, I think they managed it with xsltproc as well [01:12:51] <richlowe> the bug in my notes is not the bug I expected to find [01:13:05] <npx> i would suggest discussing these proprietary pragmas in the llvm community (e.g., compiler experts) [01:13:44] <npx> if you can't convince them to include it in mainline clang on technical merit, the odds are high that it sucks [01:13:55] <gwr_netbook_> pijewski, just saw that, sorry for the delay. No prob., smbfs works fine in a zone. [01:14:17] <ssilva> richlowe: was it like an optimizer bug? [01:14:17] <wesolows> ssilva: Strictly speaking, you can use any compiler you want. But you want to minimise churn there, because of how long it can take to find all the bugs. [01:14:27] <wesolows> It's a risk/reward calculus. [01:14:45] <wesolows> Switching compilers rarely has a high reward, and the risk is high. [01:15:16] *** brendang_ is now known as brendang [01:16:12] <ssilva> so how does this mentality fit into the context of being open-source? It seem like these things all make much more sense for a proprietary product that is shipped as a binary.

[01:16:58] <pijewski> gwr: what about connecting to a CIFS server using domain authentication? or does it only work in workgroup mode? [01:17:27] <gwr_netbook_> domain mode too. [01:17:35] <e^ipi> ssilva: easy, if you want to use a different compiler knock yourself out [01:17:44] <e^ipi> if you want something that works, use the blessed one [01:18:05] <pijewski> gwr: great, thanks [01:18:23] <wesolows> ssilva: Being open source is orthogonal to risk management. [01:18:32] <gwr_netbook_> even kerberos, if you dare to kinit first. [01:18:45] <gwr_netbook_> or whatever - I forget. klogin/ [01:18:46] <gwr_netbook_> ? [01:19:44] <wesolows> And in the limit, *everything* is shipped as a binary, even if you're only shipping it to yourself. [01:19:45] <buffyg_laptop> kinit is the CLI op. [01:19:51] <wesolows> You can't execute source code. [01:20:07] <npx> wesolows, clang actually ships a rudimentary C interpreter ;) [01:20:26] <wesolows> npx: cool, of course, but not too useful for kernel code. [01:20:58] <ssilva> maybe not: http://bellard.org/tcc/tccboot.html [01:21:14] <pijewski> gwr: would that work in a non global zone? I'm guessing probably yes... [01:21:43] <gwr_netbook_> I think we tested all of that in ngz when we were doing final q/a in sun.. [01:21:51] *** darjeeling has quit IRC [01:22:00] <gwr_netbook_> I rarely use the kerberos path though, cause it's just a pita. [01:22:47] <wesolows> ssilva: Notice that it's compiling the source code itself. So at the end of the day you have to trust something; it's either a compiler, an embedded compiler like tcc, or a VM. [01:22:49] <gwr_netbook_> There is one nit: smbutil or mount_smbfs will prompt you for a password in cases where it should do a kerberos auth or reauth. [01:23:29] <gwr_netbook_> only because I didn't connect up the "get a password" functions to the kerb5 auth stuff. [01:23:34] <wesolows> That "thing you trust" needs to be either ruthlessly tiny and simple, so that any change can be trivially understood and/or verified, or changed only very carefully when risk/reward is favourable. [01:23:38] <pijewski> gwr: which makes sense, given that you're not part of the AD domain [01:23:47] <gwr_netbook_> (instead leaving that for the user to do beforehand) [01:24:08] <wesolows> I would argue that no C compiler capable of generating usably fast code on modern hardware satisfies the simplicity constraint, so here we are. [01:24:25] <gwr_netbook_> Interestingly, the AD domain membership doesn't really come into play much when you're a client. [01:24:37] <gwr_netbook_> Other than providing a domain name in which your account is known. [01:24:52] <gwr_netbook_> The client auth work looks exactly the same domain mode or wg mode. [01:24:56] <pijewski> gwr: hmm, good to know [01:25:15] <richlowe> gwr_netbook_: what happened to your service from a zone work? [01:25:25] <gwr_netbook_> The _server_ side may insist that you have a machine account, and that the IP you're coming from is the IP for that machine, etc. [01:25:36] <ssilva> wesolows: naturally, there has to be *some* point where the "blessed" compiler changes. when does it change?

[01:25:38] <wesolows> ssilva: Bottom line, it's not for me to tell you what compiler to use to build code for yourself or your customers, of course. Open source means you're free to do whatever you like. [01:25:50] *** richoiddd has joined #illumos [01:26:01] <gwr_netbook_> but you're not actually _using_ that machine account unless you authenticate users coming IN to your box, (like the cifs server does) [01:26:13] <wesolows> ssilva: In the Sun era, it usually changed at the beginning of a new gate branching, and then N more times early on as needed to fix bugs we hit (and only bugs we hit). [01:26:33] <eschrock> @ssilva: same way anything else changes. Someone does the legwork to show that the change is correct and valid to the satisfaction of the RTI advocates [01:26:49] *** lblume has quit IRC [01:26:58] <eschrock> for something as core as a compiler shift,