Hello All. Since we can include firmware for different devices into Fedora, can we include win32-binaries for use together with Wine, DOS executables for dosbox, jars for use with Java stacks , etc (if will be confirmed that they works).
Reading guidelines about firmware and emulators I don't understand whether its prohibited or not.
On Mon, 2007-10-22 at 11:34 +0400, Peter Lemenkov wrote:
Hello All. Since we can include firmware for different devices into Fedora, can we include win32-binaries for use together with Wine, DOS executables for dosbox, jars for use with Java stacks , etc (if will be confirmed that they works).
If you have the source for them and they're under a free licence, then sure. Otherwise, no.
This is not the same thing as a firmware, because firmware doesn't execute on the host CPU. Practically speaking, that's where we draw the line.
- ajax
Adam Jackson wrote:
This is not the same thing as a firmware, because firmware doesn't execute on the host CPU. Practically speaking, that's where we draw the line.
This is not meant as a facetious question but how does this pan out with regards to emulators? Most of which require some sort of firmware which runs on the 'virtual' CPU which is technically speaking running on the real CPU, perhaps even more so in cases where JIT compilation is used. I suppose it boils down to an accepted Fedora definition of firmware.
Yo,
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
Jon.
Jon Masters wrote:
Yo,
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates,
+1
It is also useful as there is interest in creating a spin with no firmware that is not under a Free software license.
Rahul
On Mon, 22 Oct 2007 10:06:24 -0400 Jon Masters jcm@redhat.com wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
These wouldn't turn into kmod like packages would they, and have all the same kludges to work with RPM? Are you going to have to handle different firmware sets for each kernel version you might have installed, plus alternatives from upstream? Obviously I'm a bit reluctant to reintroduce nightmares like this.
On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
On Mon, 22 Oct 2007 10:06:24 -0400 Jon Masters jcm@redhat.com wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
These wouldn't turn into kmod like packages would they, and have all the same kludges to work with RPM? Are you going to have to handle different firmware sets for each kernel version you might have installed, plus alternatives from upstream? Obviously I'm a bit reluctant to reintroduce nightmares like this.
The problem is if a user needs to upgrade the firmware for some card, they can't do this if the file for that firmware lives inside the kernel package (well, they can abuse the breakage in RPM for multilib and possibly get away with another package owning the file, but...). If we're interested in allowing firmware upgrades to happen outside of the kernel (which is one reason it split out upstream), then this is needed.
Would love to hear comments ;-)
Jon.
On Mon, 22 Oct 2007 10:33:26 -0400 Jon Masters jcm@redhat.com wrote:
Would love to hear comments ;-)
Figure out a way to do it that doesn't re-introduce the nastyness that was kernel module packages.
You know, if we didn't allow for parallel kernel installs this wouldn't be a problem (:
On Mon, 2007-10-22 at 10:33 -0400, Jon Masters wrote:
On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
On Mon, 22 Oct 2007 10:06:24 -0400 Jon Masters jcm@redhat.com wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
These wouldn't turn into kmod like packages would they, and have all the same kludges to work with RPM? Are you going to have to handle different firmware sets for each kernel version you might have installed, plus alternatives from upstream? Obviously I'm a bit reluctant to reintroduce nightmares like this.
The problem is if a user needs to upgrade the firmware for some card, they can't do this if the file for that firmware lives inside the kernel package (well, they can abuse the breakage in RPM for multilib and possibly get away with another package owning the file, but...). If we're interested in allowing firmware upgrades to happen outside of the kernel (which is one reason it split out upstream), then this is needed.
Would love to hear comments ;-)
Is it frequently the case that firmware upgrades do not require driver updates as well in order to function? Many wireless issues seem to revolve around the fact that firmware and drivers that are out of sync just don't work. If firmware is split out, how will such dependencies be managed?
Jon.
On Mon, 2007-10-22 at 10:33 -0400, Jon Masters wrote:
On Mon, 2007-10-22 at 10:20 -0400, Jesse Keating wrote:
On Mon, 22 Oct 2007 10:06:24 -0400 Jon Masters jcm@redhat.com wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
These wouldn't turn into kmod like packages would they, and have all the same kludges to work with RPM? Are you going to have to handle different firmware sets for each kernel version you might have installed, plus alternatives from upstream? Obviously I'm a bit reluctant to reintroduce nightmares like this.
The problem is if a user needs to upgrade the firmware for some card, they can't do this if the file for that firmware lives inside the kernel package (well, they can abuse the breakage in RPM for multilib and possibly get away with another package owning the file, but...). If we're interested in allowing firmware upgrades to happen outside of the kernel (which is one reason it split out upstream), then this is needed.
Would love to hear comments ;-)
99% of the time, the driver and firmware[1] are closely knit. Try upgrade the firmware of a QLogic card without the driver following, and watch bad things happen.
I'm sure there are exceptions, which should be dealt with, but sometimes there are reasons why this is the case. I also seem to remember similar issues with cciss controllers which would lead to corruption with a driver/firmware mismatch.
[1]: when the firmware is shipped as part of the driver
On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
This is fine (well, not for F8 obviously, but we can make it okay for F9), with a few caveats: 1) The module *MUST* have the needed firmware tagged appropriately so that we can figure out what firmware to pull into initrds, the installer, etc 2) We should probably follow the path being blazed with wireless firmware where we include the multiple, incompatible firmware versions in one package. Otherwise, the fact that multiple kernels can be installed leads to a a bit of a quagmire 3) Care needs to be taken so that upgrades will work correctly once the firmware has moved. A requires is one answer, and maybe the best, but there definitely needs to be some thought
Jeremy
Jeremy Katz wrote:
On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
This is fine (well, not for F8 obviously, but we can make it okay for F9), with a few caveats:
- The module *MUST* have the needed firmware tagged appropriately so
that we can figure out what firmware to pull into initrds, the installer, etc 2) We should probably follow the path being blazed with wireless firmware where we include the multiple, incompatible firmware versions in one package. Otherwise, the fact that multiple kernels can be installed leads to a a bit of a quagmire 3) Care needs to be taken so that upgrades will work correctly once the firmware has moved. A requires is one answer, and maybe the best, but there definitely needs to be some thought
4) This effort must be done upstream using the current standard kernel firmware mechanisms and then trickle down into Fedora from upstream. I can already hear Dave J. screaming in the night if we are going to carry Fedora specific kernel patches for this.
Regards,
Hans
On Mon, 2007-10-22 at 16:49 +0200, Hans de Goede wrote:
Jeremy Katz wrote:
On Mon, 2007-10-22 at 10:06 -0400, Jon Masters wrote:
On a tangent, I would like to have a discussion about in-kernel firmware as it becomes split out and loaded using request_firmware. So that third parties can supply different firmware updates, can we agree that it's worthwhile having one firmware package for each firmware file set needed by the kernel package, in the longer term?
This is fine (well, not for F8 obviously, but we can make it okay for F9), with a few caveats:
- The module *MUST* have the needed firmware tagged appropriately so
that we can figure out what firmware to pull into initrds, the installer, etc 2) We should probably follow the path being blazed with wireless firmware where we include the multiple, incompatible firmware versions in one package. Otherwise, the fact that multiple kernels can be installed leads to a a bit of a quagmire 3) Care needs to be taken so that upgrades will work correctly once the firmware has moved. A requires is one answer, and maybe the best, but there definitely needs to be some thought
- This effort must be done upstream using the current standard kernel firmware mechanisms and then trickle down into Fedora from upstream. I can already hear Dave J. screaming in the night if we are going to carry Fedora specific kernel patches for this.
*grin* I just thought that was a given :-)
Jeremy