Re: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi

Sergey Babkin
>From: Warner Losh <[hidden email]>

>scottl> Scott Long
>scottl> I guess my vote would be to have a devd mechanism where the kernel
>scottl> can ask for a module via a particular key, devd maps the key to a file
>scottl> via its config file and loads it into kernel space as a KLD, and then
>scottl> the kernel unloads the KLD when its done with it.  For things like isp,
>scottl> nothing would change, and for iwi you'd get a reliable way of getting
>scottl> bits into the kernel that doesn't require messing with the VFS layer
>scottl> or hard-coding knowledge of the filesystem layout into the driver.
>
>Apart from my other objections to kld, I really don't like getting
>devd involved in this.  devd is a passive listener.  It listens for
>events and then runs programs.  It is not there to interact with the
>kernel in synchronous manner.  Everything is queued and there's
>deliberately no meachanism for a reply.

A rather stupid question:
Why not just make the loader able to load an arbitrary
file? Through a separate call, obviously.
It's the same thing, only with the linking stage
skipped, and calling a pointer received as an
argument of the call instead of the module's load
routine. Then the drivers couls just get the path from
sysconf and happily load whatever files they need.

-SB
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi

Scott Long-2
Sergey Babkin wrote:

>>From: Warner Losh <[hidden email]>
>
>
>>scottl> Scott Long
>>scottl> I guess my vote would be to have a devd mechanism where the kernel
>>scottl> can ask for a module via a particular key, devd maps the key to a file
>>scottl> via its config file and loads it into kernel space as a KLD, and then
>>scottl> the kernel unloads the KLD when its done with it.  For things like isp,
>>scottl> nothing would change, and for iwi you'd get a reliable way of getting
>>scottl> bits into the kernel that doesn't require messing with the VFS layer
>>scottl> or hard-coding knowledge of the filesystem layout into the driver.
>>
>>Apart from my other objections to kld, I really don't like getting
>>devd involved in this.  devd is a passive listener.  It listens for
>>events and then runs programs.  It is not there to interact with the
>>kernel in synchronous manner.  Everything is queued and there's
>>deliberately no meachanism for a reply.
>
>
> A rather stupid question:
> Why not just make the loader able to load an arbitrary
> file? Through a separate call, obviously.
> It's the same thing, only with the linking stage
> skipped, and calling a pointer received as an
> argument of the call instead of the module's load
> routine. Then the drivers couls just get the path from
> sysconf and happily load whatever files they need.
>
> -SB

The loader can, that's how the mfsroot.gz file gets loaded
during install.

Scott
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.c if_iwi

Warner Losh
> The loader can, that's how the mfsroot.gz file gets loaded
> during install.

/boot/loader can do this certainly.  And you can lookup a file based
on its name from the in-kernel loader.

However, there doesn't appear to be a linker class that can load
arbitrary files.  The in-kernel linker can only lookup things loaded
at boot time.

I think that creating a link_file might be a good alternative to
having drivers do vfs operations directly.  The kernel would load it
safely and hand a reference to the file to the driver.  The driver can
then frob it into the hardware and unload the module.

The problem would be that you'd want to make sure that the elf loader
got a chance to reject the module before the arbitrary file loader, or
you'd need to make the arbitrary file loader not load elf.  We may be
able to 'widen' the interface to drivers a bit by exposing
linker_load_file to the outside world.  We could then have the
arbitrary file loader 'fail' the LINKER_LOOKUP_SET method fail so that
linker_load_module would still give the current behavior.  That might
be better than a priority scheme, and would answer my main objection
to kld modules...

Warner
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi

Sergey Babkin
Warner Losh wrote:

>
> > The loader can, that's how the mfsroot.gz file gets loaded
> > during install.
>
> /boot/loader can do this certainly.  And you can lookup a file based
> on its name from the in-kernel loader.
>
> However, there doesn't appear to be a linker class that can load
> arbitrary files.  The in-kernel linker can only lookup things loaded
> at boot time.
>
> I think that creating a link_file might be a good alternative to
> having drivers do vfs operations directly.  The kernel would load it
> safely and hand a reference to the file to the driver.  The driver can
> then frob it into the hardware and unload the module.

I didn't get the e-mails in between yet, so maybe this has been
already mentioned, but I'd also have the offset in the file and
maximal length to read as arguments. This would allow the drivers
to read large files by loading a reasonably small portion at a time.

-SB
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi

Warner Losh
In message: <[hidden email]>
            Sergey Babkin <[hidden email]> writes:
: Warner Losh wrote:
: >
: > > The loader can, that's how the mfsroot.gz file gets loaded
: > > during install.
: >
: > /boot/loader can do this certainly.  And you can lookup a file based
: > on its name from the in-kernel loader.
: >
: > However, there doesn't appear to be a linker class that can load
: > arbitrary files.  The in-kernel linker can only lookup things loaded
: > at boot time.
: >
: > I think that creating a link_file might be a good alternative to
: > having drivers do vfs operations directly.  The kernel would load it
: > safely and hand a reference to the file to the driver.  The driver can
: > then frob it into the hardware and unload the module.
:
: I didn't get the e-mails in between yet, so maybe this has been
: already mentioned, but I'd also have the offset in the file and
: maximal length to read as arguments. This would allow the drivers
: to read large files by loading a reasonably small portion at a time.

That might be an interesting optimization.  I'm not sure that it would
necessarily be all that useful.  The firmware images currently are in
the 32-256k range each.  The ispfw driver is only 450k total (and has
several firmware images, iirc).  While it is desirable to be able to
use this extra memory all the time, this isn't so much memory that we
couldn't allocate and free it as needed.  The only gotcha would be to
make sure that our linker doesn't suffer address space leakage because
these files would be mapped and unmapped a lot more often than a
normal module.

Warner

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi

Bakul Shah
Right now suspend/resume is broken due to the iwi driver
loading firmware.  While you guys hash this out would it be
possible to put in an interim simple fix?  I can live with
200KB+ bloat while you guys hash out a more comple{x,ete}
fix!  As it is I kldload as much as possible so as to run
the same static image on all machines so overall I still
don't use up as much space as GENERIC.

Thanks!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: cvs commit: src/sys/modules/iwi Makefile src/sys/dev/iwi if_iwi.cif_iwi

Scott Long-2
Bakul Shah wrote:
> Right now suspend/resume is broken due to the iwi driver
> loading firmware.  While you guys hash this out would it be
> possible to put in an interim simple fix?  I can live with
> 200KB+ bloat while you guys hash out a more comple{x,ete}
> fix!  As it is I kldload as much as possible so as to run
> the same static image on all machines so overall I still
> don't use up as much space as GENERIC.
>
> Thanks!

Does the NDIS driver support suspend/resume better on this hardware?
If so then I'd suggest using it for now (I use it for my iwi hardware).

Scott
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"