Switch to DuckDuckGo Search
   May 31, 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 | >

NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:58:24] *** andy_js <andy_js!~andy@> has quit IRC (Quit: andy_js)
[01:02:18] *** phyre <phyre!~phyre___@> has joined #illumos
[01:13:17] *** phyre <phyre!~phyre___@> has quit IRC (Remote host closed the connection)
[04:21:57] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Ping timeout: 260 seconds)
[04:24:05] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[04:57:20] *** janci <janci!~janci@binaryparadise.com> has quit IRC (Read error: Connection reset by peer)
[04:57:38] *** janci <janci!~janci@binaryparadise.com> has joined #illumos
[04:57:40] *** BrownBear <BrownBear!~BrownBear@> has quit IRC (Quit: Ping timeout (120 seconds))
[04:59:50] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has quit IRC (Ping timeout: 260 seconds)
[05:00:18] *** PMT <PMT!~PMT@pool-100-33-69-155.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 260 seconds)
[05:00:18] *** tru_tru <tru_tru!~tru@> has quit IRC (Ping timeout: 260 seconds)
[05:00:56] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has joined #illumos
[05:01:04] *** tru_tru <tru_tru!~tru@> has joined #illumos
[05:01:05] *** PMT <PMT!~PMT@pool-100-33-69-155.nycmny.fios.verizon.net> has joined #illumos
[05:12:22] *** BrownBear <BrownBear!~BrownBear@> has joined #illumos
[05:34:17] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Ping timeout: 260 seconds)
[05:39:40] *** xzilla <xzilla!~robert@pool-71-166-61-141.bltmmd.fios.verizon.net> has joined #illumos
[06:14:43] *** aav1o2 <aav1o2!~aav1o25@> has joined #illumos
[06:32:05] *** aav1o2 <aav1o2!~aav1o25@> has quit IRC (Ping timeout: 265 seconds)
[07:16:18] *** BOKALDO <BOKALDO!~BOKALDO@> has joined #illumos
[07:16:22] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 260 seconds)
[07:16:53] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[07:18:32] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Quit: Leaving)
[07:45:05] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Quit: WeeChat 1.9.1)
[08:38:17] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has quit IRC (Remote host closed the connection)
[08:38:46] *** alanc <alanc!~alanc@inet-hqmc02-o.oracle.com> has joined #illumos
[09:23:33] <ypankov> jollyd: what is the point of binaries in /usr/bin/amd64 where their /usr/bin counterpart is NOT a isaexec link?
[09:39:01] *** wacki <wacki!~wacki@i577B82EA.versanet.de> has joined #illumos
[09:58:14] <richlowe> some stuff re-execs, some things we ship a 64bit version but don't automatically use it
[09:59:35] <richlowe> we really should just ship the things where it doesn't matter in /bin and drop the 32bit ones at this point
[10:18:13] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[10:33:19] *** phyre <phyre!~phyre___@> has joined #illumos
[10:41:19] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[10:41:39] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[10:41:57] *** am11 <am11!~am11@dsl-hkibng22-54f985-221.dhcp.inet.fi> has joined #illumos
[10:43:21] <am11> moi :)
[10:47:14] <am11> i am trying to find out some api to gather network (tcp and ip) statistics.
[10:47:43] <am11> is there something like kstat for networking?
[10:48:07] <am11> on linux, there is sysctlbyname("net.inet.tcp.stats",...) and friends.
[10:51:47] <ptribble> all the network stats are exposed as kstats
[10:52:12] <ptribble> you're probably interested in the ones in the mib2 class
[10:52:45] <ptribble> you can see those interactively with 'kstat -c mib2'
[10:59:13] *** phyre <phyre!~phyre___@> has quit IRC (Remote host closed the connection)
[11:58:03] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-26.net.upcbroadband.cz> has quit IRC (Quit: Leaving.)
[12:35:01] *** wilbury <wilbury!otis@netbsd/developer/otis> has quit IRC (Quit: host upgrade)
[13:02:06] <jollyd> ypankov: it made sense for foo-config binaries used to query the configuration of libraries or python/perl/... modules but since we move to 64-bit interpreters and 64-bit binaries by default it is mainly relics...
[13:03:27] <jollyd> ypankov: nowadays anytime we update a package we make it 64-bit only or put the binary in /usr/bin
[13:03:50] <jollyd> if you encounter one that does not follow the rule then it just means that it has not been converted yet
[13:13:05] <jollyd> ypankov: for some other things it is due to dependencies... like for this icu update I do not have time to check all the dependencies that possibly make use of the 32-bit version...
[13:13:08] <jollyd> :(
[13:13:37] *** pwinder <pwinder!~pwinder@> has joined #illumos
[13:14:17] <jollyd> and unfortunately LibreOffice was packaged as 32-bit :(
[13:14:22] <jollyd> so it is a pain
[13:16:44] <ypankov> Got it.
[13:18:49] *** pwinder <pwinder!~pwinder@> has quit IRC (Quit: This computer has gone to sleep)
[13:40:18] <jollyd> ypankov: actually thank you for asking, you made me realize that I can probably fix this without too much trouble
[13:50:05] *** liv3010m_ <liv3010m_!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 246 seconds)
[13:51:19] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[14:32:47] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[14:33:23] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has joined #illumos
[14:34:45] <sjorge> Alright, enough messing about today! the USB device no longer crashes the kernel when plugged in!
[14:35:13] <sjorge> I did have most tx/rx/control functions as just return ALL OK
[14:54:03] *** cantstanya <cantstanya!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Ping timeout: 240 seconds)
[14:57:39] *** cantstanya <cantstanya!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[15:01:23] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[15:05:24] *** Kurlon <Kurlon!~Kurlon@167-48.gwi.net> has quit IRC (Ping timeout: 272 seconds)
[15:13:35] <ypankov> jollyd: Great :) I was just checking if any of OI components are using isaexec, and it doesn't seem they do though.
[15:14:42] *** BOKALDO <BOKALDO!~BOKALDO@> has quit IRC (Quit: Leaving)
[15:14:52] *** roryrjb <roryrjb!~rory@> has joined #illumos
[15:18:43] <jollyd> ypankov: we removed isaexec use over the years
[15:19:03] <jollyd> ypankov: it was quite useful back then but not so much now
[15:19:25] *** dopplerg- <dopplerg-!~dop@> has quit IRC (Ping timeout: 246 seconds)
[15:22:42] *** dopplergange <dopplergange!~dop@> has joined #illumos
[15:37:47] <ypankov> I wonder why we aren't using the VPATH feature and rather do "%.o: ../../../uts/common/os/%.c" along with repeating rules instead?
[15:56:19] *** tomww <tomww!~tom@unaffiliated/tomww> has quit IRC (Remote host closed the connection)
[15:59:57] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[16:00:01] <tsoome> I did play with VPATH a bit, but it felt odd
[16:00:55] <ypankov> It's used everywhere with bmake, so it's surprising it feels odd to you.
[16:01:11] <ypankov> (It's just PATH there, but still the same)
[16:01:47] <tsoome> :D
[16:04:52] *** wilbury <wilbury!otis@netbsd/developer/otis> has joined #illumos
[16:05:35] *** BOKALDO <BOKALDO!~BOKALDO@> has joined #illumos
[18:06:13] *** PMT <PMT!~PMT@pool-100-33-69-155.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 264 seconds)
[18:17:22] *** tomww <tomww!~tom@unaffiliated/tomww> has joined #illumos
[18:29:22] *** PMT <PMT!~PMT@pool-100-33-69-155.nycmny.fios.verizon.net> has joined #illumos
[18:47:29] <tsoome> ypankov, I think it would be nice to get obj tree separated from source tree, but at that point, I did figure it was better to follow the logic of the rest of the tree.
[18:56:02] <ypankov> tsoome: I'm playing around with bmake, and e.g. the following allows both dmake and bmake to build smatch, and looks a bit cleaner IMO: https://pastebin.com/eBJFQBHU
[18:58:22] <tsoome> thats nice.
[18:59:35] <jollyd> clean :)
[19:08:38] <rmustacc> I would suggest even if we get rid of consumers of it, one doesn't remove the actual isaexec binary.
[19:09:13] <rmustacc> As other folks have used it over the years in distros and other places. But that little bit of C code doesn't hurt.
[19:09:15] <ypankov> rmustacc: agreed.
[19:09:24] <rmustacc> But there are caes where you're going to need 32-bit and 64-bit versions of thigns still.
[19:09:29] <rmustacc> Like many of the ptools and mdb.
[19:09:35] <rmustacc> So you're not going to get rid of everything.
[19:09:42] <rmustacc> But they also will often exec themselves.
[19:10:17] <rmustacc> So while isaexec is a defalut, it doesn't mean that all 32-bit/64-bit paths will disappear.
[19:10:42] <rmustacc> Regardless of whether we have 32-bit binaries or not, tools like mdb should still support 32-bit softwaer.
[19:10:45] <rmustacc> *software
[19:10:59] <ypankov> You need to use 32bit mdb for 32bit processes?
[19:11:06] <rmustacc> Yes.
[19:11:10] <rmustacc> That is how it's implemented.
[19:11:21] <ypankov> And same for ptools?
[19:11:23] <rmustacc> Same is true for a number of other libraries and things.
[19:11:49] <rmustacc> That doesn't impact isaexec.
[19:11:55] <rmustacc> But it means that you can't just burn the world.
[19:12:29] <ypankov> At least I can have one /usr/bin/w that is 64bit, and not a link to isaexec
[19:12:44] <rmustacc> Correct.
[19:13:20] <rmustacc> Though I would consider whether we want to structure things such as to ever allow a 32-bit port again or not. But something to think about and if we want a major policy shift, worthy of an ipd.
[19:13:41] <rmustacc> But for things like, w, where it has to match the bitness of the kernel, seems mostly reasonable.
[19:13:55] <rmustacc> There are other cases though where the address space limits are somewhat important for responsiveness, accidentally.
[19:13:59] <rmustacc> For example, sorting in ls.
[19:14:24] <alanc> Yeah, we got rid of most links to /usr/lib/isaexec but left it around since others could have linked to it themselves
[19:14:25] <rmustacc> If you have the 64-bit only version of it, you can exhaust memory much faster due to it trying to sort everything in a larger address space.
[19:14:52] <rmustacc> Mostly just trying to say there are trade offs and just worth thinking through.
[19:15:13] <rmustacc> And we need to go manually inspect a lot of code to make it 64-bit safe that we haven't today.
[19:15:16] <ypankov> ls is 32bit and is not a link to isaexec
[19:15:32] <ypankov> So that's separate.
[19:15:38] <rmustacc> I was talking more generally.
[19:16:32] <rmustacc> As there's both a usr/bin/ls and a /usr/bin/$(ARCH64)/ls.
[19:18:04] <alanc> in theory, isaexec can be used for other things besides 32-vs-64 bit, if there's some ISA extension that makes sense to compile a whole separate binary for, but in practice, no one does that
[19:18:26] <rmustacc> Yes. I expect if we had been earlier to ARM, one might have done that for armv6 vs. armv7.
[19:19:14] <rmustacc> It actually is a pretty interesting model of flexibility.
[19:19:37] <rmustacc> But also, the linker features thta allow for relocation based on hw caps are also a nice bit of flexiblity here.
[19:20:17] <tsoome> ls can be fixed:)
[19:20:49] <rmustacc> Sure, someone can look at redoing the sorting to not explode 64-bit memory usage.
[19:21:10] <rmustacc> None of these are blockers. Just pointing out that it's not as straightforward in some cases.
[19:21:44] <tsoome> ypankov yep.
[19:21:48] <tsoome> oops.
[19:21:50] <rmustacc> Which again, isn't true for the isaexec case.
[19:22:01] <tsoome> ypankov how about https://code.illumos.org/c/illumos-gate/+/702 ?:)
[19:22:10] * ypankov fixes tsoome
[19:29:30] <tsoome> rmustacc about CCVERBOSE, if I file the issue, and set those NULL pointer issues to be related to it, is it enough?
[19:30:06] <tsoome> I mean, we have CCVERBOSE all over the tree..
[19:30:09] <rmustacc> Either that or including it as a second bug id in the message.
[19:30:19] <rmustacc> I understand.
[19:30:33] <rmustacc> Not trying to say don't fix it, just that the way it's done leads someone to think it's for the wrong reason.
[19:31:02] <rmustacc> Because of the unfortunate misleading comments above the cflags bits.
[19:31:20] <rmustacc> If we're going to do piecewise commits, which is fine, the message should reflect everything that we're doing.
[19:31:43] <rmustacc> At least, in my opinion.
[19:31:56] <ypankov> tsoome: I'm not sure, does it really need fixing? If so, I'll let someone else +1 it.
[19:33:27] <rmustacc> Is this 12790?
[19:33:39] <ypankov> Yes.
[19:33:56] <rmustacc> I had noticed that as well and actually wanted to fix it too.
[19:34:01] <rmustacc> Because it makes it harder to find real errors in the log.
[19:34:06] <tsoome> it is noise in nightly.log, I often search for *** Error
[19:34:16] <rmustacc> Yup, exactly.
[19:34:21] <rmustacc> I'll take a look at that tsoome.
[19:34:30] <tsoome> thanks:)
[19:34:37] <ypankov> Good, solved.
[19:41:53] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has quit IRC (Quit: Leaving)
[19:48:33] *** vila <vila!~vila@laubervilliers-659-1-133-94.w80-15.abo.wanadoo.fr> has joined #illumos
[19:55:37] <gitomat> [illumos-gate] 12808 sun4u/unix: this 'if' clause does not guard -- Toomas Soome <tsoome at me dot com>
[22:11:53] *** jollyd <jollyd!~alarcher@2a01:cb1d:611:bb00:8820:7cbd:8965:af56> has quit IRC (Quit: Leaving.)
[22:16:00] *** BOKALDO <BOKALDO!~BOKALDO@> has quit IRC (Quit: Leaving)
[22:17:19] *** roryrjb <roryrjb!~rory@> has quit IRC (Ping timeout: 246 seconds)
[22:18:18] *** wacki <wacki!~wacki@i577B82EA.versanet.de> has left #illumos
[22:19:15] *** roryrjb <roryrjb!~rory@bl9-21-48.dsl.telepac.pt> has joined #illumos
[22:30:42] <sjorge> pmooney: figured out the VNC problem, it the color pallet. Using a full range pallet of 'milions' works fine
[22:30:56] <sjorge> Some clients that's only support 'thousands' corrupt the buffer and make the vnc socket break
[22:31:06] <sjorge> I wonder if it is also upstream
[22:31:11] <sjorge> but no freebsd bhyve to test
[22:38:00] <wilbury> i've had similar problem with bhyve on freebsd, had to switch quality to "medium"
[22:38:17] <wilbury> otherwise vnc just choked and won't display anything
[22:41:21] <wilbury> sjorge: ^^^
[22:45:51] *** roryrjb <roryrjb!~rory@bl9-21-48.dsl.telepac.pt> has quit IRC (Ping timeout: 260 seconds)
[22:45:58] *** roryrjb <roryrjb!~rory@> has joined #illumos
[22:50:48] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[23:00:20] <sjorge> Good to know
[23:09:07] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 246 seconds)
[23:09:17] *** lblume <lblume!~lblume@greenviolet/laoyijiehe/lblume> has quit IRC (Ping timeout: 260 seconds)
[23:15:04] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[23:16:46] *** nbhauke <nbhauke!~hauke@55d4869b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[23:59:20] *** roryrjb <roryrjb!~rory@> has quit IRC (Quit: leaving)

   May 31, 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 | >