> Added a -T option to ktrace for transparency. I got ambitious here and made
> it take suboptions, anticipating that other transparency modifications may
> be desired.
Please don't do that.
First off, I see no future in the open/openat idea. Not just pledge,
not just unveil, not just reduction
> Call getenv before issetugid.
Why??
issetugid is a syscall (yes, it has overhead) which (amongst other things)
whether you can trust the environment.
But getenv -- that's a call which trusts enough of the environment array's
structure, to do a walk, and find. Why do the walk, at all, if you
On 2020-07-09, Theo de Raadt wrote:
> Hang on. Do people ever want to force time calls, outside of ktrace?
> I doubt it. Should ktrace maybe have a flag, similar to -B with LD_BIND_NOW,
> which sets the new environment variable? Maybe -T? The problem smells very
> similar to the root cause for
this diff is about fixing some semantic issues with the current
interface input handler list processing. i was a bit worried it would
cause a small performance hit, but it seems it has the opposite effect
and is actually slightly faster. so in my opinion it is more correct,
but also improves
> On 10 Jul 2020, at 12:45 am, sven falempin wrote:
>
> On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote:
>>
>> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
>>> if i accidentally `ifconfig bridge add gre0` instead of egre0, having
>>> bridge create gre0 and then not like
Hi,
I have been running -current on my laptop the last couple of weeks and
after watching some videos I realized that audio playback is gone after
I suspended my laptop.
Reading through the code I arrived at this solution to restore audio
playback after suspend.
The patch has been tested on
Thanks. The Intel NVM update on that link is the one I mentioned that
says not to use it on OEM cards, this is in the readme
"This package is intended to be used on Intel branded adapters. Please contact
your OEM vendor for an appropriate package. In some cases this package may
update an OEM
Hi Stuart,
Just a suggestion
but I have had a difficult time with xl710s Last summer and my vendor
advised me to upgrade the firmware on the cards
if you upgrade
The firmware can be downloaded from here:
https://downloadcenter.intel.com/product/93104/Intel-Ethernet-Controller-XL710-BM1
(check the
Hi Mark,
Mark Kettenis wrote on Thu, Jul 09, 2020 at 07:59:25PM +0200:
> Ingo Schwrze wrote:
>> Now that i look at that, and at what you said previously, is it even
>> plausible that some user ever wants "-t c" ktracing but does
>> specifically *not* want to see clock_gettime(2) and friends?
> Date: Thu, 9 Jul 2020 19:43:52 +0200
> From: Ingo Schwarze
>
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> > Ingo Schwarze wrote:
>
> >> So, what about
> >> LD_KTRACE_GETTIME
> >> or a similar environment variable name?
>
> > That naming seems logical.
>
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> > Ingo Schwarze wrote:
>
> >> So, what about
> >> LD_KTRACE_GETTIME
> >> or a similar environment variable name?
>
> > That naming seems logical.
> >
> > If it is mostly hidden behind a
Hi Theo,
Theo de Raadt wrote on Thu, Jul 09, 2020 at 11:08:38AM -0600:
> Ingo Schwarze wrote:
>> So, what about
>> LD_KTRACE_GETTIME
>> or a similar environment variable name?
> That naming seems logical.
>
> If it is mostly hidden behind a ktrace flag (-T ?) then I think
> we're in good
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600:
>
> > This time, they become invisible.
> [...]
> > There are many circumstances where ltrace is not suitable.
> [...]
> > We fiddle with programs all the time, to inspect them.
>
> Fair enough,
Ingo Schwarze wrote:
> Hi Theo,
>
> Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600:
>
> > This time, they become invisible.
> [...]
> > There are many circumstances where ltrace is not suitable.
> [...]
> > We fiddle with programs all the time, to inspect them.
>
> Fair enough,
Hi Theo,
Theo de Raadt wrote on Thu, Jul 09, 2020 at 09:47:26AM -0600:
> This time, they become invisible.
[...]
> There are many circumstances where ltrace is not suitable.
[...]
> We fiddle with programs all the time, to inspect them.
Fair enough, then.
The following variables already exist
I just purchased a Dell Latitude 7300 which I ordered with a Dell
DW5821e Snapdragon X20 LTE device. Attached is a patch to add it to
usbdevs. I am working on getting it to work with umb(4) but this is a
needed step as I understand it. Also attached is my usbdevs output for
this device. Thank you.
On Thu, Jul 09, 2020 at 10:35:46AM +0200, Mark Kettenis wrote:
>
> Here is the arm64 version. Again I've taken the approach of copying
> the kernel timecounter code verbatim. Technically we don't need the
> Cortex-A73 errata workaround here since the timecounter only uses the
> low 32 bits.
David Gwynne wrote:
> so the problem is the older api doenst support the "get phy types"
> command, or the sff commands. should we silence the "get phy types"
> error output? is there a better errno to use when the sff command
> isn't supported? should we add something to the manpage? should
Ingo Schwarze wrote:
> Hi,
>
> i wonder whether there is a layering violation going on here.
>
> From the user perspective, whether an API call is a syscall or a
> mere library function doesn't make any difference, it's an
> implementation detail.
>From the developer's perspective it is a
Hi,
i wonder whether there is a layering violation going on here.
>From the user perspective, whether an API call is a syscall or a
mere library function doesn't make any difference, it's an
implementation detail. API calls have often moved from being library
functions to syscall and vice
Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Thu, 09 Jul 2020 11:07:02 -0400
> >
> > On 2020-07-08, Mark Kettenis wrote:
> > > > From: "Ted Unangst"
> > > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > > >
> > > > On 2020-07-08, Ted Unangst wrote:
> > > > > I think this makes
> From: "Theo de Raadt"
> Date: Thu, 09 Jul 2020 09:13:24 -0600
>
> Ted Unangst wrote:
>
> > On 2020-07-08, Theo de Raadt wrote:
> > > I think we need something like this.
> > >
> > > Documenting it will be a challenge.
> > >
> > > I really don't like the name as is too generic, when the
> From: "Ted Unangst"
> Date: Thu, 09 Jul 2020 11:07:02 -0400
>
> On 2020-07-08, Mark Kettenis wrote:
> > > From: "Ted Unangst"
> > > Date: Wed, 08 Jul 2020 05:20:23 -0400
> > >
> > > On 2020-07-08, Ted Unangst wrote:
> > > > I think this makes sem_init(pshared) work.
> > >
> > > Whoops, need
Ted Unangst wrote:
> On 2020-07-08, Theo de Raadt wrote:
> > I think we need something like this.
> >
> > Documenting it will be a challenge.
> >
> > I really don't like the name as is too generic, when the control is only
> > for a narrow set of "current time" system calls.
>
> I thought I'd
On 2020-07-08, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Wed, 08 Jul 2020 05:20:23 -0400
> >
> > On 2020-07-08, Ted Unangst wrote:
> > > I think this makes sem_init(pshared) work.
> >
> > Whoops, need more context to include the header file changes.
>
> It is a bit of a pity that
On 2020-07-08, Theo de Raadt wrote:
> I think we need something like this.
>
> Documenting it will be a challenge.
>
> I really don't like the name as is too generic, when the control is only
> for a narrow set of "current time" system calls.
I thought I'd start with something, but lots of
On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote:
>
> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
> > if i accidentally `ifconfig bridge add gre0` instead of egre0, having
> > bridge create gre0 and then not like it is not what i expect to happen.
> > especially when it leaves
On 2020/07/09 22:57, David Gwynne wrote:
> ok.
>
> so the problem is the older api doenst support the "get phy types" command,
> or the sff commands.
yes, looks like it.
> should we silence the "get phy types" error output?
I think that makes sense.
> is there a better errno to use when the
ok.
so the problem is the older api doenst support the "get phy types" command, or
the sff commands. should we silence the "get phy types" error output? is there
a better errno to use when the sff command isn't supported? should we add
something to the manpage? should that something be "i'm
Update on this: Silicom support responded promptly, asked sensible
questions, didn't immediately bail on the fact that I'm not running a
supported OS, and prepared an update (to run under Linux but the
Debian live image worked fine for this).
ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev
On 09.07.2020 11:35, Mark Kettenis wrote:
Here is the arm64 version. Again I've taken the approach of copying
the kernel timecounter code verbatim. Technically we don't need the
Cortex-A73 errata workaround here since the timecounter only uses the
low 32 bits. But that is true for the kernel
Here is the arm64 version. Again I've taken the approach of copying
the kernel timecounter code verbatim. Technically we don't need the
Cortex-A73 errata workaround here since the timecounter only uses the
low 32 bits. But that is true for the kernel as well! If people
think it is worth
On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
> if i accidentally `ifconfig bridge add gre0` instead of egre0, having
> bridge create gre0 and then not like it is not what i expect to happen.
> especially when it leaves me with an extra gre0 interface lying around
> afterwards.
>
if i accidentally `ifconfig bridge add gre0` instead of egre0, having
bridge create gre0 and then not like it is not what i expect to happen.
especially when it leaves me with an extra gre0 interface lying around
afterwards.
i can appreciate that this was trying to be helpful when you wanted
to
the code pretty obviously assumes that it only handles Ethernet packets,
so we should restrict it to IF_ETHER type interfaces.
ok?
Index: if_switch.c
===
RCS file: /cvs/src/sys/net/if_switch.c,v
retrieving revision 1.30
diff -u -p
On Wed, Jul 8, 2020 at 8:06 AM Theo de Raadt wrote:
> Mark Kettenis wrote:
>
> > > From: "Theo de Raadt"
> > > Date: Wed, 08 Jul 2020 09:42:41 -0600
> > >
> > > I think we need something like this.
> > >
> > > Documenting it will be a challenge.
> > >
> > > I really don't like the name as is
36 matches
Mail list logo
