From: Frans Pop <elendil@planet.nl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Woodhouse <dwmw2@infradead.org>,
davem@davemloft.net, jeffm@suse.com,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir
Date: Thu, 11 Sep 2008 18:32:36 +0200 [thread overview]
Message-ID: <200809111832.38051.elendil@planet.nl> (raw)
In-Reply-To: <alpine.LFD.1.10.0809110852460.3384@nehalem.linux-foundation.org>
On Thursday 11 September 2008, Linus Torvalds wrote:
> On Thu, 11 Sep 2008, Frans Pop wrote:
> > Just keep on ignoring current issues.
>
> Aren't _you_ the one who are ignoring current issues?
I don't think so.
_The_ current issue for me is that I can no longer build Debian kernel
packages using 'make deb-pkg', which is part of _your_ tree, and install
the resulting package *NOW*.
> The fact is, _currently_ everybody looks in /lib/firmware. The fact is,
> most people don't want millions of copies of the firmware (one copy for
> each kernel they compile - think about those of us who compile kernels
> every day).
Right, I totally agree. I did about 40 kernel builds the past two days.
(Yes, I know, there are people doing way more builds than that.)
I regularly have 5 kernels installed simultaneously, and sometimes more if
I'm actively trying to trace an issue.
> I actually like a release-specific firmware directory, but I think it's
> the *vendor* kernel that should do it, not the normal kernel. The
> _vendor_ should put its firmware files in some vendor-specific place,
> and then add that to the end of the firmware loading path.
Hey, I'm NOT propagating versioned dirs in this thread! I've only
mentioned them as one of the two options and explained why I think it's a
valid choice in some scenario's.
I've also explained that I don't think Debian will go that way, but that
is irrelevant. I basically don't care what Debian does for its official
packages.
> So all of the noise in this whole discussion has been totally inane and
> idiotic.
Please explain what is idiotic about mentioning that 'make deb-pkg'
produces broken packages solely because of the separate firmware and that
that is *not* something that is easily solvable because of the way
package management works?
Please explain why it is idiotic to say that having a compatibility option
that would allow me to build firmware _inside_ modules, just like we
always used to, would solve that problem?
That has nothing to do with vendors or distros. It has to do with me (and
others like me, as a kernel tester, having to live with broken tools NOW.
I like 'make dep-pkg' because it very quickly produces a solid, *single*
Debian package I can install and use for kernel testing. I'd like to keep
using that as I have been, but the separation of firmware essentially
kills my current workflow.
next prev parent reply other threads:[~2008-09-11 17:38 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 14:15 [PATCH] firmware: Allow release-specific firmware dir Jeff Mahoney
2008-09-10 22:35 ` Andrew Morton
2008-09-11 13:37 ` Greg KH
2008-09-10 23:01 ` David Woodhouse
2008-09-10 23:05 ` David Miller
2008-09-10 23:15 ` David Woodhouse
2008-09-10 23:24 ` Andrew Morton
2008-09-11 2:55 ` Theodore Tso
2008-09-10 23:24 ` David Miller
2008-09-10 23:36 ` David Woodhouse
2008-09-10 23:42 ` David Miller
2008-09-11 0:23 ` Herbert Xu
2008-09-11 0:39 ` David Woodhouse
2008-09-11 7:44 ` Marcel Holtmann
2008-09-11 8:13 ` Jeff Mahoney
2008-09-11 16:09 ` Marcel Holtmann
2008-09-11 8:29 ` Faidon Liambotis
2008-09-11 16:12 ` Marcel Holtmann
2008-09-11 8:58 ` Frans Pop
2008-09-11 16:16 ` Marcel Holtmann
2008-09-11 8:43 ` Frans Pop
2008-09-11 9:52 ` Frans Pop
2008-09-11 14:50 ` David Woodhouse
2008-09-11 15:24 ` Frans Pop
2008-09-11 15:31 ` David Woodhouse
2008-09-11 15:49 ` Frans Pop
2008-09-11 15:57 ` Linus Torvalds
2008-09-11 16:32 ` Frans Pop [this message]
2008-09-11 17:49 ` Linus Torvalds
2008-09-11 18:24 ` Frans Pop
2008-09-11 16:01 ` David Woodhouse
2008-09-11 4:00 ` David Newall
2008-09-11 6:35 ` Faidon Liambotis
2008-09-11 7:15 ` Jeff Mahoney
2008-09-11 13:38 ` Theodore Tso
2008-09-11 14:36 ` Jeff Mahoney
2008-09-11 16:29 ` Marcel Holtmann
2008-09-11 16:20 ` Marcel Holtmann
2008-09-11 11:29 ` Thierry Vignaud
2008-09-11 13:40 ` Greg KH
2008-09-11 16:39 ` Marcel Holtmann
2008-09-11 16:45 ` David Woodhouse
2008-09-11 20:18 ` Greg KH
2008-09-11 20:15 ` Greg KH
2008-09-11 20:38 ` David Woodhouse
2008-09-11 20:57 ` Greg KH
2008-09-11 21:15 ` David Woodhouse
2008-09-11 22:07 ` Greg KH
2008-09-11 22:25 ` David Woodhouse
2008-09-12 8:39 ` Joseph Fannin
2008-09-12 13:50 ` Gene Heskett
2008-09-12 14:32 ` David Woodhouse
2008-09-12 20:24 ` Kai Henningsen
-- strict thread matches above, loose matches on Subject: below --
2011-02-25 2:39 Jeff Mahoney
2011-02-25 5:01 ` Michael Tokarev
2011-02-25 15:03 ` Jeff Mahoney
2011-02-25 16:54 ` David Woodhouse
2011-03-01 0:48 ` Andrew Morton
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=200809111832.38051.elendil@planet.nl \
--to=elendil@planet.nl \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=jeff@garzik.org \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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