15:35:42 What is SIGAPOLLO? 16:20:59 your process has gone off into space? :) 16:23:13 or worse, your process has been bought by HP and turned into it's brand name for UNIX workstations, but only late 80's/early 90's folks remember that one 16:23:45 * alanc fighting the urge to respond to the "there can be no GPL in illumos-gate" email with https://github.com/illumos/illumos-gate/blob/master/usr/src/grub/grub-0.97/COPYING 16:29:15 bbarker: SIGAPOLLO is in code that is from ksh93/ast that is ifdef for apollo. So not something I believe that impacts us. 16:30:48 People forget how astonishingly diverse the operating systems of the 80s/90s were, but Domain/OS was peculiar even by the standards of the time 16:41:15 the underlying Domain/OS was written in Pascal, not C, but then so was the Mac OS back then - the UNIX interface was a layer on top 17:02:18 ISTR someone describing that it could have different 'personalities' (for lack of a better term) 17:02:24 unless I'm thinking of something else 17:04:40 yes, it had BSD and SysV "personalities" side-by-side. (I was at Apollo from 1988 through the HP acquisition and remained at HP for a long time afterwards) 17:08:22 the user/kernel split in Domain/OS was .. different; the kernel interface was at a somewhat lower level. emulating unix/posix APIs in the presence of fork() is tricky because of how descriptors share seek pointers. 17:08:51 but one thing this enabled was environment variable references in symlink targets. 17:10:34 and one of the environment variables picked BSD vs SysV, and /bin and /usr/bin and a bunch of other paths were symlinks which included an environment variable reference that picked the desired variant. 17:16:52 i was adding the signals to a coreutils library and was struck by how many more signals illumos had than every other supported OS, but I was already thinking a lot of it was probably historical! - thanks rmustacc, alanc 17:17:21 Where are you looking for signals? 17:17:29 there were a few easter eggs in the OS (such as the 'unit will not fit thru 25" hatch' error code which memorialized an incident when field engineers reportedly discovered at pierside that there was no way to getting one of their workstations into a submarine...) 17:17:44 rmustacc, usr/src/contrib/ast/src/lib/libast/features/signal.c 17:17:56 OK, that has nothing to do with what illumos provides. 17:18:10 That is what AT&T's cross-platform library knows about. 17:18:35 i see - probably should have realized that after seeing it under contrib 17:18:44 Our defined signals are in signal.h(3HEAD) and you can find the header for uts/common/sys/iso/signal_iso.h. 17:19:41 But note that real-time signals can begin with a varying number and that can change explicitly. 17:20:26 quoting from a PDF I found on bitsavers: "DOMAIN systems send the signal SIGAPOLLO whenever a fault occurs that is not 17:20:26 otherwise mapped into a signal. Typical generators of SIGAPOLLO include network 17:20:26 failures, display-acquire timeouts, and disk full errors." 17:20:30 So please make srue if you're transcribing signals you are paying attention to that (https://illumos.org/man/3HEAD/signal.h). 17:20:48 SIGRTMIN and SIGRTMAX are not constants. 17:22:09 rmustacc, wonderful - thank you 17:22:36 (Aegis had its own error code system which was much finer grained than UNIX/Posix errno; the same code space was used for both the AEGIS equivalent to signals and for failure returns from system calls. 17:23:44 ) 17:25:21 Domain/OS also had some nice features that were ahead of its time, like transparently compressed files, and the ability to do "ps //nodename" to check on another host's processes 17:26:10 looks like some docs have survived here, including some once internal-only docs: http://www.bitsavers.org/pdf/apollo/ 17:26:13 if I remember correctly, the '//hostname/' part of the URL spec came from Apollo's use of '//hostname/' as the equivalent to Sun's '/net/hostname/' 17:26:58 yes. partly via microsoft 17:28:23 The fact that "/.." actually resolved to a different directory ("//" - the root of the network namespace) did confuse some Unix folks 17:29:16 uuids are another thing that escaped/survived from apollo. 17:46:55 bbarker: the Solaris signals should be almost all the same as illumos, but if you need a reference for them, see: https://docs.oracle.com/cd/E88353_01/html/E37841/intro-2.html 17:47:14 75 EADI would be one notable difference 17:47:40 does escape imply they should be recaptured? :) 17:52:51 alanc: EADI looks like an errno? 18:01:06 oh, right, brain fart 18:02:36 that's the page that lists errno values, https://docs.oracle.com/cd/E88353_01/html/E37842/signal.h-3head.html is signals 18:05:50 and it looks like we failed to update that page for the one change we've made in signals (SIGAIOCANCEL replacing SIGLWP) 18:07:03 richlowe - usr/src/contrib/ast/ is populated from https://github.com/illumos/ast so the spelling fixes will just get reverted next time we do a sync over for a bug fix (although we'll likely spot it and not care too much). I'd say generally let's not "fix" minor things like typos in contrib as a general rule. It looks like there were some unresolved comments to that effect on the gerrit review in the "default" change. 18:10:27 alanc https://github.com/ksh93/ksh/tree/dev/src/lib/libast definitely has some good fixes, and I've cherry picked things from there in the past, but it also has some changes which I think head in the wrong direction. 18:15:17 the change in the https://github.com/ksh93/ksh repo we're currently struggling with is the decision to always use temporary files and remove the fallback to pipes for command substitutions, since that breaks in services in which we've removed the privs to write to the filesystem since they don't need to do that 18:15:41 (based on what I've heard from the engineer working on it) 18:16:04 https://github.com/ksh93/ksh/commit/42becab6 18:22:07 alanc, thanks - I suppose I should fire up a solaris vm to test this change on. But trying to create an Oracle Account failed with an error :'-( I will try again later though. Does solaris report its OS string as "solaris" or "sunos"? Sounds like I may be able to assume the signals are the same? 18:25:15 alanc, i'll double check the reference you sent in any case and follow up if I find any differences 18:25:26 depends where you're getting the OS string from. "uname -s" still reports "SunOS" to avoid breaking 30+ years of backwards compatibility. "uname -o" reports "Solaris" 18:25:58 bbarker: note the correction in the later discussion that I'd listed the errno reference there, and the signal one later 18:26:25 alanc, would it be easy for you to run a small hello-worldish program in Rust to find out what I need? I can paste the one-liner here (no worries if not) 18:26:55 oh SIGAIOCANCEL is in solaris now? gotcha 18:28:05 yep, technically it's in illumos too, but hidden: https://github.com/search?q=repo%3Aillumos%2Fillumos-gate%20SIGAIOCANCEL&type=code 18:28:14 alanc interesting, thanks. I had a problem with a change where there was a bug in the support for multiple interpreters (which I later fixed and sent a PR), so they just started chopping out some of that support. I think it was a structurally bad change. 18:33:25 .oO "It should all be deleted when solaris_nevada ships." 18:33:54 oh, so 12 years ago? 18:34:11 apparently 18:34:46 https://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libuutil/common/uu_misc.c?r=6a634c9d#50 18:40:54 heh, apparently I filed the bug to remove that code in 2014 - maybe I should go delete it one of these days 18:41:59 If anyone has the easy ability to run rust programs on Solaris 11.4 - `cargo new hello` and replace the println in main.rs with: println!("Hello, {}", std::env::consts::OS); 18:42:20 :D 18:43:36 oh, and then `cargo run` to execute 18:43:56 alanc btw, do you know why that source has assfail()? 18:44:11 bbarker: Hello, solaris 18:44:52 alanc, awesome - thanks again 18:45:00 at least on Solaris 11.4.66 with rustc 1.70.0 18:45:30 think i'm using the same rustc and that recent version is good enough for me 18:45:41 of Solaris that is 18:46:30 technically, 11.4.66 is a slightly future version, but it's what I'm testing on at the moment 18:46:49 I don't think it changed from the versions we already shipped 18:49:33 tsoome_: no I don't, it appears to go back to the initial integration with the greenline project 19:57:23 tsoome_: it makes no sense I can work out 19:58:29 it's not public, it seems like it would make assert() loop 20:08:32 good evening 20:09:56 I asked yesterday, but would like to ask again: if bhyve complains that bhyve: PCI device at 7 is not using the ppt driver\ndevice em 20:09:59 ulation initialization error: Device busy 20:11:17 how can I figure out why bhyve thinks the device is busy when only ppt is attached to the device, pptadm list shows correct output? and why does the number "device at 7" doesn't match the pci slot I specified with -s 8,passthru,/dev/ppt0 ? 20:14:44 pmooney and Woodstock are probably your best to ask 20:15:19 I know, but I just wanted to try my luck here before directly annoying people :) 20:15:30 Yeah, I was hoping they'd show up here when I pinged them :) 20:15:36 haha 20:15:42 ok :) 20:16:29 the 'PCI device at is not using the ppt driver' message is using the file descriptor, not the slot 20:16:49 (which, to be fair, it does not make clear) 20:16:53 ah! ok, that's pretty not intuitive :) 20:17:06 agreed 20:18:09 richlowe: I don't think it will loop, since _assert is what's called when assert fails - the only thing I can think of is it allows userspace code to use the kernel's ASSERT() macro (from sys/debug.h) instead of libc's assert() macro (from assert.h), but usr/src/lib/libc/port/threads/assfail.c also defines an assfail() 20:19:34 pmooney: so, I try to forward a wifi card. I see the ppt0 in pptadm list seeing the device, no other entries are in the path_to_inst for that pci device (except ppt of course) - what could make the device busy? 20:20:42 This is on an intel machine, I assume? 20:20:51 yes, a thinkpad T530 20:21:11 alanc: you're right, I mis-counted _'s 20:22:16 pmooney: could it be an issue with my CPU? 20:22:34 that is amazing naming where distinguishing the number of _'s changes the whole meaning - I can see why the kernel chose assfail instead 20:24:28 Agnar: well if you were on AMD, the ppt stuff hasn't been wired up 20:24:56 pmooney: no, it's a Core i7-3630QM 20:24:59 but on a consumer (read: non-Xeon) part of that vintage, I don't know if the iommu stuff is exposed 20:25:18 the difference (I think) I see is the opposite of the comment in libc's `__assfail` about how libc has it to avoid gettext 20:25:31 pmooney: it used to work on my T470 with a bit more modern core i5 20:25:32 admittedly this is an area of bhyve that has not been a strong focus 20:25:43 and then libc's assfail() just calls __assfail because libaio used to expose it (ugh) 20:25:46 pmooney: but yeah, that sounds plausible. 20:26:01 so it is possible uutil is trying to get the apparent gettext() call back? 20:26:04 I think 20:26:12 pmooney: thanks so far! 20:32:33 and check_fnames went away with direct bindings/synonyms.h purging 20:34:21 Yeah, I dunno tsoome_. It is local in libuutil, and I don't see a way anything could call it 20:35:27 (libuutil doesn't use the sys/debug.h ASSERT/VERIFY family) 20:40:22 it also has it's own panic bit.. wonder if it'd be useful at all to wire it into upanic(2) 20:43:01 I know Robert had had thoughts about that 20:44:52 About uutil? 20:46:27 about more stuff using upanic(2) 20:46:37 in general 20:46:48 Ah, yeah. In general, it'd be good. Looking at that, I'd replace anything spinning trying to abort with upanic(). 20:47:03 So that seems a reasonable candidate for simplification there jbk. 21:01:42 [illumos-gate] 16008 crypto commands should not be isaexec'd -- Richard Lowe 21:01:42 [illumos-gate] 16014 don't deliver /usr/lib/locale/C from closed-bins -- Richard Lowe