On Thu, Aug 22, 2019 at 04:30:37PM -0700, Scott Branden wrote:
On 2019-08-22 2:12 p.m., Luis Chamberlain wrote:BTW for some reason your mailer keeps adding new lines per each line. I
On Thu, Aug 22, 2019 at 01:07:41PM -0700, Scott Branden wrote:The change in the patch keeps the existing functionality in the
On 2019-08-22 12:47 p.m., Luis Chamberlain wrote:You mean in the near term future? Your change makes it use the full file.
This implies you having to change the other callers, and while currentlyYes, the list is small, very small.
our list of drivers is small,
There is a single driver making a call to the existing API.
And, the maintainer of that driver wanted
to start utilizing my enhanced API instead of the current API.
trim them below. Also for future emails please Cc:
Mimi Zohar <zohar@xxxxxxxxxxxxx>
As she'll be interested in some of this from the IMA security perspective.
qcom mdt_loader by reading the full file using the enhanced api.OK I see he did he liked the approach. OK thanks! This will make
I don't know when Bjorn will switch to use the partial firmware load:
evolutions much easier.
Yes its possible, but more on this below.We can kill the older api right now as my patch in qcom mdt_loaderAs such I think it is very reasonable to update the API right now.I'd prefer to see it separate, and we fix the race *before* we introduce
the new functionality. I'll be poking at that shortly but I should note
that I leave on vacation this weekend and won't be back for a good while.
I already have an idea of how to approach this.
When the current user want to use the new API it can do so, and then we
just kill the older caller.
calls the new API which allows reading of full or partial files?
Right, but in the new approach you'd use a newer function name withI have switched the single user of the existing api to the newIf the new user is going to move to the API once available I will befollowing the history of the firmware APII would prefer to rename the API at this time given there is only a single
and the long history of debate of *how* we should evolve its API, its
preferred we add yet another new caller for this functionality. So
please add a new caller, and use EXPORT_SYMBOL_GPL().
And while at it, pleaase use firmware_request_*() as the prefix, as we
have want to use that as the instilled prefix. We have yet to complete
the rename of the others older callers but its just a matter of time.
So something like: firmware_request_into_buf_offset()
Otherwise I would need to duplicate quite a bit in the test code to support
testing the single user of the old api and then enhanced API.
Or, I can leave existing API in place and change the test case to
just test the enhanced API to keep things simpler in the test code?
happy to then leave out testing for the older API. That would make
API in the patch already?
the new feature.
Sure, if you want me to remove the change to the existing qcom driver to keep using the old api as well I'll do so.
And both full and partial reads using the new API are tested with thisYes please.
patch series.Â If you really insist on keeping the old API for a
single user I can drop that change from the patch series and have the
old request_firmware_api call simply be a wrapper calling the new API.
Yes this makes sense. But I want to take a bit step back right now andBut if you do want to keep testing for the old API, and allow an easyWe can skip right now then.Â As enhanced API is a superset of old API.
removal for it on the test driver, wouldn't a function pointer suffice
for which API call to use based on a boolean?
But yeah if we're going to abandon the old mechanism I'm happy to skip
If you want the old API left in place I can just add the wrapper
described and only test the newly named function and thus indirectly
test the old request_firmware_into_buf.
think about this a bit more. I'm starting to wonder if this whole sysfs
stuff should be replaced with a better scalable scheme. Consider all the
fancy things you can do in userspace with a block device. Offsets are
already supported, and so much more.
So I'm starting to think that the
firmware fallback upload sysfs interface is much better suited as a
really simple block device long term.
I understand you want your solutions addressed upstream yesterday, but
this is the *sort of review* on architecture that should have been
done for the request_firmware_into_buf() long ago. But since you
probably don't want to wait for a revamp of the interface, a middle
ground might be in order for now, with the roadmap put in place to
evaluate scalable alternatives.
Either way, we should consider the current bug you ran into for the
solutions put forward, with the new functionality you are proposing.
The core of the issue you ran into was the duplicate named kobjects,
which are reflected also on the sysfs hierarchy. The directory name
created for each firmware request, when duplicate entries exist for
one device collide. Upon a secondary request for firmware using the
fallback interface, the kobject/directory already exists.
Its easier to understand this from a directory hierarchy perspective.
For instance the test driver uses:
The test script for the test_firmware driver uses:
To load firmware we use a directory underneath this firmware name for
the file name of the firmware requested, so to load firmware called
$name on the test script we use:
echo 1 >"$DIR"/"$name"/loading
cat "$file" >"$DIR"/"$name"/data
echo 0 >"$DIR"/"$name"/loading
An issue no one has cared for, and also we have not hit yet is that,
this implies no firmware names can be used which match other sysfs
attributes exported by a driver. I'm not too concerned for this right
now, but it is a worthy thing to consider long term under a new
So the issue is that the firmware loader will try to create two equally
named entries underneath the firmware loader directory. Yes we can
sledge hammer the API to act serially, but this is will just
just move one problem to another, your secondary call would have to
wait until the first one not only completes the call, but also
release_firmware() is called.
I'm looking at using a device name prefix if we do add a new API
or functionality. This way userspace can expend and knows what
extra tag to use other than the driver name.