On Fri, Jul 31, 2020 at 10:25:48PM +0200, Martin Pieuchot wrote:
> On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote:
> > [...]
> > What denies us to move pipex(4) under it's own lock?
>
> Such question won't lead us anywhere. It assumes it makes sense to move
> pipex under its own lock. This ass
On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote:
> [...]
> What denies us to move pipex(4) under it's own lock?
Such question won't lead us anywhere. It assumes it makes sense to move
pipex under its own lock. This assumption has many drawback which clearly
haven't been studied and more importa
Well, since pipexintr() killing was rejected, I propose to implement
reference counters to protect pipex(4) session itself. Diff below does
this.
Index: sys/net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving
On Fri, Jul 31, 2020 at 08:26:22PM +0200, Martin Pieuchot wrote:
> On 31/07/20(Fri) 12:15, Vitaliy Makkoveev wrote:
> > On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote:
> > > On Thu, 30 Jul 2020 22:43:10 +0300
> > > Vitaliy Makkoveev wrote:
> > > > On Thu, Jul 30, 2020 at 10:05:13
On 31/07/20(Fri) 12:15, Vitaliy Makkoveev wrote:
> On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote:
> > On Thu, 30 Jul 2020 22:43:10 +0300
> > Vitaliy Makkoveev wrote:
> > > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote:
> > >> On Thu, 30 Jul 2020 15:34:09 +0300
When playing around with uvideo(4) devices I'm quite regular hitting
the error message in the subject when closing the device. The problem
seems to be some false return code ordering in xhci_device_isoc_start():
if (sc->sc_bus.dying || xp->halted)
return (USBD_IOERROR);
/* Why would you
On 31/07/20(Fri) 11:22, Marcus Glocker wrote:
> Maybe I'm missing something here.
You aren't. Historically usbd_close_pipe() wasn't aborting transfers.
We changed it to do so as it happened to be the easiest fix to some
issues that had been copy/pasted.
It's just that nobody took the time to do
As a general rule, pledge uses isn't supposed to make programs
more complicated.
Stuart Henderson wrote:
> On 2020/07/31 00:07, tempmai...@firemail.cc wrote:
> > I have to say I'm only a beginner to C but hopefully my patch is
> > good.
> >
> > This patch adds a second and more restrictive pled
On Fri, 31 Jul 2020 11:59:45 +0200
Gerhard Roth wrote:
> Hi Marcus,
>
> On 2020-07-31 11:22, Marcus Glocker wrote:
> > Maybe I'm missing something here.
> >
> > But is there any specific reason why the most of our USB drivers are
> > calling usbd_abort_pipe() right before usbd_close_pipe()? Si
Hi Marcus,
On 2020-07-31 11:22, Marcus Glocker wrote:
Maybe I'm missing something here.
But is there any specific reason why the most of our USB drivers are
calling usbd_abort_pipe() right before usbd_close_pipe()? Since
usbd_close_pipe() already will call usbd_abort_pipe() if the pipe isn't
e
Maybe I'm missing something here.
But is there any specific reason why the most of our USB drivers are
calling usbd_abort_pipe() right before usbd_close_pipe()? Since
usbd_close_pipe() already will call usbd_abort_pipe() if the pipe isn't
empty, as documented in the man page:
DESCRIPTION
Th
On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote:
> On Thu, 30 Jul 2020 22:43:10 +0300
> Vitaliy Makkoveev wrote:
> > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote:
> >> On Thu, 30 Jul 2020 15:34:09 +0300
> >> Vitaliy Makkoveev wrote:
> >> > On Thu, Jul 30, 2020
On 2020/07/31 00:07, tempmai...@firemail.cc wrote:
> I have to say I'm only a beginner to C but hopefully my patch is
> good.
>
> This patch adds a second and more restrictive pledge (only "stdio"
> instead of "stdio rpath") after the getopt loop if there is no
> input file or if the input file is
This diff is to be applied on top of my other diff on tech@ with subject
"ifconfig: merge switch_status() into bridge_status()".
It hooks completes the output of tpmr intefaces in what I think is the
simplest and least intrusive way.
tpmr is a trivial bridge and has no specific ioctls, so to dist
14 matches
Mail list logo