--+xNpyl7Qekk2NvDX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 28, 2005 at 05:06:16PM +0200, Martin Husemann wrote:
>=20
> What I would do is:
>=20
>  - create two kernel functions fwdownload_register_hook and=20
>    fwdownload_remove_hook. Drivers register their download function
>    with this - passing the device name and a token (most cases: softc poi=
nter)
>  - create a /dev/fwdownload and a driver that only understands a very sim=
ple
>    ioctl (much like the isdn stuff)
>  - create a userland tool that loads a file, passes it via that ioctl thr=
ough
>    the above device to it's target device drivers fwdownload hook.
>    You would then call:
>=20
>       /usr/sbin/fwdownload ffb0 /usr/local/lib/afb.ucode
>=20
>    and the ffb driver gets it's hook function called with all the data fr=
om
>    the given file.

Why not just use the device? Define a standard ioctl that all=20
firmware-loading devices support and have one tool that will itteratively=
=20
upload.

My concern with a firmware device is that it adds complexity. =20
Downloading devices have to hook into and out of it. We already have a
node for the device, why not use it?

I expect that the ioctl structuring would be something like

	switch (cmd) {

	case DEV_LOAD_FIRMWARE:
		error =3D dev_load_firmware(data, flag,=20
				our_dev_fw_load_helper);

Thus each device just hooks into a common firmware helper.

While this is just a repackaging of what you propose, I think it's better=
=20
both because we don't add a device we can do without and because we keep=20
device naming out of the kernel. While the latter's a minor issue, it=20
means that the one place that does device name -> dev_t mapping is the=20
file system. Also, it means that we can choose, on a device-by-device=20
basis, to permit non-root users to upload firmware. Further, we can choose=
=20
which user(s) have this ability.

While I think requiring root for now is best, we could opt that some=20
devices only require write permission on the device. Then permissions on=20
the device control firmware access. Obviously we want to think something=20
like that through, but it could be very powerful and flexible.

As a total asside, I think it'd be better if the firmware upload call had=
=20
two forms. One would pass in a memory range, the other would just pass in=
=20
a file descriptor. Or maybe just pass it a file descriptor. The main=20
issue is that as Jachym Holecek noted, firmware images can get large.

> Note, however, that this is far more than I realy want to do for the ffb =
case.
> The current "afbinit" program is userspace only - it mmaps() a part of the
> ffb and does it's magic in userland. The idea to have the X server (since=
 it
> is the only application needing that firmware) handle it, sounds good too=
 -=20
> and as Antti noted is basically the same thing we do for isdn cards now.

I dislike the idea of the X server (or even isdnd) uploading firmware. I=20
see firmware uploading as an at-boot kind of thing to do, while I see X=20
sessions as potentially much more transient. The only reason I could see=20
to have the X server upload the firmware would be if different users could=
=20
get different firmware uploaded. However I think a cleaner fix to the=20
latter would be something like verifiedexec and a centralized firmware=20
uploader. At boot we sign potential firmware images, and we let the=20
individual user upload a special firmware if needed.=20

Take care,

Bill

--+xNpyl7Qekk2NvDX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCnQg8Wz+3JHUci9cRAhHwAJ40nmr37VxCDe44PmAubbE0vRruZwCeN2c8
n9/0FLppqOnVWOyeEZUbwSw=
=iKXu
-----END PGP SIGNATURE-----

--+xNpyl7Qekk2NvDX--