Skip to contentSkip to conversation

Netboot test suite: PXE instead of qemu -kernel?

DISCUSSION Warren Togami 3 participants 3 messages Jun 23, 2009 – Jun 24, 2009 2 messages not in the archive

lore
Share & tools
lore
#0 lore raw

Just a quick thought.

The netboot tests currently create a server and client qemu image.

Why are we using -kernel and -initrd on the client-side qemu? Wouldn't testing PXE with the dhcp + tftp server on the server-side be more realistic?

Additionally we could use -net tap* instead of -net socket, which would allow brctl setfd of a large value like 20 seconds to simulate the link delay in the test suite.

Warren Togami
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 3 lines · Warren Togami

Why are we using -kernel and -initrd on the client-side qemu? Wouldn't testing PXE with the dhcp + tftp server on the server-side be more realistic?

Yes, but I don't know that it buys us much other than giving us BOOTIF, which we can test by adding it to the test command line. It slows down the boot process, and means you have to have more software installed to run the test suite -- a minor point, but something to consider.

Quoted 3 lines

Additionally we could use -net tap* instead of -net socket, which would allow brctl setfd of a large value like 20 seconds to simulate the link delay in the test suite.

There is merit here, but I think we probably need to have a separate test suite to check the ip= option parsing. I haven't thought much how it should be done, other than it seems like we could use a pre-mount hook to check the configuration without needing to actually mount a real root.

If we have that test suite, then doing PXE boot or emulating BOOTIF= seems like a good idea. And I'd rather add a 20+ second delay to one or two tests here rather than every network root test we do.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 1245819018.18861.3.camel-1q1vX8mYZiGLUyTwlgNVppKKF0rrzTr+@public.gmane.org

#4 lore raw

David Dillow wrote:
[snip]

Quoted 11 lines
Quoted 1 line

Additionally we could use -net tap* instead of -net socket, which would allow brctl setfd of a large value like 20 seconds to simulate the link delay in the test suite.

There is merit here, but I think we probably need to have a separate test suite to check the ip= option parsing. I haven't thought much how it should be done, other than it seems like we could use a pre-mount hook to check the configuration without needing to actually mount a real root.

If we have that test suite, then doing PXE boot or emulating BOOTIF= seems like a good idea. And I'd rather add a 20+ second delay to one or two tests here rather than every network root test we do.

I used an ugly copy of the nfs test suite to test ip= options handling. I'll try to make time this evening to clean it up and post it. --
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html