Discussion:
[edk2] upload two drivers
S.Vieira
2015-07-14 18:31:52 UTC
Permalink
Hi everyone.

It's possible to do upload of two drives just in ONE .efi

I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.




Thx
S.Vieira
Laszlo Ersek
2015-07-14 21:21:56 UTC
Permalink
Post by S.Vieira
Hi everyone.
It's possible to do upload of two drives just in ONE .efi
I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.
I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.

Laszlo
Post by S.Vieira
Thx
S.Vieira
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Andrew Fish
2015-07-14 21:49:17 UTC
Permalink
Post by Laszlo Ersek
Post by S.Vieira
Hi everyone.
It's possible to do upload of two drives just in ONE .efi
I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.
I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.
You could also convert one of the drivers to a NULL library (change the INF file), and add that new NULL library to the DSC statement for the other driver.

Conceptually the build system could support this behavior, since the library constructors and entry point functions are auto-gem’ed code, but it currently does not.

Thanks,

Andrew Fish
Post by Laszlo Ersek
Laszlo
Post by S.Vieira
Thx
S.Vieira
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/ <https://www.gigenetcloud.com/>
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel <https://lists.sourceforge.net/lists/listinfo/edk2-devel>
Carsey, Jaben
2015-07-14 22:00:17 UTC
Permalink
From: Andrew Fish [mailto:***@apple.com]
Sent: Tuesday, July 14, 2015 2:49 PM
To: Laszlo Ersek
Cc: S.Vieira; edk2-***@lists.sourceforge.net
Subject: Re: [edk2] upload two drivers


On Jul 14, 2015, at 2:21 PM, Laszlo Ersek <***@redhat.com<mailto:***@redhat.com>> wrote:

On 07/14/15 20:31, S.Vieira wrote:

Hi everyone.

It's possible to do upload of two drives just in ONE .efi

I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.

I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.


You could also convert one of the drivers to a NULL library (change the INF file), and add that new NULL library to the DSC statement for the other driver.

Conceptually the build system could support this behavior, since the library constructors and entry point functions are auto-gem’ed code, but it currently does not.

It might work if you made the constructor what was the “main” and the destructor what was the driver unload and still get without a c code change required.

You’d also have to make sure that there are no variable collisions in the resultant image. They might use the same name now


-Jaben

Thanks,

Andrew Fish


Laszlo






Thx
S.Vieira


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
edk2-***@lists.sourceforge.net<mailto:edk2-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Laszlo Ersek
2015-07-15 09:55:38 UTC
Permalink
Post by Andrew Fish
Post by Laszlo Ersek
Post by S.Vieira
Hi everyone.
It's possible to do upload of two drives just in ONE .efi
I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.
I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.
You could also convert one of the drivers to a NULL library (change the
INF file), and add that new NULL library to the DSC statement for the
other driver.
Independently of the thread starter question -- I've never quite gotten
a clear image of NULL libraries. How do they work?

Thanks
Laszlo
Post by Andrew Fish
Conceptually the build system could support this behavior, since the
library constructors and entry point functions are auto-gem’ed code, but
it currently does not.
Thanks,
Andrew Fish
Post by Laszlo Ersek
Laszlo
Post by S.Vieira
Thx
S.Vieira
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
edk2-devel mailing list
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Andrew Fish
2015-07-15 13:40:54 UTC
Permalink
Post by Laszlo Ersek
Post by Andrew Fish
Post by Laszlo Ersek
Post by S.Vieira
Hi everyone.
It's possible to do upload of two drives just in ONE .efi
I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.
I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.
You could also convert one of the drivers to a NULL library (change the
INF file), and add that new NULL library to the DSC statement for the
other driver.
Independently of the thread starter question -- I've never quite gotten
a clear image of NULL libraries. How do they work?
It is not really that complicated. It is just a way to force the build system to call the libraries constructor/destructor.

If you add a NULL library to the LibraryClasses section of a DSC that that library gets linked against all drivers. This is not common, but it is useful for a library that produces compiler intrinsics.

If you list a NULL library in the <LibraryClasses> of a component section in the DSC then that library gets added. A good example of this is it is a way to add optional shell commands. The library constructor will call another library function to register shell commands.

Normally you just get the libraries the driver/application depends on (listed in the INF, mapped in the DSC), and the libraries the libraries depend on, etc.

Examples:
https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellPkg/ShellPkg.dsc <https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellPkg/ShellPkg.dsc>
[LibraryClasses.ARM]
#
# It is not possible to prevent the ARM compiler for generic intrinsic functions.
# This library provides the instrinsic functions generate by a given compiler.
# [LibraryClasses.ARM] and NULL mean link this library into all ARM images.
#
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf

[Components]
...
ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
!ifndef $(NO_SHELL_PROFILES)
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
!ifdef $(INCLUDE_DP)
NULL|ShellPkg/Library/UefiDpLib/UefiDpLib.inf
!endif #$(INCLUDE_DP)
!endif #$(NO_SHELL_PROFILES)
}
Thanks,
Andrew Fish
Post by Laszlo Ersek
Thanks
Laszlo
Laszlo Ersek
2015-07-15 13:50:59 UTC
Permalink
Post by Andrew Fish
Post by Laszlo Ersek
Post by Andrew Fish
Post by Laszlo Ersek
Post by S.Vieira
Hi everyone.
It's possible to do upload of two drives just in ONE .efi
I am wanting to do upload of the AtaAtapiPassThruDxe and AtaBusDxe only in
ONE file.
I think it should be possible to install any number of driver binding
protocol instances in a single driver module, on the image handle.
However, you'd have to merge the two drivers into one in C source code,
and then build the resultant driver.
You could also convert one of the drivers to a NULL library (change the
INF file), and add that new NULL library to the DSC statement for the
other driver.
Independently of the thread starter question -- I've never quite gotten
a clear image of NULL libraries. How do they work?
It is not really that complicated. It is just a way to force the build
system to call the libraries constructor/destructor.
If you add a NULL library to the LibraryClasses section of a DSC that
that library gets linked against all drivers. This is not common, but it
is useful for a library that produces compiler intrinsics.
If you list a NULL library in the <LibraryClasses> of a component
section in the DSC then that library gets added. A good example of this
is it is a way to add optional shell commands. The library constructor
will call another library function to register shell commands.
Normally you just get the libraries the driver/application depends on
(listed in the INF, mapped in the DSC), and the libraries the libraries
depend on, etc.
How cool is that. edk2 has a substitute for
"__attribute__((constructor))". :)

Thank you for the clear explanation!
Laszlo

Continue reading on narkive:
Loading...