Ugh, it looks like hotmail.com is dropping our mail

I've lodged a support request with Microsoft

lists our, or other our?

if it's other our, is it because the people who spam the bug tracker then get that turned into (small amounts of) email?

we're a small-scale flappy bird amplifier

Just bug tracker, I assume. I can't really see detail about the lists

forth... is not a good language lol

it's exciting

That is a word I would not have chosen

But I guess it is at least printable

so that's an advantage

I always think of forth as at a level where you're asm but also need a language real quick

and then kind of that, but in spirit

where lua is now

To be honest, I think I would rather read the assembly

once it starts changing at runtime, I don't know what I'd rather do

I guess that's fair

I certainly do not enjoy that the parts that don't change at runtime are themselves written in forth

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?

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)

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.

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.

it's incredibly simple and has a very small footprint is my guess

(well simple to implement)

Fascinating. I suppose that is what the Oxide folks set out to correct.

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.

in IT*

Itrospection is a good thing as well as being open to languages one is not used to.

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).

so everything we do has price tag of some sort attached.

*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.

also lua is using more stack space.

The tradeoff for speed and limited space over higher level readability makes sense there.

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.....

or even read, for that matter.

Ha. Probably a good idea to know the language well, yes. It must be an interesting space to work in.

I know Forth is often used in HPC clusters and financial apps but was not aware of its presence in the bootloader.

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;)

tsoome: "if you can not handle one, you need to look in the mirror" is just victim blaming

By way of example, it's not clear why this is in forth and not in C: github.com/illumos/illumos-gate/blo…/boot/forth/support.4th#L1236-L1335

being subjected to forth does make one feel like a bit of a victim, that's true

(i joke)

iximeow: victim is actually the guild-recognised title for a forth programmer

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.

andyf: "the few people that spend time in the loader" is absolutely self reinforcing

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

heh

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

Seems an appropriate guild title. That is not the easiest code to make sense of.

May I ask what is the defect and how you came across it?

illumos.org/issues/17293 -- when I updated my software and the console was gone

→ BUG 17293: console configuration is ignored on some systems (New)

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.

gone how? your console to serial redirection was not configured to 9600?

Setting aside the passive aggressiveness

I had configured it in /boot/conf.d/console and when I rebooted it was trying to use a different device

cut your crap, can you answer even single question without insults?

What exactly do you think your constant stream of snark and negativity is?

oof, that sounds like a tough one. Didn't mean to set anyone off heheh.

iprog4u: You have done nothing wrong!

Oh good. Figured you two were just having some work fun but I am quite new here and didn't want to assume.

so, what was in config and what was actually used?

I don't recall right now, I'm going to have to dig up my notes and figure out what machine it was.

In the meantime I am adding a tracing facility to the environment store so that I can debug it

log.omnios.org/illumos/2024-02-24#1708832291-745890 was one of the machines

was it uefi or bios boot?

I expect probably BIOS

yes, its bios boot, it has the bug about 'N'

Right. It also has the bug that it ignored what was in the file

that is debatable, but its not important right now on this machine. The better question is, where from it got "9600,8,n,1,-"

It's definitely not debatable. I specified what I wanted, and that used to work, and on new bits it stopped working

you did not read my comment, right?

Which one

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.

so the immediate question would be, where from 9600 is appearing.

conf.d files are processed almost at the end, after bootenv.rc, defaults/loader.conf and loader.conf

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

ttya-spcr-mode was set already and ignored my instructions

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

both ttyX-mode and ttyX-spcr.mode have 'N' issue, fixed in code.illumos.org/c/illumos-gate/+/3…sr/src/boot/i386/libi386/biosacpi.c

→ CODE REVIEW 3327: 16330 loader: SPCR needs better handling (NEW) | illumos.org/issues/16330

As in, they don't understand the uppercase "N" ?

oh, as in, we set them both in the SPCR code with the uppercase N

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.

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.

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.

and bhyve is not only one doing so.

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

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:(

sadly, even with uefi, it seems sometimes more like a suggestion than a standard... for legacy bios it's probably even worse...

like the uefi standard has the (unfortunately named) concept of SysPrep applications

where like your boot order, you can define UEFI applications to run prior to running the boot application to prepare the system

supermicro's bios say they support them, but they don't actually

they also do some non-standard stuff with the bootorder

that sounds so much fun

buckets full

How come ${X_GATE}/usr/src/cmd/zoneadmd/mcap.c is present in illumos-gate but not illumos-joyent nor illumos-omnios?

I do not see it in illumos-gate

are you sure its not leftover from somewhere else?

Apparently so... I don't see it in the fresh gate either

git whatchanged did not list it either

I am looking through old commits and maybe I mistakenly copied something

It was removed in OmniOS in commit 3f77773bdad3d0bfbd6cd39cf45434a46b6369d5 which looks like it came over from SmartOS

Which means it was probably introduced to OmniOS in the same way

jbk have you worked with libzpool in user space? I get 630 threads from it and it makes gdb to crawl:(

yes, it looks like it was never in illumos

Jerry added it, Jerry removed it

added with OS-11 removed with OS-6355

@andyf Was there a replacement elsewhere for the functionality of mcap.c?

fenix: OS-6355

OS-6355: in-kernel zone page invalidation (Resolved)

↳ smartos.org/bugview/OS-6355 | joyent/illumos-joyent 99e0ea6

which points to joyent rfd 38, which I don't know how to look at

danmcd?

but it sounds like they did the same thing, better and more accurately.

@tsoome This is what I was looking for. Thanks for that

yw

tsoome: i have not

ok.

You can look at any of the RFDs in the aforementioned github repository, @richlowe .. Thanks @tsoome for beating me to the punch.

I have those moments between stepping gdb;)

I was trying to compile some cgo, ran into missing Ftm_gmtoff and Ftm_zone are undefined. Do we have these? gitlab.com/cznic/libc/-/blob/master…llumos_amd64.go?ref_type=heads#L190

Doesn't look like it :(

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

The "tzname" global seems to contain the names of the effective timezones as well

see also: illumos.org/man/3C/ctime