the bad thing is, we actually do have not one but two whole disk device nodes, GPT label will add second one (minor 'u'). IMO it would be nice to have just one (minor 'u'), and p0 as symlink for transition time (deprecated).

I agree it would be good to have a separate explicit "whole disk" public link that works regardless of which label (or if no label) is present etc

I suspect we could do a better job at documenting this, too; e.g., there are notes in disks(8) which is a deprecated program

Also, TIL devinfo(8), what even is this!

I did remember wrong, its not 'u' conflicting minort node, the actual problem is that for GPT, we do create minor node with name "wd", but its numeric value is 7 and it is conflicting with VTOC node 'h'.

Right

There's obviously a lot of history here

The bare device name, e.g., c0t0d0, points to the "wd" minor, I believe. Is that still true VTOC labels?

it is not, with VTOC world, there is no node c0t0d0

Ah

I guess we could fix that by just creating one then haha

on sparc, there has been only s2 to access whole disk, and on x86, the p0

Right.

And on x86 s2 would get you access to the whole SOLARIS2 partition I guess

yes

errm. actually because on transition from EFI to VTOC and VTOC to EFI, we do remove and create minor devices as needed, we could just re-create "wd" node with other numeric value for minor. But of course, thats not really nice and it would be better to have one value.

I don't think the numeric value is particularly important

actually it is, because we have #define WD_NODE 7 and it is used to index cl_map array like there: src.illumos.org/source/xref/illumos…b.c?r=bbf21555&mo=19489&fi=685#1149

so it is software and can be reworked, but still something to keep in mind

Yes I understand that the driver uses it internally, I just mean outside the driver it's more important that there be a consistently named minor available etc

I have filed: 17043 disk device nodes and label types could be documented in disks(7)

This has come up a lot in the last couple of years so it's probably time to write it down

Is the ARM stuff just 100% GPT?

probably -- AFAIK it all uses UEFI for better or worse, which would mean GPT

GPT is probably the most acceptable part of UEFI so that seems fine haha

there are other parts that aren't _too_ bad, but the windows-centric bits are quite annoying (e.g. UCS2 strings)

It as after all MS-DOS 2097!

*It is

jclulow: we support non-gpt, because of some booting quirks

jclulow: (and because that's all common code, I guess)

I just remember that andyf made it optional what we use on the images because of something or other (hadfl's rpi rev?)

something weird didn't work

yeah my old rpi4 didn't boot other than MBR. but a firmware update fixed it. so not relying on MBR anymore

well, we have seen system boot implemented as read N blocks from fixed location (N from [1-16]), now we see read file from file system, and to be honest, file system is much more better option. Even if its FAT.

richlowe: Interesting!

also: writing CamelCase C just feels wrong :P

(other UEFI quirks)

:D

It's not great!

one can always just use linuxboot;)

[illumos-gate] 17031 ddi_intr_add_handler(9f): several issues -- Yuri Pankov <yuri⊙ao>

@yuripv ^^^

[illumos-gate] 17012 ZTS: add new_fs -- Toomas Soome <tsoome⊙mc>

BootLayer [~BootLayer@user/BootLayer] has quit [Quit: Leaving]

uhhh, unintentionally copypasted part of my irssi buffer? sorry about that

I thought it was a joke about us complaining about UEFI and then "BootLayer" quitting, tbh

[illumos-gate] 16835 mkfs_pcfs: allow sector sizes other than 512B -- Toomas Soome <tsoome⊙mc>

That's usually how I hedge my bets when mine don't land

"oh, yeah, I was just trying to quit vi ha ha"

for 4kn, code.illumos.org/c/illumos-gate/+/3738 is left for OS itself.

→ CODE REVIEW 3738: 16837 libzfs: pool start needs to be properly aligned with zpool_label_disk() (NEW) | illumos.org/issues/16837