Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Last revision Both sides next revision
unity-patch [2009/11/25 10:05]
rwcr
unity-patch [2009/11/25 10:47]
rwcr
Line 46: Line 46:
 Currently, each SAN boot protocol has four components (example): the block device protocol (''​scsi.c''​),​ the networked backend transport (''​iscsi.c''​),​ the firmware table creator (''​ibft.c''​),​ and the boot glue (''​iscsiboot.c''​). The latter two are OS-specific,​ and the boot glue is the entry point; it creates a block device of the appropriate type, calls the networked backend to "​attach"​ it, calls the firmware table creator to fill in data about it, hooks the device via int13h, attempts to boot it, and undoes all of that if keep-san isn't set and the boot fails. This is all rather undesirable,​ as it involves a lot of code duplication and makes SAN booting inherently platform-specific because that's where its entry point lies. Currently, each SAN boot protocol has four components (example): the block device protocol (''​scsi.c''​),​ the networked backend transport (''​iscsi.c''​),​ the firmware table creator (''​ibft.c''​),​ and the boot glue (''​iscsiboot.c''​). The latter two are OS-specific,​ and the boot glue is the entry point; it creates a block device of the appropriate type, calls the networked backend to "​attach"​ it, calls the firmware table creator to fill in data about it, hooks the device via int13h, attempts to boot it, and undoes all of that if keep-san isn't set and the boot fails. This is all rather undesirable,​ as it involves a lot of code duplication and makes SAN booting inherently platform-specific because that's where its entry point lies.
  
-In the new system, SAN booting is not a special case; any data source that looks like a hard disk or CD can be booted, thanks to a new ''​bootsector''​ image format (a semi-thin wrapper around the existing ''​call_bootsector()''​) and a generalization of gPXE's ElTorito support. One can ''​chain''​ or ''​imgfetch''​ a SAN disk in the same way as a URI, and ''​sanboot''​ would be identical to ''​chain''​ were it not for the need to keep support for the ''​keep-san''​ setting. ​As such, the boot glue is removed entirely in the unity patch. The firmware table creator is extended with a small glue function to make it work as a data source attacher, so SAN protocol code need not know about its existence directly; this allows the SAN code to remain platform-independent. The block device protocol provides a data source interface instead of a ''​struct blockdev''​ interface (''​blockdev''​ and ''​ramdisk''​ are both done away with) and the network backend transport provides a VFS binding (see below) to continue the existing URI-like syntax for lookups.+In the new system, SAN booting is not a special case; any data source that looks like a hard disk or CD can be booted, thanks to a new ''​bootsector''​ image format (a semi-thin wrapper around the existing ''​call_bootsector()''​) and a generalization of gPXE's ElTorito support. One can ''​chain''​ or ''​imgfetch''​ a SAN disk in the same way as a URI, and ''​sanboot''​ would be identical to ''​chain''​ were it not for the need to keep legacy ​support for the ''​keep-san''​ setting. ​The boot glue is removed entirely in the unity patch. The firmware table creator is extended with a small glue function to make it work as a data source attacher, so SAN protocol code need not know about its existence directly; this allows the SAN code to remain platform-independent. The block device protocol provides a data source interface instead of a ''​struct blockdev''​ interface (''​blockdev''​ and ''​ramdisk''​ are both done away with) and the network backend transport provides a VFS binding (see below) to continue the existing URI-like syntax for lookups. 
 + 
 +Attachment of a data source now occurs in three places: before attempting a SAN boot if ''​keep-san''​ is set; just before executing a bootsector or ElTorito image (and detached if execution fails); and when the user explicitly requests it using a new ''​attach''​ command. The traditional use-case for ''​keep-san'',​ a Windows install, is replaced simply by 
 +  gPXE> attach iscsi:​1.2.3.4::::​iqn.2009-06.com.example.host:​wininst 
 +  gPXE> exit 
 +and can be automated by serving a gPXE script with the "​attach"​ line in it. Also, ''​attach''​ now supports an option ''​-t extra''​ to attach the source as an "​extra"​ disk (numbered after existing hard drives) instead of the default of a "​boot"​ disk (first hard drive, pushing others down). You can even attach a "​boot"​ disk that's blank, an "​extra"​ disk containing WinPE, boot the "​extra"​ disk, and use it to install Windows onto the blank iSCSI target :-) 
 + 
 +**Size impact:** 
 + 
 +^ object ​   ^ size change | 
 +| autoboot ​ | +33         | 
 +| int13     | +320        | 
 +| keepsan ​  | -128        | 
 +| abft      | +23         | 
 +| ibft      | +29         | 
 +| aoe       | +121        | 
 +| iscsi     | +105        | 
 +| aoeboot ​  | -427        | 
 +| iscsiboot | -453        | 
 +| ata       | +149        | 
 +| scsi      | +350        | 
 +^ Total     | +122        |
  
-To be continued... 

QR Code
QR Code unity-patch (generated for current page)