Switch to DuckDuckGo Search
   May 23, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >

Toggle Join/Part | bottom
[00:00:05] <LeftWing> am11: FWIW, I would ignore krytarowski where possible and use arc4random_uniform()
[00:00:07] <LeftWing> He's just wrong
[00:11:01] <pmooney> jbk: I'm planning to just fix how bhyve allocates guest memory
[00:11:30] <pmooney> kmem_alloc(32GB+) isn't really reasonable
[00:12:24] <pmooney> especially for large guests, being able to demand-page the allocation over time will be a huge win for start up times
[00:15:02] <sjorge> So it will grab pages in small chunks until it has enough?
[00:16:01] <pmooney> and critically: allow the VM to run while doing so
[00:16:49] <pmooney> it'll cost some in overhead, but it's probably worth it
[00:16:55] <toastersonerson> is that overprovisionable or will the allocator block if swap is full?
[00:20:04] <pmooney> no plans for overcommit or swapable VMs at this point
[00:20:13] <pmooney> that's a recipe for pain
[00:20:59] <toastersonerson> true but helpfull in small use cases. but mostly hell
[00:24:27] *** jessfraz <jessfraz!~jessfraz@unaffiliated/jessfraz> has joined #illumos
[00:25:22] *** jessfraz_ <jessfraz_!~jessfraz@unaffiliated/jessfraz> has quit IRC (Ping timeout: 272 seconds)
[00:25:23] *** jessfraz is now known as jessfraz_
[00:35:25] <LeftWing> I think you'd have to find someone for whom the memory overcommit case is more economically relevant than the failure cases it would allow for
[00:35:27] <LeftWing> to work on it
[00:35:40] <LeftWing> Anybody with an eye to robustness or performance is going to avoid it
[00:36:51] <LeftWing> Even techniques like page dedup seem to allow for security problems with all the timing side channel stuff these days
[00:37:16] <LeftWing> In that you'd be allowing one VM to impact or observe cache activity in another
[00:42:48] <gitomat> [illumos-gate] 12768 12392 regressed ftello64 behavior -- Robert Mustacchi <rm at fingolfin dot org>
[01:04:24] <sjorge> pmooney: so the memory will be grabbed eventually? Or if I have 2x 24G vm in a 64G system but only about 8 is used per VM, would that leave 32G unclaimed until needed by bhyve?
[01:05:01] <sjorge> So fair game for say arc or other cache?
[01:31:34] <pmooney> tbd
[01:34:33] <gitomat> [illumos-gate] 12735 bhyve upstream sync 2019 Sept -- Michael Zeller <mike at mikezeller dot net>
[01:47:03] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[01:47:42] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[02:03:07] *** merzo <merzo!~merzo@137-26-132-95.pool.ukrtel.net> has joined #illumos
[02:03:12] *** merzo_ <merzo_!~merzo@137-26-132-95.pool.ukrtel.net> has joined #illumos
[02:03:47] *** merzo_ <merzo_!~merzo@137-26-132-95.pool.ukrtel.net> has quit IRC (Client Quit)
[02:28:21] <LeftWing> I think you could make the case either way
[02:29:04] <LeftWing> e.g., you could imagine an option that did or did not have a background thread that seeks to complete the allocation
[02:29:27] <LeftWing> But it should almost certainly work better in the face of a large existing ARC
[02:29:43] <LeftWing> in terms of applying smaller, but constant, memory pressure
[02:35:03] <pmooney> and better to not be waiting for an ARC resize if you need some pages ASAP
[02:54:10] *** Allan_ <Allan_!~allan@freebsd/developer/AllanJude> has joined #illumos
[02:56:11] *** AllanJude <AllanJude!~allan@freebsd/developer/AllanJude> has quit IRC (Ping timeout: 244 seconds)
[02:58:34] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[02:59:16] *** Allan_ <Allan_!~allan@freebsd/developer/AllanJude> has quit IRC (Ping timeout: 272 seconds)
[03:02:31] *** AllanJude <AllanJude!~allan@freebsd/developer/AllanJude> has joined #illumos
[03:03:59] *** Tempt <Tempt!~avenger@unaffiliated/tempt> has joined #illumos
[03:03:59] *** ChanServ sets mode: +o Tempt
[03:05:22] *** Allan_ <Allan_!~allan@freebsd/developer/AllanJude> has joined #illumos
[03:08:04] *** AllanJude <AllanJude!~allan@freebsd/developer/AllanJude> has quit IRC (Ping timeout: 244 seconds)
[03:10:58] *** Allan_ <Allan_!~allan@freebsd/developer/AllanJude> has quit IRC (Ping timeout: 260 seconds)
[03:11:38] *** AllanJude <AllanJude!~allan@freebsd/developer/AllanJude> has joined #illumos
[04:28:38] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has joined #illumos
[04:42:01] *** arnoldoree <arnoldoree!~arnoldore@113.210.182.166> has joined #illumos
[04:42:38] <LeftWing> Right
[04:43:00] <LeftWing> The whole system is kind of constructed around the idea that memory usage will be increased gradually, I feel
[04:43:30] <LeftWing> Gradually could be over a short amount of wall time, even -- just, not gigabytes in a single allocation call
[04:44:17] <jbk> kmem_alloc(YES, KM_NOSLEEP)
[04:45:18] <LeftWing> hahaha
[04:45:28] <LeftWing> How much memory do you want? B_TRUE, please!
[04:52:12] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:55:16] <jbk> if it ends up taking a bit to get that working, we could look at the workaround i did (it was always intended as an interim solution)
[04:56:49] <jbk> and if not even better..
[05:01:30] <LeftWing> What was your workaround?
[05:05:09] <jbk> basically i track the amount of vmm allocations and deallocations (actually I call it a reservation), and each reservation bumps an arc counter which is examined (along with the existing ones) in arc_available_memory.. it seems to do a better job of letting the ARC know how much it needs to reap
[05:05:24] <jbk> i was able to get it to release like 30Gb of ARC in 5-6 secs
[05:05:43] <jbk> which i mean isn't great, but a lot better than minutes (or longer)
[05:06:04] <LeftWing> Seems much better than what we've seen from the status quo
[05:06:23] <LeftWing> And that really shouldn't just apply to the ARC, I think it should also apply to slack in magazines and other things we can reap
[05:06:45] <LeftWing> We do sometimes sit on quite a lot of stuff that isn't in the free list, especially in larger memory machines with lots of cores
[05:07:11] <jbk> https://github.com/joyent/illumos-joyent/tree/arc-testing has most of hte work (actually one sec.. there's one commit i didn't push up)
[05:07:27] <LeftWing> Which, I get it, memory you aren't using is wasted memory -- but when we can't make an allocation of a particular type, it's a pretty frustrating posture
[05:09:27] <jbk> it's not perfect, but we've been messing around with it without any issues so far (of course doesn't mean it can't introduce new pathological behaviors, but hopefully they're more rare than what's been seen)
[05:10:37] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[05:11:25] <jbk> it was inspired by a similar arc tunable from fbsd (though it wasn't intended for bhyve, but in fbsd it's a way to dynamically adjust the amount of ram the ARC will try to use since messing with arc_c_max appears to only work at boot
[05:14:14] <jbk> though one thing i haven't dug into too much (yet) is how it behaves with mixed VM and non-VM workloads -- i have a suspicion that such a setup could still cause problems, but not sure how hard it would be in practice
[05:14:53] <jbk> (and at least for Triton at least, we can of course use the placement bits to avoid problematic situations)
[05:16:42] *** arnoldoree <arnoldoree!~arnoldore@113.210.182.166> has quit IRC (Ping timeout: 272 seconds)
[05:28:43] *** arnoldoree <arnoldoree!~arnoldore@113.210.49.223> has joined #illumos
[05:48:51] <LeftWing> TIL sysdef(1M)
[05:51:17] <LeftWing> There's a command that almost certainly belongs in the rubbish bin lol
[05:53:05] <LeftWing> jbk: I guess my fear with this is that it's too ZFS and VMM specific
[05:53:18] <LeftWing> Like, what if the memory is stuck in magazines
[05:53:27] <LeftWing> Or what if the reservation is PostgreSQL trying to make room for SHM
[05:53:39] *** khng300 <khng300!~khng300@unaffiliated/khng300> has quit IRC (Read error: Connection reset by peer)
[05:53:46] <LeftWing> I feel those problems and this problem are really the same problem
[05:54:23] *** khng300 <khng300!~khng300@unaffiliated/khng300> has joined #illumos
[05:57:18] <jbk> yes, though as i said, it was just an interim solution, and the ARC seemed to be (by far) the biggest culprit
[05:58:32] <LeftWing> I agree that it is the most obvious and frequently experienced one
[06:16:25] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Ping timeout: 264 seconds)
[06:26:23] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has quit IRC (Quit: Leaving)
[07:12:47] *** blackwood821 <blackwood821!~blackwood@c-174-49-16-176.hsd1.tn.comcast.net> has quit IRC ()
[07:23:51] *** nbhauke <nbhauke!~hauke@55d4b00b.access.ecotel.net> has joined #illumos
[07:39:17] *** igork <igork!~igork@91.204.56.74> has quit IRC (Quit: Leaving.)
[07:40:12] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Quit: WeeChat 1.9.1)
[07:40:29] *** igork <igork!~igork@91.204.56.74> has joined #illumos
[08:38:38] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:39:05] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[09:39:16] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[09:40:53] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Client Quit)
[09:59:37] <gitomat> [illumos-gate] 12745 man page typos -- Peter Tribble <peter.tribble at gmail dot com>
[10:07:19] *** nde <nde!uid414739@gateway/web/irccloud.com/x-gzpzeahrhqchildl> has quit IRC (Quit: Connection closed for inactivity)
[10:24:20] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[10:24:32] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 260 seconds)
[10:25:45] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[10:26:57] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[10:31:30] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[10:37:23] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has joined #illumos
[11:02:13] <am11> LeftWing: is there a prebuilt gcc-7 cross compiler for Debian/Linux targetting Illumos (x86_64-sun-solaris2.11), or do we need to compile it?
[11:02:40] <am11> something like https://gist.github.com/AlainODea/6679613 or https://github.com/dhuseby/rust-cross-toolkit/blob/1d70284/stage2.sh.
[11:04:48] <am11> trying to DRY if it is already published somewhere.
[11:05:15] <LeftWing> am11: You could use the WIP script I am aiming to get integrated into Rust
[11:05:19] <LeftWing> https://github.com/jclulow/rust/blob/illumos-x86-ci/src/ci/docker/scripts/illumos-toolchain.sh
[11:05:58] <andyf> jbk, LeftWing at least it would make it less frequent that I need to do mkfile 16g /tmp/l; rm /tmp/l to get a new bhyve VM to boot
[11:06:00] <LeftWing> GCC 7 is probably no good
[11:06:15] <LeftWing> See my comment in the script
[11:08:04] <LeftWing> andyf: Haha that's creative
[11:08:35] * LeftWing returns to bed, as it is 0208 here
[11:08:55] <am11> wow, that is exactly what i was searching for. thanks! i will switch to gcc 8. only thing is that the upstream CI currently only supports gcc7. they compile gcc7 with clang9. i tried to update it to gcc9, but clang9 failed to compile it.
[11:09:43] <LeftWing> You could compile a native GCC 7 with clang, and the cross GCC 8 with that GCC!
[11:12:12] <am11> true, i think it will increase the ci build time (which creates docker images github.com/dotnet/dotnet-buildtools-prereqs-docker), i will give it a try.
[11:12:53] <am11> regarding you rust script, is there anything particular which is WIP/untested?
[11:20:37] *** Guest12241 <Guest12241!~kayront@zbase.xen.prgmr.com> has left #illumos ("Leaving")
[11:29:46] *** kayront <kayront!~kayront@unaffiliated/kayront> has joined #illumos
[11:32:11] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[11:35:18] *** merzo_ <merzo_!~merzo@88-35-133-95.pool.ukrtel.net> has joined #illumos
[11:38:16] *** merzo <merzo!~merzo@137-26-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 265 seconds)
[11:46:30] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Quit: This computer has gone to sleep)
[11:52:45] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has quit IRC (Read error: Connection reset by peer)
[11:53:02] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has joined #illumos
[11:55:43] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)
[12:02:23] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has joined #illumos
[12:14:50] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[12:15:25] *** jellydonut <jellydonut!~quassel@141.98.255.144> has quit IRC (Quit: jellydonut)
[12:17:35] *** jellydonut <jellydonut!~quassel@141.98.255.152> has joined #illumos
[12:32:03] *** wacki <wacki!~wacki@i577B8B91.versanet.de> has joined #illumos
[13:03:54] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[13:30:23] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[13:31:06] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[13:31:13] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[13:33:12] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Client Quit)
[13:48:33] *** gitomat <gitomat!~nodebot@165.225.148.18> has quit IRC (Remote host closed the connection)
[13:48:42] *** gitomat <gitomat!~nodebot@165.225.148.18> has joined #illumos
[14:00:51] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[14:12:55] *** arnoldoree <arnoldoree!~arnoldore@113.210.49.223> has quit IRC (Ping timeout: 256 seconds)
[14:26:07] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2082:1ad1:72de:2ffb:d117:9c57> has joined #illumos
[15:15:02] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[15:18:01] *** tsoome <tsoome!~tsoome@2e9d-2d78-2aa3-e04f-2f80-4a40-07d0-2001.sta.estpak.ee> has quit IRC (Ping timeout: 272 seconds)
[15:19:00] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has quit IRC (Ping timeout: 272 seconds)
[15:27:28] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has joined #illumos
[15:30:15] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has quit IRC (Remote host closed the connection)
[15:30:47] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has joined #illumos
[15:33:35] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has quit IRC (Remote host closed the connection)
[15:34:14] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has joined #illumos
[15:42:17] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has quit IRC (Remote host closed the connection)
[15:42:23] <sjorge> that was harder than I had hoped :| took me 3h to get a copy of usbscam to build as uchcom so I can start stripping back from that
[15:42:57] *** teutat3s[m]1 <teutat3s[m]1!~teutat3sp@85.88.23.162> has joined #illumos
[16:06:24] *** abf <abf!~abf@2601:404:c100:7e40::16f8> has quit IRC (Quit: Leaving)
[16:12:43] <am11> LeftWing: thanks a lot for that script. i made a minor modifcation (paramerized sysroot directory), but otherwise it has been well-integrated in the existing dotnet/arcade setup. I am at the point where libunwind, libpalrt etc. archives have started to cross-compile on Debian/Linux for Illumos target, but linker is throwing for executables: http://sprunge.us/5LA85R. looks like some missing cxx symbols. i
[16:12:44] <am11> haven't modified any linker flags in git branch (which builds on smartos).
[16:14:03] <LeftWing> am11: Those are symbols in libssp.so.1 I believe
[16:14:25] <LeftWing> Many systems put them in libc but we don't as yet
[16:16:19] <jollyd> LeftWing: indeed there are in libssp
[16:16:59] <LeftWing> wrt. the script, it's just a WIP because it's not been accepted as a Rust PR yet. I believe it works well, which is why I'm trying to get it integrated now!
[16:24:20] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[16:24:52] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[16:25:12] <am11> thanks, i will try to find out why libssp is missed in our linker enlistings (maybe because when i was compiling on smartos, it was included by default).
[16:26:16] <am11> LeftWing: i only applied this patch on top of your branch https://github.com/am11/rust/commit/1604665.
[16:27:57] <LeftWing> Cool!
[16:39:37] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 260 seconds)
[16:40:37] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[17:01:30] <sjorge> Didn't some of those get moved to libc in Oracle Solaris somewhere after 11?
[17:01:52] <sjorge> I vaguely remember -lsocket and -lnsl at least being stubs now and actually being moved to libc
[17:05:49] <sjorge> Well then, I think I stripped everything down and it now compile doing nothing (I hope)
[17:05:51] <am11> looks like cross ld is not happy about the symbol file format: http://sprunge.us/uMMCIq ; content of dbgshim.exports: http://sprunge.us/GTTp3U. (works on SmartOS machine)™
[17:05:55] <sjorge> Lets reboot and see if that still works xD
[17:07:06] <am11> by adding ssp to the linker flags, the previous error went away. :)
[17:09:39] <sjorge> am11 those are the easy ones :)
[17:11:33] <sjorge> Well good, the onu env did not panic on boot :D
[17:11:38] <am11> sjorge: yup, once we know what we are looking for. :D i think this "exports file" error is because in cross-compiler, ld is from GNU Binutils and the cmake scripts have Solaris ld flags for SunOS-derivatives.
[17:12:14] <am11> need a way to figure out how to `if(IsSolarisLinker)` in cmake.
[17:12:26] <sjorge> I'm not sure, but I think our ld is also gnu ld? Someone here can probably deny or confirm that
[17:12:32] <rmustacc> No, it's not.
[17:12:34] <andyf> nope
[17:12:40] <sjorge> Or multiple peopel :D
[17:12:53] <rmustacc> illumos uses is own ld; however, when you're in a cross-compiling environment like am11 is, you're using gld.
[17:13:11] <rmustacc> However, often the target linker flags are mixed up with the build ld flags, like it sounds like in this case.
[17:13:17] <rmustacc> The same happened in rust at some point, iirc.
[17:14:54] <am11> yup, i think we should support both. gld for cross-compilation (or some distro which might have ld -> gld symlink set). just need to introspect it, rest of the code (flags for gld and Illumos ld) is there.
[17:15:16] <andyf> sjorge - see https://github.com/illumos/illumos-gate/blob/master/exception_lists/check_rtime#L183 for what has been deprecated by being moved into libc
[17:15:51] <andyf> parts of libnsl were moved IIRC
[17:16:14] <andyf> and good progress on getting the onu env to boot
[17:16:18] <andyf> it's just iteration from here on out :)
[17:16:44] <sjorge> haha well I force loaded the module and it pooped the bed, but I was expecting that tbh
[17:17:22] <sjorge> I stripped down most stuff with just a attach and dettach that return USB_FAILURE
[17:17:27] <sjorge> But i hit an undefined symbol
[17:17:36] <sjorge> I also still have little idea of what I am doing
[17:17:47] <sjorge> monkey see, monkey think, monkey do and hope for the best
[17:21:38] <rmustacc> Feel free to ask questions and we can help make suggestions.
[17:22:06] <sjorge> I'm not yet at the asking meaningful questions stage
[17:22:18] <sjorge> And if I can the dev guide answered them so far
[17:22:30] <rmustacc> For example, undefined symbols suggest one of two things, either you have an unnamed function or a missing dependency.
[17:22:38] <andyf> If you haven't already, you'll soon have a script or something that can boot new bits quickly
[17:22:51] <sjorge> I do :p you gave me one that I modified
[17:23:06] <sjorge> I also have aliases to jump to the src and header directory quickly
[17:23:06] <andyf> (oh, the zsh prompt thing is being fixed, but it only happens if you are running as root... one should not generally run bldenv as root)
[17:23:11] <sjorge> and to run dmake -e install/-e clean
[17:25:50] <sjorge> Time to stop for today
[17:26:16] <sjorge> I fixed the symbol error now it doesn't have anything to attach too, which makes sense as I have not figured out the bits to tell it what hardware it needs
[17:26:26] <sjorge> I probably dropped that code form the driver I copied
[17:26:36] <sjorge> But food time, I skipped lunch
[17:26:52] <sjorge> Still think I'm biting of more than I can chew, but I at least want to try
[17:36:42] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has quit IRC (Ping timeout: 256 seconds)
[17:38:58] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[18:04:25] <LeftWing> I think you're doing just fine!
[18:06:47] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[18:23:43] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Ping timeout: 240 seconds)
[18:25:07] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[18:39:44] <gitomat> [illumos-gate] 12737 sync shadow PCIR_COMMAND with real one for bhyve pass-thru -- Michael Zeller <mike at mikezeller dot net>
[18:46:24] *** pwinder <pwinder!~pwinder@86.11.191.8> has joined #illumos
[19:10:17] *** pwinder <pwinder!~pwinder@86.11.191.8> has quit IRC (Quit: This computer has gone to sleep)
[19:12:55] <am11> LeftWing: would it make sense to add the script in illumos/sysroot repo, so both rust and dotnet can source it from one place? was thinking it as analogous to https://github.com/alpinelinux/alpine-chroot-install.
[19:44:50] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 256 seconds)
[19:45:14] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[19:59:29] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has quit IRC (Ping timeout: 265 seconds)
[20:02:06] *** lystra <lystra!~lystra@d53-64-11-169.nap.wideopenwest.com> has joined #illumos
[20:07:02] *** jollyd <jollyd!~alarcher@2a01:cb1d:611:bb00:8820:7cbd:8965:af56> has quit IRC (Quit: Leaving.)
[20:42:06] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2082:1ad1:72de:2ffb:d117:9c57> has quit IRC (Quit: Leaving)
[20:55:09] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[21:31:24] *** BOKALDO <BOKALDO!~BOKALDO@46.109.202.100> has quit IRC (Quit: Leaving)
[22:23:37] <sjorge> Yay the missing bit I needed for ppt landed :)
[22:33:39] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Read error: Connection reset by peer)
[22:35:54] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has quit IRC (Read error: Connection reset by peer)
[22:38:14] *** nikolam <nikolam!~Nikolam@unaffiliated/nikolam> has joined #illumos
[22:39:21] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[22:40:34] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[22:48:23] <am11> coreclr has successfully built with cross compiler and sysroot, LeftWing. I will build the other parts of repo now. fyi: I had to rev binutils to v2.33.1, because i was getting a relocation error and it turned out to be due to binutils 2.25 bug (either in ar or as), where it compiles assembly file and messes up the relocation info in its object file.
[22:51:09] *** neirac <neirac!~neirac@pc-4-149-45-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[22:53:07] *** wacki <wacki!~wacki@i577B8B91.versanet.de> has left #illumos
[22:56:21] *** jollyd <jollyd!~alarcher@2a01:cb1d:611:bb00:8820:7cbd:8965:af56> has joined #illumos
[23:00:12] <sjorge> That’s a big milestone right am11 ?
[23:03:05] <am11> sjorge: yup. we are getting closer to run our first hello world, but there is a lot of mechanical work left (mostly about adding strings like illumos-x64 in tons of files). :)
[23:05:41] <am11> after that we will enter "managed libraries", where there are quite a few platform dependent APIs (like systemio.filesystem, fs watcher etc.)
[23:07:07] <am11> but those vast majority is agnostic / sitting behind platform abstraction layer, which hello world milestone will light up.
[23:37:39] <andyf> sjorge - which bit were you waiting for?
top

   May 23, 2020  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >