From: Sam Ravnborg <sam@ravnborg.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: David Woodhouse <dwmw2@infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Regression] Build failure in current mainline - firmware related
Date: Sat, 3 Jan 2009 23:14:55 +0100 [thread overview]
Message-ID: <20090103221455.GA8312@uranus.ravnborg.org> (raw)
In-Reply-To: <200901032243.28684.rjw@sisk.pl>
>
> 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
next prev parent reply other threads:[~2009-01-03 22:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-03 11:47 [Regression] Build failure in current mainline - firmware related Rafael J. Wysocki
2009-01-03 20:49 ` Sam Ravnborg
2009-01-03 20:54 ` Sam Ravnborg
2009-01-03 21:43 ` Rafael J. Wysocki
2009-01-03 22:14 ` Sam Ravnborg [this message]
2009-01-04 21:44 ` Sam Ravnborg
2009-01-04 22:43 ` Rafael J. Wysocki
2009-01-10 14:36 ` David Woodhouse
2009-01-10 14:58 ` David Woodhouse
2009-01-11 14:42 ` Mauro Carvalho Chehab
2009-01-11 15:01 ` David Woodhouse
2009-01-11 19:07 ` Rafael J. Wysocki
2009-01-08 7:59 ` Sam Ravnborg
2009-01-08 20:17 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090103221455.GA8312@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox