[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140411130747.GR26358@brightrain.aerifal.cx>
Date: Fri, 11 Apr 2014 09:07:47 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Preparing for releases 1.1.0 and 1.0.1
On Fri, Apr 11, 2014 at 11:46:16AM +0200, Szabolcs Nagy wrote:
> > > * use 1/eps for rounding check (with *4 it's nicer, ymmv)
> >
> > Could you explain why? I would prefer a change that doesn't require so
> > many lines changed since they're all places errors could hide. Just
> > getting rid of the CONCAT hack seems preferable to me, but I don't
> > mind hearing the reason you like the *4.
>
> well integers are special (eg x87 has fld1) so a bit better code
> may be generated and they are more familiar
I see.
> another way to make the code better on some platforms is to use floats:
> (and help valgrind)
Yes but this leads to serious breakage if the compiler does not handle
the request to drop precision in a conforming way, and it still
doesn't help the fact that strtod depends on long double semantics.
> > > * only use nanosec for entropy
> >
> > I just worry on some archs with bad timer, this could prevent getting
> > sufficiently many temp names (of course the problem already existed).
> > Is there more non-valuable entropy we could merge into it? One idea
> > was the bytes of struct stat from stat() on /proc/self (this is like
> > using pid, but better). But perhaps there's more we could do with just
> > time.
>
> stat is ok
>
> if there are different clock sources then you can do more with time
> or if we assume the retries take non-predictable time (open syscall
> on a crowded /tmp) then that can be measured as well
>
> using the seconds may help a bit
>
> r = ts.tv_sec ^ ts.tv_nsec;
>
> (all the relevant 30bits of r are used so further mixing does not help)
This is probably a good mixing since the bits of the seconds that will
change "often" are overlaid with the bits of nsec that might be
missing, but it's probably insufficient if we only have microsecond
time values or worse.
The stat would give a good per-process source of bits, but doesn't
help if a single process needs lots of temp files. And I'm not sure
the double-call to gettime would help if nsec has poor resolution
since the delay between subsequent calls is likely to be on the scale
of ~1us.
Perhaps even with just usec resolution, we get enough names anyway.
I'm open to other ideas.
> > > * broken legacy header..
> > >
> > > diff --git a/include/sys/procfs.h b/include/sys/procfs.h
> > > index f7936c4..a1fcabf 100644
> > > --- a/include/sys/procfs.h
> > > +++ b/include/sys/procfs.h
> > > @@ -40,7 +40,7 @@ struct elf_prpsinfo
> > > char pr_zomb;
> > > char pr_nice;
> > > unsigned long int pr_flag;
> > > -#if UINTPTR_MAX == 0xffffffff
> > > +#if UINTPTR_MAX == 0xffffffff && !defined __powerpc__
> >
> > I'm ok with this hack I think.
>
> this is probably still broken on microblaze
>
> my guess is that nobody is actually using this header
IIRC gdb is but we should look this up. I have no problem removing it
if it's true that nothing is using it. Do we have history (e.g. on the
list) from when it was added motivating the addition?
> > > * linux 3.14 stuff
> > > (sched_setattr/sched_getattr syscall numbers, new sockopt flag, new arphdr type)
> >
> > This should probably be held until a later release. We need to
> > consider ABI issues. I believe we have sufficient room to put a union
> > (rather than the kernel's silly non-union approach) over top of our
> > schedparam struct and fit all the values needed without ABI breakage,
> > but this requires some code to convert to/from the kernel format.
>
> well the kernel did not export any definition for the syscalls
> and the sched_attr struct so far, only the syscall numbers
>
> i'm not sure if that was intentional, but currently they cannot
> be used reasonably from userspace
OK, then adding just the syscall numbers is no problem.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
