FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-23-2008, 07:49 PM
Alan Cox
 
Default Plan for tomorrows (20080522) FESCO meeting

On Fri, May 23, 2008 at 08:44:17AM +0100, David Woodhouse wrote:
> > No it isn't. See "mere aggregation"
>
> That's a very optimistic interpretation of 'mere aggregation', given
> that the licence is very clearly stating that it applies not only to
> derivative works but also to collective works.

I think the lawyers probably have more idea than you.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-23-2008, 11:27 PM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 23, 2008, Les Mikesell <lesmikesell@gmail.com> wrote:

> Alexandre Oliva wrote:
>>
>> Any reason to not have moved it to the firmware/ dir, as I expected
>> from looking at your patches?
>>
>> rm -rf firmware/ is so much simpler :-)

> For your purpose, wouldn't you want to separate
> source-available-firmware and documentation-available bit settings
> from the parts that would be more difficult for you to modify freely?

For my purpose, yes, removing firmware that is Free would be
unnecessary. But if it can be packaged separately and there are
advantages to it, why take the technically inferior course of action?

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member °Sť Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-24-2008, 09:51 AM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote:
> Understood.
>
> I see one of your patches simply renames a .h to a .c and makes the
> blob a built-in firmware.
>
> Any reason to not have moved it to the firmware/ dir, as I expected
> from looking at your patches?

I considered it, but I figured it was better to do things one step at a
a time. I was probably wrong though; I'll take another look.

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-24-2008, 10:57 AM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote:
> I see one of your patches simply renames a .h to a .c and makes the
> blob a built-in firmware.
>
> Any reason to not have moved it to the firmware/ dir, as I expected
> from looking at your patches?

This attempts it, on top of the current git tree. Doesn't work with O=
build though, because it doesn't create the firmware/korg/ directory:

Real life calls...

index f6b0c3c..f9d7f17 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -2,9 +2,12 @@
# kbuild file for firmware/
#

+firmware-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg/k1212
+
firmware_bins := $(subst ",,$(CONFIG_BUILTIN_FIRMWARE))
-firmware_objs := $(patsubst %,%.o, $(firmware_bins))
-firmware_srcs := $(patsubst %,$(obj)/%.c, $(firmware_bins))
+firmware_srcs_generated := $(patsubst %,$(obj)/%.c, $(firmware_bins))
+firmware_objs := $(patsubst %,%.o, $(firmware_bins) $(firmware-y))
+firmware_dirs := $(dir $(firmware_objs))


quiet_cmd_fwbin = MK_FW $@
@@ -21,4 +24,4 @@ $(firmware_srcs): $(obj)/%.c: $(srctree)/$(obj)/%

obj-y := $(firmware_objs)

-targets := $(firmware_objs)
+targets := $(firmware_objs) $(firmware_srcs_generated)
diff --git a/sound/pci/korg1212/korg1212-firmware.c b/firmware/korg/k1212.c
similarity index 100%
rename from sound/pci/korg1212/korg1212-firmware.c
rename to firmware/korg/k1212.c
diff --git a/sound/pci/korg1212/Makefile b/sound/pci/korg1212/Makefile
index 7a5ebdf..f11ce1b 100644
--- a/sound/pci/korg1212/Makefile
+++ b/sound/pci/korg1212/Makefile
@@ -7,4 +7,3 @@ snd-korg1212-objs := korg1212.o

# Toplevel Module Dependency
obj-$(CONFIG_SND_KORG1212) += snd-korg1212.o
-obj-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg1212-firmware.o


--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-24-2008, 11:37 AM
Alexandre Oliva
 
Default Plan for tomorrows (20080522) FESCO meeting

On May 23, 2008, Alan Cox <alan@redhat.com> wrote:

> On Fri, May 23, 2008 at 08:44:17AM +0100, David Woodhouse wrote:
>> > No it isn't. See "mere aggregation"
>>
>> That's a very optimistic interpretation of 'mere aggregation', given
>> that the licence is very clearly stating that it applies not only to
>> derivative works but also to collective works.

> I think the lawyers probably have more idea than you.

Although I'm pretty sure they'd have a hard time making this case once
they saw something like this: http://lkml.org/lkml/2007/9/18/277

Their opinions may very well be more informed, but until a court
decides on the matter, they're just as right or wrong as ours. It's
not too hard to find a lawyer that will tell you what you want to
hear. It's like going to doctors until you find one that says you're
not going to die soon, and then become convinced this one is right and
all the others were wrong in their diagnostic :-)

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member °Sť Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-24-2008, 02:39 PM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Sat, 2008-05-24 at 11:57 +0100, David Woodhouse wrote:
> This attempts it, on top of the current git tree. Doesn't work with O=
> build though, because it doesn't create the firmware/korg/ directory:

This works, but why in hell do I need the FORCE on the rule for
$(firmware_dirs)? Without it, the directory (in the object dir,
obviously) never gets created.

Sam, any ideas?

commit e5d131e78c4da8e3579aba0d7f533018bd801fdf
Author: David Woodhouse <dwmw2@infradead.org>
Date: Sat May 24 11:56:32 2008 +0100

test
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/firmware/Makefile b/firmware/Makefile
index f6b0c3c..8ce2b81 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -2,10 +2,15 @@
# kbuild file for firmware/
#

