I'm not sure about this chunk.
There are fdti chipsets that expose two uftdi, with a ucom each.
But maybe there are chipsets that expose one uftdi, which has two ucom?
It could be saying such a model is not supported.
If that is the gap, it is wrong to say ucom needs extending. uftdi would
need
Marcus Glocker wrote:
> Hi All,
>
> I recently started to play around with uvideo(4) and uaudio(4) on my
> amd64 iMacs. There I quickly noticed regular freezes when streaming
> USB video or audio. On some of those machines it was very frequent,
> like every few seconds the video or audio strea
Mark Kettenis wrote:
> Well, we deliberately chose not to do that since that would lead to a
> gazillion of kernel threads if you have lots of sensor drivers.
>
> Sensor drivers that are "good citizens" should probably continue to
> use the sensor thread. Butfor things like asmc(4) that handle
I'd be ok with renames of all of them.
It is really weird that portable filenames aren't just 255 characters
avoiding NUL or path-separator (usually /).
This is not about msdos alone. The implication has slowly infected
other systems and applications -- which now make logical decisions, and
thos
> I don't think it is worth doing without doing all of it.
Series of commits.
Jan Klemkow wrote:
> for frequent performance test it would be nice to just start tcpbench
> as a regular service. tcpbench gets an extra user and group with this
> diff and is already pledged to "stdio". Thus, there should be no
> security risk to do this even in hostile environments.
You're
Jan Klemkow wrote:
> On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > Jan Klemkow wrote:
> >
> > > for frequent performance test it would be nice to just start tcpbench
> > > as a regular service. tcpbench gets an extra user and group wi
Stuart Henderson wrote:
> On 2020/12/15 16:33, Theo de Raadt wrote:
> > Jan Klemkow wrote:
> >
> > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote:
> > > > Jan Klemkow wrote:
> > > >
> > > > > for frequent perfor
the term "suid" includes setgid executables... so your conclusions
are way wrong.
Heck, you should give it a try. Good luck logging in afterwards.
Josh Rickmar wrote:
> Playing around with find ${dir} -type f -perm -04000, I see that there
> are no longer any more suid executables placed in /u
Todd C. Miller wrote:
> I like this direction but I worry about breaking existing configs.
> How are we going to alert existing users that they need to update
> their configs if the behavior silently changes?
I think the configuration is backwards.
Every endpoint box will need these new stanza.
There are thousands of people with smtpd configurations, and sysmerge
is not going to handle this.
We cannot expect them all to change their files. This is madness.
Gilles, I think you should be adding an option that blocks it optionally,
and then some operators can use that. If they wish. I a
Florian Obser wrote:
> On Sun, Dec 20, 2020 at 02:34:09PM +0100, Claudio Jeker wrote:
> > On Sun, Dec 20, 2020 at 01:39:57PM +0100, Otto Moerbeek wrote:
> > > Hi,
> > >
> > > scope is there, just not shown. While there, use proper constants for
> > > two sizes.
> > >
> > > -Otto
> > >
> > >
Ted Unangst wrote:
> On 2020-12-18, Martijn van Duren wrote:
> > So I ended up in doas again, this time with the CFLAGS I use for most of
> > my other projects. This popped up a few new not very exciting warnings.
> > Diff below compiles clean with both clang and gcc on amd64.
>
> > static int
catching underflow which results in infinite delays is probably very
handy.
Scott Cheloha wrote:
> The manpage for delay(9) suggests that the prototype is:
>
> void delay(int);
>
> But on armv7, arm64, hppa, macppc, and powerpc64 the input is unsigned
> or a u_int instead of an int. Like this
I agree. This chunk below is really gross and does not follow the
special wakeup channel metaphor.
It is *entirely clear* that a &channel called "nowake" has no wakeup.
Like duh.
> +/*
> + * nowake is a global sleep channel for threads that do not want
> + * to receive wakeup(9) broadcasts.
> +
Daniel Moch wrote:
> I like being able to specify a user to run the script as. In my case
> it's sufficient to run the script as 'nobody'.
Regarding this second sentence: never use nobody for another purpose.
It has other purposes, and if people follow this pattern of using nobody
then potentia
Martin Pieuchot wrote:
> On 26/12/20(Sat) 18:23, Mark Kettenis wrote:
> > [...]
> > NetBSD and Solaris both provide SIMPLEQ_* and STAILQ_*. I'm not sure
> > removing one in favour of the other is helpful.
>
> It would be helpful to provide both set of macros for some time to ease
> the transiti
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify
> with FreeBSD and Linux.
More than half the stuff being touched doesn't exist in FreeBSD or Linux.
SIMPLEQ_ goes back to 97.
Why is this the direction to go???
Denis, you appear to be making an arbitrary decision and not
Denis Fondras wrote:
> Le Sat, Dec 26, 2020 at 06:23:41PM +0100, Mark Kettenis a écrit :
> > > > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify
> > > > with FreeBSD and Linux.
> > > >
> > > > I added aliases at the end of queue.h to avoid breaking base too much.
> > > > t
Todd C. Miller wrote:
> On Sat, 26 Dec 2020 10:45:21 -0700, "Theo de Raadt" wrote:
>
> > > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify
> > > with FreeBSD and Linux.
> >
> > More than half the stuff being touched doesn'
Christian Weisgerber wrote:
> Theo de Raadt:
>
> > What is lacking in this converstation is the justification.
> > Why?
>
> Providing STAILQ in OpenBSD will simplify porting to OpenBSD.
> (Reality check: There is one port affected by this.)
>
> Switchin
fork_filter_process() does not feel like the right name for
the function anymore.
Take note the exit value of the process (as seen by wait elsewhere) will
be subtly differe after this conversion from system() to execve().
Upon failure, rather than being 127, it is now 1.
Martijn van Duren wrote:
Take note this change is fine for modern POSIX systems, but there are
earlier systems where unistd.h did not contain these externs.
That is why these externs were placed.
As such, this change makes the software less portable against such
ancient systems. At this point, I'm fine with that.
Jan
Miod Vallat wrote:
> Up until 6.5, sparc64 bsd.rd were gzipped kernels. This got lost during
> the Great Installation Media Unification of the 6.6 release cycle, and
> since then bsd.rd are uncompressed.
>
> The following diff ought to fix this and bring back sparc64 netboot
> times down to acce
I disagree with this.
Because next you'll be asking for the ls manpage to list "rm" and "touch"...
Donovan Watteau wrote:
> Hi,
>
> Ten years ago, a teacher of mine asked why "the command which
> concatenates files never mentions the command which splits files".
>
> Ten years later, I still t
Donovan Watteau wrote:
> Theo de Raadt wrote:
> > I disagree with this.
> >
> > Because next you'll be asking for the ls manpage to list "rm" and "touch"...
>
> That's not my personal intent no, but I get your point.
>
> concat
Jason McIntyre wrote:
> On Thu, Jan 21, 2021 at 12:47:15PM +, Stuart Henderson wrote:
> > On 2021/01/21 12:43, Jason McIntyre wrote:
> > > On Thu, Jan 21, 2021 at 11:15:48AM +0100, Martin Vahlensieck wrote:
> > > > Hi
> > > >
> > > > I think the backslash at the beginning of the line is an e
I guess so, though I cannot imagine a program-context where bcrypt_newhash
stack's can be leaked in a dangerous way.
Programs that create these hashes end up knowing more, or having more power.
Peter J. Philipp wrote:
> Hi,
>
> On IRC, someone and I were arbitrarily going through bcrypt.c and
Otto Moerbeek wrote:
> On Sun, Jan 24, 2021 at 01:18:46PM +0100, Alejandro Colomar wrote:
>
> > This is useful for using tee to just write to a file,
> > at the end of a pipeline,
> > without having to redirect to /dev/null
> >
> > Example:
> >
> > echo 'foo' | sudo tee -q /etc/foo;
> >
> > i
I completely despise that the option is called "--null".
Someone was a complete idiot.
Ted Unangst wrote:
> On 2021-01-22, Omar Polo wrote:
> >
> > quasi three-weekly ping.
> >
> > Is this such a bad idea?
>
> This seems reasonable. I think there's no need to change print line calls
> thoug
Stuart Henderson wrote:
> On 2021/01/24 12:10, Theo de Raadt wrote:
> > I completely despise that the option is called "--null".
> >
> > Someone was a complete idiot.
>
> gnu grep has both --null and -z for this (why do they do that?!).
> If it's
It should use 'demotion counter' everywhere.
Stuart Henderson wrote:
> On 2021/02/01 14:32, Klemens Nanni wrote:
> > On Mon, Feb 01, 2021 at 01:13:20PM +, Stuart Henderson wrote:
> > > I think this needs documenting somewhere; I had to use the source to
> > > remember what triggered "carpde
Otto Moerbeek wrote:
> On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote:
>
> > Anyone?
>
> Fixing a particluar issue is fine, but more important is an assessment
> it does not break other things. In particular, does this limit the VM
> for data available to any program (which is
Philippe Meunier wrote:
> Theo de Raadt wrote:
> >Otto Moerbeek wrote:
> >> Fixing a particluar issue is fine, but more important is an assessment
> >> it does not break other things. In particular, does this limit the VM
> >> for data available to any progra
Yes it is unacceptable.
Alexander Bluhm wrote:
> On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote:
> > Just commit it. OK claudio@
> > If people see problems we can back it out again.
>
> This has huge impact on TCP performance.
>
> http://bluhm.genua.de/perform/results/2021-02-07
Claudio Jeker wrote:
> On Mon, Feb 08, 2021 at 07:46:46PM +0100, Alexander Bluhm wrote:
> > On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote:
> > > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote:
> > > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote:
>
Alexander Bluhm wrote:
> Hi,
>
> Every time we ship a libcrypto erratum, we have to relink isakmpd.
> I think that isakmpd and iked are in /sbin due to a historic mistake.
> Probably it is for people who mount /usr via NFS over IPsec.
That was the reason originally. Today I am not sure it make
Oh wait I misread.
When I re-ordered rc in Slovenia many years ago, I got it right.
So, I think we should move these two daemons.
Addendum: shared library linking increases the .so footprint, and
cross-.so ROP attacks are a tiny bit more difficult in OpenBSD.
Reading a recent junk-thread, I realized the algorithms for rand
and random have changed numerous times since the late 80's.
As such you cannot trust that a seed given 20 years ago, produces the
same sequence today.
I did a rough study of the commits to our versions. Other operating
systems chan
Hi Nelson -
Nelson H. F. Beebe wrote:
> Thanks, Theo, for this good advice about random-number generators:
In this discussion, I made no comments about "random-number generators".
Instead I commented on "deterministic generators", which have been
incorrectly placed inside subsystems claiming
Nelson H. F. Beebe wrote:
> Thanks for the comments, Theo.
>
> I wasn't clear in my posting about distinguishing deterministic from
> nondeterministic generators. The former are required for reproducible
> simulations
Perhaps. Even then they often criminally abused, ie. Neil Ferguson --
somet
Sebastien Marie wrote:
> Please note I am unsure about sgi: disklabel -w is using
> "OpenBSD/sgi " as packid, and I changed it to "OpenBSD/${MACHINE}".
> But the packid used isn't uniform across archs, so it might not matter.
I think you mean "volid", this is the -V option. The thing to not
t; + cp ${DESTDIR}/usr/mdec/cdboot
> ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot
> mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \
> - -A "OpenBSD ${OSREV} amd64 bootonly CD" \
> + -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \
>
I like that.
Sebastien Marie wrote:
> Hi,
>
> arm64 ramdisk has customization in mr.fs target, in order to create
> usr/mdec/pine64 and usr/mdec/rpi directories (files will be copied
> inside them by runlist.sh).
>
> I will argue that mr.fs target isn't the place for such per-arch
> customizat
Luke Small wrote:
> if calloc() and recallocarray() needs nmemb and size, why doesn't
> freezero()?
>
> Should there be a freeczero(size_t nmemb, size_t size) ?
Performing the nmemb*size overflow detection a second time provides
no benefit.
Luke Small wrote:
> I guess I always thought there'd be some more substantial overflow mitigation.
You have to free with the exact same size as allocation.
nmemb and size did not change.
The math has already been checked, and regular codeflows will store the
multiple in a single variable after
> > Would it be too much hand-holding to put in the manpage that to avoid
> potential
> > freeezero() integer overflow,
> > it may be useful to run freezero() as freezero((size_t)nmemb *
> (size_t)size);
>
> Wow, Those casts make it very clear you don't understand C, if you do
> that kind o
Regarding port 323,
+If not specified the default
+.Ic port
+is
+.Em 323 .
and
+rtr: RTR address {
+ currtr = get_rtr(&$2);
+ currtr->remote_port = 323;
+ if (insert_rtr(currtr) == -1) {
+
Claudio Jeker wrote:
> Sure. Lets do that. I just checked, bgpd does not use getservbyname() for
> the BGP connection either (it uses a define). Maybe that should be changed
> as well.
Yeah, no kidding.
Luke Small wrote:
> However, calloc(ptr, nmemb, size) may have been called using smaller int
> variable types which would overflow when multiplied.
In which case the allocation would not have succeeded.
> Where if the variables
> storing the values passed to nmemb and size are less than or espe
This diff will land in snapshots.
Luke Small wrote:
> malloc(3) already speaks to programmers who might use int multiplication and
> telling
> them to test for int multiplication overflow in malloc(), so you presume that
> they are
> already prepared to use something smaller than size_t, when you could have
> just said:
> “on
Jan Stary wrote:
> Say explicitly that doas needs doas.conf to exist,
> and point to the example one.
>
> Jan
>
>
> Index: doas.1
> ===
> RCS file: /cvs/src/usr.bin/doas/doas.1,v
> retrieving revision 1.25
> diff -u -p -r1.2
Stuart Henderson wrote:
> On 2021/02/20 09:20, Remi Locherer wrote:
> > On February 19, 2021 8:56:31 PM UTC, Stuart Henderson
> > wrote:
> > >Canvassing opinions on having . and ! this way around. I'm using . for
> > >response, ! for no response, which makes more sense to me but it's been
> > >
Bryan Steele wrote:
> On Tue, Feb 23, 2021 at 06:23:22PM +1100, Jonathan Gray wrote:
> > On Tue, Feb 23, 2021 at 08:10:54AM +0100, Otto Moerbeek wrote:
> > > On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote:
> > >
> > > >
> > > > > No problem, real-life often takes precedence.
> > >
OK with me.
I'll say it again, the unveils in here are misguided. Almost as
misguided as the mmap's (which prevents large file transfer, and
there are other problems..)
Claudio Jeker wrote:
> There is no need for cpath or the unveil of . in the rsync process.
> That process just does fork+exe
Scott Cheloha wrote:
> Any reason not to ANSIfy these? While we're here we can kill some
> ARGUSED comments, too.
Absolutely, go ahead with that.
> I don't have a sparc64 machine so I'd appreciate a test compile.
It compiles fine.
Definately! It will round-trip through poll() less often.
Claudio Jeker wrote:
> It is perfectly fine to wait for read and write at the same time.
> The code in rpki-client should do that too, I think it will not matter
> but it is what I intended.
>
> --
> :wq Claudio
>
> Index: main.c
> ==
I agree.
Alexander Bluhm wrote:
> On Wed, Feb 24, 2021 at 04:27:03PM +1000, David Gwynne wrote:
> > it's a start though. cocci and i came up with this to push in after.
>
> Less casting is better. OK bluhm@
>
> > Index: arch/armv7/sunxi/sxie.c
> >
There is nothing beyond SIGILL.
Why would we want such a thing? We are operating in a source-code-available
world. Why would any one us want to encourage a must-run-binaries future?
The history of syscall-compatibility in BSD operating systems has been
forgotten. Back in the NetBSD days, Chris
Theo Buehler wrote:
> On Sat, Feb 27, 2021 at 12:21:35AM +1100, Jonathan Gray wrote:
> > Bring in a change which was backported to Mesa 20.1 but not 20.0.
> > This is for inteldrm with >= gen8/broadwell hardware.
> > /var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will
> > show 'Screen
Stuart Henderson wrote:
> On 2021/02/27 11:50, Theo de Raadt wrote:
> > To see the problem, It is better to look at "UVM amap" in "vmstat -m"
> >
> > UVM amap 32835 1690K 2636K 78644K 268129080
> > 16,32,64,128,256,512,1024,4096,8
Theo Buehler wrote:
> On Tue, Mar 02, 2021 at 02:09:37PM +0100, Claudio Jeker wrote:
> > This diff just brings all err(3) calls for out of memory situations to one
> > form: err(1, NULL);
> > It is not very helpful to tell if malloc, strdup or asprintf failed with no
> > mem. Just one common idio
It is a bug in dhclient introduced a few days ago.
Thomas L. wrote:
> Hi,
>
> current snapshot hangs during sysupgrade after rootfs mount with
>
> iwm0: DAD detected duplicate IPv6 address fe80:1::164f:8aff:fe25:dbef: NS
> in/out=1/1, NA in=0
> iwm0: DAD complete for fe80:1::164f:8aff:fe25:
Fix dump() to convert subclass == NULL into something else, or maybe the
fix should be in pci_subclass() itself.
Converting NULL to %s into "(null)" is non-standard and has led to sloppier
code, there have been efforts improve the whole tree enough that we could
one day simply crash on such circum
Matthieu Herrb wrote:
> On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote:
> > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov :
> > >
> > > Hello all.
> > >
> > > Since xenodm has DEF_USER_AUTH_DIR set to "/tmp", we need to ignore
> > > /tmp/.Xauth* in daily cleanup, don't we?
> > >
> > > Fo
Matthieu Herrb wrote:
> On Sat, Mar 06, 2021 at 09:56:34AM -0700, Theo de Raadt wrote:
> > Matthieu Herrb wrote:
> >
> > > On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote:
> > > > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov :
> > > >
Vadim Zhukov wrote:
> > The backup dir can be configured to something else, but it needs to be
> > writeable by the user whois login in. It could be a subdir of /tmp (if
> > the rc.d script takes care of creating it) or I can remove that
> > feature from xenodm and fail the login if /home is not
Vadim Zhukov wrote:
> сб, 6 мар. 2021 г. в 20:53, Theo de Raadt :
> >
> > Vadim Zhukov wrote:
> >
> > > > The backup dir can be configured to something else, but it needs to be
> > > > writeable by the user whois login in. It could be a subdir of /
Matthieu Herrb wrote:
> Linux, systemd and XDG have inventend this /run/user/$uid tmpfs that
> is created automagically and they use that in place of /tmp for
> volatile things that don't beloing to $HOME, but this is not a can of
> worms I want to open now.
Awesome, another directory to drop st
Paul Kelly wrote:
> So...here is a proposal for updating various man pages to try help
> others who make a similar migration to dhcpleased. It's a bit of a
> scattershot approach and the wording can probably be improved, but it is
> hopefully consistent with the existing pattern for describing au
I guess the rest of the page contains 0?
It would be better if it contained "trap" instructions. We still don't
have an ideal way of doing that tho.
Miod Vallat wrote:
> The code responsible for filling a page with repeated copies of the
> signal trampoline code assumes that PAGE_SIZE % sigfil
I see I misunderstood, and this does what is desired.
Miod Vallat wrote:
> The code responsible for filling a page with repeated copies of the
> signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0.
>
> While this is true on all currently supported OpenBSD platforms, this
> might not
Miod Vallat wrote:
> > It would be better if it contained "trap" instructions. We still don't
> > have an ideal way of doing that tho.
>
> That would work, but that would make the code a bit more complicated.
> And I'm not sure it's worth doing anyway. Running into an unmapped page
> will segfa
Alexander Bluhm wrote:
> I hope to have addressed all issues.
>
> On Sun, Mar 07, 2021 at 11:50:24AM +, Visa Hankala wrote:
> > This copyin() can also result in copying the buffer from userspace twice.
> > This might not be a problem with log data though.
>
> Is double copyin a problem? I
Vitaliy Makkoveev wrote:
> > On Mon, Mar 08, 2021 at 01:37:51AM +0300, Vitaliy Makkoveev wrote:
> >> I wonder they were not buffered. But does it make sense to drop the
> >> most recent messages?
> >
> > The oldest message should be kept. In my experience you get most
> > information why loggin
Todd C. Miller wrote:
> On Tue, 09 Mar 2021 20:14:19 +, Mark Lumsden wrote:
>
> > Here is a diff from Joachim Wiberg's version of mg.
> >
> > "The strlcpy() function is guaranteed to never copy more than 'len - 1'
> > bytes, so there is no need to check if we copied more. This is a bogus
>
There is a pattern we've followed in the past, that when a manpage applies
to more than 2 (or 3?) architectures, then we simply make it MI.
So MANSUBDIR would get deleted, and then the sets would be updated.
People with old systems will retain the old files, but I think man(1)
selects the MI ones
Otto Moerbeek wrote:
> On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote:
>
> > On 2021/03/19 17:05, Jan Klemkow wrote:
> > > Hi,
> > >
> > > I had the same issue a few days ago a server hardware of mine. I just
> > > ran 'cvs up'. So, it looks like a generic bug in FFS and not
Jason McIntyre wrote:
> On Sat, Mar 20, 2021 at 07:29:11PM -0600, Theo de Raadt wrote:
> > There is a pattern we've followed in the past, that when a manpage applies
> > to more than 2 (or 3?) architectures, then we simply make it MI.
> >
> > So MANSUBDIR woul
The sensor framework generally does not know where a sensor is. A
sensor could reside on some device which has been plugged in, rather
than be the primary sensor.
But the users of apm are only hoping for best effort.
meaning "some information", not "perfect information". Many PC BIOS
have lied
Klemens Nanni wrote:
> > So which is better:
> >
> > (1) try to emit some information for the people who quicky-use the apm
> > interface
> >
> > (2) change apm to not print those lines on architectures where we are
> > unsure.
> >
> > I think (1) is acceptable for a tool which has never pro
Fine with me.
The malloc'd memory is not identical to bss memory, but this still matches
the spirit of the test.
Brent Cook wrote:
> In the next version of Linux glibc, SIGSTKSZ is defined at runtime if
> source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to
> bring in asprintf
Marcus Glocker wrote:
> Index: sys/dev/sdmmc/sdmmc_scsi.c
> ===
> RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
> retrieving revision 1.59
> diff -u -p -u -p -r1.59 sdmmc_scsi.c
> --- sys/dev/sdmmc/sdmmc_scsi.c15 Oct 2020 1
That is what I envisioned. It is just an off-by-one on the bounds check.
Marcus Glocker wrote:
> On Tue, Mar 23, 2021 at 08:29:06AM -0600, Theo de Raadt wrote:
>
> > Marcus Glocker wrote:
> >
> > > Index:
Mark Kettenis wrote:
> > > Index: sys/dev/sdmmc/sdmmc_scsi.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v
> > > retrieving revision 1.59
> > > diff -u -p -u -p -r1.59 sdmmc_scsi.c
> > > --- sys/dev/sdmmc/sdmmc_scsi
Marcus Glocker wrote:
> On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote:
>
> > Mark Kettenis wrote:
> >
> > > > > Index: sys/dev/sdmmc/sdmmc_scsi.c
> > > > > ==
No way for this diff. This is the wrong way. Surely there are ways
to disable compression negotion on specific sessions, but removing
the code from the kernel is the wrong knob.
Balder Oddson wrote:
> Compression in PPP was great in the age of ISDN to increase speeds.
> The more common use cas
I have reviewed all the pledge using programs in the tree, and I do not
see additional risk from this change.
Who wants to take care of the commit?
Josh Rickmar wrote:
> The kern.somaxconn sysctl was previously permitted under the inet
> pledge, which allowed pledged Go applications to listen o
Stuart Henderson wrote:
> > Not having read the code, case in point on principle, I'm arguing that
> > there should be solid reasoning to enable it by default, as those with a
> > need for it can certainly enable it and build a kernel.
>
> It's not that simple, using a custom kernel means you ca
Balder Oddson wrote:
> On Thu, Mar 25, 2021 at 03:40:15PM -0600, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > > Not having read the code, case in point on principle, I'm arguing that
> > > > there should be solid reasoning to enable it
Absolutely -- this allows me to skip a few steps when tracing.
Claudio Jeker wrote:
> It is time to use setproctitle() in rpki-client.
> Right now there are three processes, soon it will be four.
> This should help identify the different processes.
> I did not change the proc title of the main p
Yep.
Theo Buehler wrote:
> d->uri was allocated by xstrdup(), so needs to be freed. Was going back
> and forth between the below and adding free(d->uri).
>
> Index: rrdp_notification.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-clien
Yep, all good
Jason McIntyre wrote:
> yep, better than mine. ok
> jmc
>
> On 4 April 2021 14:41:13 BST, Klemens Nanni wrote:
> >On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote:
> >> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
> >> > @@ -119,6 +119,17 @@ send
Mark Kettenis wrote:
> Before you go further down this path, please realize that "fixing" the
> TSC this way is racy in much the same ways as determining the skew is.
> If an SMM or a VM exit happens between reading the TSC and the actual
> write to the MSR, the new value of the TSC will be off b
So, your argument is that displays should remain broken forever.
> The bug in NetBSD and Linux should be fixed, but that's off-topic here.
If you cannot explain how this problem is going to be fixed (reversed)
in these opposing ecosystems (and it is not just Linux and NetBSD), then
you've closed
Fine.
Though I think this approach will bite us in a different way one day...
Mark Kettenis wrote:
> While working on suspend/resume for another arm64 board, I ran into an
> issue with xhci(4). We detach USB devices early on in the suspend
> process. At this point we mark the USB bus as "dyi
Damien Miller wrote:
> On Wed, 20 Jul 2022, Chris Cappuccio wrote:
>
> > Klemens Nanni [k...@openbsd.org] wrote:
> > > veb(4) works just fine in this setup, so don't give the impression only
> > > bridge(4) would work.
> >
> > In related items, is it time to tedu bridge(4) and vether(4) ? Is th
> One concern I had while working on this was that changing the point at which
> YP is enabled might affect the boot process. ypbind is started right after
> ypldap, and ypldap becomes discoverable to ypbind before it daemonises,
> so this doesn't change the ordering.
Yes, it is a bit weird.
The
fine
Daniel Dickman wrote:
> The Rise mp6 was a short lived processor that was announced around 20+
> years and didn't make it to market.
>
> I think we can delete the cpu identification for this cpu at this point.
>
> ok?
>
> Index: i386/machdep.c
> =
1 - 100 of 2939 matches
Mail list logo
