linux-kernel - Re: [PATCH 01/18] Altera FPGA firmware download module.

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]

Date:	Fri, 07 Jan 2011 14:31:48 -0500
From:	Ben Gamari <bgamari.foss@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	"Igor M. Liplianin" <liplianin@...by>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, aospan@...up.ru
Subject: Re: [PATCH 01/18] Altera FPGA firmware download module.

Hi Mauro,

On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
> Em 31-12-2010 09:30, Laurent Pinchart escreveu:
> > Hi Mauro,
> > 
> > [snip]
> > 
> > I understand this. However, a complete JTAG state machine in the kernel, plus 
> > an Altera firmware parser, seems to be a lot of code that could live in 
> > userspace.
> 
> Moving it to userspace would mean a kernel driver that would depend on an
> userspace daemon^Wfirmware loader to work. I would NAK such designs.
> 
> The way it is is fine from my POV.

Any furthur comment on this? As I noted, I strongly disagree and would
point out that there is no shortage of precedent for the use of
userspace callbacks for loading of firmware, especially when the process
is as tricky as this.

I also work with Altera FPGAs and have a strong interest in making this
work yet from my perspective it seems pretty clear that the best way
forward both for both maintainability and useability is to keep
this code in user-space. There is absolutely no reason why this code
_must_ be in the kernel and punting it out to userspace only requires
a udev rule.

Placing this functionality in userspace results in a massive duplication
of code, as there are already a number of functional user-space JTAG
implementations.

> > If I understand it correctly the driver assumes the firmware is in an Altera 
> > proprietary format. If we really want JTAG code in the kernel we should at 
> > least split the file parser and the TAP access code.
> > 
> 
> Agreed, but I don't think this would be a good reason to block the code merge
> for .38.
> 
Sure, but there should be agreement that a kernel-mode JTAG state
machine really is the best way forward (i.e. necessary for effective
firmware upload) before we commit to carry this code around forever.

- Ben
--
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/