mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Manuel Estrada Sainz <ranty@debian.org>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6 PATCH/RFC] Firmware loader - fix races and resource dealloocation problems
Date: Fri, 26 Dec 2003 18:29:52 +0100	[thread overview]
Message-ID: <20031226172952.GB16008@ranty.pantax.net> (raw)
In-Reply-To: <20031222232250.GB4358@kroah.com>

On Mon, Dec 22, 2003 at 03:22:50PM -0800, Greg KH wrote:
> On Tue, Dec 23, 2003 at 12:05:59AM +0100, Manuel Estrada Sainz wrote:
> > 
> >  What can actually be a problem is that hotplug delays event handling
> >  while booting, and if firmware needing drivers load at boot time they
> >  usually timeout before the event gets handled, and when hotplug tryies
> >  to handle the event the files are already gone.
> 
> What would remove the files?

 Once the firmware load is over, whether normally or because of any error
 request_firmware() cleans up, and that includes removing sysfs files. 

> And if you need firmware at boot time, stick it, and the firmware loader
> in initramfs.

 Once klibc and hotplug go into the standard kernel I'll look into
 request_firmware support there, even ACPI could benefit from it, but
 until then ...

 Although I don't have it clear, what happens between mounting the real
 root device on top of rootfs and hotplug starting to handle events?
 Maybe hotplug could treat firmware events specially and not delay them
 even while booting.

 I guess that we will get the real taste of it once initramfs gets it's
 klibc and starts being used broadly.

 Have a nice day

 	Manuel


-- 
--- Manuel Estrada Sainz <ranty@debian.org>
                         <ranty@bigfoot.com>
			 <ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

      reply	other threads:[~2003-12-26 17:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-21  6:37 Dmitry Torokhov
2003-12-22  9:37 ` Greg KH
2003-12-22 23:42   ` Marcel Holtmann
2003-12-23  3:29   ` Dmitry Torokhov
2003-12-23  8:48     ` Marcel Holtmann
2003-12-27  5:29       ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 Dmitry Torokhov
2003-12-27  5:29         ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 1/2) Dmitry Torokhov
2003-12-27  5:30           ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 2/2) Dmitry Torokhov
2003-12-31 21:31             ` Greg KH
2003-12-31 22:16           ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 1/2) Manuel Estrada Sainz
2003-12-31 22:32       ` [2.6 PATCH/RFC] Firmware loader - fix races and resource dealloocation problems Manuel Estrada Sainz
2003-12-31 23:03         ` Greg KH
2003-12-22 23:05 ` Manuel Estrada Sainz
2003-12-22 23:22   ` Greg KH
2003-12-26 17:29     ` Manuel Estrada Sainz [this message]

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=20031226172952.GB16008@ranty.pantax.net \
    --to=ranty@debian.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®