public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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