linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1259537732.5231.11.camel@palomino.walls.org>
Date:	Sun, 29 Nov 2009 18:35:32 -0500
From:	Andy Walls <awalls@...ix.net>
To:	Ray Lee <ray-lk@...rabbit.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jon Smirl <jonsmirl@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	mchehab@...hat.com, stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> > This has zero advantages besides good developer feeling that "My system
> > has one less daemon..."
> 
> Surely it's clear that having an unnecessary daemon is introducing
> another point of failure?

A failure in a userspace IR daemon is worst case loss of IR
functionality.

A failure in kernel space can oops or panic the machine.

> Reducing complexity is not just its own
> reward in a 'Developer Feel Good' way.

No complexity is being reduced here.  It's being shoved from one side of
a fence to another.  A bad part about the proposed move is that in user
space, user address space is fairly isolated from other applications and
separate from kernel space.  Partitioning reduces complexity and the
impact of failures.  Moving things into kernel space just adds more to
the pile of code; it should have a good reason for being there.

> If decoding can *only* be sanely handled in user-space, that's one
> thing. If it can be handled in kernel, then that would be better.

Why does the address space in which decoding is performed make the
decoding process better or worse?  The in kernel infrastructre and
restrictions add constraints to a decoding implementation.  Userspace is
much more flexible.

Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/