Remove swblk_t.

[markj]

Summary

It was used only to store the bounds of each swap device. However,
since swblk_t is a signed 32-bit int and daddr_t is a signed 64-bit
int, swp_pager_isondev() may return an invalid result if swap devices
are repeatedly added and removed and sw_end for a device ends up
becoming a negative number.

Note that the removed comment about maximum swap size still applies.

[markj]

This change probably can't be MFCed. We could fix the problem in a different way, by changing swaponsomething() to allocate block ranges more carefully. The current algorithm just scans the list of existing swap devices and places the new one after the end of the last one. I think I will just commit the change and make the block range allocation smarter in a follow-up change.

[kib]

In D23666#519984, @markj wrote:

This change probably can't be MFCed.

Why ?

We could fix the problem in a different way, by changing swaponsomething() to allocate block ranges more carefully. The current algorithm just scans the list of existing swap devices and places the new one after the end of the last one. I think I will just commit the change and make the block range allocation smarter in a follow-up change.

swdevt is kernel-internal, more it is sys/vm internal. The external userspace view on it is provided by struct xswdev.

[markj]

In D23666#519989, @kib wrote:

In D23666#519984, @markj wrote:

This change probably can't be MFCed.

Why ?

We could fix the problem in a different way, by changing swaponsomething() to allocate block ranges more carefully. The current algorithm just scans the list of existing swap devices and places the new one after the end of the last one. I think I will just commit the change and make the block range allocation smarter in a follow-up change.

swdevt is kernel-internal, more it is sys/vm internal. The external userspace view on it is provided by struct xswdev.

I was worried that removal of swblk_t would cause some out-of-tree code to fail to compile (e.g. because of copy-and-paste of libkvm code). Maybe this is still acceptable for the stable branches, I am not sure. I will add a MFC marker and wait for any reported fallout from ports.