twobitsahead: G'day!

How's it going?

It's been a busy day!

Really?

Yes indeed haha

We're doing a software release at work

i figured this week is probably not a great one to bug you about the pbchk changes :P

iximeow: From what I have seen, which is not much, they seem on the right track, but yeah, I'll circle back haha sorry

i'll just remember to not pbchk the wrong thing, np

I am interested in ways in which I might be able to contribute to illumos. Is there anything that might exist which is somewhat beginner friendly?

twobitsahead: I think the best way to contribute is to find something that you're personally motivated to fix!

That is: a bug you're hitting personally, or a missing feature you need for something, or driver for hardware that you have available to work on and test with

Noted, thank you

I have a small list of features which I noticed could possibly be useful. If memory serves me right, one was the '-r' flag for 'pkg list'. I recall that 'pkg search' had that flag but not 'pkg list'. I'll have to check my notes to confirm that this was really it

Admittedly, I have spent more time in the books than at the keyboard. If I run into uncharted territory and can't find the way out alone, would this place be the right one to ask for a bit of advice?

twobitsahead: Sure, you can always ask questions here

We'll do our best to answer them or to redirect you elsewhere!

For pkg, FWIW, that comes from a separate repository from the illumos base. It's here: github.com/omniosorg/pkg5

I added a flag there myself recently: omniosorg/pkg5 #504

hrm.. just by any chance does anyone have a disk (virtural or physical) w/ a GPT label that was created on linux, but could run prtvtoc against it?

or has tried to access it from illumos?

it looks like parted (among other things) will create an empty array of 128 partition entries

i'm just curious how illumos would handle that (p0-127? or will it ignore the trailing empty partitions)

I can't recall ever seeing a p100+ haha

But I have definitely noticed weird/unusual looking layouts in prtvtoc before

i'm thinking it does... but i hate assuming.. I can probably construct something

I just cannot remember the specifics

just figured if someone had something they could easily run prtvtoc against

that's a lot faster

I looked at the pkg man pages for Omni and OpenIndiana. It looks like Omni already has the -r flag for pkg list, and the man pages show that it doesn't search the remote repository

It looks like the OI pkg doesn't include an -r flag for pkg list

I looked through any mention of 'pkg list' through the files in the parent and subdirectories and didn't find where 'pkg list' is defined

Many mentions of it and the interface in Python, but not the piece I am looking for

Any ideas where it might be?

^just to clarify, I am looking through the pkg5 repo from OpenIndiana

for my tar change, gordon suggested using I_PEEK instead of a 'peeker' thread.. testing seems to work against a fifo (from a simple test)... what I'm trying to think of is if there is a scenario (at least one plausible) where tar would be reading from something other than a regular file or a fifo (i.e. stdin is a pipe)

since if there isn't any, that would make I_PEEK an option

stdin can be any kind of fd that the person who calls fork/exec wants it to be.

While sure an event port isn't the case, certainly a character device or socket doesn't feel out of the question, even if a door isn't very realistic.

yes, but auto-detecting compression format when input on stdin is already broken, the question is would using I_PEEK instead of a thread that basically buffers the first few bytes to check be enough of an improvment to prefer scrapping the thread approach

and so is getting tar's stdin on something where I_PEEK doesn't work (which would be the status quo) a scenario that would be common enough

(at the same time, I really don't know when I'd have the time to go back and rewrite everything just because one advocate wants a specific approach)

but it'd at least be good to make sure the tradoffs between the two are known..

Well, that's more context than I had when you asked as I don't know your tar change really.

so the other scenarios are likely enough that not fixing them is a problem would favor what's there

+if

but if not, then maybe going the other way is better...

i suspect most use where a file isn't specified is via a pipe to stdin, but then, i've been surprised before :)

128 partitions can be seen with illumos tools as well, but we normally truncate the list and only show first 9 (end with reserved partition number 8). 128 is coming from the fact that by specification, we are required to allocate space for that many entries in partition entry array (16k, or 128 * 128 bytes).

