Switch to DuckDuckGo Search
   February 13, 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

Toggle Join/Part | bottom
[00:27:47] <andyf> jlevon - smartos gate?
[00:28:43] <jlevon> illumos-joyent I mean
[00:29:17] <andyf> I'm seeing races with illumos-omnios, but mostly because of things merged from joyent
[00:29:47] <jlevon> a current gate? jerry made fixes
[00:29:49] <jlevon> got to run
[00:30:01] <andyf> yes, Jerry and I have been exchanging emails
[00:30:11] <jlevon> ok
[00:48:57] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[00:49:42] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[00:50:06] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Read error: Connection reset by peer)
[00:50:17] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[01:14:28] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Ping timeout: 245 seconds)
[01:25:35] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[01:29:25] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 272 seconds)
[01:35:56] *** MaidenAmerica is now known as insomnia
[01:42:05] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[01:48:45] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[01:49:21] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[01:56:42] *** user888 <user888!~user888@pool-173-70-72-142.nwrknj.fios.verizon.net> has joined #illumos
[02:33:56] *** user888 <user888!~user888@pool-173-70-72-142.nwrknj.fios.verizon.net> has quit IRC (Remote host closed the connection)
[02:34:11] *** user888 <user888!~user888@pool-173-70-72-142.nwrknj.fios.verizon.net> has joined #illumos
[02:49:39] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has joined #illumos
[03:04:57] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[03:31:07] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has quit IRC (Ping timeout: 260 seconds)
[03:32:51] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has joined #illumos
[03:40:12] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has quit IRC (Ping timeout: 265 seconds)
[03:51:35] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has joined #illumos
[03:56:19] *** robertdfrench <robertdfrench!~robertdfr@c-73-113-24-194.hsd1.tn.comcast.net> has quit IRC (Ping timeout: 260 seconds)
[04:00:03] *** hemi770 <hemi770!~hemi666@unaffiliated/hemi770> has quit IRC (Ping timeout: 260 seconds)
[04:01:52] *** hemi770 <hemi770!~hemi666@unaffiliated/hemi770> has joined #illumos
[04:22:02] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[04:25:35] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 246 seconds)
[05:30:23] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has quit IRC (Quit: Leaving.)
[05:36:14] *** BOKALDO <BOKALDO!~BOKALDO@87.110.100.238> has joined #illumos
[05:42:41] *** user888 <user888!~user888@pool-173-70-72-142.nwrknj.fios.verizon.net> has quit IRC (Quit: Leaving)
[05:45:57] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has joined #illumos
[05:54:14] *** cypa <cypa!~cypam]_@5.79.173.34> has joined #illumos
[05:55:03] <cypa> on mpls
[05:55:41] <cypa> what if I have a few zones/VM? and I want to route their traffic with mpls
[05:55:56] <cypa> I need mpls on host then
[06:24:29] *** fanta1 <fanta1!~fanta1@p200300F76BC16C00043491682FCCD146.dip0.t-ipconnect.de> has joined #illumos
[06:50:55] <rmustacc> jlevon: Yeah, with guidance. I noticed that it wasn't always in the nightly log or similar. But I'm trying to rely on my memory from 7+ years ago, which I don't trust.
[07:00:39] *** tru_tru <tru_tru!~tru@157.99.90.140> has quit IRC (Ping timeout: 272 seconds)
[07:27:20] *** nde <nde!uid414739@gateway/web/irccloud.com/x-ipeizihdmjpmbtpj> has quit IRC (Quit: Connection closed for inactivity)
[07:48:59] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: This computer has gone to sleep)
[08:09:43] *** v_a_b <v_a_b!~volker@p57A2764F.dip0.t-ipconnect.de> has joined #illumos
[08:36:10] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 268 seconds)
[08:46:30] *** tsoome <tsoome!~tsoome@89.219.128.66> has joined #illumos
[09:15:47] *** wiedi <wiedi!~wiedi@185.85.220.199> has joined #illumos
[09:17:00] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[09:18:43] *** cypa <cypa!~cypam]_@5.79.173.34> has quit IRC (Ping timeout: 268 seconds)
[09:22:39] *** ekix <ekix!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has quit IRC (Quit: leaving)
[09:25:12] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[09:25:35] *** eki <eki!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has joined #illumos
[09:32:30] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[09:41:23] *** fanta1 <fanta1!~fanta1@p200300F76BC16C00043491682FCCD146.dip0.t-ipconnect.de> has quit IRC (Quit: fanta1)
[09:47:41] *** basvdlei <basvdlei!~basvdlei@2001:980:a4c3:1:b88b:1590:d6bf:fbee> has quit IRC (Quit: basvdlei)
[10:16:50] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[10:29:12] *** man_u <man_u!~manu@manu2.gandi.net> has joined #illumos
[10:36:45] *** _alhazred <_alhazred!~Alex@mobile-access-bceeb6-196.dhcp.inet.fi> has joined #illumos
[10:41:35] *** fanta1 <fanta1!~fanta1@p200300F76BC16C00043491682FCCD146.dip0.t-ipconnect.de> has joined #illumos
[10:47:26] *** TheGreekOwl <TheGreekOwl!~Arkomeda@2a02:587:487b:9a00:cde1:38b4:520c:5662> has quit IRC (Ping timeout: 246 seconds)
[10:51:25] *** andy_js <andy_js!~andy@51.146.99.40> has joined #illumos
[11:09:43] *** fanta1 <fanta1!~fanta1@p200300F76BC16C00043491682FCCD146.dip0.t-ipconnect.de> has quit IRC (Quit: fanta1)
[11:33:58] <jimklimov> An interesting blog popped up in my stream: https://www.backblaze.com/blog/hard-drive-stats-for-2019/ (and I think they post such reviews quarterly) - with data that might be of interest regarding "Why ZFS?" pitches for our community members :)
[11:35:08] <jimklimov> I am not sure which "failure" they rate though, when a drive died completely or when there are per-sector issues (catchable by checksumming in very few FSes out there)
[11:36:55] <jimklimov> ...or if that fine grain matters at their scale and technology...
[11:38:16] <jimklimov> https://www.backblaze.com/blog/vault-cloud-storage-architecture/
[11:40:04] *** kovert <kovert!~kovert@204.141.173.249> has quit IRC (Ping timeout: 248 seconds)
[11:42:14] <jimklimov> TLDR: They do account for sector errors too, not too different from ZFS with regard to transparent detection and rewrite (but very differently for implementation and purpose)
[11:45:04] *** kovert <kovert!~kovert@204.141.173.249> has joined #illumos
[11:57:14] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 240 seconds)
[12:04:25] *** _alhazred <_alhazred!~Alex@mobile-access-bceeb6-196.dhcp.inet.fi> has quit IRC ()
[12:05:12] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[12:24:20] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 268 seconds)
[12:25:39] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Remote host closed the connection)
[12:26:05] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[12:48:02] *** tomww <tomww!~tom@unaffiliated/tomww> has quit IRC (Ping timeout: 240 seconds)
[12:49:23] *** tomww <tomww!~tom@unaffiliated/tomww> has joined #illumos
[13:11:02] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:19:39] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Read error: Connection reset by peer)
[13:19:54] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[13:29:32] *** wiedi <wiedi!~wiedi@185.85.220.199> has quit IRC (Read error: Connection reset by peer)
[13:30:12] *** wiedi <wiedi!~wiedi@185.85.220.199> has joined #illumos
[13:48:02] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 240 seconds)
[14:09:30] *** tru_tru <tru_tru!~tru@157.99.90.140> has joined #illumos
[14:17:19] *** nde <nde!uid414739@gateway/web/irccloud.com/x-faistmcxsesnkfpz> has joined #illumos
[14:18:41] *** tru_tru <tru_tru!~tru@157.99.90.140> has quit IRC (Ping timeout: 265 seconds)
[14:22:00] *** tsoome__ <tsoome__!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[14:22:03] *** tsoome__ <tsoome__!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Client Quit)
[14:35:11] <sjorge> jbk did you time to poke ldap some more?
[15:08:20] *** BOKALDO <BOKALDO!~BOKALDO@87.110.100.238> has quit IRC (Quit: Leaving)
[15:14:30] *** Lirion <Lirion!~kesselink@wikimedia-commons/Lirion> has quit IRC (Remote host closed the connection)
[15:21:13] *** tru_tru <tru_tru!~tru@157.99.90.140> has joined #illumos
[15:25:03] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Ping timeout: 240 seconds)
[15:25:28] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[15:26:04] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[15:29:49] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has joined #illumos
[15:30:48] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[15:38:50] *** jimklimov <jimklimov!~jimklimov@31.7.243.238> has quit IRC (Ping timeout: 240 seconds)
[15:50:57] *** gitomat <gitomat!~nodebot@165.225.148.18> has quit IRC (Remote host closed the connection)
[15:51:06] *** gitomat <gitomat!~nodebot@165.225.148.18> has joined #illumos
[16:11:47] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has quit IRC (Ping timeout: 265 seconds)
[16:14:39] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: This computer has gone to sleep)
[16:15:17] *** tsoome <tsoome!~tsoome@89.219.128.66> has quit IRC (Quit: tsoome)
[16:15:54] *** BOKALDO <BOKALDO!~BOKALDO@46.109.201.199> has joined #illumos
[16:22:26] <jbk> not yet
[16:32:34] *** Kruppt <Kruppt!~Kruppt@50.111.3.84> has joined #illumos
[16:41:41] <jbk> well i did get openldap built yesterday inbetween some other stuff, but that's it
[16:42:42] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[16:50:36] *** xzilla <xzilla!~robert@96-91-192-211-static.hfc.comcastbusiness.net> has joined #illumos
[17:13:41] *** BOKALDO_ <BOKALDO_!~BOKALDO@46.109.201.199> has joined #illumos
[17:14:46] *** BOKALDO <BOKALDO!~BOKALDO@46.109.201.199> has quit IRC (Read error: Connection reset by peer)
[17:18:21] <sjorge> I am using the one form pkgsrc?
[17:18:34] <sjorge> Do you want a dump of my notes?
[17:22:04] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[17:23:59] <kkantor> jimklimov: I love their hard drive stats info. If you look at their BoMs, they're currently not using SAS at all due to the increased cost of components. In this interview (https://www.backblaze.com/blog/how-backblaze-buys-hard-drives/) they discuss possibly moving to a SAS topology in the future.
[17:24:11] <kkantor> That was all really surprising for me to learn.
[17:28:24] <gitomat> [illumos-gate] 10931 BUILDPY2TOOLS and BUILDPY3TOOLS need to be documented in illumos.sh -- Hans Rosenfeld <hans.rosenfeld at joyent dot com>
[17:32:14] <gitomat> [illumos-gate] 12224 ctfconvert conv backend error missing newline -- Robert Mustacchi <rm at fingolfin dot org>
[17:32:15] <gitomat> [illumos-gate] 12227 libctf incorrectly handles clang anonymous unions -- Robert Mustacchi <rm at fingolfin dot org>
[17:47:00] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has quit IRC (Quit: aszeszo)
[18:03:14] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Ping timeout: 240 seconds)
[18:17:04] *** wiedi <wiedi!~wiedi@185.85.220.199> has quit IRC (Ping timeout: 268 seconds)
[18:44:22] *** xzilla <xzilla!~robert@96-91-192-211-static.hfc.comcastbusiness.net> has quit IRC (Read error: Connection reset by peer)
[18:46:23] <gitomat> [illumos-gate] 11682 zpool iostat and status improvements -- Tony Hutter <hutter2 at llnl dot gov>
[18:53:35] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: Leaving)
[18:53:46] *** tsoome <tsoome!~tsoome@04c9-04d6-3809-695f-2f80-4a40-07d0-2001.sta.estpak.ee> has joined #illumos
[18:59:09] <gitomat> [illumos-gate] 12287 errors in audio utility man pages -- Peter Tribble <peter.tribble at gmail dot com>
[19:02:51] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has joined #illumos
[19:03:06] *** TheGreekOwl <TheGreekOwl!~Arkomeda@2a02:587:487b:9a00:cde1:38b4:520c:5662> has joined #illumos
[19:07:17] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has joined #illumos
[19:13:19] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[19:19:47] *** jimklimov1 <jimklimov1!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has joined #illumos
[19:40:26] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Ping timeout: 240 seconds)
[19:44:26] *** _alhazred <_alhazred!~Alex@mobile-access-bceeb6-196.dhcp.inet.fi> has joined #illumos
[19:55:26] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has joined #illumos
[20:05:59] <ptribble> I should probably stop reading man pages
[20:06:49] <Agnar> why?
[20:07:24] <ptribble> I keep spotting errors
[20:08:45] <Agnar> ah. wine will help too :)
[20:08:51] <Agnar> or read linux man pages ;)
[20:18:06] *** _alhazred <_alhazred!~Alex@mobile-access-bceeb6-196.dhcp.inet.fi> has quit IRC ()
[20:26:02] *** Alek <Alek!43bc77f7@c-67-188-119-247.hsd1.ca.comcast.net> has joined #illumos
[20:31:09] <rmustacc> ptribble: But I need copy-editors for the ones I write!
[20:33:27] <Alek> Hey y'all, On my SmartOS server I've periodically been getting ereport.io.service.lost + ereport.io.device.stall and the device-path points to the CPU (/pci@0,0/pci8086,1c1a@1c,5/pci15d9,0@0). Is this telling me it's time for a new CPU?
[20:34:49] <rmustacc> So that does'nt look like it's the CPU at first glance. But do you happen to have the full ereports or fmdump output.
[20:35:04] <rmustacc> It looks like a PCI device off of a root port.
[20:35:41] <rmustacc> We'll need to figure out what the SMCI rebranded part is.
[20:38:10] <Alek> here is fmdump output: https://paste.dilos.org/?09cf78fea37d3115#gwBoZF3fQN45qLebgo2KSaSvedgyP1z7jOOIkLntUdo=
[20:38:58] <rmustacc> Do you know what device would be plugged into that root port?
[20:39:36] <Alek> i don't have any PCI devices pluged in to the mobo so that's why I assumed CPU
[20:39:46] <rmustacc> Not even an on-board NIC?
[20:40:40] <rmustacc> In general, those ereports are explicitly enumerated by device drivers.
[20:40:49] <rmustacc> Erm, emitted, not enumerated.
[20:43:04] <Alek> on-board NIC could be it. I'm loosing connection every time these ereports happen
[20:43:23] <rmustacc> The stall event usually means that they found hardware has a queue stall.
[20:48:58] *** EisNerd <EisNerd!~manschwet@mail.cs-software-gmbh.de> has joined #illumos
[21:01:13] <jbk> tsoome: is there an example anywhere of chainloading from the booter (figure you might know offhand)? i'm guessing it should be possible to do..
[21:02:28] <tsoome> jbk chain /boot/file.efi for uefi; chain disk0s1: for bios
[21:02:45] <jbk> cool.. thanks
[21:03:07] <tsoome> jbk see lsdev for disk names, note the colon.
[21:04:13] <Alek> hmm maybe I guess I should try a bios update. Thanks Robert
[21:04:14] <tsoome> also, for bios we can load from file, but then it must be 512B, copy of mbr or partition boot block.
[21:10:37] <jbk> and another loader question -- have you looked at supporting the ACPI SPCR table for locating the console at all?
[21:12:09] <jbk> (talking to jlevon at one point, I think we arrived that it might be useful for loader to read it and pass along the info to the kernel -- though we didn't nail down the exact behavior
[21:12:24] <jbk> (manually overriding, etc.)
[21:12:40] <tsoome> the problem is, there are systems where we can not rely on api spcr
[21:13:01] <jbk> i keep hearing that, but no one AFAIK has actually provided an example
[21:13:09] <jbk> the table is pretty simple
[21:13:16] <jbk> and has been around for almost 20 years..
[21:13:26] <tsoome> however, we do get console device from uefi ConOout variable
[21:13:28] <jbk> and everywhere we've checked it's been correc
[21:13:28] <jbk> t
[21:14:25] <tsoome> I guess it may be worth playing with the idea anyhow.
[21:14:45] <jbk> it would be nice -- it won't always be there, so we don't want to assume it will be present
[21:14:52] <jbk> but when present, it would be nice to have a way to use it
[21:15:25] <jbk> since dells default to using ttya, while supermicro defaults to ttyb
[21:15:45] <jbk> (and both appear to report correct values at least on the ones we've looked at)
[21:15:53] <jbk> which would be a nice way for things to 'just work'
[21:16:08] <jbk> though would still want a way to manually override and such...
[21:17:38] <tsoome> right, ACPI SPCR is for serial redirect, I did mix it up with local console information
[21:18:01] <jbk> ahh
[21:18:26] <tsoome> local console == vga
[21:18:43] <jbk> but i guess the answer is 'no' :)
[21:19:53] <tsoome> it would be good to have acpi parsing support, we actually would need it for uefi serial handle identification too.
[21:19:55] <jbk> i was going to look into it sometime if you hadn't.. but didn't want to duplicate any work..
[21:20:18] <tsoome> no, I haven't done anything in that area.
[21:22:53] <tsoome> I do have few preliminary bits to get serial console from ConOut in uefi, even as those bits are also in fbsd, there is some work to be done.
[21:25:00] <tsoome> just drawing fbsd console at the moment:)
[21:26:08] *** jenelizabeth <jenelizabeth!jenelizabe@gateway/vpn/privateinternetaccess/jenelizabeth> has joined #illumos
[21:48:42] *** BOKALDO_ <BOKALDO_!~BOKALDO@46.109.201.199> has quit IRC (Quit: Leaving)
[21:57:41] <sjorge> Agnar we don't want ptribble to go insane from reading those... and mostly lack of good examples brr illumos and freebsd man pages are so much better than linux
[21:58:40] <Agnar> sjorge: it was just meant for him to adjust to the reality out there :)
[22:04:14] <tsoome> linux never meant to have man, they have info:)
[22:04:39] <tsoome> man is so unixish, and linux is not unix:)
[22:06:56] <rmustacc> That's more GNU than linux.
[22:09:49] <tsoome> true:)
[22:13:11] <jbk> a linux center with a GNUy outer shell.. it's like an inverted candy bar :P
[22:13:29] <ptribble> Mind you, reading the dhcp man pages didn't actually help me when I was trying to work out why an AWS instance wasn't bringing up the network properly.
[22:14:48] <ptribble> Although I also wonder how much effort to put into fixing spelling mistakes in code comments
[22:20:03] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has quit IRC (Remote host closed the connection)
[22:20:29] *** KeiraT <KeiraT!~k4ra@gateway/tor-sasl/k4ra> has joined #illumos
[22:34:23] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has quit IRC (Quit: Leaving.)
[22:51:24] <sjorge> I use linux at work and it never really feels like.... home, while both illumos, freebsd, and openbsd quickly feel homey
[22:51:28] <sjorge> It's weird
[22:56:44] *** Alek <Alek!43bc77f7@c-67-188-119-247.hsd1.ca.comcast.net> has quit IRC (Remote host closed the connection)
[23:09:46] *** ldepandis <ldepandis!~ldepandis@unaffiliated/ldepandis> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[23:12:57] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[23:21:24] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[23:22:43] <andyf> I'm sorry to keep bringing this up, but does anyone have any insight into all of this C99/xpg4/xpg6 values stuff?.. Every couple of months I hit another problem
[23:22:49] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[23:23:28] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[23:23:29] <andyf> As far as I understand it, if we're building things as C99, then we need to be linking in xpg6-values to get C99/SUSv3 conforming behaviour
[23:23:53] <andyf> yet this also changes the behaviour of PTYs in a way that breaks loads of software
[23:24:01] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Read error: Connection reset by peer)
[23:24:07] <andyf> (openssh being the latest victim here)
[23:24:35] <andyf> Basically nothing ever expects null mblks to be passed up the stream, and yet they are if xpg4/6-values is linked in
[23:26:50] *** andy_js <andy_js!~andy@51.146.99.40> has quit IRC (Quit: andy_js)
[23:27:26] <rmustacc> I understand the principles, but no the practice.
[23:27:49] <rmustacc> And maybe we need to figure out what the concrete breaking behaviors are versus the more subtle things in terms of things like c99 math rounding rules.
[23:28:31] <rzezeski> What is a "null mblk"? A zero length one?
[23:28:37] <andyf> yes
[23:28:39] <rmustacc> Yeah
[23:29:06] <andyf> when you open a PTY with xpg4/6 set in the C library, then it sets a flag that's used in streams modules like ptem, ldterm
[23:29:24] <rmustacc> It seems worth taking apart the differences for PTYs and the specs.
[23:29:28] <andyf> and that means that zero length blocks are no longer suppressed
[23:29:45] <andyf> and almost no application expects read() to return 0 and that not mean EOF, it seems
[23:29:47] <rmustacc> Because the generation of them seems, weird.
[23:29:59] <rmustacc> Right, I don't know semantically how anything could handle that.
[23:30:34] <andyf> Our man page for read(2) says that a tty can return 0 if no data is available and it was opened with O_NONBLOCK, FWIW
[23:31:03] <andyf> and -1/EAGAIN if opened with O_NDELAY
[23:31:13] <rmustacc> The -1/EAGAIN behavior makes more senes.
[23:31:14] <andyf> sorry, the other way around
[23:31:16] <rmustacc> *sense
[23:31:19] <rmustacc> Wheh
[23:32:05] <rmustacc> andyf: So are generating the O_NDELAY case?
[23:32:08] <rzezeski> Yea, I know nothing about the terminal stuff. But I've always found it weird that certain parts of the network stack check for zero-len mblks. I think I understand how it might happen. But I also feel like it's one of those things you could just guarantee doesn't get pushed around.
[23:32:36] <andyf> Here's an example of the condition
[23:32:38] <andyf> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/ptem.c#L565
[23:33:03] <andyf> IS_PTSTTY is set if the stream was opened by an application linked with xpg4-values or xpg6-values
[23:33:43] <andyf> so for a pre-c99 application, the mblk is just dropped
[23:34:22] <andyf> rmustacc - I never managed to find any details on why xpg4 would require this different behaviour
[23:34:38] <andyf> even the original Sun bug that Josh had archived was not explicit
[23:35:16] <rmustacc> OK.
[23:35:23] <andyf> A simple test is to just write a program that does write(1, NULL, 0)
[23:35:37] <rmustacc> So, let's ask ourselves this. If software didn't get the zero reads does that hurt anything?
[23:36:20] <rmustacc> So, I guess we need to read the differences in the specs. But my suspision is that one of the standards allows these and the other doesn't, but that doesn't imply that we must generate them, tbh.
[23:36:41] <andyf> I doubt any software will care if they don't arrive
[23:37:02] <rmustacc> The other difference seems to be in flushing behavior.
[23:37:09] <andyf> so far, they definitely break - zsh, tmux, screen, openssh daemon
[23:37:12] <rmustacc> Which I think is worth understanding.
[23:37:20] <rmustacc> But it's hard to imagine a zero-byte read being useful.
[23:37:24] <rmustacc> And not just confusing.
[23:38:38] <rmustacc> My gut is that if you compare specs, something will have changed that.
[23:38:43] <rmustacc> But that doesn't mean we have to...
[23:39:21] *** aszeszo <aszeszo!~aszeszo@unaffiliated/aszeszo> has joined #illumos
[23:41:04] <andyf> Makes sense - I think doing something about this rather than continuing to patch software, or making gcc not link those files, is worthwhile
[23:41:10] <andyf> I can try and find the specs again
[23:42:33] <andyf> this seems to be XPG4 related
[23:42:47] <rmustacc> I think the zero byte read not being EOF is really a hard one to get folks out of.
[23:43:01] <rmustacc> Honeslty if it was non-blocking and did return EAGAIN, that'd be better.
[23:43:12] <rmustacc> But most folks aren't making the terminal non-blocking.
[23:45:12] <jbk> it sounds like maybe it's related to the I_SRDOPT setting.. or at least in whatever standard is from 2004
[23:45:46] <jbk> https://pubs.opengroup.org/onlinepubs/009695399/functions/read.html
[23:45:55] <jbk> i think that's xpg6, but not 100% sure
[23:46:38] <rmustacc> It is. Per the issue 6.
[23:46:40] <andyf> It's going to be the same thing that said that opening a PTY should cause certain modules to be pushed automatically
[23:46:51] <andyf> so maybe not strictly related to read()
[23:49:37] <rmustacc> Does this seem a reasonable plan, andyf?
[23:53:50] <jbk> though i guess we're learning why AT&T decided to yell when referring to STREAMs :)
[23:54:18] <rmustacc> Honestly, a lot of the issues with dlpi/streams are in the locking and implementations here, not the actual general idea, imho.
[23:54:33] <andyf> I think if we can find a clue about why this was done, we can assess if we can undo it..
[23:54:52] <rmustacc> andyf: Right, agreed.
[23:54:58] <jbk> isn't there a mailing list for posix?
[23:55:08] <rmustacc> I wouldn't go to them with this unless you have to.
[23:55:17] <rmustacc> Because I suspect a lot of this is implementation specific.
[23:55:25] <andyf> I am just grepping the opensolaris bug database... but it takes a while
[23:55:36] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
top

   February 13, 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