That's... very basic. Not an awful lot of useful information about the hardware environment.
The challenge for things like EC2 is more in that most cloud hypervisors, for security/performance/complexity reasons, have stopped emulating the older hardware a lot of "basic osdev projects" rely on. So you're stuck with a very modern set of hardware for interrupt controllers, disk IO, etc. I was hoping to see something more along those lines here, not just how to make and upload a disk image.
I agree that it's basic information -- but that's the most important information to have! This blog post was essentially constructed from the replies I sent people who asked me to help them.
> ...most cloud hypervisors, for security/performance/complexity reasons, have stopped emulating the older hardware a lot of "basic osdev projects" rely on.
If you're really determined to do basic/hobbyist OS dev on EC2, you can always just run it under QEMU, which is pretty much what you'd do if you're developing on your own hardware, anyway. I know that's kinda beside the point, and reintroduces all those performance issues, but, security isn't a concern here, and it's certainly no more complex than just running it on your own machine.
I guess it depends on how you read "Your OS." I read it as "Hobby osdev project."
"Port your OS to EC2," as I read it (I live in weird weeds so this may not be how other people read it) implies an OS you've written ("your OS") that currently doesn't run on EC2 (or you wouldn't need to "port" it - that implies, at least to me, getting something running where it doesn't currently run).
A lot of the hobby OSes out there, even if they're 64-bit, don't always support the latest and greatest drive controllers, interrupt controllers, etc. So if you don't have NVMe support (or virtio block device support - not sure if EC2 supports that or not), you won't be able to read the disk. Legacy ATA/SATA interfaces are often what's supported.
I would have expected, based on the title and what it implied, a list of the hardware supported in various instance types. If the virtualized instances support virtio, mention it. If they only support SATA or NVMe, mention that. And perhaps some references to the relevant specs to implement those.
But if all you have to do to get your OS running is just put it on a disk image, then I'm not sure it really qualifies as "porting to EC2." Just "Installing on" would be more useful phrasing for that.
You are correct. There are actually quite a few different configurations available on AWS alone - not to mention most cloud providers are very different. What works on one instance type on AWS won't immediately run on Azure without additional drivers.
Google Cloud is probably the most friendly one for hobby osdev cause they are based on KVM.
For instance when starting with https://github.com/nanovms/nanos (whom I'm with) we targeted the t2 instances first and it actually took a longer time to come up with support for some of the newer t3 instances because we had to add ENA and NVMe drivers.
Though I see no reason why EC2 would barf on it, as long as you support the proper hardware. They just don't include a lot of legacy hardware you find on a more standard bit of x86 hardware.
Now, if you wanted a really interesting article, discuss how to port your OS to run on the EC2 ARM instances!
The challenge for things like EC2 is more in that most cloud hypervisors, for security/performance/complexity reasons, have stopped emulating the older hardware a lot of "basic osdev projects" rely on. So you're stuck with a very modern set of hardware for interrupt controllers, disk IO, etc. I was hoping to see something more along those lines here, not just how to make and upload a disk image.