Seems better.
Toggling the behaviour while video occurs should be tested, to make
sure it matches expectations.
Marcus Glocker wrote:
> On Sat, Oct 24, 2020 at 11:34:07AM -0600, Theo de Raadt wrote:
>
> > Marcus Glocker wrote:
> >
> > > On Sun, Sep 27, 2020 at
Marcus Glocker wrote:
> On Sun, Sep 27, 2020 at 05:57:51PM +0100, Laurence Tratt wrote:
>
> > On Sun, Sep 13, 2020 at 09:23:36AM +0100, Laurence Tratt wrote:
> >
> > > Since I recently opened my big fat mouth and suggested that
> > > "kern.video.record" (analogous to kern.audio.record) might be
I believe most of the new local variables you added in main,
can instead be added in the flush loop you wrote, even if you
have to instantiate them. Or move it into a new function,
then it is even easier. their scope is just too large...
> @@ -240,6 +240,17 @@ void pr_retip6
Mark Kettenis wrote:
> > Date: Mon, 19 Oct 2020 16:36:14 +0200
> > From: Christian Weisgerber
> >
> > Belatedly, ARM has taken a slice of the reserved opcode space and
> > assigned it as a properly defined illegal instruction, udf #imm16.
> > (Armv8 Architecture Reference Manual, edition F.c, s
Thanks for finding a better instruction!
ok deraadt
Christian Weisgerber wrote:
> Belatedly, ARM has taken a slice of the reserved opcode space and
> assigned it as a properly defined illegal instruction, udf #imm16.
> (Armv8 Architecture Reference Manual, edition F.c, section C6.2.335).
> Clan
Mark Kettenis wrote:
> > /* For user defined stacks (from sendsig). */
> > if (sp < (vaddr_t)vm->vm_maxsaddr)
> > - return;
> > + goto out;
>
> Since vm_maxsaddr is ummutable, this check can be done without holding
> the lock. I think that's worth it as it will preve
> I think this is good to go. ok kettenis@
>
> Did briefly discuss with Theo during k2k20 and the consensus was it
> should go in after relase. Which is now!
Agree.
Klemens Nanni wrote:
> The diff does not change behaviour or output for end-users on the
> command line; instead it changes syslog messages which by default are
> only readable by root.
^
That's the key detail for me, as it means no additional information
is being exposed
OK deraadt
Gerhard Roth wrote:
> The current definition of SIOCG80211JOIN uses 256 for the command,
> but the _IOC() macro only allows 8 bit for the command value.
> Using 256 would set the lowermost bit of the ioctl group.
> Fortunately, 'i' (0x69) already has the lowermost bit set. Otherwise
> For shits and giggles I deceided to look into pthread_spin_unlock and
> saw that we return EPERM here, while POSIX states that this behaviour
> is unconditionally undefined.[0] Is there a reason why we shouldn't
> abort here as well?
Undefined doesn't mean it can turn into a bowl of petunias.
A
This lacks diffs for MAKEDEV and other files. We need to see
those.
Patrick Wildt wrote:
> On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote:
> > + if (strcmp(ia->ia_name, "st,m41t83") == 0)
> >
> > fine with me. But in that case, why not call the driver i2c/m41t83.c
>
> Because it's a series of
+ if (strcmp(ia->ia_name, "st,m41t83") == 0)
fine with me. But in that case, why not call the driver i2c/m41t83.c
Duncan Roe wrote:
> > I disagree with your plan. This kind of "force it off" programming is
> > typical.
> >
> Might be typical, but I think it's sloppy.
I don't think it is sloppy.
Instead, I think your additional logic complicates review.
Duncan Roe wrote:
> On Sun, Sep 27, 2020 at 02:18:21PM -0600, Bob Beck wrote:
> > On Sun, Sep 27, 2020 at 02:46:39PM +1000, Duncan Roe wrote:
> > > The motivation for this is to make debug logs less confusing.
> >
> > What is this fixing and what behavior are you changing?
>
> You can only see t
David Riley wrote:
> On Sep 25, 2020, at 3:13 PM, Todd C. Miller wrote:
> >
> > On Fri, 25 Sep 2020 13:58:01 -0500, Scott Cheloha wrote:
> >
> >> `found' serves as a boolean here. I'd prefer to simple and set it to
> >> 1 instead of incrementing it when we find what we're looking for.
> >
>
We can't have 2 billion processes to reach a wrap.
But I agree, it seems quite wrong, and seems better to just observe
match rather than count.
Scott Cheloha wrote:
> `found' serves as a boolean here. I'd prefer to simple and set it to
> 1 instead of incrementing it when we find what we're lo
Mark Kettenis wrote:
> And as I implied, KASSERTs are no-ops in RAMDISK kernels so they don't
> stop things going horribly of the rails in that context, whereas a
> panic would still happen.
That's an important point, with big consequences.
Compile a RAMDISK, and the KASSERT gets removed. Also
Scott Cheloha wrote:
> Is there any scenario where
>
> if (condition)
> panic();
>
> is preferable to
>
> KASSERT(condition);
>
> outside of function calls with side effects?
Definately, sometimes you want to use simple english language for the
failure conditi
>> From: Theo de Raadt
>> Date: Thu, 24 Sep 2020 15:27:06 -0600 (MDT)
>>
>> >The call is missing from the trap handler, probably because I was
>> >looking at arm64 where it is missing as well. The result is that the
>> >stack size accounting will be
>The call is missing from the trap handler, probably because I was
>looking at arm64 where it is missing as well. The result is that the
>stack size accounting will be wrong.
Nice find.
>In the diff below I only added the call to the "data" trap. That
>means that an "instruction" trap will not
Mark Kettenis wrote:
> > Date: Thu, 24 Sep 2020 11:53:59 +0200
> > From: Martin Pieuchot
> >
> > Convert various "if (x) panic()" idioms into "KASSERT(!x)". The panic
> > message isn't helping for such sanity checks and this help reducing the
> > diff with NetBSD.
> >
> > ok?
>
> Yes, the KA
Theo de Raadt wrote:
> kettenis, mortimer, and I have had long discussions about the
> uvm_map_inentry() checks in MD trap.c being excessively broad. We can
> this check-function less often.
>
> I don't want to explain the full picture about how SP and PC checks
>
Theo de Raadt wrote:
> Theo de Raadt wrote:
>
> > kettenis, mortimer, and I have had long discussions about the
> > uvm_map_inentry() checks in MD trap.c being excessively broad. We can
> > this check-function less often.
> >
> > I don't want to exp
Theo de Raadt wrote:
> kettenis, mortimer, and I have had long discussions about the
> uvm_map_inentry() checks in MD trap.c being excessively broad. We can
> this check-function less often.
>
> I don't want to explain the full picture about how SP and PC checks
>
kettenis, mortimer, and I have had long discussions about the
uvm_map_inentry() checks in MD trap.c being excessively broad. We can
this check-function less often.
I don't want to explain the full picture about how SP and PC checks
in syscall() and trap() hinder ROP, ROP stack pivoting, gadgets w
It also lacks SENSOR_UNUSEDFEATURES.
No.
Paul de Weerd wrote:
> Hi all,
>
> While browsing sensorsd.c for inspiration for a small project I'm
> working on, I noticed that both src/usr.sbin/sensorsd/sensorsd.c and
> src/sbin/sysctl/sysctl.c have a 'print_sensor' function that
> returns/prints t
Something doesn't feel right.
db_kill_cmd finds a process, called p, then kills it. In your new diff
calling sigexit, take note of the comment at the top:
* Force the current process to exit with the specified signal, dumping core
current process? Doesn't look like it, it looks like it kills
Two days ago during my work on ongoing work for non-acpi suspend,
kettenis and I observed the same thing.
your diff works very well for me.
Absolutely.
Having it in the file also makes sure that early call to rresvport(3),
bindresvport(3), or bindresvport_sa(3) won't allocate it before the
daemon is started locally.
Martijn van Duren wrote:
> I currently don't see any reason for adding agentx over tcp support to
> our daemons, but
Excellent!
Alexander Bluhm wrote:
> Hi,
>
> A while ago dhill@ pointed out that syslogd TCP sockets will stay
> open forever if a client aborts the connection silently. As syslogd
> does not write anything into incoming connections, it will not
> recognize failure and the socket will stay for
A similar fix for the "sh" cpu, which is in the landisk.
Index: sh/sh/trap.c
===
RCS file: /cvs/src/sys/arch/sh/sh/trap.c,v
retrieving revision 1.40
diff -u -p -u -r1.40 trap.c
--- sh/sh/trap.c6 Sep 2019 12:22:01 - 1
i386 has the same problem.
Index: arch/i386/i386/trap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v
retrieving revision 1.143
diff -u -p -u -r1.143 trap.c
--- arch/i386/i386/trap.c 19 Aug 2020 10:10:58 - 1.143
++
We need to know which one is hitting a broken counter party -- is it the
stack checker, or the syscall checker.
Sebastien Marie wrote:
> On Sun, Sep 13, 2020 at 03:29:57PM +0200, Martin Pieuchot wrote:
> > I'm no longer able to reproduce the corruption while building lang/go
> > with the diff below. Something relevant to threading change in go since
> > march?
> >
> > Can someone try this diff and tell m
Stuart Henderson wrote:
> On 2020/09/13 11:12, Stuart Henderson wrote:
> > This has been tried before, I forget what but there were problems
>
> from chat logs when I tried this before:
>
> 14:52 < sthen> if i kill the if_down, no crash, but the mac address doesn't
> get updated so i end up wi
ok deraadt
Christian Weisgerber wrote:
> Add format string checking annotations for dprintf(3) and vdprintf(3).
>
> This was apparently forgotten when the functions were added. It is
> required so the compiler can warn
>
> t.c:25:25: warning: format string is not a string literal (potentially
Too much ifdef. Can you try a different approach -- leave the ipi code
intact, but wrap the call to db_enter() with #ifdef DDB? The ipi won't
be activated, so it should be fine for it to return 0.
Matt Baulch wrote:
> Currently, it's not possible to build on arm64 without the in-kernel debugge
Yep.
Martijn van Duren wrote:
> Just reminded myself of this one.
> The manpage says nothing about ober_read_elements setting errno upon
> failure, yet it does in most cases. Furthermore, applications like
> snmpd use errno in ober_read_elements to determine if a read is
> incomplete (checking f
I had this diff in my tree for a while, but haven't gotten around
to passing it up.
there are other warnings in the tree, found by newer clang, that
people should review. Some of them are just noise, in particular
relating to missing {}.
Theo Buehler wrote:
> clang 10 complains:
>
> /usr/src/
> Taking advantage of the sparse address space is smart and as 64-bit
> is now the norm, that space is even sparser.
Fundamentally this is moving various forms of pressure to the kernel,
which does not do the best job yet.
The pivot code in mmap for new mappings isn't entirely bug-free so we've
a
> If I am interpreting this correctly, realloc could be used to groom/shape
> the heap such that future allocations are less random and more predictable?
Traditionally the word "heap" refers to the zone of allocations in a
sbrk allocator, meaning things are packed tightly together in a known
space
Paul de Weerd wrote:
> On Tue, Aug 25, 2020 at 09:27:20PM +0200, Mark Kettenis wrote:
> | > I've dug out my stash of weird usb devices and found another sensor (a
> | > uthum(4), with only temperature support). I have a few other sensors
> | > in live machines too (acpitz(4), cpu(4), admtemp(4),
Mark Kettenis wrote:
> > Date: Tue, 25 Aug 2020 21:19:19 +0200
> > From: Paul de Weerd
> >
> > Hi all,
> >
> > I've dug out my stash of weird usb devices and found another sensor (a
> > uthum(4), with only temperature support). I have a few other sensors
> > in live machines too (acpitz(4), c
i've discusssed this offline with florian (many times, over the years)
It is quite possible there will be subtle behaviour changes, but in a
system configuration where "other programs on the machine are using also
ports quickly", we both expect unbound will behave *better* using kernel
support rat
Scott Cheloha wrote:
> There is one behavior change: in the setitimer(2) swap case it is now
> possible to EFAULT on copyout(9) *after* you have written the new
> timer value and (possibly) started the ITIMER_REAL timeout.
>
> For example, the following code now yields EFAULT even though a new
>
> It has occurred to me that we could do a trial copyout(9) in
> sys_setitimer() before entering the critical section. This is a *bit*
> wasteful, but is relatively inexpensive and narrows the behavior
> change I mentioned down to truly improbable cases involving multiple
> threads and munmap(2).
Christian Weisgerber wrote:
> On 2020-08-14, Jason McIntyre wrote:
>
> > - i cannot work out what is with the \! examples. i know we try to make
> > entries work for both csh and sh style shells, but stuff like this
> > works without escaping:
> >
> > $ find . ! -type f
>
> Going throu
Philipp Klaus Krause wrote:
> Am 11.08.20 um 02:48 schrieb Damien Miller:
> >
> > We went with explict_bzero because our only use-case for this was
> > safe erasure that could not be elided by the compiler.
> >
> > I don't see any need for explicit_memset() - if anything depends on
> > the over
As a general rule, pledge uses isn't supposed to make programs
more complicated.
Stuart Henderson wrote:
> On 2020/07/31 00:07, tempmai...@firemail.cc wrote:
> > I have to say I'm only a beginner to C but hopefully my patch is
> > good.
> >
> > This patch adds a second and more restrictive pled
Florian Obser wrote:
> On Wed, Jul 29, 2020 at 03:51:17PM +0200, Sebastian Benoit wrote:
> > If i remember correctly, the fallout was caused by EDNS but i might be
> > wrong. The unbound commit caused a developer some headscratching, because
> > his upstream internet did not work with such packet
Claudio Jeker wrote:
> On Wed, Jul 29, 2020 at 04:43:18PM +0200, Klemens Nanni wrote:
> > On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
> > > Wouldn't this break those who already have
> > > !route -T2
> > >
> > > in their hostname.if files?
> > No,
> >
> > $ route -
You were already able to execute a !command inside the rdomain, either
by specifying the rdomain (on commands which can do that) or by using
route -T manually.
But now, you can't easily execute commands *outside the rdomain*, and
there are some things folk might want to do.
Also, there is an orde
Stuart Henderson wrote:
> On 2020/07/25 09:20, Theo de Raadt wrote:
> > The normal idiom is when last-close happens in a driver, all modal-state
> > is lost and restored to default, and when you use the driver again --
> > the new open gets you a raw configuration whic
Matthieu Herrb wrote:
> On Sat, Jul 25, 2020 at 09:17:24AM -0600, Theo de Raadt wrote:
> > Marcus Glocker wrote:
> >
> > > Instead of introducing the CLI parameter controls in video(1), we could
> > > introduce videoctl(1) in base, same as we have with audio
$ video -c white_balance_temperature=6500
$ video
$ video -c reset
$ video
BTW, no other subsystem of ours has this "reset" type thing.
A few subsystems have persistance, but persistant modes are usually only
in the software layer, not in the hardware layer.
The normal idiom is when last
Marcus Glocker wrote:
> Instead of introducing the CLI parameter controls in video(1), we could
> introduce videoctl(1) in base, same as we have with audioctl(1). This
> also gives us the possibility to only display the current video
> parameters.
I must have missed something. Why does it need
Since there are mailers which want these features, I think removing
this out of base is silly. mailwrapper exists to abstract it, and
why shouldn't it remain as-is?
Todd C. Miller wrote:
> On Thu, 23 Jul 2020 21:41:53 +0200, Klemens Nanni wrote:
>
> > Ping.
> >
> > Feedback? Objections? OK?
>
Yeah, fine.
Sebastian Benoit wrote:
> Ross L Richardson(open...@rlr.id.au) on 2020.07.15 14:49:23 +1000:
> > Field kv_type in struct kv is not used. As that's the only use of
> > enum key_type, delete them both.
>
> This is probably because its a copy from relayd.
> I dont think there is a rea
> about -s: it's inclusion probably comes from a time when there was an
> annoying bug in nroff that made our man pages randomly display a number
> of blank lines in the middle of a page. -s mitigated that somewhat.
that is also what I recall.
Good.
The user-interface of less is slightly more refined, and definately
preferred.
Ingo Schwarze wrote:
> Hi,
>
> currently, if neither the MANPAGER nor the PAGER environment variable
> is set, man(1) uses "more -s" as the manual page pager. I am quite
> sure that the only reason i did this
> Note the third sentence.
>
> Given that, I reason that a serializing instruction before *and* after
> the RDTSC should freeze it in place.
I haven't seen anyone read it that way.
> So here is a new iteration taking feedback into account, using the
> #if WS_DEFAULT_BG == WSCOL_WHITE check for clarity, and also switching
> the foreground color of printed kernel messages to light cyan to improve
> contrast and readability.
I really dislike how two issues are being mixed into
It is extremely unwise to use DNS names at this level (or things which
look like DNS names). The same problems that pf has with DNS, are
present here. You really don't want people to get into this habit.
Klemens Nanni wrote:
> Here's an addition to EXAMPLES for one of my frequent use cases tha
If I remember the story right, historically unistd.h did not declare
those two, so to encourage portable reuse of parts of our tree they
remained.
You touch the ssh directory, and I think if that was commited you would
break downstream users, unless -portable handled it.
Can a posix laywer pipe u
At driver attach, cd (inside M_ZERO softc) is 0.
But if a reset (or suspend/resume) happens, then sis_rx_prod/sis_rx_cons
will be within the middle of the ring, and it isn't clear if everything
else in the chip+driver are ready for that.
ok deraadt
Kevin Lo wrote:
> ok?
>
> Index: sys/dev/p
No harm in adding it.
Mark Kettenis wrote:
> The firmware on the POWER9 machines provides an energy sensor. This
> sensor measures the energy on/in/at the chip. I'm not sure what that
> actually means. But it is different from the energy content of a
> battery which is measured in Watthours.
Denis Fondras wrote:
> I was upgrading an EdgeRouter and it restarted multiple times instead of
> booting
> /bsd
Try to produce a log of that problem, instead.
Fine with me.
Ted Unangst wrote:
> On 2020-07-09, Theo de Raadt wrote:
> > > Added a -T option to ktrace for transparency. I got ambitious here and
> > > made
> > > it take suboptions, anticipating that other transparency modifications may
> > > be
ote:
> On Mon, Jul 13, 2020 at 2:38 PM Theo de Raadt wrote:
>
> > I am sceptical of any need to support what you propose, especially
> > when it isn't documented, and secondly when it is shitty, and
> > outside the scope of the project.
> >
>
>
&
I am sceptical of any need to support what you propose, especially
when it isn't documented, and secondly when it is shitty, and
outside the scope of the project.
sven falempin wrote:
> ?(+([!@])@)
>
> is not very smart for something:something@
> but i guess it is enough ?
>
> ( tabulation sho
Todd C. Miller wrote:
> On Sat, 11 Jul 2020 13:35:57 -0700, Greg Steuck wrote:
>
> > The problem seems to be due to Chromium doing a readlink (likely at
> > [1]) on /etc/localtime, which fails. There's a workaround that
> > happens to work for chromium (and firefox). Just set TZ in your
> > env
Greg Steuck wrote:
> The problem seems to be due to Chromium doing a readlink (likely at
> [1]) on /etc/localtime, which fails.
If that is what it is doing, then it should stop doing so.
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Fri, Jul 10, 2020 at 10:02:46AM -0600:
>
> > I also don't see the point of the leading _
> >
> > Where does that come from?
> >
> > This isn't a function namespace. What does it si
I also don't see the point of the leading _
Where does that come from?
This isn't a function namespace. What does it signify, considering
no other environment variable uses _ prefixing.
I think you are mixing too much stuff in here...
> Added a -T option to ktrace for transparency. I got ambitious here and made
> it take suboptions, anticipating that other transparency modifications may
> be desired.
Please don't do that.
First off, I see no future in the open/openat idea. Not just pledge,
not just unveil, not just reduction
> Call getenv before issetugid.
Why??
issetugid is a syscall (yes, it has overhead) which (amongst other things)
whether you can trust the environment.
But getenv -- that's a call which trusts enough of the environment array's
structure, to do a walk, and find. Why do the walk, at all, if you a
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> > Ingo Schwarze wrote:
>
> >> So, what about
> >> LD_KTRACE_GETTIME
> >> or a similar environment variable name?
>
> > That naming s
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600:
>
> > This time, they become invisible.
> [...]
> > There are many circumstances where ltrace is not suitable.
> [...]
> > We fiddle with programs all the tim
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600:
>
> > This time, they become invisible.
> [...]
> > There are many circumstances where ltrace is not suitable.
> [...]
> > We fiddle with programs all the tim
David Gwynne wrote:
> so the problem is the older api doenst support the "get phy types"
> command, or the sff commands. should we silence the "get phy types"
> error output? is there a better errno to use when the sff command
> isn't supported? should we add something to the manpage? should that
Ingo Schwarze wrote:
> Hi,
>
> i wonder whether there is a layering violation going on here.
>
> From the user perspective, whether an API call is a syscall or a
> mere library function doesn't make any difference, it's an
> implementation detail.
>From the developer's perspective it is a HUGE
Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Thu, 09 Jul 2020 11:07:02 -0400
> >
> > On 2020-07-08, Mark Kettenis wrote:
> > > > From: "Ted Unangst"
> > > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > > >
> > > > On 2020-07-08, Ted Unangst wrote:
> > > > > I think this makes sem_init(
Ted Unangst wrote:
> On 2020-07-08, Theo de Raadt wrote:
> > I think we need something like this.
> >
> > Documenting it will be a challenge.
> >
> > I really don't like the name as is too generic, when the control is only
> > for a narrow set of &qu
Ted's new experimental mailer is incompatible with the real world.
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Wed, 08 Jul 2020 09:42:41 -0600
> >
> > I think we need something like this.
> >
> > Documenting it will be a challenge.
> >
> > I really don't like the name as is too gen
I think we need something like this.
Documenting it will be a challenge.
I really don't like the name as is too generic, when the control is only
for a narrow set of "current time" system calls.
Ted Unangst wrote:
> Not sure how useful this will be, but I think it could be helpful to still
> s
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
Ugly test program (not s
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
A few small test program
Scott Cheloha wrote:
> > - __asm volatile("rd %%sys_tick, %0" : "=r" (tick) :);
> > + __asm volatile("rd %%sys_tick, %0" : "=r" (tick));
> >
> > return (tick & ~0u);
> > }
>
> The only thing that gives me pause is the inline assembly.
>
> I know it isn't a lot of assembly, but would
> The /sys/arch/powerpc/include/timetc.h in your diff never gets used,
> because there is no #include . On macppc,
I am fixing this issue for all the architectures, just being careful
by doing builds first.
Mark Kettenis wrote:
> Unless there is an overwhelming majority of users/developers who thing
> the colors should indeed be changed. If there is a significant
> minority that thinks the current colormap severely impacts the
> usability of the framebuffer console, then maybe an interface to
> cha
wrote:
> Related, I looked through the xterm code to see how hard it would
> be to use some of it directly in the wscons system for accurate
> emulation, and it looked pretty challenging to me. Fixing problems
> piecemeal is probably easier than trying to reuse code.
It was obvious 25-30 years
Frederic Cambus wrote:
> One can test in frame buffer consoles by doing:
>
> export TERM=wsvt25
>
> And run either vim or colorls -G.
>
Furthermore the situation is just beyond ridiculous.
On the one hand your diff is talking about minimizing the differences
between terminals, but your examp
> One can test in frame buffer consoles by doing:
>
> export TERM=wsvt25
>
> And run either vim or colorls -G.
Why not set it to wyse30?
Come on. We chose a default. If you change it to some arbitrary value,
then you get to reap the upsides and downsides. Our emulation is *NOT*
'NetBSD "wsco
Jonathan Gray wrote:
> On Tue, Jul 07, 2020 at 03:16:33PM +0200, Frederic Cambus wrote:
> > Hi tech@,
> >
> > The recent spike of interest around framebuffer consoles has prompted
> > me to revisit a proposal I sent back in early 2017 [1].
> >
> > Aesthetics considerations aside, kettenis@ rais
Ah, it was seen.
But everyone has too much memory these days.
Vitaliy Makkoveev wrote:
> Sorry for late reaction. At least VirtualBox based virtual machines
> started to panic with the recent kernel. I reverted your diff and panics
> stopped.
> Screenshot attached.
Mark Kettenis wrote:
> I did not add the LFENCE to tc_get_timecount() itself. We probably
> should, but in the past some networking folks complained about slow
> timecounters affecting network performance, so I wanted confirmation
> that this didn't cause problems.
I don't see how a more precis
Scott Cheloha wrote:
> I was under the impression kettenis@ had added an lfence to the kernel
> TSC's tc_get_timecount(), but I was mistaken.
>
> We can deal with that separately.
the question was asked, but I guess not answered definitively
I think we should *always* lfence, because in the en
The unveil("/", "x") is to support command executation:
daemon facility. Optionally, an alert can be configured to execute a
command.
Your proposal breaks that. It will need to be added back.
Alexander Bluhm wrote:
> Hi,
>
> sensorsd(8) reports an unveil failure due to chdir / .
801 - 900 of 2939 matches
Mail list logo
