On Wed, Aug 30, David Lang wrote:
> >initramfs is always in use.
>
> not on my machines.
klibc can be build like:
cd linux-2.6.*
make headers_install INSTALL_HDR_PATH=/dev/shm/$$
cd ..
wget
http://www.kernel.org/pub/linux/libs/klibc/Testing/klibc-1.4.29.tar.bz2
On 08/30/06 02:11:51PM -0700, David Lang wrote:
> >Yep, but initramfs is initialized ways earlier than normal userspace.
> >
> >>however this is not soon enough to supply the firmware for devices like
> >>this.
> >
> >Are you sure of this ? This is somewhat contrary to what i have heard, and
> >it
On Wed, 30 Aug 2006, Sven Luther wrote:
no, at least not in the current kernel. as was mentioned earlier in this
thread the ipw2200 needs the firmware at initialization, but some others
don't need it until open. I don't know if it's even possible to re-write
the driver to do this.
Oh well, thi
On Wed, Aug 30, 2006 at 12:34:16PM -0700, David Lang wrote:
> On Wed, 30 Aug 2006, Sven Luther wrote:
>
> >>>
> >>>Do you really need to bring up ipw2200 so early ? It is some kind of
> >>>wireless
> >>>device, right ?
> >>
> >>if modules are not in use the device is initialized when the kernel st
On Wed, 30 Aug 2006, Sven Luther wrote:
Do you really need to bring up ipw2200 so early ? It is some kind of
wireless
device, right ?
if modules are not in use the device is initialized when the kernel starts
up. this is before any userspace starts.
Well. but you could do the initialization
On Wed, Aug 30, 2006 at 11:20:53AM -0700, David Lang wrote:
> On Wed, 30 Aug 2006, Sven Luther wrote:
>
> >On Wed, Aug 30, 2006 at 10:52:02AM -0700, David Lang wrote:
> >>On Wed, 30 Aug 2006, Olaf Hering wrote:
> >>
> you are assuming that
>
> 1. modules are enabled and ipw2200 is com
On Wed, 30 Aug 2006, Sven Luther wrote:
On Wed, Aug 30, 2006 at 10:52:02AM -0700, David Lang wrote:
On Wed, 30 Aug 2006, Olaf Hering wrote:
you are assuming that
1. modules are enabled and ipw2200 is compiled as a module
No, why?
becouse if the ipw isn't compiled as a module then it's in
On Wed, 30 Aug 2006, Olaf Hering wrote:
you are assuming that
1. modules are enabled and ipw2200 is compiled as a module
No, why?
becouse if the ipw isn't compiled as a module then it's initialized (without
firmware) before the initramfs or initrd is run. if it could be initialized
later
On Wed, Aug 30, 2006 at 10:52:02AM -0700, David Lang wrote:
> On Wed, 30 Aug 2006, Olaf Hering wrote:
>
> >>you are assuming that
> >>
> >>1. modules are enabled and ipw2200 is compiled as a module
> >
> >No, why?
>
> becouse if the ipw isn't compiled as a module then it's initialized
> (without
On Tue, Aug 29, David Lang wrote:
> you are assuming that
>
> 1. modules are enabled and ipw2200 is compiled as a module
No, why?
> 2. initrd or initramfs are in use
initramfs is always in use.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [
Michael Buesch <[EMAIL PROTECTED]> wrote:
> The ipw needs the firmware on insmod time (in contrast to bcm43xx
> for example, which needs it on ifconfig up time).
> So ipw needs to call request_firmware at insmod time. In case of
> built-in, that is when the initcall happens. No userland is availab
Due to return -ENOPATCH, don't CC lkml please.
Hallo,
On Tue, Aug 29, 2006 at 06:30:25PM +0200, Michael Buesch wrote:
> On Tuesday 29 August 2006 04:15, Oleg Verych wrote:
> > James Bottomley wrote:
> > > On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> > >
> > >>reques
On Tue, Aug 29, 2006 at 01:42:56PM -0700, David Lang wrote:
>
> besides, several kernel versions ago this used to work. the current
> requirement is a regression as far as the user is concerned.
Then go bug the driver authors please :)
thanks,
greg k-h
--
To UNSUBSCRIBE, email to [EMAIL PRO
On Tue, 29 Aug 2006, Olaf Hering wrote:
On Tue, Aug 29, Michael Buesch wrote:
On Tuesday 29 August 2006 20:32, Greg KH wrote:
On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
On Mon, 28 Aug 2006, Greg KH wrote:
I think the current way we handle firmware works quite well, especia
On Tue, Aug 29, Michael Buesch wrote:
> On Tuesday 29 August 2006 20:32, Greg KH wrote:
> > On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
> > > On Mon, 28 Aug 2006, Greg KH wrote:
> > >
> > > >I think the current way we handle firmware works quite well, especially
> > > >given the w
On Tuesday 29 August 2006 20:32, Greg KH wrote:
> On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
> > On Mon, 28 Aug 2006, Greg KH wrote:
> >
> > >I think the current way we handle firmware works quite well, especially
> > >given the wide range of different devices that it works for (e
On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
> On Mon, 28 Aug 2006, Greg KH wrote:
>
> >I think the current way we handle firmware works quite well, especially
> >given the wide range of different devices that it works for (everything
> >from BIOS upgrades to different wireless driv
On Tuesday 29 August 2006 04:15, Oleg Verych wrote:
> James Bottomley wrote:
> > On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> >
> >>request_firmware() is dead also.
> >>YMMV, but three years, and there are still big chunks of binary in kernel.
> >>And please don't add new useless info _
On Mon, 28 Aug 2006, Greg KH wrote:
I think the current way we handle firmware works quite well, especially
given the wide range of different devices that it works for (everything
from BIOS upgrades to different wireless driver stages).
the current system works for many people yes, but not eve
Greg KH wrote:
On Tue, Aug 29, 2006 at 05:14:30AM +0200, Oleg Verych wrote:
On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:
On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
request_firmware() is dead also.
YMMV, but three years, and there are still big chunks of binary
On Tue, Aug 29, 2006 at 05:14:30AM +0200, Oleg Verych wrote:
> On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:
> > On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
> > > >>request_firmware() is dead also.
> > > >>YMMV, but three years, and there are still big chunks of binary i
On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:
> On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
> > >>request_firmware() is dead also.
> > >>YMMV, but three years, and there are still big chunks of binary in kernel.
> > >>And please don't add new useless info _in_ it.
> > He
On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
> James Bottomley wrote:
> >On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> >
> >>request_firmware() is dead also.
> >>YMMV, but three years, and there are still big chunks of binary in kernel.
> >>And please don't add new useless
On Tue, Aug 29, 2006 at 02:35:26AM +0200, Oleg Verych wrote:
> Sven Luther wrote:
> >On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
> >
> >>I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
> >>tag. Initramfs should be much easier because it already include
James Bottomley wrote:
On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
request_firmware() is dead also.
YMMV, but three years, and there are still big chunks of binary in kernel.
And please don't add new useless info _in_ it.
I er don't think so.
Hell, what can be as easy as this:
,-
On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> request_firmware() is dead also.
> YMMV, but three years, and there are still big chunks of binary in kernel.
> And please don't add new useless info _in_ it.
I er don't think so.
We (as in the Kernel) are forcing drivers on to this path. Y
On Tue, 2006-08-29 at 01:04 +0200, Sven Luther wrote:
> Notice that mkinitrd-tools is dead, and will probably be removed from etch.
>
> mkinitramfs-tools and yaird are the two currently used tools.
Yes ... I'm aware of that. That's why this is a reference
implementation. initramfs should be eas
Sven Luther wrote:
On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
>
I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
tag. Initramfs should be much easier because it already includes most
of the boot time loading; all it has to do is the piece identifyi
On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
> This is a reference implementation with the debian mkinitrd-tools
> package. It shows how to identify the firmware files necessary for
> drivers in the initrd and also includes a primitive system for loading
> them.
>
> I've teste
This is a reference implementation with the debian mkinitrd-tools
package. It shows how to identify the firmware files necessary for
drivers in the initrd and also includes a primitive system for loading
them.
I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
tag. Initramf
30 matches
Mail list logo
