Re: Class device namespaces

[Michael Brown <mebrown@michaels-house.net>]

On Wed, Apr 29, 2009 at 5:30 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> Overall, the interface is pretty pathetic because it doesnt fit our
>> use case *at all*, but way back in the day that is what we had to do
>> to get it reviewed and approved for merge upstream. At least it is
>> better than the earlier versions where we had to do a separate
>> request_firmware() for every 4k packet (and spin waiting for files to
>> disappear/reappear)
>
> It handles huge files just fine, since the beginning. The space is
> realloced in the kernel. I have a modem which loads 200kb files since
> years.

Sorry, to be brief in my email I probably didnt give quite enough
info. There are two types of bios update: monolithic and packetized.
The monolithic mode requires *physically* contiguous memory below the
4GB boundary, usually 1MB worth. This is unbelievably hard to get
normally, and is almost definitely different from your modem upload
which almost certainly just needs a virtually contiguous 200kB.
Packetized mode lifts the physically-contiguous restriction and just
has to have page-aligned packets.

>
>> All this code is in libsmbios(*) if you want to see the ugly details,
>> but the short version is this:
>>
>> 1) we poke the image_type file and packet_size files with appropriate
>> data, which causes the driver to do a request firmware
>> 2) spin until request_firmware creates the files we need
>
> This is totally insane!

Yes, that was the point. :)

>
>> 2) loop over our file packet_size bytes at a time writing data into
>> the data file
>> 3) set loading to 0 when done
>>
>> *) src/python/libsmbios_c/rbu_update.py
>>
>> The code basically "packetizes" the bios update into page-sized chunks
>> with a header so BIOS can find them and reassemble them for the final
>> update.
>>
>> For older systems (monolithic mode), the kernel code has to allocate
>> physically contiguous region to hold the entire firmware image.
>
> Yeah, maybe you can not use the in-kernel firmware-request filled
> memory. But you can copy it just fine, once it is in the kernel. There
> is no reason to fiddle around with chunks here in userspace.

Pretty much describes exactly what dell_rbu does, except that the
in-kernel packetizing code was rejected on our first submission, so we
moved it into userspace.

> How do you make sure udev does not handle the request at the same
> time? This interface is not public at all, on a general system. As
> long as udev is active you can not use it at all. Udev will run at the
> same time and write to the same files, and even cancel the request if
> the requested file is not found. How does your software cope with
> that?

That is a very interesting question, as I've never seen udev do
anything to interfere with our process. We dont do anything special to
disable udev. Like I said above, we scribble some values to one file,
wait for the request_firmware() files to appear and write stuff to
them when they do. Udev hasnt ever tried to handle this that I have
seen, especially since we dont have any appropriate files sitting
around that udev would ever have access to in order to feed
request_firmware().
--
Michael