i mean, it just means your syscall layer is going to accrete decades of cruft

and why not have all of that in the kernel?

(if you've not read bryan's commentary on futex(2) in the lx implementation, it's pretty good)

my random coding atrocity of the day is in the zfs send dedup code (which openzfs deprecated and ripped out a few years back...)

take a look at cksummer() in usr/src/lib/libzfs/common/libzfs_sendrecv.c

it wants 20 to 40% of your physical memory, but it does the calculation with an int rather than a uint64, so if it decides it needs more than 2^30 buckets it overflows, and calloc() returns NULL and it just drives onward as if nothing has happened.

(it claims to only want 20% but there's an off-by-one error in high_order_bit())

who does the code think it is? a nic driver? :)

We have nfsv4 acl with zfs right?

yes

Nice, and that would work with the nfs server running in a zone?

yes, why not?:)

it should

Hi, I have some questions

First, is the contributing guide on the website still how development works?

Thanks tsoome and jbk

dnewhall: it should be -- there's been no major changes in the process for quite some time.

Is there a way to mount exFAT drives? Cursory look at the man pages doesn't seem to show anything. But is there a pkg for it?

i think there's a patent concern issue over it

MS at one point seemed to be threatening to be rather litigious over exFAT

Well, that's some crap: Looking it up, it looks like Linux is specifically allowed to implement the patents, but not anyone else. Though, FreeBSD has a FUSE implementation.

that status might have changed over the years, but by then there also might not have been a huge need for it either...

since it was originally introduced in 2006, the patent may be expired already or expiring soon

true..

If, hypothetically, I were to look into implementing this, should it go into the pcfs stuff with FAT16/32, or a new mount_exfat, etc.?

if you believe what people post on hackernews, it should expire in 2027

i think IBM's ARC patent has also expired..

so it could be used in places other than ZFS now

dnewhall the implementation depends on factors like code reuse and user experience (least surprise principle).

[illumos-gate] 18009 gptzfsboot: boot prompt should emit new line on input -- Toomas Soome <tsoome⊙mc>

Here's a much more technical question, how is killall(1) even able to work?

Looking at the code, if I login to console 1 and then console 2, and run killall from console 1, due to the loop I'd expect it to just kill the process on console 1 but leave everything still running on console 2.

Is this broken, or am I just dumb?

(SysV did this all as one syscall, IIRC)

you may want to read killall(8). there is no killall(1).

Typo from another time. killall was in section 1M in HP-UX and SCO.

here it was changed with man section update;)

killall was never really intended to be run by users in their terminal session, but as part of the system shutdown init.d scripts, and now by SMF

so yeah, it's probably broken in the scenario described

and then linux made killall to kill only some processes...

(actually I have no idea if that behavior is from linux or something else)

the original SVR4 killall used setprocset()/sigsendset() to send all the signals in a single system call

I think IRIX was the first to have killall basically be what we use pkill for and then GNU (and the BSDs?) also implemented some of extra features along those lines

[illumos-gate] 18002 libdtrace: null pointer dereference -- Toomas Soome <tsoome⊙mc>

Linux killall works somewhat like pkill or like kill but with names rather than numbers

linux systems commonly call an illumos-like killall killall5