Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
unity-patch [2009/11/25 10:47] rwcr |
unity-patch [2009/11/25 11:20] 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. |