+firmware-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg/k1212
+
firmware_bins := $(subst ",,$(CONFIG_BUILTIN_FIRMWARE))
-firmware_objs := $(patsubst %,%.o, $(firmware_bins))
-firmware_srcs := $(patsubst %,$(obj)/%.c, $(firmware_bins))
+firmware_srcs_generated := $(patsubst %,$(obj)/%.c, $(firmware_bins))
+firmware_objs := $(patsubst %,%.o, $(firmware_bins) $(firmware-y))
+firmware_dirs := $(patsubst %,$(obj)/%,$(dir $(firmware_objs)))

+quiet_cmd_mkdir = MKDIR $@
+ cmd_mkdir = mkdir -p $@

quiet_cmd_fwbin = MK_FW $@
cmd_fwbin = echo '/* File automatically generated */' > $@ ;
@@ -16,9 +21,15 @@ quiet_cmd_fwbin = MK_FW $@
echo '};' >> $@ ;
echo 'DECLARE_BUILTIN_FIRMWARE("$(patsubst firmware/%.c,%,$@)",fw);' >> $@

-$(firmware_srcs): $(obj)/%.c: $(srctree)/$(obj)/%
+$(firmware_srcs_generated): $(obj)/%.c: $(srctree)/$(obj)/%
+ echo dirs :$(firmware_dirs)
$(call cmd,fwbin)

+$(firmware_dirs): FORCE
+ $(call cmd,mkdir)
+
+$(patsubst %,$(obj)/%,$(firmware_objs)): $(firmware_dirs)
+
obj-y := $(firmware_objs)

-targets := $(firmware_objs)
+targets := $(firmware_objs) $(firmware_srcs_generated)
diff --git a/sound/pci/korg1212/korg1212-firmware.c b/firmware/korg/k1212.c
similarity index 100%
rename from sound/pci/korg1212/korg1212-firmware.c
rename to firmware/korg/k1212.c
diff --git a/sound/pci/korg1212/Makefile b/sound/pci/korg1212/Makefile
index 7a5ebdf..f11ce1b 100644
--- a/sound/pci/korg1212/Makefile
+++ b/sound/pci/korg1212/Makefile
@@ -7,4 +7,3 @@ snd-korg1212-objs := korg1212.o

# Toplevel Module Dependency
obj-$(CONFIG_SND_KORG1212) += snd-korg1212.o
-obj-$(CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL) += korg1212-firmware.o

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-25-2008, 05:50 PM
David Woodhouse
 
Default Plan for tomorrows (20080522) FESCO meeting

On Fri, 2008-05-23 at 16:00 -0300, Alexandre Oliva wrote:
> Understood.
>
> I see one of your patches simply renames a .h to a .c and makes the
> blob a built-in firmware.
>
> Any reason to not have moved it to the firmware/ dir, as I expected
> from looking at your patches?

OK, this is now done, posted to lkml and in the git tree. You (or your
minions) can now set about converting all the existing users of 'blobs'
to use request_firmware() for them, as I've demonstrated for the
korg1212 driver. I can give accounts on git.infradead.org for people to
put up git trees.

Would be good if someone would do the ACPI 'Custom DSDT' support too...

--
dwmw2

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-27-2008, 07:01 PM
Peter Jones
 
Default Plan for tomorrows (20080522) FESCO meeting

David Woodhouse wrote:


What I'd do is augment the kernel's firmware class support so that users
can build firmware blobs into their kernel to be accessed through the
firmware class. So the ifdefs in the above code go away -- the user can
just choose to include the blobs in the kernel build or not, as they see
fit, and the driver just invokes the firmware loader and doesn't
actually _care_ whether the firmware comes from within the kernel or
from userspace.


(Having not read the follow-ups on the list yet...)

This is the right track, but if anybody goes down this route, please,
please organize it this way:


1) make the firwmare class support caching of firmware images (which
also means supporting manual expiry of them at runtime...)
2) give the firmware class an interface to "push" an image which has not
been requested. That is, preloading the cache.
3) make an initcall that runs before almost all of drivers/ which loads
all built-in firmware images.


This solves the "built-in modules using request_firmware don't work"
problem, but still allows us to e.g. update built-in firmware images at
runtime to support debugging builds, new features, blatantly violating
the "can not modify" license sections in the comfort of our own homes, etc.


--
Peter

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-27-2008, 07:20 PM
Peter Jones
 
Default Plan for tomorrows (20080522) FESCO meeting

Alexandre Oliva wrote:

On May 21, 2008, Josh Boyer <jwboyer@gmail.com> wrote:


So work with upstream to get them removed or pushed to separate
firmware packages.


It's been tried before. I gather upstream is not interested in
achieving a 100% Free Software kernel tarball. It's in conflict with
our stated mission. Where do we go from that point, when upstream is
not cooperative and there is a drop-in alternative.


I think this is a bit heavy-handed. If we take the "make it doable
either as built-in or loaded from userspace at runtime, from a second
tarball" approach as discussed, I suspect you'll discover that it's less
"is not interested in achieving" (by which I assume you meant "is
unwilling") and more "doesn't perceive it as useful goal to work on".



Having that virtual package is more pain to maintain than a ks file


Err... The only person I know who has volunteered to maintain this
package disagrees with this assessment, especially because the ks file
does not even begin to address the longer-term goal of enabling a user
to avoid the installation of non-Free Software on his system (install
time and updates over time), rather than a short-term goal of avoiding
the inclusion of non-Free Software in one particular spin.


You are largely ignoring the infrastructure around installation and
upgrades of multiple kernels. There is more maintenance work than just
in the kernel package (or packages, in your scenario) itself. It is not
insignificant.


Josh Boyer wrote:

I certainly didn't think you intended to _replace_ the main kernel
package. But I don't agree with even providing a completely different
alternative "kernel-libre" package. If it can't be built as a flavor
of the existing kernel package, then I don't see it being approved for
inclusion.


And I'd still be against that. If the goal is allowing users to install
and use a system without any of the non-free firmware (assuming that's
even plausible for our hypothetical user), then you also need to change
the package selection code in anaconda, among other things. As much as
I wish it were, kernel* is not just another package.


--
Peter

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 03:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org