csh: calloc->malloc for new directory pointer

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

Re: inteldrm(4) tests needed

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.

move carp interface pointers from struct ifnet to struct arpcom

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 ---

Re: disabled code in ksh tree.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

Re: VMD: vioscsi refactor

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: VMD: vioscsi refactor

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

VMD: vioscsi refactor

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

inteldrm(4) tests needed

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

Re: merge vlan and carp input back into ether_input

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.

Re: stack pointer checking

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

Re: authpf: use monotime for duration log

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

ksh: unifdef HISTORY/EDIT

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 >>

Re: amd64 Intel cpu microcode

> 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.

Re: amd64 Intel cpu microcode

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.

Re: disabled code in ksh tree.c

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.

Re: disabled code in ksh tree.c

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 >

ksh: ulimit optstring

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

Re: ksh: remove BRACE_EXPAND

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

Re: Spectre defence for armv7

> 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