Differences

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

Link to this comparison view

Both sides previous revision Previous revision
unity-patch [2009/11/25 10:47]
rwcr
unity-patch [2009/11/25 11:20] (current)
rwcr
Line 49: Line 49:
  
 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 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> attach ​-f iscsi:​1.2.3.4::::​iqn.2009-06.com.example.host:​wininst
   gPXE> exit   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 :-)+and can be automated by serving a gPXE script with the "​attach"​ line in it. (The ''​-f''/''​--fetch''​ option asks to create an image for a URI and attach that, instead of attaching an already-fetched image.) ​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:** **Size impact:**
Line 69: Line 69:
 ^ Total     | +122        | ^ Total     | +122        |
  
 +===== Binding abstraction =====
 +How does one acquire a data source in the first place? Well, if you're downloading it, you get it using ''​download_uri()'',​ which calls ''​create_downloader()'',​ which calls ''​xfer_open()''​. It would be a mistake to try to fit random-access storage into the ''​xfer_interface''​ framework; that framework does a marvelous job of handling network sockets, but it's very stream-oriented. So URI openers will stay download-only. How do we fit in SAN protocols, and eventually filesystem access?
 +
 +The unity patch introduces the concept of a //​binding//,​ an object that lets one look up a URI and get a data source back. Bindings are registered with a name, and when one attempts to fetch a URI with that name as the scheme, it gets looked up in the appropriate binding instead of downloaded. SAN boot protocols are implemented as global bindings named ''​iscsi'',​ ''​aoe'',​ ''​ib_srp'',​ etc, so when you do
 +  gPXE> imgfetch iscsi:​1.2.3.4::::​iqn.2009-06.com.example.host:​mydisk
 +it's passing a URI to ''​iscsi_lookup()''​ that has ''​scheme''​ set to ''​iscsi''​ and ''​opaque''​ set to ''​1.2.3.4::::​iqn.2009-06.com.example.host:​mydisk''​. The fact that a full URI is passed allows something like HTTPDisk or NFS to work intuitively;​ you can (assuming proper implementation of an ''​httpdisk''​ SAN boot protocol)
 +  gPXE> chain httpdisk://​my.server/​myimage.hdd
 +and it'll work exactly like ''​chain http://​...''​ except the whole image won't be downloaded before it's booted.
 +
 +Looking ahead a bit, this patch implements the concept of a //binding type//, a way of creating bindings that are based on some data source instead of being global. For instance, if ''​ext2''​ is a binding type, you can do
 +  gPXE> imgfetch -n disk aoe:e0.0
 +  gPXE> attach disk
 +  gPXE> bind -t ext2 disk bootfs
 +  disk on bootfs type ext2
 +  gPXE> chain bootfs:/​boot/​vmlinuz
 +The explicit ''​attach'',​ to fill the aBFT for the kernel, will probably become unnecessary.
 +
 +A binding is memory-managed much like a network device; the allocation for its structure contains some amount of private data requested by the binding type creating it, and ''​binding->​priv''​ points at that private data. Sources looked up in the binding hold a reference to it, and a reference is taken when it is registered with a name as well. The binding holds a reference to the source it's based on. This system keeps sources and bindings around as long as anyone is using them.
 +
 +A global binding is created as a ''​struct global_binding'',​ which serves as the template for an autoregistered ''​struct binding''​ at init-time. Data source attachers can specify a ''​struct global_binding''​ to limit themselves to, so only AoE disks will be recorded in the aBFT, etc.
 +
 +There'​s also a special URI syntax for recursive binding in a single command:
 +  gPXE> chain ext2(part(aoe:​e0.0):​1):/​boot/​bzimage
 +If both ext2 filesystems and partition tables can be autodetected,​ that reduces to
 +  gPXE> chain ((aoe:​e0.0):​1):/​boot/​bzimage
 +This is rather obtuse, but it does allow a complicated boot path to be specified in a single DHCP filename option.
 +
 +**Size impact**: ''​uri.o''​ +56, ''​vfs.o''​ +895, ''​vfs_cmd.o''​ +2037.

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