lkml.org 
[lkml]   [2011]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [REVIEW] NVM Express driver
> And non-automated loading of firmware as well.  Dell uses this for
> updating their BIOSes just fine, with a userspace tool that initiates
> the loading of the firmware.

Try using the Dell tool with namespaces.

> How does Dell do it?

How do most other apps do it.

> So, what could be changed in the current firmware interface to fix this
> problem in a manner which would solve these perceived issues?

I'm not sure it can. The basis of the interface is driver requests
firmware. That is done by using a pathname which in a namespaced
environment isn't global and has races

(Several things break quite spectacularly if you request_firmware while
updating a package, but of course nobody considered such details even for
automatic stuff in many cases. Really there is some locking needed).

For manual updating of a block of firmware the interface most stuff wants
is

copy_from_user()

or if you wanted to wrap it up nicely

x = vmalloc_from_user(void __user *ptr, ssize_t len);

The app knows which firmware it is talking about and can inspect and
compare it while holding an open file handle on the deivce. That protects
against hotplug races and getting the wrong device second access, and
ensures that the firmware, device and userspace are all talking about
exactly the same thing.

It would nice to say "its an obscure corner case that will just error",
but far too much hardware still gets semi permanently (or permanently)
converted into junk if you goof a permanent flash firmware update.



\
 
 \ /
  Last update: 2011-03-06 12:29    [W:0.096 / U:4.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site