Prev: [PATCH v3 0/3] MAX8998 changes for RTC
Next: [PATCH v3 3/3] rtc: Add MAX8998 rtc driver
From: Linus Torvalds on 5 Aug 2010 22:30
On Thu, Aug 5, 2010 at 7:23 PM, David Howells <dhowells(a)redhat.com> wrote:
>
> I wonder if tty_init() should be moved up, perhaps to immediately after
> chrdev_init().

I do think that sounds sane. The tty layer is kind of special.

I wouldn't call it _after_ chrdev_init(), though, I'd call it _from_
chrdev_init(). Doesn't that make more sense (and keep it out of
fs/dcache.c, which is an odd place to have some tty init).

But maybe there's some reason why it's an initcall. Unlikely.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 6 Aug 2010 00:30
On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu <herbert(a)gondor.hengli.com.au> wrote:
>
> Because it can save data. �Each cryptographic algorithm (such as
> AES) may have multiple impelmentations, some of which are hardware-
> based.

Umm. The _developer_ had better test the thing. That is absolutely
_zero_ excuse for then forcing every boot for every poor user to re-do
the test over and over again.

Guys, this comes up every single time: you as a developer may think
that your code is really important, but get over yourself already.
It's not so important that everybody must be forced to do it.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kyle Moffett on 6 Aug 2010 01:00
On Fri, Aug 6, 2010 at 00:20, Linus Torvalds
<torvalds(a)linux-foundation.org> wrote:
> On Thu, Aug 5, 2010 at 7:35 PM, Herbert Xu <herbert(a)gondor.hengli.com.au> wrote:
>> Because it can save data.  Each cryptographic algorithm (such as
>> AES) may have multiple impelmentations, some of which are hardware-
>> based.
>
> Umm. The _developer_ had better test the thing. That is absolutely
> _zero_ excuse for then forcing every boot for every poor user to re-do
> the test over and over again.
>
> Guys, this comes up every single time: you as a developer may think
> that your code is really important, but get over yourself already.
> It's not so important that everybody must be forced to do it.

Speaking as a user whose been bitten several times by bad crypto
implementations, I'd personally rather have this testing on by default
(if the crypto API it depends on is on). It's pretty damn inexpensive
to do a few brief crypto operations during initialization as a quick
smoke test. We already do something somewhat similar when loading the
RAID5/RAID6 driver, although admittedly that's a speed-test for
picking an optimized algorithm.

You should also realize that crypto drivers are very much *NOT* in the
same situation as most other drivers. Without this test, adding a new
crypto hardware driver to the kernel is a completely unsafe operation,
because it could completely break users setups. You have previously
said you're fine accepting new drivers even after the initial merge
window because they can't break anything, but in crypto that's not
true.

I've actually had it trigger in exactly the described situation. I
had a box with an encrypted filesystem that I downloaded a new distro
kernel on with new drivers. The new kernel included a bunch of new
"EXPERIMENTAL" drivers for hardware, none of which I thought I cared
about until I noticed in "dmesg" that one of them was getting enabled
and then failing tests.

So there are unique and compelling reasons for default-enabled basic
smoke tests of cryptographic support during boot. To be honest, the
test and integration engineer in me would like it if there were more
intensive in-kernel POST tests that could be enabled by a kernel
parameter or something for high-reliability embedded devices.

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 6 Aug 2010 11:30
On Fri, Aug 6, 2010 at 1:06 AM, Olivier Galibert <galibert(a)pobox.com> wrote:
>
> Maybe Linus would be happier if the self-tests were limited (by
> default) to the hardware accelerators? �Having a software backup and
> the risk of data loss indeed makes things different.

No. I'd be happier if it was an OPTION.

And it damn well defaults to "off". Like all other options.

Then, for people who use it, and worry (and distro test kernels etc),
turn it on. But don't make it a forced feature, and don't make it
something that people think they _should_ turn on.

I have crypto enabled, but I don't _use_ it. The upside for me is
zero. Nil. Nada. And I bet that's the common case.

And dammit, it you don't trust the hardware, don't send the driver
upstreams. And if you worry about alpha-particles, you should run a
RAM test on every boot. But don't ask _me_ to run one.

It's that simple.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH v3 0/3] MAX8998 changes for RTC
Next: [PATCH v3 3/3] rtc: Add MAX8998 rtc driver