00:07:48 Ugh, it looks like hotmail.com is dropping our mail 00:07:58 I've lodged a support request with Microsoft 00:25:22 lists our, or other our? 00:26:36 if it's other our, is it because the people who spam the bug tracker then get that turned into (small amounts of) email? 00:26:44 we're a small-scale flappy bird amplifier 00:36:28 Just bug tracker, I assume. I can't really see detail about the lists 00:45:49 forth... is not a good language lol 00:48:49 it's exciting 00:49:37 That is a word I would not have chosen 00:49:53 But I guess it is at least printable 00:49:56 so that's an advantage 00:50:34 I always think of forth as at a level where you're asm but also need a language real quick 00:50:55 and then kind of that, but in spirit 00:51:01 where lua is now 00:51:21 To be honest, I think I would rather read the assembly 00:51:59 once it starts changing at runtime, I don't know what I'd rather do 00:52:17 I guess that's fair 00:52:35 I certainly do not enjoy that the parts that don't change at runtime are themselves written in forth 02:30:36 Truly not trying to trigger anyone but rather educate myself. What parts of Illumos are written in forth or is it something else that causes the pain? 02:32:33 the bootloader uses it for scripting... and it was also used by the firmware for sparc systems (technically never a part of illumos or solaris before it, but arguably closely linked) 02:35:18 Wow! I would have had no idea otherwise, thank you. The last exposure I had to Forth was taking a class at a community college during high school. SPARC stuff seems very cool from what I remember about reading of the architecture. I am impressed at the low-level understanding you all have. 02:43:54 Why forth though? Thank you all for your work on Illumos. I feel like I am just catching up to decades ago but somehow also looking at the future at the same time. 02:54:03 it's incredibly simple and has a very small footprint is my guess 02:54:11 (well simple to implement) 02:57:04 Fascinating. I suppose that is what the Oxide folks set out to correct. 08:46:36 every language has its ups and downs. In it, it is languages what you are working with, if you can not handle one, you need to look into the mirror. 08:47:08 in IT* 17:04:41 Itrospection is a good thing as well as being open to languages one is not used to. 17:28:38 the cost of forth interpreter versus cost of lua in terms of bytes is 57344 versus 122880 bytes in fbsd BIOS loader version (loader_lua - loader_simp and loader_4th - loader_simp sizes in this test system). 17:29:13 so everything we do has price tag of some sort attached. 17:30:37 *Introspection. I can spell when not tired. There is a Lua bootloader too? I imagine that at such a low level as bootloader that Forth makes much more sense from the size perspective. I should not have been so perjorative about it. 17:31:19 also lua is using more stack space. 17:32:59 The tradeoff for speed and limited space over higher level readability makes sense there. 17:33:00 well, yes, there is lua too, and the suggestion was that writing lua is more intuitive than forth. At the end, it did turn out that you still need to know the language well to actually write in it..... 17:33:20 or even read, for that matter. 17:34:40 Ha. Probably a good idea to know the language well, yes. It must be an interesting space to work in. 17:38:34 I know Forth is often used in HPC clusters and financial apps but was not aware of its presence in the bootloader. 17:40:04 It really depends;) How interesting you may find a piece of software which is running about 30 seconds (depending on what is your timeout counter value to allow you to interrupt automated boot;) 17:41:01 tsoome: "if you can not handle one, you need to look in the mirror" is just victim blaming 17:44:26 By way of example, it's not clear why this is in forth and not in C: https://github.com/illumos/illumos-gate/blob/e581456dc8e63dfcc1866df3444fe7b59c5d0d1c/usr/src/boot/forth/support.4th#L1236-L1335 17:44:46 being subjected to forth does make one feel like a bit of a victim, that's true 17:44:48 (i joke) 17:45:11 iximeow: victim is actually the guild-recognised title for a forth programmer 17:47:23 For the few people that spend time in the loader forth code, I didn't see the real benefit of all the work that went on to rewrite that in lua. Maybe I'm wrong. Perhaps the number of loader developers tripled. 17:47:50 andyf: "the few people that spend time in the loader" is absolutely self reinforcing 17:47:55 i will say having tripped over the bootloader a few months ago i had a fairly hard time learning enough forth to make sense of what i was seeing 17:47:58 heh 17:48:35 I have two degrees, I could write a forth from scratch if I wanted to, and I am investigating to fix a critical defect in the loader -- and yet, it's a truly massive impediment that is making me rethink my life choices 17:49:25 Seems an appropriate guild title. That is not the easiest code to make sense of. 17:51:21 May I ask what is the defect and how you came across it? 17:51:51 https://www.illumos.org/issues/17293 -- when I updated my software and the console was gone 17:51:52 → BUG 17293: console configuration is ignored on some systems (New) 17:52:21 well, it is rather obvious there are some better know languages around, but the fact is, the same few people who were writing boot loader scripts in fbsd, they are still writing those scripts. 17:53:41 gone how? your console to serial redirection was not configured to 9600? 17:54:28 Setting aside the passive aggressiveness 17:54:53 I had configured it in /boot/conf.d/console and when I rebooted it was trying to use a different device 17:54:57 cut your crap, can you answer even single question without insults? 17:55:30 What exactly do you think your constant stream of snark and negativity is? 17:56:03 oof, that sounds like a tough one. Didn't mean to set anyone off heheh. 17:56:14 iprog4u: You have done nothing wrong! 17:56:57 Oh good. Figured you two were just having some work fun but I am quite new here and didn't want to assume. 18:01:17 so, what was in config and what was actually used? 18:01:46 I don't recall right now, I'm going to have to dig up my notes and figure out what machine it was. 18:02:09 In the meantime I am adding a tracing facility to the environment store so that I can debug it 18:12:03 https://log.omnios.org/illumos/2024-02-24#1708832291-745890 was one of the machines 18:16:18 was it uefi or bios boot? 18:16:28 I expect probably BIOS 18:17:58 yes, its bios boot, it has the bug about 'N' 18:18:22 Right. It also has the bug that it ignored what was in the file 18:20:55 that is debatable, but its not important right now on this machine. The better question is, where from it got "9600,8,n,1,-" 18:21:28 It's definitely not debatable. I specified what I wanted, and that used to work, and on new bits it stopped working 18:21:45 you did not read my comment, right? 18:21:52 Which one 18:24:22 there are systems around which hung your machine, if you change the serial port speed. Your host has "good" SPCR, value is "115200,8,N,1,-", so even with your custom value it should be just fine, yet we land in kernel with 9600, which clearly is not neither your intent nor something which is configured by firmware. 18:24:44 so the immediate question would be, where from 9600 is appearing. 18:26:32 conf.d files are processed almost at the end, after bootenv.rc, defaults/loader.conf and loader.conf 18:31:24 A quick glance at i386/libi386/comconsole.c suggests: comc_ini() attempted to read the speed via comc_getspeed(), which either read 9600 or failed to read and defaulted to COMSPEED (9600). Then, because there was an SPCR table, we set ttya-mode-spcr to the value with "N" in it, then when my config file tried to set "ttya-mode" correctly to my chosen value, the comc_mode_set() hook saw 18:31:26 ttya-spcr-mode was set already and ignored my instructions 18:35:02 The fact that ttya-spcr-mode ends up as an invalid value is definitely a bug, but the fact that expressly ignore user directives in comc_mode_set() -- and maybe other places, I haven't done an extensive review yet -- is most of what 17293 is about 18:40:41 both ttyX-mode and ttyX-spcr.mode have 'N' issue, fixed in https://code.illumos.org/c/illumos-gate/+/3327/3/usr/src/boot/i386/libi386/biosacpi.c 18:40:42 → CODE REVIEW 3327: 16330 loader: SPCR needs better handling (NEW) | https://www.illumos.org/issues/16330 18:41:40 As in, they don't understand the uppercase "N" ? 18:42:15 oh, as in, we set them both in the SPCR code with the uppercase N 18:42:22 yep, but, the fact that we do not explicitly set 9600 in comconsole, does suggest we actually do get 9600 with comc_getspeed(port->ioaddr); and this is very disturbing. 18:44:28 what we could do there (in comc_ini()), is to parse ttyX-mode (or spcr mode, altho they must be the same because we do set them same in biosacpi.c), and only set speed if the comc_getspeed() differs from what SPCR is telling us. 18:51:04 again, the reason I am avoiding, well, very much suggesting to avoid setting the port speed, is the risk of getting hung system. bhyve with BHYVE_CSM firmware actually does hung on any serial input, BHYVE.fd hungs when we do change the port speed. 18:51:17 and bhyve is not only one doing so. 18:53:58 anyhow, if you get to the console of this machine, please check if you can get boot: prompt - that is, press space (anything but enter;) as a very first thing, and you should get functional boot: prompt. We can not really check the port attributes from it, but at least we can confirm if it is usable 19:04:02 Second interesting fact would be to see if fixing 'N' would fix the port speed problem. On my supermicro and X6-2 I did not observe such issue but this does not really mean anything other that those machines are behaving as expected:( 19:06:57 sadly, even with uefi, it seems sometimes more like a suggestion than a standard... for legacy bios it's probably even worse... 19:07:37 like the uefi standard has the (unfortunately named) concept of SysPrep applications 19:08:03 where like your boot order, you can define UEFI applications to run prior to running the boot application to prepare the system 19:08:18 supermicro's bios say they support them, but they don't actually 19:08:51 they also do some non-standard stuff with the bootorder 19:15:27 that sounds so much fun 19:23:07 buckets full 20:05:09 How come ${X_GATE}/usr/src/cmd/zoneadmd/mcap.c is present in illumos-gate but not illumos-joyent nor illumos-omnios? 20:06:05 I do not see it in illumos-gate 20:08:14 are you sure its not leftover from somewhere else? 20:08:54 Apparently so... I don't see it in the fresh gate either 20:09:26 git whatchanged did not list it either 20:09:43 I am looking through old commits and maybe I mistakenly copied something 20:11:33 It was removed in OmniOS in commit 3f77773bdad3d0bfbd6cd39cf45434a46b6369d5 which looks like it came over from SmartOS 20:12:59 Which means it was probably introduced to OmniOS in the same way 20:13:17 jbk have you worked with libzpool in user space? I get 630 threads from it and it makes gdb to crawl:( 20:13:19 yes, it looks like it was never in illumos 20:13:43 Jerry added it, Jerry removed it 20:14:11 added with OS-11 removed with OS-6355 20:15:08 @andyf Was there a replacement elsewhere for the functionality of mcap.c? 20:16:06 fenix: OS-6355 20:16:07 OS-6355: in-kernel zone page invalidation (Resolved) 20:16:07 ↳ https://smartos.org/bugview/OS-6355 | https://github.com/joyent/illumos-joyent/commit/99e0ea6 20:16:52 which points to joyent rfd 38, which I don't know how to look at 20:16:54 danmcd? 20:17:05 but it sounds like they did the same thing, better and more accurately. 20:17:55 https://github.com/TritonDataCenter/rfd/blob/master/rfd/0038/README.md 20:22:08 @tsoome This is what I was looking for. Thanks for that 20:22:16 yw 20:25:01 tsoome: i have not 20:25:26 ok. 20:28:21 You can look at any of the RFDs in the aforementioned github repository, @richlowe .. Thanks @tsoome for beating me to the punch. 20:29:32 I have those moments between stepping gdb;) 22:58:27 I was trying to compile some cgo, ran into missing Ftm_gmtoff and Ftm_zone are undefined. Do we have these? https://gitlab.com/cznic/libc/-/blob/master/time/time_illumos_amd64.go?ref_type=heads#L190 23:02:05 https://github.com/illumos/illumos-gate/blob/master/usr/src/head/iso/time_iso.h#L80 23:02:18 Doesn't look like it :( 23:54:38 Smithx10: If you already have a "struct tm", you can use "tm_isdst" to determine if DST is in effect or not. If DST, the "altzone" global contains the tm_gmtoff value, and if not DST the "timezone" global contains the value 23:56:02 The "tzname" global seems to contain the names of the effective timezones as well 23:56:14 see also: https://illumos.org/man/3C/ctime