Currently, I must uniquely identify an OS on a computer.
Now I use the serial of a disk and a partition number, which means the OS is installed in that partition of the disk. Because I think only one OS can be installed on one partition on a disk. So, that determines a unique OS.
Or, is there some better way to represent it?
Uniquely is a very slippery concept. Let's say I make VirtualBox machine image, and run five identical instances on my server. They'll all have the same disk serial number and the same partition id. Are they supposed to be the same, or different? Maybe you could add network address to the mix, so that could be the discriminator. But what if they are not networked?
There are many other possible grey areas: I can have a dozen different kernels on the same partition on a Linux system, and boot whichever one I choose at startup time. Should those all be the same, or different?
Early versions of Windows installed on top of a DOS install, and you booted in DOS and then brought up Windows on top of it. Are those two different OS's or just one?
Related
Is it safe to use the MAC address as the serial number of a microcontroller in embedded systems? Is it a security threat or can it be duplicated perhaps? (Usually through software from what I read).
MAC Addresses are generated randomly by the manufacturer but as far as I understood there is a slight chance (0.000001% perhaps) that the MAC Address will be duplicate. i.e. it is not entirely unique.
How does a computer know where in the filesystem the bootloader is located? Is there a common file among all operating systems and all computers (maybe not all computers, but all architectures) that points to the bootloader? I know Raspberry Pi always loads bootcode.bin from the first partition of the SD card. Do PCs share a common file like this?
The Master Boot Record occupies the first 512 bytes of the first hard disk, and is the first thing loaded by the BIOS to hand over control to a program capable of booting the desired operating system. In general, a bootloader gets installed in the MBR, removing its previous content. It is (in dual boot cases) possible for them to live in co-existence, which is known as multi-booting.
It is different among different architectures. But usually there is a register the cpu reads its first instruction from after reset to begin execution. This register is often contains the bits for an assembly jump operation to another memory address which is the address of the boot code. On the next clock cycle it will fetch the operation at that address and so on.
The hardware designer will have to determine how this is implemented. For example the first instruction could be to read from a memory address on an eeprom chip that contains the boot code.
As far as PC's go the motherboard has its own boot process which will load the OS bootloader. Hence the reason you can still startup a pc and see the BIOS without an OS installed
Or at least thats what I remember from my Comp. Arch. class forever ago.
I'm building an IOKit CFPlugin driver for OS X. I'll be working with network data coming in that will be translated to MIDI data. No hardware is involved other than the built-in Airport. I have experience with drivers on Windows machines and firmware but this is my first dip into doing it on the Mac. So far things are going pretty well, but the Apple documentation sez: "For safety reasons, you should not load your driver on your development machine."
I only have one Mac. I really don't want two Macs- sorry, Apple. Should I take this warning seriously? Are there things I need to know?
Thanks, Tom Jeffries
You could also consider running OS X inside a VM as your testbed. It would surely be much more convenient that having a separate boot volume.
The warning is rather poorly worded; what you should consider doing is using a separate boot volume (partition) for trying out your driver, since it's possible to arbitrarily hose your system with your driver.
If you're doing kernel development on any OS that isn't isolated from your main system (via a VM, alternate boot disk, etc.), you're crazy!
What may be a bigger issue is that you can't do any kernel debugging, because the only option for that is to use GDB on a remote OS X system. For this, you may want to consider running OS X in virtualization.
you DEFINITELY want to have some way to recover a fubar kext installation: a bootable external drive or something you can quickly restore from-- this is the main reason for Apple's warning against running in-development-kernel-extensions on your production machine.
Nicholas is right that in order to debug using gdb (the only way in kernel space) you do need two machines. I've never tried using a VM as Coxy suggests: but I guess it's feasible (assuming that you run your kext on the virtual machine and use the real host machine to run gdb).
My preferred method for tracing and debugging in the kernel is kprintf() routed to firewire (aka firewire kprintf (man fwkpfv) ). for this you do need two machines with firewire ports.
finally, being an old computer musician myself, I wonder why you want to program a MIDI synthesizer (or transformer) on the network stack level. my guess is that you would have a much more gratifying experience working in userland (where you can use floating point math...)
if you need some hints or tips, feel free to get in touch...
|K<
from the ADC Kernel Programming Guide
Kernel programming is a black art that
should be avoided if at all possible.
Fortunately, kernel programming is
usually unnecessary. You can write
most software entirely in user space.
Even most device drivers (FireWire and
USB, for example) can be written as
applications, rather than as kernel
code. A few low-level drivers must be
resident in the kernel's address
space, however, and this document
might be marginally useful if you are
writing drivers that fall into this
category.
In order to recognize a computer in a certain manner (MAC adress not appropriate for some cases, disk ID or hostname neither etc.), I would like to detect a CPU id (or first CPU core id)... How can I achieve this on different platforms? (not necessarily in manner that is robust to OS change on the same computer)
Thanks
The CPU id identifies the processor model, and isn't unique to each computer. See: http://en.wikipedia.org/wiki/CPUID
The MAC address is usually the best way to uniquely identify a system.
My dad is looking for ways to automate checking the settings of a Windows server for giving it a standards compliance grade. He needs to know if more than one OS is installed, but wants to avoid taking down the server at all costs. Is there any technique within Windows (XP and newer) for programmatically ascertaining whether a machine has multiple OSs installed?
It depends on what you consider "an installed OS".
At the very least you'd have to scan all partitions (including the ones Windows's limited filesystem support can't recognize) for filesystems and then see if they "look" like another OS. If you need to know if the alternate OS is bootable as well, you'll have to scan for boot loaders and their configuration as well.
By the way, what difference does it make if there's another OS installed on the computer?
Not entirely reliably. You could attempt to access the MBR and the partition table and sniff for evidence of the competition if you can persuade Windows to let you open the other partitions as raw devices. It would be a heap of work.
How about doing a checksum of the bootloader and comparing it against a known-good list of Windows OS bootloaders on the HDs?