We destroy pppx(4) related sessions while we performing PIPEXDSESSION
command. But with pppac(4) we set session's state to
PIPEX_STATE_CLOSE_WAIT2 and we wait garbage collector to do destruction.
We removed `pipex{in,out}q'. So we can safe destroy session in any time.
I propose to make pppac(4)
On Tue, Aug 11, 2020 at 05:46:05PM -0500, Abel Abraham Camarillo Ojeda wrote:
> Hi to all,
>
> (unsure if this if for tech@ or misc@)
>
> I'm using wireguard interfaces but I see that no matter what
> domain I put the interface:
>
> # ifconfig wg0 rdomain X
>
> It always listens in rdomain 0
Updated to the recent source. The diff is OK'ed by yasuoka@. Also I did
what mpi@ requested. Should I still wait?
Index: sys/net/if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.100
diff -u -p -r1.100
On Wed, Aug 12, 2020 at 11:17:29AM +0900, YASUOKA Masahiko wrote:
> On Tue, 11 Aug 2020 23:06:45 +0300
> Vitaliy Makkoveev wrote:
> > We removed `pipex{in,out}q'. So now we can destroy pppac(4) session just
> > like we do in pppx(4) case. Also there is no reason to allow
> > pipex_timer() to
On 8/2/20 9:34 AM, Aisha Tammy wrote:
> On 7/26/20 5:25 PM, Aisha Tammy wrote:
>> On 7/26/20 5:21 PM, Aisha Tammy wrote:
>>> Hi,
>>> Am reviving an old thread from
>>> https://marc.info/?l=openbsd-tech=152663835315469=4
>>> (i did cc reyk@ sorry if it is noise)
>>>
>>> For some reason seems
On Tue, Aug 11, 2020 at 10:22:51PM -0400, Aisha Tammy wrote:
> Another bump.
I think this is useful and am ok with this.
Are there any concerns? If not, I'm going to commit it tomorrow.
Index: etc/examples/ldapd.conf
===
RCS file:
Hi,
On Wed, 12 Aug 2020 12:38:39 +0300
Vitaliy Makkoveev wrote:
> We don't need to mark pppx(4) sessions because there is no special cases
> for them. We just need to kill pppx(4) related "pr_timeout_sec != 0"
> checks and call pipex_get_closed() by pppx_get_closed().
How do you implement that
On Wed, Aug 12, 2020 at 09:07:15PM +0900, YASUOKA Masahiko wrote:
> Hi,
>
> On Wed, 12 Aug 2020 12:38:39 +0300
> Vitaliy Makkoveev wrote:
> > We don't need to mark pppx(4) sessions because there is no special cases
> > for them. We just need to kill pppx(4) related "pr_timeout_sec != 0"
> >
Hi,
On Wed, 12 Aug 2020 09:00:18 +0200
Theo Buehler wrote:
> On Tue, Aug 11, 2020 at 10:22:51PM -0400, Aisha Tammy wrote:
> > Another bump.
>
> I think this is useful and am ok with this.
>
> Are there any concerns? If not, I'm going to commit it tomorrow.
for an sshPublicKey attribute,
Hi,
Things in getitimer(2) and setitimer(2) have been rearranged
adequately. Their critical sections are ready to be combined.
Merging these critical sections is necessary to make getitimer(2) and
setitimer(2) MP-safe. They are not ready to run without the kernel
lock just yet, but this diff
This diff lays the groundwork for HS200 mode for eMMC. This mode
supports data transfer modes of up to 200 MB/s. The crucial bit here
is that using this mode requires tuning which is done by calling a
chip-specific execute_tuning function. I have an implementation for
amlmmc(4) that seems to
11 matches
Mail list logo
