Hi folks,
Is there some kind of specification for the above packages or are we free to design the interface as we choose? The reason I ask is that the current interposition order doesn't seem to be particularly logical. At the moment, the order goes like this for a CDROM:
cdrom -> deblocker -> disk-label -> (misc-files or sun-parts or pc-parts)
But I think it makes more sense to do this:
cdrom -> deblocker -> disk-label -> (sun-parts or pc-parts) -> misc-files
The reason for suggesting a change is because by placing misc-files directly after disk-label, all partition offsets have to be bubbled back up the chain using a series of get-info words to the device. If this could be reordered, it should be possible to remove most of this logic and simply pass the read/seeks back up to the parent.
Otherwise, like at the moment, there is lots of code in misc-files that has to work out whether you are accessing a file or a partition directly and act differently which can't be a good thing.
ATB,
Mark.
Mark Cave-Ayland wrote:
Hi folks,
Is there some kind of specification for the above packages or are we free to design the interface as we choose? The reason I ask is that the current interposition order doesn't seem to be particularly logical. At the moment, the order goes like this for a CDROM:
cdrom -> deblocker -> disk-label -> (misc-files or sun-parts or pc-parts)
But I think it makes more sense to do this:
cdrom -> deblocker -> disk-label -> (sun-parts or pc-parts) -> misc-files
The reason for suggesting a change is because by placing misc-files directly after disk-label, all partition offsets have to be bubbled back up the chain using a series of get-info words to the device. If this could be reordered, it should be possible to remove most of this logic and simply pass the read/seeks back up to the parent.
Otherwise, like at the moment, there is lots of code in misc-files that has to work out whether you are accessing a file or a partition directly and act differently which can't be a good thing.
Anyone have any comment on this? Or can I just go ahead and start tidying up and applying patches?
ATB,
Mark.
Mark Cave-Ayland wrote:
Anyone have any comment on this? Or can I just go ahead and start tidying up and applying patches?
Right. I'm pleased to report that I have a patch that works reasonably well here which changes the interposition order as discussed in this thread. I did a lot of tidyups, commenting and adding extra debugging where I felt was relevant.
I'm quite pleased with this patch, as with the new order it's possible for each module instance to keep track of its own position and simply call the parent with the modified offsets (rather than using get-info). This makes the code a lot easier to follow.
Since I was working on SPARC64, I also fixed up some alignment errors in the pc-parts module so that OpenBIOS SPARC64 can now read partitions from VM images, plus the argument passing (partition id/filename) now works correctly which should allow load to be integrated properly into the boot word with a subsequent patchset.
The main reason I haven't committed this yet is that I currently don't have a disk image to test /packages/mac-parts so I can make the relevant changes there. Can anyone point me towards, or possibly supply a small test image so I can update the relevant code before commit?
ATB,
Mark.
On 6/7/10 7:41 PM, Mark Cave-Ayland wrote:
Mark Cave-Ayland wrote:
Anyone have any comment on this? Or can I just go ahead and start tidying up and applying patches?
Right. I'm pleased to report that I have a patch that works reasonably well here which changes the interposition order as discussed in this thread.
Very nice!
Please make sure it complies with http://www.openbios.org/data/docs/rec.intpos.d02.pdf
Stefan
Stefan Reinauer wrote:
Very nice!
Please make sure it complies with http://www.openbios.org/data/docs/rec.intpos.d02.pdf
Okay - just to clarify, it doesn't change the interposition code at all, just the order in which the various interposed modules are invoked when reading from disk block devices (see my first email in the thread).
I'm still unable to update /packages/mac-parts without access to a test image though, which means if I commit what I have now it will break reading from Mac partitions. Then again, my next round of load/boot patches will depend upon this and so I do need to get it committed at some point in order to progress - what to do?
ATB,
Mark.
-
Mark Cave-Ayland -
Stefan Reinauer