Hello,
A fresh new 'struct directory' is allocated at three points in dir.c.
This struct has four members: di_name, di_count, di_next and di_prev.
For each instance all struct members are initialised immediately after
the calloc(), so the new memory doesn't need to be cleared first.
- Michael
I
On Mon, Jan 15, 2018 at 01:02:58AM +0100, Mark Kettenis wrote:
> The diff below adopts more of the Linux code to manage i2c
> transactions on hardware supported by inteldrm(4). The i2c stuff is
> reponsible for detecting panels and monitors, so it is somewhat
> important that this works right. An
both ethernet and carp interfaces use arpcom, so we can put the pointers
there instead of wasting space in struct ifnet.
ok?
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.538
diff -u -p -r1.538 if.c
---
On Sun, Jan 14, 2018 at 05:47:43PM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Jan 14 2018, Anton Lindqvist wrote:
> > On Thu, Jan 11, 2018 at 03:25:15PM +0800, Michael W. Bombardieri wrote:
> >> Hello,
> >>
> >> Revision 1.9 of tree.c (from 1999) added the disabled code and it
> >> is still
On Sun, Jan 14, 2018 at 06:08:05PM -0800, Mike Larkin wrote:
> On Sun, Jan 14, 2018 at 05:15:54PM -0800, Carlos Cardenas wrote:
> > Howdy.
> >
> > Attached is a patch that refactors the vioscsi driver (in particular,
> > the vioscsi_notifyq function).
> >
> > Each opcode is now handled in it's re
On Sun, Jan 14, 2018 at 05:15:54PM -0800, Carlos Cardenas wrote:
> Howdy.
>
> Attached is a patch that refactors the vioscsi driver (in particular,
> the vioscsi_notifyq function).
>
> Each opcode is now handled in it's respective function
> (vioscsi_handle_xxx). Which means, it's now easier to
Howdy.
Attached is a patch that refactors the vioscsi driver (in particular,
the vioscsi_notifyq function).
Each opcode is now handled in it's respective function
(vioscsi_handle_xxx). Which means, it's now easier to add more opcodes
and functionality to the driver. (Like supporting the new SeaB
The diff below adopts more of the Linux code to manage i2c
transactions on hardware supported by inteldrm(4). The i2c stuff is
reponsible for detecting panels and monitors, so it is somewhat
important that this works right. And the Linux code developed some
quirks over the years that my rewrite o
On 01/11/18 14:51, Martin Pieuchot wrote:
On 11/01/18(Thu) 21:59, David Gwynne wrote:
[...]
when you say i break carp balancing, are you talking about the removal of the
PACKET_TAG_CARP_BAL_IP tagging? PACKET_TAG_CARP_BAL_IP is only used in
carp_lsdrop to clear the M_MCAST flag on the mbuf. M_
Hi,
On Thu, Jan 11, 2018 at 08:39:25PM -0700, Theo de Raadt wrote:
> I'm asking for some feedback to discover what ports this breaks, we'd
> like to know. Those would be ports which try to (unconvenionally)
> create their stacks in malloc()'d memory or inside another
> datastructure. Most of the
On Sat, Jan 06 2018, Scott Cheloha wrote:
> Hey,
>
> Use monotime here so the correct session duration is logged even
> in the event of a clock jump.
>
> While here, I think it's a good idea to cast time_t to the widest
> practical integer type when printing it to minimize the likelihood
> of trun
On Sun, Jan 14 2018, Jeremie Courreges-Anglas wrote:
> On Sat, Jan 13 2018, Anton Lindqvist wrote:
>> Hi,
>> Looks like all variants of ksh in the tree is compiled with BRACE_EXPAND
>> defined, therefore remove it. No binary change. While here, fix an endif
>> typo.
>>
>> Comments? OK?
>
> ok jca
> Does microcode updated that way is being erased after each reboot?
Yes, it is lost.
Kernel installs new firmware onto the cpu at every boot.
When you update your BIOS, it works the same way.
Does microcode updated that way is being
erased after each reboot?
From: "Theo de Raadt"
To: tech@openbsd.org;
Date: 1:09 Niedziela 2018-01-14
Subject: amd64 Intel cpu microcode
> Patrick and others commited amd64 Intel cpu microcode update code
> over the last few days. The approach isn't per
On Sun, Jan 14 2018, Anton Lindqvist wrote:
> On Thu, Jan 11, 2018 at 03:25:15PM +0800, Michael W. Bombardieri wrote:
>> Hello,
>>
>> Revision 1.9 of tree.c (from 1999) added the disabled code and it
>> is still disabled. Would it be better to remove it?
>
> Fine with me. Anyone else willing OK?
On Thu, Jan 11, 2018 at 03:25:15PM +0800, Michael W. Bombardieri wrote:
> Hello,
>
> Revision 1.9 of tree.c (from 1999) added the disabled code and it
> is still disabled. Would it be better to remove it?
Fine with me. Anyone else willing OK?
> - Michael
>
>
> Index: tree.c
> =
Hi,
Stop constructing the optstring passed to ksh_getopt() for ulimit at
runtime. While here remove ifdef RLIMIT_VMEM block since it's not
defined.
Comments? OK?
Index: c_ulimit.c
===
RCS file: /cvs/src/bin/ksh/c_ulimit.c,v
retrievin
On Sat, Jan 13 2018, Anton Lindqvist wrote:
> Hi,
> Looks like all variants of ksh in the tree is compiled with BRACE_EXPAND
> defined, therefore remove it. No binary change. While here, fix an endif
> typo.
>
> Comments? OK?
ok jca@
I have a diff to remove EDIT and HISTORY too.
--
jca | PGP :
> Date: Sat, 13 Jan 2018 23:08:55 +
> From: Dimitris Papastamos
>
> > + case CPU_ID_CORTEX_A15:
> > + case CPU_ID_CORTEX_A57:
> > + case CPU_ID_CORTEX_A72:
> > + /*
> > +* Vulnerable; BPIALL is "not effective" so must use
> > +* ICIALLU and hope the fir
19 matches
Mail list logo