On Sun, Jan 04, 2015 at 08:37:24PM +0000, Pavel Machek wrote:
> On Sun 2015-01-04 15:25:02, Nicolas Pitre wrote:
> > On Sun, 4 Jan 2015, Pavel Machek wrote:
> >
> > > On Sun 2015-01-04 15:03:02, Nicolas Pitre wrote:
> > > > If that is still unacceptable to you for whatever reason, then the
> > > > least
> > > > wrong compromize should be:
> > > >
> > > > seq_printf(m, "BogoMIPS\t: 1.00\n");
> > > >
> > > > That'D allow for those broken applications to run while making clear
> > > > that the provided value is phony. I was about to suggest 0.00 but that
> > > > could trigger a divide by zero error somewhere I suppose.
> > >
> > > I don't know what 1.00 will cause, and neither do you, so what about
> > > simply reverting the bad patch?
> >
> > Because the patch wasn't "bad". It did solve a recurring support
> > problem where people did actually complain on the list because the value
> > was not what they would have liked. Removing this meaningless value did
> > actually fix that support issue as no more complaints came through for
> > the last 1.3 year, and is actually the only way for user space to be
> > fixed too.
>
> People complain on the list, so what? People complain about systemd,
> too. We ignore them.
>
> Alternatively, just don't touch the bogomips computation. It is not
> that much of maintainance burden. You can probably also get away with
> replacing bogomips with actual cpu frequency.
>
> Replacing it with 1 is asking for trouble.
Peversely, I think that '1.00' would be the correct value for your libjack
case!
I had a quick look at the code, and it seems to be used to construct a
microsecond-precision timeline for things like:
ctl->signalled_at = jack_get_microseconds();
Now, jack_get_microseconds() is:
static inline jack_time_t
jack_get_microseconds (void)
{
return _jack_get_microseconds ();
}
_jack_get_microseconds is a pointer that points to this guy:
jack_time_t
jack_get_microseconds_from_cycles (void) {
return get_cycles() / __jack_cpu_mhz;
}
where __jack_cpu_mhz is the bogomips read once from /proc/cpuinfo and
get_cycles (on ARM) is this gem:
static inline cycles_t get_cycles(void)
{
struct timeval tv;
gettimeofday (&tv, NULL);
return ((cycles_t) tv.tv_sec * 1000000) + tv.tv_usec;
}
The return value from jack_get_microseconds gets used interchangeably with
real usecond values to do things like find the audio frame at Nus into a
stream, so I don't really see how any of this can work. In this case, we
just need *a* bogomips value to stop the initialisation from failing, then
hope that pyaudio decides not to use jack after all (it falls back to some
alsa thing on my machine)
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
