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, 31 Dec 2010 10:04:13 -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.

On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab <mchehab@...radead.org> wrote:
> > 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.
> 
Why? I agree that JTAG is a lot to place in the kernel and is much
better suited to be in user space. What exactly is your objection to
depending on a userspace utility? There is no shortage of precedent for
loading firmware in userspace (e.g. fx2 usb devices).

> > 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.
> 
I agree with the above isn't good reason to block it but if there is
still debate about the general architecture of the code (see above),
then it seems aren't ready yet. The code looks very nice, but I'm not at
all convinced that it needs to be in the kernel. Just my two-tenths of a
cent.

Cheers,
- 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/