Thank you, Vic, for your efforts. My perceptions about the conflicts that seem to be stirred by any posts that compares 9front with the original, poorly defined, shall we say, "heritage" Plan 9 release are well reflected in your original, detailed posting.
I was planning to address the issue, but you have done that more proactively than I would manage.
I suspect that Jacob misinterpreted my intentions, so at this point I will limit myself to a simple explanation and a possibly controversial request.
I have two large data objects: a fossil cache and a venti backing arena. They are held on one SATA drive. Both seem intact, although I am limited to only superficial inspection because of the size of the objects and the limits in the hardware available to me. I have made various attempts at booting the release Plan 9 legacy system on the available platform that supports SATA drives - but not serial IDE - and have failed. The hardware involved pre-dates UEFI so I am using the traditional boot procedure, to the best of my ability. Booting the 9-legacy distribution from either a SATA optical drive or a USB device has proved beyond my understanding.
I could however boot 9front (I have used 9front on a number of occasions, I have no reservations doing so, but my comfort zone remains with the legacy system which I have been using ever since 2nd Edition was released for sale - I still have the original CD-ROM and two volume documentation) from a USB stick and eventually installed it on the SATA-capable platform where the BIOS allows me to select which device I choose to boot from, within limits.
What I have been unable to do so far has been to get the right combination of master boot record, Plan 9 bootstrap loader (legacy's 9load in preference to 9front's 9boot for various reasons, not all perfectly water-tight), Fossil- and Venti-capable kernel and the right Fossil and Venti embedded configurations to complete the Plan 9 bootstrap procedure.
As I'm presently stuck with /386/pbslba (announcing itself as PBS2) reporting "Bad format or I/O error" my guess is that either the kernel "bootfile" is being specified incorrectly or (a subset condition) I am instructing the loader to look for the kernel on the wrong device. Specifically, I was surprised to discover that 9front uses "sdC[01]" and "sdD[01]" where 9legacy, in my experience uses "sd[EF][01]" as the drive selector. I could be wrong, it has been hard to try all possible permutations, maybe I have missed one or more.
Now, I didn't explicitly indicate where 9front comes into this: I manipulated the disk drive holding my precious data using 9front. Once I had the means to edit the configuration in the Fossil cache partition - and remembered that the Venti tool (venti/conf) for that operation is included in the 9front distribution, which in my confusion I had actually forgotten - I was confident that I had the boot issue sewn up, but as I explained, I am still stuck.
There are many sharp corners I bumped my shins against in this exercise; mostly of my own making as I am somewhat lazy and not as sharp as I thought I was when younger.
The absence of Fossil from 9front was the one I found most difficult to overcome, but at least in theory only the equivalent of "fossil/conf" (an rc script I eventually shoehorned from plan9port) is essential. I can see how it would be inconvenient to need to support software that is significantly complex, especially when it must also be able to be embedded in the kernel.
Jacob makes the point that porting Fossil to 9front is not a 9front responsibility, analogously he also states that the dp9ik code is available to be ported to 9legacy. I concur with Vic that a port of dp9ik to 9legacy is extremely desirable, but I disagree with whomever has dropped the Fossil source code entirely from the 9front release. Right or wrong, I think it will require assistance from the 9front development community to get Fossil working on 9front and plenty of diplomacy to arrive at a release of Fossil on 9front where both participants are proud of the result. Without the sources in the 9front release it is not only hard to contemplate the option, but it is also quite likely that progress in that direction may already have been made but not shared with those who may in turn also contribute to this.
My request, therefore, is that anyone who has worked with the Fossil code in the 9front context (and that includes my minor tweaks to fossil/conf, if any) should find a way to publish what they have. That may stir the pot a bit.
As far as dp9ik goes, I have personal reasons to enhance 9legacy's security code, but it is a massive endeavour, at least as I see it and I am always fearful of undertaking anything I don't think I can handle. But the motivation is there, the question is whether the necessary cooperation will also materialise.
My sincere thanks to Vic, once again, for dowsing the looming flames, we do not need conflict, of the emotional brand, to escalate out of measure.
Lucio.