* The request_firmware() changes causing problems with make-kpkg
@ 2008-07-18 11:58 Theodore Tso
2008-07-18 12:42 ` Marcel Holtmann
2008-07-18 14:14 ` David Woodhouse
0 siblings, 2 replies; 4+ messages in thread
From: Theodore Tso @ 2008-07-18 11:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, sam
Using 2.6.26-git4 and -git6, and with CONFIG_FIRMWARE_IN_KERNEL=y,
make modules_install is calling firmware_install, which is dropping
files in /lib/firmware --- which make-kpkg is happily picking up and
including in the debian kernel package. Which was fine --- until I
tried to build and install kernel package for -git6, at which point I
got an error at install time because the second package was tying to
overwrite files installed by the first linux-image file. Doh!
Given that Ubuntu's firmware loader already tries to find firmware at
/lib/firmware/<kpkg> and only if that fails, to load it from
/lib/firmware, it seems like the obvious thing to do is to add a
quickie CONFIG option which changes the default setting of
INSTALL_FW_PATH in the top-level makefile from /lib/firwmare to
/lib/firmware/<kver>.
Maybe the userspace for other distributions won't support this, but
they can simply not use this CONFIG option for now; but it will solve
the problem for all Ubuntu, and possibly Debian, users who want to
build their own kernel using make-kpkg. If I cons a patch like this,
is there likely going to be any objections with it getting merged?
Regards,
- Ted
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The request_firmware() changes causing problems with make-kpkg
2008-07-18 11:58 The request_firmware() changes causing problems with make-kpkg Theodore Tso
@ 2008-07-18 12:42 ` Marcel Holtmann
2008-07-18 14:14 ` David Woodhouse
1 sibling, 0 replies; 4+ messages in thread
From: Marcel Holtmann @ 2008-07-18 12:42 UTC (permalink / raw)
To: Theodore Tso; +Cc: David Woodhouse, linux-kernel, sam
Hi Ted,
> Using 2.6.26-git4 and -git6, and with CONFIG_FIRMWARE_IN_KERNEL=y,
> make modules_install is calling firmware_install, which is dropping
> files in /lib/firmware --- which make-kpkg is happily picking up and
> including in the debian kernel package. Which was fine --- until I
> tried to build and install kernel package for -git6, at which point I
> got an error at install time because the second package was tying to
> overwrite files installed by the first linux-image file. Doh!
>
> Given that Ubuntu's firmware loader already tries to find firmware at
> /lib/firmware/<kpkg> and only if that fails, to load it from
> /lib/firmware, it seems like the obvious thing to do is to add a
> quickie CONFIG option which changes the default setting of
> INSTALL_FW_PATH in the top-level makefile from /lib/firwmare to
> /lib/firmware/<kver>.
>
> Maybe the userspace for other distributions won't support this, but
> they can simply not use this CONFIG option for now; but it will solve
> the problem for all Ubuntu, and possibly Debian, users who want to
> build their own kernel using make-kpkg. If I cons a patch like this,
> is there likely going to be any objections with it getting merged?
sounds like a good idea to me. I am going to prepare a patch for udev to
actually look at /lib/firmware/`uname -r`/ first to unify all the
distros again.
Regards
Marcel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The request_firmware() changes causing problems with make-kpkg
2008-07-18 11:58 The request_firmware() changes causing problems with make-kpkg Theodore Tso
2008-07-18 12:42 ` Marcel Holtmann
@ 2008-07-18 14:14 ` David Woodhouse
2008-07-18 15:21 ` Theodore Tso
1 sibling, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2008-07-18 14:14 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux-kernel, sam
On Fri, 2008-07-18 at 07:58 -0400, Theodore Tso wrote:
> Using 2.6.26-git4 and -git6, and with CONFIG_FIRMWARE_IN_KERNEL=y,
> make modules_install is calling firmware_install, which is dropping
> files in /lib/firmware --- which make-kpkg is happily picking up and
> including in the debian kernel package. Which was fine --- until I
> tried to build and install kernel package for -git6, at which point I
> got an error at install time because the second package was tying to
> overwrite files installed by the first linux-image file. Doh!
Fedora has already taken the other approach -- it uses 'make
firmware_install' to create a noarch package, and each binary package
depends on that. You can have multiple kernel binaries, but you only
need to have the latest firmware package. (Just like you only need one
kernel-headers package.)
The GPL zealots can now drop that firmware package from their build
(actually, to satisfy the hard dependency they probably need to build
their own replacement with only the one or two firmwares for which we
have source), and then they can sod off and stop bothering us.
I would be quite surprised if Debian didn't want to take this kind of
approach, in the fairly short term -- shipping the firmware in a
separate package.
> Given that Ubuntu's firmware loader already tries to find firmware at
> /lib/firmware/<kpkg> and only if that fails, to load it from
> /lib/firmware, it seems like the obvious thing to do is to add a
> quickie CONFIG option which changes the default setting of
> INSTALL_FW_PATH in the top-level makefile from /lib/firwmare to
> /lib/firmware/<kver>.
I assume those are actually the same -- <kpkg> vs. <kver>?
> Maybe the userspace for other distributions won't support this, but
> they can simply not use this CONFIG option for now; but it will solve
> the problem for all Ubuntu, and possibly Debian, users who want to
> build their own kernel using make-kpkg. If I cons a patch like this,
> is there likely going to be any objections with it getting merged?
Hm. The way we normally override such paths is with make variables.
If you really can't just fix make-kpkg to set INSTALL_FW_PATH when
installing modules, you could export MAKEFLAGS=INSTALL_FW_PATH=/foo
before invoking make-kpkg.
Your logic is that it's easier for you to update your config than to
override $(INSTALL_FW_PATH) by either method above?
It seems a little odd to me, but I suppose I don't have any particular
objection if that's _really_ the case. The makefiles are baroque enough
anyway; it would be churlish of me to object to a bit more complexity :)
Given that 'make firmware_install' is intended to work when there is
no .config, I would probably recommend making the new config option
affect only modules_install rather than also affecting firmware_install.
In general, I don't much like putting firmware in a kver-specific
directory. It _doesn't_ change from kernel to kernel, as a general rule
-- and on the rare occasions that it does change incompatibly from
kernel to kernel, we should be changing the filename anyway. But as a
short-term hack I certainly see the utility of it.
--
dwmw2
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The request_firmware() changes causing problems with make-kpkg
2008-07-18 14:14 ` David Woodhouse
@ 2008-07-18 15:21 ` Theodore Tso
0 siblings, 0 replies; 4+ messages in thread
From: Theodore Tso @ 2008-07-18 15:21 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, sam
On Fri, Jul 18, 2008 at 07:14:35AM -0700, David Woodhouse wrote:
> > Given that Ubuntu's firmware loader already tries to find firmware at
> > /lib/firmware/<kpkg> and only if that fails, to load it from
> > /lib/firmware, it seems like the obvious thing to do is to add a
> > quickie CONFIG option which changes the default setting of
> > INSTALL_FW_PATH in the top-level makefile from /lib/firwmare to
> > /lib/firmware/<kver>.
>
> I assume those are actually the same -- <kpkg> vs. <kver>?
Yes, sorry. I was typing too fast.
> Hm. The way we normally override such paths is with make variables.
>
> If you really can't just fix make-kpkg to set INSTALL_FW_PATH when
> installing modules, you could export MAKEFLAGS=INSTALL_FW_PATH=/foo
> before invoking make-kpkg.
>
> Your logic is that it's easier for you to update your config than to
> override $(INSTALL_FW_PATH) by either method above?
Well, make-kpkg is a little easier to follow and modify than say, Red
Hat's kernel-building rpm macros (a task which I wouldn't wish on my
worst enemy, having done it once in the RHEL4 era), but that's not
saying much. But *yes*, much easier to modify my config. :-)
- Ted
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-07-18 15:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-18 11:58 The request_firmware() changes causing problems with make-kpkg Theodore Tso
2008-07-18 12:42 ` Marcel Holtmann
2008-07-18 14:14 ` David Woodhouse
2008-07-18 15:21 ` Theodore Tso
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox