2010-04-19 21:16:01 +02:00
|
|
|
#ifndef _IPXE_SANBOOT_H
|
|
|
|
#define _IPXE_SANBOOT_H
|
2008-10-13 11:05:23 +02:00
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
/** @file
|
|
|
|
*
|
|
|
|
* iPXE sanboot API
|
|
|
|
*
|
|
|
|
* The sanboot API provides methods for hooking, unhooking,
|
|
|
|
* describing, and booting from SAN devices.
|
|
|
|
*
|
|
|
|
* The standard methods (readl()/writel() etc.) do not strictly check
|
|
|
|
* the type of the address parameter; this is because traditional
|
|
|
|
* usage does not necessarily provide the correct pointer type. For
|
|
|
|
* example, code written for ISA devices at fixed I/O addresses (such
|
|
|
|
* as the keyboard controller) tend to use plain integer constants for
|
|
|
|
* the address parameter.
|
|
|
|
*/
|
|
|
|
|
2009-05-01 16:41:06 +02:00
|
|
|
FILE_LICENCE ( GPL2_OR_LATER );
|
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
#include <ipxe/api.h>
|
|
|
|
#include <config/sanboot.h>
|
|
|
|
|
|
|
|
struct uri;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Calculate static inline sanboot API function name
|
|
|
|
*
|
|
|
|
* @v _prefix Subsystem prefix
|
|
|
|
* @v _api_func API function
|
|
|
|
* @ret _subsys_func Subsystem API function
|
|
|
|
*/
|
|
|
|
#define SANBOOT_INLINE( _subsys, _api_func ) \
|
|
|
|
SINGLE_API_INLINE ( SANBOOT_PREFIX_ ## _subsys, _api_func )
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Provide a sanboot API implementation
|
|
|
|
*
|
|
|
|
* @v _prefix Subsystem prefix
|
|
|
|
* @v _api_func API function
|
|
|
|
* @v _func Implementing function
|
|
|
|
*/
|
|
|
|
#define PROVIDE_SANBOOT( _subsys, _api_func, _func ) \
|
|
|
|
PROVIDE_SINGLE_API ( SANBOOT_PREFIX_ ## _subsys, _api_func, _func )
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Provide a static inline sanboot API implementation
|
|
|
|
*
|
|
|
|
* @v _prefix Subsystem prefix
|
|
|
|
* @v _api_func API function
|
|
|
|
*/
|
|
|
|
#define PROVIDE_SANBOOT_INLINE( _subsys, _api_func ) \
|
|
|
|
PROVIDE_SINGLE_API_INLINE ( SANBOOT_PREFIX_ ## _subsys, _api_func )
|
|
|
|
|
|
|
|
/* Include all architecture-independent sanboot API headers */
|
|
|
|
#include <ipxe/null_sanboot.h>
|
|
|
|
|
|
|
|
/* Include all architecture-dependent sanboot API headers */
|
|
|
|
#include <bits/sanboot.h>
|
2008-10-13 11:05:23 +02:00
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
/**
|
|
|
|
* Hook SAN device
|
|
|
|
*
|
|
|
|
* @v uri URI
|
|
|
|
* @v drive Requested drive number
|
|
|
|
* @ret drive Assigned drive number, or negative error
|
|
|
|
*/
|
|
|
|
int san_hook ( struct uri *uri, unsigned int drive );
|
2008-10-13 11:05:23 +02:00
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
/**
|
|
|
|
* Unhook SAN device
|
|
|
|
*
|
|
|
|
* @v drive Drive number
|
|
|
|
*/
|
|
|
|
void san_unhook ( unsigned int drive );
|
2009-03-12 20:41:40 +01:00
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
/**
|
|
|
|
* Attempt to boot from a SAN device
|
|
|
|
*
|
|
|
|
* @v drive Drive number
|
|
|
|
* @ret rc Return status code
|
|
|
|
*/
|
|
|
|
int san_boot ( unsigned int drive );
|
2008-10-13 11:05:23 +02:00
|
|
|
|
[block] Replace gPXE block-device API with an iPXE asynchronous interface
The block device interface used in gPXE predates the invention of even
the old gPXE data-transfer interface, let alone the current iPXE
generic asynchronous interface mechanism. Bring this old code up to
date, with the following benefits:
o Block device commands can be cancelled by the requestor. The INT 13
layer uses this to provide a global timeout on all INT 13 calls,
with the result that an unexpected passive failure mode (such as
an iSCSI target ACKing the request but never sending a response)
will lead to a timeout that gets reported back to the INT 13 user,
rather than simply freezing the system.
o INT 13,00 (reset drive) is now able to reset the underlying block
device. INT 13 users, such as DOS, that use INT 13,00 as a method
for error recovery now have a chance of recovering.
o All block device commands are tagged, with a numerical tag that
will show up in debugging output and in packet captures; this will
allow easier interpretation of bug reports that include both
sources of information.
o The extremely ugly hacks used to generate the boot firmware tables
have been eradicated and replaced with a generic acpi_describe()
method (exploiting the ability of iPXE interfaces to pass through
methods to an underlying interface). The ACPI tables are now
built in a shared data block within .bss16, rather than each
requiring dedicated space in .data16.
o The architecture-independent concept of a SAN device has been
exposed to the iPXE core through the sanboot API, which provides
calls to hook, unhook, boot, and describe SAN devices. This
allows for much more flexible usage patterns (such as hooking an
empty SAN device and then running an OS installer via TFTP).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2010-09-03 17:11:51 +02:00
|
|
|
/**
|
|
|
|
* Describe SAN device for SAN-booted operating system
|
|
|
|
*
|
|
|
|
* @v drive Drive number
|
|
|
|
* @ret rc Return status code
|
|
|
|
*/
|
|
|
|
int san_describe ( unsigned int drive );
|
2009-11-04 02:18:08 +01:00
|
|
|
|
2010-04-19 21:16:01 +02:00
|
|
|
#endif /* _IPXE_SANBOOT_H */
|