linux-kernel - Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN

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]

Message-Id: <1211792238.17151.46.camel@johannes.berg>
Date:	Mon, 26 May 2008 10:57:18 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
	aoliva@...hat.com, alan@...rguk.ukuu.org.uk,
	Abhay Salunke <Abhay_Salunke@...l.com>, kay.sievers@...y.org,
	Takashi Iwai <tiwai@...e.de>, Michael Buesch <mb@...sch.de>
Subject: Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

> >> Look at the device nodes. The kernel has mouse0 for example and udev
> >> will translate this into /dev/input/mouse0. Nobody expects the kernel
> >> to use input/mouse0 and actually you even can't do that at all since
> >> the device model forbids "/" as bus id. Same applies for the firmware
> >> filenames.
> >
> > No, it doesn't.
> 
> please enlighten me how you can use "/" within bus ids.

Please enlighten me why you need to use the firmware key in the bus ID.

> So you actually do know how request_firmware() actually works right  
> now? You need to change the firmware_class implementation and API to  
> give it an extra parameter to allow any kind if simultaneous loading  
> within one driver. 

Yeah, the API change required is internal and rather trivial.

> Having the FIRMWARE as environment variable is  
> actually suboptimal. 

Why? You still haven't given any reason for this.

> You want to have the FIRMWARE environment  
> variable as bus_id for the firmware struct device object.

Why?

The way I see it, there's nothing stopping you from creating firmware
"devices" using a simple increasing number as the bus_id, and having the
firmware key be presented in a 'FIRMWARE' property of those devices.
Then, the userspace loader realises such a device is created, looks at
the firmware property, takes the firmware, and stuffs it into the 'data'
property. It doesn't matter how many there are outstanding at the same
time because one userspace process is invoked per firmware device, hence
per ID.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)