Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
unity-patch [2009/11/25 09:37]
rwcr
unity-patch [2009/11/25 10:47]
rwcr
Line 40: Line 40:
 | script ​    | +38       | +19        | +57    | | script ​    | +38       | +19        | +57    |
 ^ Totals ​    | +386      | +169       | +555   | ^ Totals ​    | +386      | +169       | +555   |
 +
 +Most of the ''​mem - old''​ impact is from the 64-bitness of ''​image->​source->​len''​ and the additional level of indirection required to access the fields of ''​image->​source''​. The ''​full - mem''​ impact is from the fact that ''​source_read_user()''​ takes two more parameters, including one 64-bit one, than the ''​memcpy()''​ that ''​copy_from_user()''​ reduced to before.
  
 ===== Changes to SAN booting ===== ===== Changes to SAN booting =====
 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)