2012/2/9 Paul Brook <p...@codesourcery.com> > > So if we consider this bootloader a device and its -dtb argument a > property > > of that device, then what you are implying is that every device property > of > > every device in a machine must be managed by the machine model? Isn't the > > dynamic machine model work that is in progress is trying to get away the > > approach where fixed machine models have to micromanage all their > attached > > devices? with the ultimate goal of -no-machine how will the bootloader > get > > this dtb argument? > > My expectation is that we have some way for the machine description to tag > objects/properties that pap to the generic commandline options. In the > same > way that we'd probably want to tag the default PCI bus, or UARTs for > matching > with the -serial commandline. Some of these can be guessed, others you > need > the machine description to tell you. > > Paul >
Ok, so it seems that for command line driven arguments the policy is with standard arguments such as -dtb, the machine model must get it on the device behalf and instantiate the device, and that fits in with this patch. Its the other problem I am more worried about, i.e. when I -device instantiate my bootloader with an existing machine how do I get my ram_size and board_ID? The no machine opts for devices policy makes this impossible such that I would have to pass in board_id and ram_size to the boot-loader on the command line. Is there any acceptable way where the machine model can make something globally available to devices for the purpose of instantiating them with -device?
