hello all the OS/kernel developer, do you advice DISM on illumos related fork? (on x86_64 platform), I read some document that do not advice enable DISM for x86 platform, is it safe?

the postgres had DISM enable on omnios’s package

Hey all. any idea where I can find the EBNF of DTrace?

eBNF on Linux and DTrace on Illumos/Solaris, FreeBSD and macOS

DTrace is also available on Linux afaik but not much used

I think they mean the extended backus-naur form for the DTrace language, not eBPF

ah yes reading what I wanted to see not what was written

in that case no idea

as for the question I don't know the answer, but I'd look in the dtrace directories in illumos-gate for any .y files that you could convert to BNF

src.illumos.org/source/xref/illumos…race/common/dt_grammar.y?r=8019f4e7 might be what you're looking for

Hi, all. I think, I find a bug on Illumos about pseudo-tty, it will convert tab character to spaces.

See: postgresql.org/message-id/MEYP282MB…P282MB1669.AUSP282.PROD.OUTLOOK.COM

There are two illumos build farm members, hake and pollock, which are showing green for regression tests at buildfarm.postgresql.org/cgi-bin/sh…=pollock&member=hake&member=haddock - I wonder if the build flags are a bit different, or if that test is somehow excluded in the build farm (that would be a surprise, but I haven't checked)

The reproducer defines _XOPEN_SOURCE=600 but nothing else, which means it gets strict XPG4v2 behaviour

There's illumos.org/issues/12306 in which we prevent people stumbling into this by accident

→ BUG 12306: XPG4v2 slave pty behaviour should generally be disabled (Closed)

Quick fix is to define __EXTENSIONS__ too

at some point, we should just make that the default... i would be shocked if our defaults have prevented more problems than they've caused at this point

alanc, thanks for your input earlier - here's the signals diff for coreutils in case you want to have a look: github.com/uutils/coreutils/compare…er:coreutils:illumos_sunos?expand=1

also a few other changes needed to get the coreutils project to build

welcome a review from others as well of course should anyone want to have a peak - i'll probably post a PR to the coreutils project later this evening

danmcd: we've been wanting to merge libsocket and libnsl into libc for years, both yurip and i have done different takes on it. There are symbol collisions and points of confusion.

I think what we each ended up doing was leaving problematic bits behind, but it didn't feel entirely complete (at least mine didn't)

we'd talked about a short term (already scary, it never is) solution of filtering the important symbols onto them out of libc, as things stand now

that is accept(3SOCKET) (or 3XNET) stays where it is, but libc gains a filter so it appears in libc also

obviously this all really requires the socket/xnet thing done first, or careful checks that 3xnet can still interpose fully and correctly

if I recall, nsl has less compat things to think about, but more direct symbol collisions

danmcd: with your understanding of our networking history, you'd be ideal to fix these things...

the best I can do is tell you about the link editor, and the makefiles involved.

Yeah... I know it's scary. It's why I haven't done it ever. Also, I'm trying to get back neck-deep into mlxcx.

The big thing that motivates me on this front is sendmsg() and recvmsg() which is VASTLY different between pre-xnet and xnet.

(Something about old SunOS 4 apps was why we never ripped off the band-aid.)

the xnet v. socket thing is most unfortunate because you can't build test that

unlike pulling libnsl or the old libsocket into libc

(though not all of libsocket into libc, because you have to check it doesn't break xnet...)

libnsl into libc should at least be smooth, if you pick the interfaces to come along and filter only those back out of libnsl, or filter them from libc onto libnsl (either way is an architectural mess, but it has to happen one way or the other)

In my perfect world I'd burn pre-xnet to the ground. I can see jperkin and others grinding their teeth over the sheer amount of recompilation (and `configure` testing) that'd need to get fixed, however.

jperkin is wonderful for recompilation testing, and has done so much for me and others, and deserves much more credit

the challenge is that it changes _behaviour_, we know things build, but will they work?

sorry, I'm getting the iconv cleanup ready for RTI and actually writing my research into the bug, or trying to

I kinda wish someone could confirm it for me, just because it seems so haphazard

"We need a mapping from one byte to another" ... "You know what does that? Keyboard maps!"

Ah, dos2unix!

I suppose the ARM port has to figure out if they want to change the man page to stop saying "non-i386" or change the behavior to use something more sane like $LC_CTYPE

also, "This command can be invoked from either DOS or SunOS." seems like a leftover from the old suni386 Merge environment

there is so much manual page work that will be necessary

so much