Date: Sun, 16 Dec 2012 19:44:26 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r244287 - projects/calloutng/sys/x86/isa Message-ID: <50CE087A.2020200@FreeBSD.org> In-Reply-To: <CAJ-Vmok7rdooCifWmNw2LJ95BSuOwwz6wPeq86x8AcAp7FzuJw@mail.gmail.com> References: <201212161116.qBGBGEwn063983@svn.freebsd.org> <CAJ-VmonYuh4dTwY9PjBmE4uOq8nNAL_kDKXpi6knwvc99PqJcw@mail.gmail.com> <50CE009B.7010804@FreeBSD.org> <CAJ-Vmok7rdooCifWmNw2LJ95BSuOwwz6wPeq86x8AcAp7FzuJw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16.12.2012 19:18, Adrian Chadd wrote: > On 16 December 2012 09:10, Alexander Motin <mav@freebsd.org> wrote: > >> This change affects only one-shot operation mode of i8254 eventtimer, which >> we can't enable by default because it can't coexist with i8254 timecounter, >> which we can't disable by default because we can't be sure that there is any >> other timecounter. That is why I've written about fun. And no, I have no >> all possible weird i8254 clones to test, so any help and ideas are welcome. >> :) > > That's why I think you guys have to be very careful here. There's > still plenty of embedded x86 hardware out there which uses > not-quite-matching i8254 silicon implementations. > I realise it's not enabled by default, but by putting this code in > there, you risk having it eventually bubble up and become potentially > available/active on some quirky embedded platforms (or heck, > non-embedded platforms where for some reason the i8254 eventtimer is > active, but the timecounter isn't.) > > The point I'm trying to make here is that you guys shouldn't just > change things because you don't think that it'll not be used. You may > not think it's being used but the whole i386 space (embedded or > otherwise) is full of legacy (and non-legacy) hilarity. You should be > really careful that you don't break previous things which you just > don't have a chance in hell of being able to test thoroughly. > > We have 15 years of "mostly working" on a really really quirky > platform. You won't get that kind of testing again. > > I'm (kind of) sorry for being overly serious and ranty here - but this > is exactly the kind of thing that breaks hardware support in > unpredictable ways, making us all look bad. I understand your concerns, but we can't get somewhere without walking steps. As I've told, that feature is disabled by default, and even if it ever be possible, I will definitely think twice considering risks before enabling it. The only other thing I can tell into my defense is that I am running all this code on my personal laptop, several systems from different generations and classes on my lab table and some other nearby machines. That is not speaking about help from volunteers. If you know anything specific why or where that may cause problems, or which specific tests should I run, I will gladly accept your experience. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50CE087A.2020200>