Re: Anyone here would consider to split the sanboot comand into two commands?

On Tuesday 21 July 2009 18:32:18 Joshua Oreman wrote:
> That would certainly solve the immediate problem, but I can't help but
> feel like the OP's proposal is a more elegant way of achieving this. For
> images we have a fetch/load/exec/free separation, which seems to work
> quite well indeed. "Fetch" doesn't make much sense for SAN, but we could
> still separate SAN booting into sanload/sanboot/sanfree, where load and
> free control what's in the appropriate [ia]BFT. For backwards
> compatibility, `sanboot' could call `sanload' if it received an
> argument. (I wouldn't suggest calling the load-command "ibft", since it
> could equally well be used with AoE.)

Agreed.  For reference, my ideal situation wrt handling SAN booting is that 
both the filename and root-path fields can be interpreted as URIs; the 
filename field says "connect to this URI, download the entire content, and 
boot it" and the root-path field says "connect to this URI and expose it via 
the block device API".

There's quite a lot of work required for this to happen (some of which is 
already done and sitting in my fun-with-interfaces branch), but I think it 
gives the cleanest solution.

> Of course, if sanload didn't boot, users might expect to be able to call
> it multiple times to set up several SAN drives and then boot off only
> one of them. (Does the iBFT allow multiple entries?)

No; the iBFT allows multiple target definitions, but that's only for 
multipathing.

> It'd need to be 
> discussed whether this is useful functionality, but I think the current
> BIOS-drive hooking mechanism is generic enough for it to work without
> much code addition.

Correct.  The BIOS drive-hooking code already allows for multiple drives, 
though this functionality is not exposed to the user yet.

Michael

------------------------------------------------------------------------------