05:50:47 <arekinath> anyone have an opinion on whether poll() on a connection-oriented AF_UNIX socket should be able to give you POLLHUP, even if you didn't specify POLLIN?
05:51:20 <arekinath> context is illumos #18080
05:51:50 <arekinath> linux says yes you can get POLLHUP, and you even get woken up for it
05:52:14 <arekinath> BSDs say no, you never get POLLHUP on a UDS (even with POLLIN!), you have to read or write and look for EOF or SIGPIPE
05:53:37 <arekinath> actually sorry that isn't true for more modern BSDs, they will give you POLLHUP but only if you ask for POLLIN
05:53:55 <arekinath> but pfd.events = 0 will never wake you up
05:55:47 <arekinath> (or any pfd.events value that doesn't include POLLIN)
05:58:48 <arekinath> maybe I should just ask the list lol
06:34:36 <tsoome> :) I guess ppl are sleeping still in US
06:34:53 <tsoome> or rather, already;)
06:35:29 <arekinath> haha it's probably also the kind of thing that is best considered for a bit before replying. better fit for the list than irc ;)
14:48:23 <sommerfeld> arekinath: I agree with your analysis of #18080.  It's a bug that we *usually* wake up the waiter but don't *always* wake it up.  Sending extra events is less likely to induce application misbehavior than withholding them.
15:09:44 <arekinath> yeah I don't think the current situation we're in could _not_ be a bug, it's inconsistent and basically racey haha
15:10:36 <arekinath> just a matter of whether we stop trying to deal in HUPs for UDS altogether like BSD does, or add in the missing wakeups to get to the Linux semantics
15:12:25 <arekinath> I get paranoid about unintended consequences in these dusty little corners though
15:17:52 <arekinath> I guess if user code is currently working on us though, it means it does already cope with getting POLLHUP on UDS, sometimes
15:18:16 <arekinath> since we do already give it to them, just not consistently
15:19:49 <arekinath> so maybe getting rid of it altogether is more likely to cause problems than getting it consistently?
15:20:25 <arekinath> certainly seems true with LX and other users of devpoll/epoll
15:52:47 <sommerfeld> arekinath: yeah, that's my take -- the current behavior may work well enough that disabling the events to match BSD would lead to hangs of thought-to-be-working applications.
15:57:22 <jbk> yeah, i'd lean towards the linux behavior.. (not having heavily used UDS sockets, the linux behavior is closer to what i'd expect)
16:25:29 <sommerfeld> our man page says " The event flags  POLLHUP, POLLERR, and  POLLNVAL
16:25:29 <sommerfeld>        are always  set in revents if the conditions they indicate are true;
16:25:29 <sommerfeld>        this occurs even though these flags were not present in events."
16:25:36 <sommerfeld> so I think that seals it.
18:16:07 <gitomat> [illumos-gate] 18000 tty group id should use a named constant from sys/param.h -- Andy Fiddaman <illumos⊙fn>
18:16:07 <gitomat> [illumos-gate] 17994 Duplicate link entries accumulate in devlink database without bound -- Andy Fiddaman <illumos⊙fn>
21:46:03 <Guest63> Hey Ya'll sorry for the basic question but does anyone know of an illumos disro that will work on arm? I'd ideally like to run something like omni on a rasp pi but it  seems like builds for this don't exist? What's the arm progress for illumos is this something I could do myself?
22:10:54 <ptribble> For arm builds, see https://downloads.omnios.org/media/braich/
22:44:48 <gitomat> [illumos-gate] 18077 RPC fixes after 16390 -- Gordon Ross <gordon.w.ross⊙gc>
22:44:48 <gitomat> [illumos-gate] 18076 NFSv4.0 Client Receives NFS4ERR_DELEG_REVOKED -- Gordon Ross <gordon.w.ross⊙gc>
23:48:43 <gitomat> [illumos-gate] 18034 libscf: deadlock in `scf_value_set_from_string` with some invalid values -- Robert Mustacchi <rm⊙fo>