On Wed, Jan 25, 2023 at 03:17:48PM +0100, Moritz Buhl wrote:
>
> Dear tech,
>
> Looking into various reports on errors with mini routers that use
> igc(4), I found the following diff in FreeBSD:
> https://github.com/freebsd/freebsd-src/commit/29d7f1ff579579711dd5a3325480728b8ed45f8c
>
> I additi
Almost every platform initializes stathz and profhz like this:
stathz = hz;
profhz = stathz * 10;
This patch brings a few stragglers in line with everyone else.
This does not change stathz and profhz on the listed platforms: hz is
100 in every case.
ok?
Index: macppc/macppc/clo
Ah of course. I will move the missing files into base.
Brian Conway wrote:
> Just a heads up, I was trying a few install variations of -current and
> noticed sshd reorder failing on boot on one of them. Unpacking
> /usr/share/relink/usr/sbin/sshd/sshd.tar and running `make -f Makefile.relink
Just a heads up, I was trying a few install variations of -current and noticed
sshd reorder failing on boot on one of them. Unpacking
/usr/share/relink/usr/sbin/sshd/sshd.tar and running `make -f Makefile.relink
relink` by hand yielded:
ld: error: cannot open crt0.o: No such file or directory
c
On Sun, Jan 15, 2023 at 09:08:29AM -0500, Dave Voutila wrote:
>
> Dave Voutila writes:
>
> > It turns out not only does vmd have numerous error paths for handling
> > when something is amiss with a guest, most of the paths don't check if
> > it's a known vm defined in vm.conf.
> >
> > As a resul
No reason to keep it, selinfo is just wrapper to klist. netstat(1) and
libkvm use socket structure, but don't touch
so_{snd,rcv}.sb_sel.si_note.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving
On Thu, Jan 26, 2023 at 10:37 AM Todd C. Miller
wrote:
> On Thu, 26 Jan 2023 10:29:36 -0800, enh wrote:
>
> > yeah, but that's the copy & paste-o, no? (apologies if it's just too
> early
> > for me to be looking at code yet...)
> >
> > doesn't this need to be int64_t?
> >
> > int result = 0;
>
On Thu, Jan 26, 2023 at 03:28:07PM +, Visa Hankala wrote:
> On Thu, Jan 26, 2023 at 01:57:56AM +0300, Vitaliy Makkoveev wrote:
> > On Wed, Jan 25, 2023 at 10:43:50PM +0300, Vitaliy Makkoveev wrote:
> > > visa@, mpi@, I'm asking you to review, because you are involved in the
> > > kevent(9) deve
On Thu, 26 Jan 2023 10:29:36 -0800, enh wrote:
> yeah, but that's the copy & paste-o, no? (apologies if it's just too early
> for me to be looking at code yet...)
>
> doesn't this need to be int64_t?
>
> int result = 0;
Yes, it does, thanks.
> https://github.com/openbsd/src/blob/master/lib/lib
On Thu, Jan 26, 2023 at 9:42 AM Todd C. Miller
wrote:
> On Thu, 26 Jan 2023 09:36:52 -0800, enh wrote:
>
> > it's quite possible that this could use _conv_num64(), but it wasn't
> > obvious to me that that function's correct? (i haven't thought too hard
> > about the overflow logic, but just the
One (midly annoying) feature of mg is that it appends /dev/null to the
grep invocation. I guess this was done so grep is never called with
only one file argument and so it always displays the filename in its
output.
However, this gets a bit annoying when one only types "grep -n -R foo"
and yields
On Thu, 26 Jan 2023 09:36:52 -0800, enh wrote:
> it's quite possible that this could use _conv_num64(), but it wasn't
> obvious to me that that function's correct? (i haven't thought too hard
> about the overflow logic, but just the fact that result is an `int` seems
> odd?)
It just returns a boo
well, the
+ if (bp == old_bp || errno == ERANGE ||
+((long) t) != n) return NULL;
bit is the "most active ingredient" here, deliberately failing (rather than
wrapping) if out of 32-bit range.
it's quite possible that this could use _conv_num64(), but it wasn't
obvious to me that that functio
On Thu, Jan 26, 2023 at 01:57:56AM +0300, Vitaliy Makkoveev wrote:
> On Wed, Jan 25, 2023 at 10:43:50PM +0300, Vitaliy Makkoveev wrote:
> > visa@, mpi@, I'm asking you to review, because you are involved in the
> > kevent(9) development.
> >
> > Hrvoje, if you want to test this diff, you need to d
Is there a reason you didn't just change the gmtime_r() in the 's'
case to localtime_r()? That seems like the simplest fix. Using
strtol() for what may be a 64-bit value on an 32-bit system looks
wrong.
- todd
On Thu, Jan 26, 2023 at 02:06:28PM +0300, Vitaliy Makkoveev wrote:
> On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote:
> > Jan Klemkow:
> >
> > > we have several drivers which have to parse the content of mbufs. This
> > > diff suggest a central parsing function for this. Thu
On Thu, Jan 26, 2023 at 11:37:51AM +0100, Christian Weisgerber wrote:
> Jan Klemkow:
>
> > we have several drivers which have to parse the content of mbufs. This
> > diff suggest a central parsing function for this. Thus, we can reduce
> > redundant code.
> >
> > I just start with ix(4) and ixl
Jan Klemkow:
> we have several drivers which have to parse the content of mbufs. This
> diff suggest a central parsing function for this. Thus, we can reduce
> redundant code.
>
> I just start with ix(4) and ixl(4) because it was easy to test for me.
> But, this could also improve em(4), igc(4)
18 matches
Mail list logo