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

Joshua Oreman <[email protected]>
Newsgroups gmane.network.etherboot.user
Message-ID <[email protected]>
On Tue, 2009-07-21 at 10:19 -0700, Kyle Kienapfel wrote:
> http://git.etherboot.org/?p=gpxe.git;a=blob;f=src/arch/i386/interface/pcbios/iscsiboot.c
> 65         printf ( "Booting from BIOS drive %#02x\n", drive->drive );
> 66         rc = int13_boot ( drive->drive );
> 67         printf ( "Boot failed\n" );
> 
> 
> Looks like a willing coder could add a dont_boot option similar to the
> keep_san option for the use case you want. Lines 65-67 would get
> surrounded by the if statement.

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.)

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?) 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.

In this system, the keep-san option would just control whether sanboot
does a sanfree if it sanloads a drive but can't boot off of it.

-- Josh

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

_______________________________________________
Etherboot-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/etherboot-discuss
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBKZfuiI6LPMrSI3tYRArpFAJ48K/uzOcgWuMTYTiEte82vvuu1wACgqxLk
USFLFmZ0K+OOC5KWzLXYXLo=
=bInc
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.