yeah, i have a situation where I actually want to increase that -- mostly to force the last usable LBA on a disk to a specific alignment in a way where tools aren't all 'hey! you've got unused space there, do you want me to use it?'

as at least some seem to dislike it if you just set the last usable lba value in the label to something that leaves a gap between it and the GPT entries in the backup label

I guess, thats why they did create this reserved partition.

the reserved partition is used on illumos to stash a copy of the disk id.. i think that's for disks where we have to generate an id

it's not used for anything else, and the fixed size won't really change the alignment

(granted i've had a few ideas for things that might be interesting to stash in that partition)

yep

Hello

Hello

hi

How's it going?

First, thank you all for Illumos! I feel like I have found some kind of secret treasure. That being said I tried out all of the Illumos-based distros on some new hardware and found out that it uses a newer Realtek 8125 driver. After testing the efforts of someone who patched the vendor's driver for FreeBSD I wonder how difficult it would be to port their efforts to the Illumos kernel. Is that even a reasonable approach or am I

getting in over my head?

iprog4u: I think it will take some work, but I believe anybody can do kernel work if they stick with it!

@jclulow I am by no means a C guru but have successfully integrated C apps into a Common Lisp app years ago. Hoping that it could be a "simple" matter of porting the success that person had with FBSD kernel over to Illumos kernel but initial searching looks like kernel dev is INVOLVED!

It definitely won't be a case of copying a C file into place, adjusting a couple of include paths, and then it works

But it also won't be like inventing a totally new thing

Right. Clearly not a copy pasta situation but it also looks like there is a possibility of preparing the info for some entry points and then letting the C driver junk provided by the vendor work with the hardware.

Where would one even begin? This? illumos.org/books/wdd/bookinfo.html#bookinfo ? The idea of this mini pc with 2x 2.5Gb NICs running an Illumos-based distro would open up some fun possibilities.

illumos.org/man/9E/mac is the overview for the current networking framework.

I don't think it's going to be just pointing things into the vendor driver per se.

Writing device drivers is useful background as well.

The challenge of no docs for the RTL8125 is definitely a factor that has slowed down support for it in the past.

Thank you for the direction. Figured it couldn't be super easy or else more would be doing it. Might be above my paygrade, I can parse C but not write idiomatic code. All I found was a leaked pdf for the 8125 and it definitely has a ton of info right down to electrical level.

Does it have the firmware docs?

Or really things like PCIe BAR layouts?

If you have specific questions, happy to answer them. I'm to blame for the mac manuals and can probably point you to some other references.

Oh nice! I would like to contribute somehow once I learn enough. Please forgive my massive ignorance here. Hehehe for example, how would I even determine firmware docs vs. PCIe BAR layouts?

There is AC and DC characteristics, Serial EEPROM Interface Timing, Differential Receiver Parameters, REFCLK Parameters. Tons of things I know nearly nothing about :)

Probably easier to work from something else.

Just to have a comparison point.

Like the drivers that worked for FBSD?

I meant easier to explain with a datasheet that has it.

intel.com/content/www/us/en/content…-ethernet-controller-datasheet.html is the 82599. You want things like section 7/8/9.

wow you weren't kidding that there's no docs here. that's unfortunate

I see. Yeah seems that there is not much of anything for this chip. So lame, I was looking forward to running Illumos-based goodness on this machine. Will have to settle for other hardware for now.

Thank you all for getting back to me and for your work on Illumos. I want to write a post about a lab-in-a-box on OmniOS or similar.

it does look like our rge driver supports some of the same models as the freebsd if_re driver (just that freebsd supports additional ones the illumos rge does not -- including the 8125)

which suggests there might be some common bits so it _might_ be a matter of just adding some 8125 specific bits

though at the same time, that could also be harder than just porting the driver..

github.com/alexdupre/rtl_bsd_drv/tree/v1.100 is the freebsd driver

jbk: btw. I just tried RTL8125 2.5Gbps recently which wasnt supported on OmniOS