Page MenuHomeFreeBSD

vt(4): allow up to _SIG_MAXSIG (128) for VT_SETMODE
AcceptedPublic

Authored by quentin.thebault_defenso.fr on Thu, Nov 6, 2:05 PM.
Tags
None
Referenced Files
F136409691: D53615.id165954.diff
Mon, Nov 17, 4:21 PM
Unknown Object (File)
Wed, Nov 12, 6:40 PM
Unknown Object (File)
Tue, Nov 11, 5:50 PM
Unknown Object (File)
Fri, Nov 7, 11:45 PM
Unknown Object (File)
Fri, Nov 7, 3:32 PM
Unknown Object (File)
Fri, Nov 7, 12:12 PM
Unknown Object (File)
Fri, Nov 7, 12:12 PM
Unknown Object (File)
Fri, Nov 7, 6:52 AM
Subscribers

Details

Summary

VT_SETMODE ioctl currently checks the provided signal numbers with its own
ISSIGVALID macro that uses NSIG (32) as a maximum, although the code that will
actually send the signal in sys/kern/kern_sig.c uses _SIG_VALID which allows up
to _SIG_MAXSIG (128).

This change aligns the vt code with the kernel internals and enables the use of
higher signal numbers so that applications are not limited to SIGUSR1 and
SIGUSR2 for vt release and acquire signals.

Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr>

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 68458
Build 65341: arc lint + arc unit

Event Timeline

kevans added a reviewer: ray.

I know ray@ pops in sometimes so we might give him (and Ed) a little time to object, but I also didn't really see a reason to impose this particular limit. I did wonder if it was just an oversight because NSIG on other platforms *does* usually cover all valid signals (as far as I've observed)

This revision is now accepted and ready to land.Thu, Nov 6, 2:30 PM

This looks good to my eye as well. We're just using kern_psignal(), which doesn't care. If there's some reason to avoid them, it's going to be subtle enough we should document the why.