So here is a diff that cleans things up and implements sparc64
support. Showing both together since some of the amd64 changes were
inspired by the sparc64 code.
* TC_LAST can be removed; it really doesn't serve any purpose
* the functions in usertc.c need to be static to avoid namespace
poll
On 2020-07-07 23:49, Christian Weisgerber wrote:
Userland gettime support for alpha.
Alas, completely untested since I don't have access to that arch.
Never had an alpha. Reads OK to me (if you make the function static like
kettenis@ said).
Index: lib/libc/arch/alpha/gen/usertc.c
On 2020-06-26 06:22, George Koehler wrote:
On Mon, 22 Jun 2020 19:12:22 +0300
Paul Irofti wrote:
New iteration:
- ps_timekeep should not coredump, pointed by deraadt@
- set ps_timekeep to 0 before user uvm_map for randomization
- map timekeep before fixup. confirmed by naddy@ that it
On 2020-07-08 01:09, Theo de Raadt wrote:
The /sys/arch/powerpc/include/timetc.h in your diff never gets used,
because there is no #include . On macppc,
I am fixing this issue for all the architectures, just being careful
by doing builds first.
Thank you for handling this.
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.
Index: include/semaphore.h
===
RCS file: /home/cvs/src/include/semaphore.h,v
retrieving revi
I think this makes sem_init(pshared) work.
I have a test program from Lauri Tirkkonen and if I've understood it
correctly, it works now.
The essence of the diff is that we must eliminate the indirection so that
the application can properly allocate (mmap) the semaphore into shared memory.
There's
Hi tech@,
I created a new size for Spleen, to bridge the gap between the 5x8 and
the 8x16 versions. The idea is to have something more readable than the
5x8 version while still being small enough to be usable on OLED displays.
Similar to "Spleen 5x8" it only contains the printable ASCII character
On 07/07/20(Tue) 11:13, Martin wrote:
> Hi tech@,
>
> Not so long ago I've ported UHD driver to support Ettus USRP devices which
> uses libusb and asynchronous USB3 data transfers.
> Is USB3 async. data stack implemented or planned to have some devices like
> USRP working?
I'm not aware of anyo
Gracious ping for these patches.
сб, 27 июн. 2020 г. в 20:14, Dmitry Baryshkov :
>
> Allow users to specify new curves via strings.
>
> Sponsored by ROSA Linux
>
> Signed-off-by: Dmitry Baryshkov
> ---
> src/lib/libcrypto/gost/gostr341001_params.c | 10 ++
> 1 file changed, 10 insertions
сб, 27 июн. 2020 г. в 22:37, Dmitry Baryshkov :
>
> 64-bit ciphers are old, but it would be good to use common code for
> their implementations.
Gracious ping for this patchset.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> src/lib/libcrypto/modes/cbc64.c | 202
>
> From: Paul Irofti
> Date: Wed, 8 Jul 2020 12:05:04 +0300
>
> On 2020-06-26 06:22, George Koehler wrote:
> > On Mon, 22 Jun 2020 19:12:22 +0300
> > Paul Irofti wrote:
> >
> >> New iteration:
> >>
> >>- ps_timekeep should not coredump, pointed by deraadt@
> >>- set ps_timekeep to 0 befo
`pppx_devs_lk' used to protect `pxd_entry' list. We lock `pppx_devs_lk'
in pppx_if_output() to be sure `pxd' is not destroyed by concurrent
pppxclose() but it's useless. We destroy all corresponding `pxi' before
`pxd' and `ifnet's are already detached.
Index: sys/net/if_pppx.c
Not sure how useful this will be, but I think it could be helpful to still
see section (2) functions in ktrace, even if there's magic to avoid that.
As proof of concept, if env LIBC_NOSYSWRAPPERS is set, the libc timecounters
are turned off. Now I see lots of gettimeofday syscalls in ktrace again.
Paul Irofti:
> > Userland gettime support for alpha.
> > Alas, completely untested since I don't have access to that arch.
>
> Never had an alpha. Reads OK to me (if you make the function static like
> kettenis@ said).
For the archives, here's a version that looks like kettenis@'s
style.
Unfort
On 2020-06-26, George Koehler wrote:
> Here's macppc again. My macppc isn't using your newest diff but does
> now need to define TC_TB in .
Crucial question: How confident are we that TB is in sync on
multiprocessor machines?
--
Christian "naddy" Weisgerber na...@mips
On Wed, Jul 08, 2020 at 01:35:30AM +0200, Mark Kettenis wrote:
> > Date: Tue, 7 Jul 2020 23:46:00 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Tue, 7 Jul 2020 23:13:06 +0200
> > > From: Christian Weisgerber
> > >
> > > Mark Kettenis:
> > >
> > > > > --- lib/libc/arch/alpha/gen/usertc.c
Scott Cheloha wrote:
> > - __asm volatile("rd %%sys_tick, %0" : "=r" (tick) :);
> > + __asm volatile("rd %%sys_tick, %0" : "=r" (tick));
> >
> > return (tick & ~0u);
> > }
>
> The only thing that gives me pause is the inline assembly.
>
> I know it isn't a lot of assembly, but would
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
A few small test program
Christian Weisgerber wrote:
> On 2020-06-26, George Koehler wrote:
>
> > Here's macppc again. My macppc isn't using your newest diff but does
> > now need to define TC_TB in .
>
> Crucial question: How confident are we that TB is in sync on
> multiprocessor machines?
Ugly test program (not s
On Wed, Jul 08, 2020 at 09:09:53AM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > > - __asm volatile("rd %%sys_tick, %0" : "=r" (tick) :);
> > > + __asm volatile("rd %%sys_tick, %0" : "=r" (tick));
> > >
> > > return (tick & ~0u);
> > > }
> >
> > The only thing that gives me pause
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.
Ted Unangst wrote:
> Not sure how useful this will be, but I think it could be helpful to still
> s
Hi tech@,
Here is a diff to enable spleen16x32 and spleen32x64 on armv7 for
GENERIC kernels, like on arm64.
I'm using the 16x32 version on my Cubieboard2.
I'm not sure if any armv7 devices we support is actually capable
of driving a 4K screen, so the 32x64 version might not be useful.
If this is
> 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 too generic, when the control is only
> for a narrow set of "current time" system calls.
I'm not sure we shoul
> Date: Wed, 8 Jul 2020 18:02:06 +0200
> From: Frederic Cambus
>
> Hi tech@,
>
> Here is a diff to enable spleen16x32 and spleen32x64 on armv7 for
> GENERIC kernels, like on arm64.
>
> I'm using the 16x32 version on my Cubieboard2.
>
> I'm not sure if any armv7 devices we support is actually c
On Wed, Jul 08, 2020 at 09:36:03AM -0600, Theo de Raadt wrote:
> Christian Weisgerber wrote:
>
> > On 2020-06-26, George Koehler wrote:
> >
> > > Here's macppc again. My macppc isn't using your newest diff but does
> > > now need to define TC_TB in .
> >
> > Crucial question: How confident ar
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 too generic, when the control is only
> > for a narrow set of "current t
> 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 we have to expose the internals here, but I
don't see a
On Wed, Jul 08 2020 19:19:38 +0200, Mark Kettenis wrote:
> This will require a libpthread major bump, and those are really
> painful! So I'm not sure we should do this just for pshared
> semaphores which hardly anybody uses.
FWIW, I have an implementation of a jobserver for make(1) that uses
psha
On Wed, Jul 08, 2020 at 12:19:35PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> I created a new size for Spleen, to bridge the gap between the 5x8 and
> the 8x16 versions. The idea is to have something more readable than the
> 5x8 version while still being small enough to be usable on OLED displa
Where is the original email that you replied too? The subject interests me but
I don't see Ted's original email.
I don't see the original mail here either. Is it me or Ted, or a forward from a
private conversation? Anyway, I am OK with this and Robert had a similar diff
two months ago when this started. Just make sure this is off by default for
both type of binaries.
Paul
În 8 iulie 2020 18:42:41 EEST,
Ted's new experimental mailer is incompatible with the real world.
I have some ixl cards which show "unable to query phy types" at
attach time, and return either EIO or ENODEV if I try fetching sff
pages.
I booted with SFP+ in all ixl ports and have this:
ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 5.0.40043
API 1.5, msix, 4 queues, add
On Wed, 08 Jul 2020 23:14:17 +0300, Paul Irofti wrote:
> I don't see the original mail here either. Is it me or Ted, or a forward from
> a private conversation? Anyway, I am OK with this and Robert had a similar d
> iff two months ago when this started. Just make sure this is off by default f
> o
On 6/28/20 11:15 PM, Jason McIntyre wrote:
On Sat, Jun 27, 2020 at 11:56:49AM -0700, jungle boogie wrote:
Hi Friends,
Here's a small patch to the OpenBSD.calendar. I didn't want to spend too
much time on this until I find out if it would be accepted.
morning.
i think if such a file is worth
Hi,
the following is the execution of an idea brought up by deraadt@.
There are four problems with the printf(3) manual page:
1. While some modifiers (like "argno$" and "width") do the same
for all conversion specifiers, the effects of some other
modifiers varies wildly. For example, "
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 to
37 matches
Mail list logo
