Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Mon, Apr 12, 2021 at 05:16:37AM -, Michael van Elst wrote: > >options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads > > It's a compile-time option for the pms driver to include code that > handles Synaptics Touchpads. So I can assume synaptics support is compiled in. So why doesn't sysctl -a show the synaptics options mentioned in man pms? Is there any alternative way to cross check whether option is compiled into the running kernel? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
mayur...@acm.org (Mayuresh) writes:
>On Sun, Apr 11, 2021 at 08:15:03PM +0200, Martin Husemann wrote:
>> grep '^pms' /var/run/dmesg.boot
>pms0 at pckbc2 (aux slot)
>wsmouse0 at pms0 mux 0
>But the following line in the kernel config is enabled. How is it supposed
>to play a role? The name Synaptics comes only on 'options' line and not
>like a device line (e.g. like 'wsmouse*at pms? mux 0').
>options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads
It's a compile-time option for the pms driver to include code that
handles Synaptics Touchpads.
There is:
defflag opt_pms.h PMS_SYNAPTICS_TOUCHPAD
defflag opt_pms.h PMS_ELANTECH_TOUCHPAD
defflag opt_pms.h PMS_ALPS_TOUCHPAD
and
filedev/pckbport/synaptics.cpms & pms_synaptics_touchpad
filedev/pckbport/elantech.c pms & pms_elantech_touchpad
filedev/pckbport/alps.c pms & pms_alps_touchpad
in the included files.pckbport config file. The upper case defflags
are used as lower case condition names to optionally include source
files.
opt_pms.h is created by the config program and includes definitions
for the flags that are enabled by the option statement. E.g.
#define PMS_SYNAPTICS_TOUCHPAD 1
#ifdef _LOCORE
.ifndef _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD
.global _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD
.equiv _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD,0x1
.endif
#else
__asm(" .ifndef _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD\n .global
_KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD\n .equiv
_KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD,0x1\n .endif");
#endif
C code can just use the macro PMS_SYNAPTICS_TOUCHPAD, assembler code
can evaluate the global symbol _KERNEL_OPT_PMS_SYNAPTICS_TOUCHPAD.
Re: OS-level virtualization
On Apr 11, 2021, at 2:51 AM, Thomas Mueller wrote: > > What is this, NetBSD's SCM system switching from CVS to Git? > > I thought NetBSD was setting up to switch from CVS to Mercurial. > > I am still curious when this planned switch is intended to take place, or if > they might ultimately decide in favor of git. I was not aware that this had moved beyond just a work-in-progress stage; has Core committed to this? Is there a timetable for this migration? If not, FWIW one possible suggestion might be for Core to consider announcing holding a public vote later this year, say on July 1, among all NetBSD developers with CVS commit rights, between migrating NetBSD’s SCM system to Mercurial versus migrating to Git. (That would give people time to do their own research into the relative merits and trade-offs between the two systems.) A public commitment by Core to back whatever consensus emerges from the majority of NetBSD committers as a result of such a vote, along with a tentative goal of completing such a migration by, say, New Year's 2022 to whichever SCM system the developers ultimately vote for, would not only go a long way to overcoming the energy of activation of moving forward with that migration, but also potentially motivate a lot of developers to contribute, knowing their efforts have the Project’s formal backing. > > FreeBSD switch from svn to git was a decidedly nontrivial matter, especially > for the ports tree, ports being FreeBSD's counterpart to NetBSD's pkgsrc. > > Tom > Looking through FreeBSD’s mailing lists during the time of their CVS → SVN migration and more recently their SVN → Git migration, all the lively debates about choice of VCS are clearly nothing new (which makes it all the more remarkable that in they end they somehow made it happen). If the FreeBSD Project could do it, not just once, but twice, I have no doubt that migrating to either Mercurial or Git could be made to work; which is why leaving it up to a vote and going with the majority consensus of NetBSD committers might be the best way to go. In any case, both Git and Mercurial would be a vast improvement over the status quo IMHO, if for no other reason than for the once-in-a-lifetime opportunity of finally being able to clean up so many things that have accumulated over a quarter century. Austin “We are responsible for actions performed in response to circumstances for which we are not responsible.” —Allan Massie, _A Question of Loyalties_, 1989
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 08:15:03PM +0200, Martin Husemann wrote: > grep '^pms' /var/run/dmesg.boot pms0 at pckbc2 (aux slot) wsmouse0 at pms0 mux 0 But the following line in the kernel config is enabled. How is it supposed to play a role? The name Synaptics comes only on 'options' line and not like a device line (e.g. like 'wsmouse*at pms? mux 0'). options PMS_SYNAPTICS_TOUCHPAD # Enable support for Synaptics Touchpads -- Mayuresh
NetBSD 9.1 VPS: Too many dhclient XMT: solicit messages
Such messages are appearing every 2 minutes 2s. Apr 11 23:32:35 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110920ms. Apr 11 23:34:27 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 115560ms. Apr 11 23:36:22 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 117380ms. Apr 11 23:38:20 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 119250ms. Apr 11 23:40:19 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 109500ms. Apr 11 23:42:09 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 124470ms. Apr 11 23:44:14 localhost dhclient[2032]: XMT: Solicit on vioif0, interval 110970ms. Anything to look out for? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, 11 Apr 2021 at 18:57, Mayuresh wrote: > > On Sun, Apr 11, 2021 at 11:18:48PM +0530, Mayuresh wrote: > > Or may be it has to be enabled. man pms shows this: > > > > options PMS_SYNAPTICS_TOUCHPAD > > > > May be compiling this in the kernel should be the first thing to try. > > I checked the GENERIC kernel configuration file and above line is already > uncommented there. So, shouldn't it have shown the snyaptics options in > sysctl -a (as per man pms)? What am I missing? > Well, it is not Synaptics. On my other NetBSD laptop - an Hewlett-Packard HP EliteBook 8570w - I also do not have any mentioning of Synaptics from sysctl hw, although the machine certainly has one. Unfortunately I can't even try any windowing system on it, as the FirePro graphics adapter it has has a hardware problem and any attempt to initialize it results in a hard reset. > -- > Mayuresh --
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:27:15PM +0530, Mayuresh wrote: > I checked the GENERIC kernel configuration file and above line is already > uncommented there. So, shouldn't it have shown the snyaptics options in > sysctl -a (as per man pms)? What am I missing? If grep '^pms' /var/run/dmesg.boot does not show anything mentioning "Synaptics touchpad" the device was not recognized as one. Martin
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:18:48PM +0530, Mayuresh wrote: > Or may be it has to be enabled. man pms shows this: > > options PMS_SYNAPTICS_TOUCHPAD > > May be compiling this in the kernel should be the first thing to try. I checked the GENERIC kernel configuration file and above line is already uncommented there. So, shouldn't it have shown the snyaptics options in sysctl -a (as per man pms)? What am I missing? -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:05:53PM +0530, Mayuresh wrote: > BTW on NetBSD 9.1 Synaptics properties don't seem to be present > # sysctl -a | grep -i syna > # Or may be it has to be enabled. man pms shows this: options PMS_SYNAPTICS_TOUCHPAD May be compiling this in the kernel should be the first thing to try. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 11:05:53PM +0530, Mayuresh wrote: > Thanks. Based on the following I do not know how to decide whether it is > Synaptics. > > $ grep Touch /var/log/Xorg.0.log > [ 899.721] (II) Using input driver 'libinput' for 'FocalTechPS/2 FocalTech > Touchpad' It seems to be using libinput on Linux. I don't find anything equivalent of that - neither in base nor in pkg - on NetBSD; except that there is one wip/libinput - not sure about its state. Its PLIST is not having libinput_drv.so. -- Mayuresh
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sun, Apr 11, 2021 at 04:41:37PM +0100, Chavdar Ivanov wrote: > And still --- in -current at least, if the trackpad is a Synaptics, I have Thanks. Based on the following I do not know how to decide whether it is Synaptics. This [1] old thread shows, on Linux it was recognized as Synaptics on the same hardware back then. Today on a recent Linux it does not show so: $ grep Touch /var/log/Xorg.0.log [ 899.721] (II) config/udev: Adding input device FocalTechPS/2 FocalTech Touchpad (/dev/input/event5) [ 899.721] (**) FocalTechPS/2 FocalTech Touchpad: Applying InputClass "libinput touchpad catchall" [ 899.721] (II) Using input driver 'libinput' for 'FocalTechPS/2 FocalTech Touchpad' [ 899.721] (**) FocalTechPS/2 FocalTech Touchpad: always reports core events [ 899.725] (II) event5 - FocalTechPS/2 FocalTech Touchpad: is tagged by udev as: Touchpad [ 899.726] (II) event5 - FocalTechPS/2 FocalTech Touchpad: no resolution or size hints, assuming a size of 69x50mm [ 899.728] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device is a touchpad [ 899.728] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device removed [ 899.761] (II) XINPUT: Adding extended input device "FocalTechPS/2 FocalTech Touchpad" (type: TOUCHPAD, id 14) [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) selected scheme none/0 [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) acceleration factor: 2.000 [ 899.768] (**) FocalTechPS/2 FocalTech Touchpad: (accel) acceleration threshold: 4 [ 899.772] (II) event5 - FocalTechPS/2 FocalTech Touchpad: is tagged by udev as: Touchpad [ 899.773] (II) event5 - FocalTechPS/2 FocalTech Touchpad: no resolution or size hints, assuming a size of 69x50mm [ 899.776] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device is a touchpad [ 899.778] (II) config/udev: Adding input device FocalTechPS/2 FocalTech Touchpad (/dev/input/mouse0) [ 918.079] (II) event5 - FocalTechPS/2 FocalTech Touchpad: device removed BTW on NetBSD 9.1 Synaptics properties don't seem to be present # sysctl -a | grep -i syna # [1] https://mail-index.netbsd.org/netbsd-users/2017/06/16/msg019731.html -- Mayuresh
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sat, 10 Apr 2021, Rhialto wrote: > I have a laptop of about 10 years old with an Intel "GM45"(?) chipset > (or i965 is mentioned in some places). I have a G41 chipset in my primary workstation machine and I see frequent references to i965 for dri-related things (and that the i965 vdpau module is not present in NetBSD's Xorg/OpenGL--as noted by mplayer, mpv, vlc, etc.). > It worked fine up to NetBSD 8.x. But now on 9.1, if I run x64 (from > package emulators/vice) on it for a while I get errors in my xterm > "i965: Failed to submit batchbuffer: Input/output error", > and the kernel crashes sometimes a short time later. I've seen/experienced these as well, mostly when trying to play videos through firefox (firefox52, actually). IIRC, the workaround has been to set "LIBGL_ALWAYS_INDIRECT=1". I do it in a wrapper script for firefox, but if other things trigger it, perhaps it should be set/exported in .xsession (or other display-manager session configuration/startup file). > The config file is mostly the auto-detected stuff, enhanced with some > preferences from my previous xorg.conf file. For some reason, 2 cards > were detected, Card0 and Card1 and I just copied that, just in case it > is important. > > 000:02:0: Intel 82GM45 Integrated Graphics Device (VGA display, revision > 0x07) [i915drmkms0] > 000:02:1: Intel 82GM45 Integrated Graphics Device (miscellaneous display, > revision 0x07) Function 0, according to the device ID reported in your Xorg.0.log and matched in "i915pciids.h" is a GM45_G. You said it's a laptop, so I suppose it's the "Mobile" variant of the G45. Function 1 is not listed. I wonder what "miscellaneous display" means? Before the gen 3/4/5 chips were defaulted to UXA, the only xorg.conf I needed was to set AccelMethod UXA. Since the default to UXA, the auto-detection works properly and I don't need xorg.conf anymore. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: NetBSD 9.1 amd64, base X11: garbled display
On Sun 11 Apr 2021 at 08:07:20 -0500, John D. Baker wrote: > I've seen/experienced these as well, mostly when trying to play videos > through firefox (firefox52, actually). IIRC, the workaround has been > to set "LIBGL_ALWAYS_INDIRECT=1". I do it in a wrapper script for > firefox, but if other things trigger it, perhaps it should be set/exported > in .xsession (or other display-manager session configuration/startup file). I tried setting this and it certainly has some effect but not yet the one I hoped for :) All programs I tried didn't like it: most terminate with some error. mpv runs, but simply doesn't paint its window. LIBGL_ALWAYS_INDIRECT certainly has interesting effects :) Grepping for this string I found /usr/xsrc/external/mit/MesaLib/dist/docs/envvars.html which gave me some other things to try. I could get extensive debugging output for example with INTEL_DEBUG=all. But that was unfortunately so much detail that it didn't mean much to me. I did find a more interesting part of the kernel messages though (related to the original problem I'd say). I'm including them for the record, in case it means anything to somebody who could fix it. Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] kern info: [drm] stuck on render ring Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] kern info: [drm] GPU HANG: ecode 4:0:0x86fefffc, reason: Ring hung, action: reset Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c:3196)i915_context_is_banned] *ERROR* gpu hanging too fast, banning! Apr 11 18:43:26 vargaz /netbsd: [ 362.4169375] drm/i915: Resetting chip after gpu hang Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] kern error: [drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/i915_irq.c:2703)i915_handle_error] *ERROR* Error state: Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] GPU HANG: ecode 4:0:0x86fd, reason: Ring hung, action: reset Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Time: 1618159400 s 39278 us Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Kernel: 90100 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Reset count: 0 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Suspend count: 0 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] PCI ID: 0x2a42 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IOMMU enabled?: -1 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] EIR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IER: 0x02028053 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] PGTBL_ER: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] FORCEWAKE: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] DERRMR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] CCID: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] Missed interrupts: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[0] = bc205c50cd Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[1] = bd70bd400d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[2] = bdb0bd800d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[3] = ef60c7704d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[4] = f3e0f2301d Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[5] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[6] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[7] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[8] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[9] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[10] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[11] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[12] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[13] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[14] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] fence[15] = Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_0: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_1: 0xbfdc Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_2: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE_3: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] render command stream: Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] START: 0x3000 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] HEAD: 0x00014ef8 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] TAIL: 0x00014f60 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] CTL: 0x0001f001 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] HWS: 0x1000 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] ACTHD: 0x 1f2632b4 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IPEIR: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] IPEHR: 0x7902 Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] INSTDONE: 0x Apr 11 18:43:26 vargaz /netbsd: [ 362.4269447] BBADDR: 0x
Re: NetBSD 9.1 amd64 base X11: hypersensitive touchpad
On Sat, 10 Apr 2021 at 11:22, Chavdar Ivanov wrote: > > On Sat, 10 Apr 2021 at 10:51, Mayuresh wrote: > > > > Seems an old issue [1][2] where the touchpad gestures happen inadvertently > > while typing on keyboard with slightest of touch. > > > > Is there any solution in sight, such as even by conceding some > > functionality? Tried the settings suggested in [1], that did not solve it. > > > > [1] https://mail-index.netbsd.org/netbsd-users/2018/05/07/msg020740.html > > [2] https://mail-index.netbsd.org/netbsd-users/2017/06/12/msg019686.html > > Running -current, usually. I used to always attach a USB mouse when I > was booting NetBSD on my laptop; recently - say, the last two months - > this seems no longer needed; although the trackpad is still a bit > oversensitive, I am able to use it reasonably well. > > Still, with the mouse is better I think... And still --- in -current at least, if the trackpad is a Synaptics, I have hw.synaptics.up_down_emulation = 3 hw.synaptics.up_down_motion_delta = 1 hw.synaptics.gesture_move = 200 hw.synaptics.gesture_length = 20 hw.synaptics.edge_left = 1632 hw.synaptics.edge_right = 5312 hw.synaptics.edge_top = 4288 hw.synaptics.edge_bottom = 1568 hw.synaptics.edge_motion_delta = 32 hw.synaptics.finger_high = 35 hw.synaptics.finger_low = 20 hw.synaptics.two_fingers_emulation = 0 hw.synaptics.scale_x = 4 hw.synaptics.scale_y = 4 hw.synaptics.scale_z = 32 hw.synaptics.max_speed_x = 32 hw.synaptics.max_speed_y = 32 hw.synaptics.max_speed_z = 2 hw.synaptics.movement_threshold = 4 hw.synaptics.movement_enable = 1 hw.synaptics.button_boundary = 2288 hw.synaptics.button2_edge = 2858 hw.synaptics.button3_edge = 4085 hw.synaptics.finger_scroll-min = 13 hw.synaptics.finger_scroll-max = 14 hw.synaptics.finger_scroll-hysteresis = 30 hw.synaptics.aux_mid_button_scroll = 1 (sysctl sh.synaptics) So you have a great many knobs to play with. > > > > > -- > > Mayuresh > > > > -- > --
Re: OS-level virtualization
> Zooming out, in the grand scheme of things, as desirable as having a NetBSD > counterpart fo Illumos Zones or FreeBSD Jails would be, I realize this is > down the list of priorities behind migrating NetBSDâs SCM system from CVS > to Git being the first priority followed (IMHO) by getting root on ZFS integrated into _sysinst_. Both are things I would be interested in contributing to one day (but can never seem to force myself to make free time), though in the case of the former, while Iâm ok decent with Git, to be able to contribute anything useful Iâd obviously have to get more intimately familiar with CVS (but am really dreading sitting down to read up on CVS; Iâd even prefer Subversion or Mercurial over CVS). I feel like (though I donât have any evidence to back this up) perennially never attaining critical mass to migrate to Git is potentially turning off potential new users and developers to the project (particularly fresh young CS/CE talent coming out of schools and universities where Git is pretty much the standard SCM system taught todayâimagine if you came across a Web site about an OS you werenât previously familiar with but upon further reading found out it was still using SCCS or RCS as its VCS and how that might affect your perception of the project), but that is the topic of a completely different thread entirely. (Sorry I got off topic; recently came across some old articles about FreeBSDâs 2012â13 transition from CVS to SVN and more recently from SVN to Git and was just floored thinking about the technical heavy lift and engineering challenge that must have involved on the part of so many people and just awestruck how they in the end managed to pull it offâ¦) > Austin What is this, NetBSD's SCM system switching from CVS to Git? I thought NetBSD was setting up to switch from CVS to Mercurial. I am still curious when this planned switch is intended to take place, or if they might ultimately decide in favor of git. FreeBSD switch from svn to git was a decidedly nontrivial matter, especially for the ports tree, ports being FreeBSD's counterpart to NetBSD's pkgsrc. Tom
Re: OS-level virtualization
On Apr 8, 2021, at 12:12 PM, Rhialto wrote: > > On Tue 06 Apr 2021 at 20:01:15 -0400, Austin Kim wrote: >> On Apr 6, 2021, at 2:16 PM, Martin Husemann wrote: >>> Yes, but there are various KAUTH_REQ_PROCESS_CANSEE* that solve parts of >>> that problem. Some more may be missing. >>> >>> Martin >> >> Hmmm? Now I?m starting to wonder how much of the equivalent >> functionality you could achieve just through judicious use of >> chroot(2) and kauth(9) alone ? > > I had the same idea in the past, but haven't done anything concrete with > it. > > For faking separate PID 'namespaces', you could get away with just > hiding processes that you're now allowed to see. PIDs are random anyway > so you won't really notice. > > For other things, like UIDs, GIDs, etc it is a bit trickier because you > could get multiple 'namespaces' using the same value and you can't even > prevent it without causing weird failures. For those, you'd need some > mapping layer somewhere to translate between global values and > inside-the-namespace values. There is something like that for stacked > file systems (mount_umap) but that won't be enough. > > Maybe we can invent something cleverer than Linux. Syscall interception > layers as a file system perhaps? > > -Olaf. > -- > ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert > \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl Thanks for the insights; another issue might be the need to bind the sandboxed, OS-level-virtualized instances to specific IP addresses while disabling raw IP sockets. The more I think about it, the more exponentially complex this suddenly seems to become. I think for my use case (supporting multi-tenancy for unrelated clients who have no mutual trust relationships on physical racks), the combination of using ZFS + chroot(2) + kauth(9) where needed would suffice; but the idea of implementing a more general OS-level virtualization system on NetBSD is hella intriguing. Zooming out, in the grand scheme of things, as desirable as having a NetBSD counterpart fo Illumos Zones or FreeBSD Jails would be, I realize this is down the list of priorities behind migrating NetBSD’s SCM system from CVS to Git being the first priority followed (IMHO) by getting root on ZFS integrated into _sysinst_. Both are things I would be interested in contributing to one day (but can never seem to force myself to make free time), though in the case of the former, while I’m ok decent with Git, to be able to contribute anything useful I’d obviously have to get more intimately familiar with CVS (but am really dreading sitting down to read up on CVS; I’d even prefer Subversion or Mercurial over CVS). I feel like (though I don’t have any evidence to back this up) perennially never attaining critical mass to migrate to Git is potentially turning off potential new users and developers to the project (particularly fresh young CS/CE talent coming out of schools and universities where Git is pretty much the standard SCM system taught today—imagine if you came across a Web site about an OS you weren’t previously familiar with but upon further reading found out it was still using SCCS or RCS as its VCS and how that might affect your perception of the project), but that is the topic of a completely different thread entirely. (Sorry I got off topic; recently came across some old articles about FreeBSD’s 2012–13 transition from CVS to SVN and more recently from SVN to Git and was just floored thinking about the technical heavy lift and engineering challenge that must have involved on the part of so many people and just awestruck how they in the end managed to pull it off…) Austin “We are responsible for actions performed in response to circumstances for which we are not responsible.” —Allan Massie, _A Question of Loyalties_, 1989
