linux-kernel - Re: [Regression] Build failure in current mainline

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090103221455.GA8312@uranus.ravnborg.org>
Date:	Sat, 3 Jan 2009 23:14:55 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Regression] Build failure in current mainline - firmware related

> 
> Well, in the meantime I ran 'make modules_install V=1' and this is the
> last thing printed (the previous ones are not really interesting):
> 
> make -f /home/rafael/src/linux-2.6/scripts/Makefile.fwinst obj=firmware __fw_modinst
>   gcc -Wp,-MD,firmware/.ihex2fw.d -Ifirmware -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o firmware/ihex2fw /home/rafael/src/linux-2.6/firmware/ihex2fw.c
> /home/rafael/src/linux-2.6/firmware/ihex2fw.c:268: fatal error: opening dependency file firmware/.ihex2fw.d: Read-only file system
> compilation terminated.
> make[3]: *** [firmware/ihex2fw] Error 1
> make[2]: *** [_modinst_post] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
> 
> It fails because of the attempt to compile ihex2fw .

I recall we had this bug in previous kernel too.
But it seems noone cared to fix it.

Looking at all this firmware stuff makes me sad.

We have a nice distributed way to keep all our
drivers and suddenly all the firmware are stored in
a central place.
So adding a driver requiores changes to a central file,
and moreso adding a file in a central place far far away from
the driver itself.

I recall a long long thread about this that I never even looked at.
[I commented on an early version of the implementation but never
looked at it seriously despite being copied on stuff].

What we should have done:
1) all firmware files should be stored with their drivers
so firmare are kept logically in the same place as the source.

2) we should add firmware information using config options
rather than a long list in a centeal file.

config MY_DRIVER_FIRMWARE
	string
	depends on MY_DRIVER
	default "drivers/my/driver.bin"

or something similar.

Then we could post process autoconf.h to have all relevant
information I think.

This is far away from solving this regression - just my
initial braindump seeing the implementation of
the firmware stuff.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/