On Wed, Jul 08, 2020 at 09:09:53AM -0600, Theo de Raadt wrote:
> Scott Cheloha <scottchel...@gmail.com> 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 it be a layer violation to
> > put, e.g.
> >
> > uint64_t
> > rd_systick(void)
> > {
> > uint64_t val;
> >
> > __asm volatile("rd %%sys_tick, %0" : "=r" (val));
> >
> > return val;
> > }
> >
> > into something like sys/arch/sparc64/include/cpufunc.h and use it
> > in both the kernel and libc?
>
> I don't see anything which precludes libc doing __asm calls, itself,
> and I don't think we need to use cpp or inline declarations to cheat.
> It is not impossible for userland and kernel use of such "macros" to
> change, and would it be OK for libc to "abi change" (note little abi)
> because an include file changed? I don't think that's nice.
>
> > In general isn't it nicer to write it once?
>
> In general yes. But in the specific, I don't think so.
>
> > We could do the same thing on other platforms too for select
> > instructions that are useful in both libc and the kernel.
>
> Until the general rule breaks down, in a variety of ways. At which
> point, why replace a simple thing with a spread out abstraction?
>
> It is already impossible for the abstraction to MI and invisible, it
> must be MD (because some architectures have more than 1 counter to look
> at)
Makes sense, nevermind.
