Re: netbsd-10, merging device-streams (xstreamtodev, rdbinfo)
David Brownlee <[email protected]> Tue, 21 Mar 2023 19:43:45 +0000
| Newsgroups | gmane.os.netbsd.ports.amiga |
|---|---|
| Message-ID | <CAGN_6pYfTe_ET_MwUy_7OxG0GvBEmFcTDTWye3v41Cy3dPPZ2Q@mail.gmail.com> |
OK, updated build with binaries http://sync.absd.org/amiga/current/installation/misc/ modulus any negative feedback I'm going to push the changes into NetBSD HEAD, then look to get pullups into the various branches On Tue, 21 Mar 2023 at 18:39, David Brownlee <[email protected]> wrote: > > On Tue, 21 Mar 2023 at 15:32, Roc Vall=C3=A8s <[email protected]> wrote= : > > > > On Tue, 21 Mar 2023 at 23:15, David Brownlee <[email protected]> wrote: > > > I have another question :) > > > > > > xstreamtodev and xdevtostream are just streamtodev and devtostream > > > with EXPERT_VERSION. > > > > > > Given that the expert versions appear to be entirely a superset (so > > > the behave identically for all basic supported options other than the > > > usage string), is there any need to build and or include the basic > > > versions? The binaries are a few 100s of bytes larger, so its not > > > likely to be useful on the basis of memory or file size. > > > > > > My natural inclination would be just to default to EXPERT_VERSION on > > > always (or even unifdef it), and have a single set of binaries. (I > > > would also probably just want to call them streamtodev and > > > devtostream, but I suspect we have enough years of habit using the "x= " > > > prefix that its best to keep it). > > > > This is very much the reasoning I applied. I am not a fan of this > > distinction either, but thought best to avoid changing anything > > user-facing beyond necessary. > > > > Without having to look outside of netbsd, the netbsd documentation > > does say to use xstreamtodev, and existing releases of netbsd used to > > provide only the xstreamtodev and rdbinfo binaries in the > > /amiga/installation/misc/ directory. > > OK, I'll update the files in NetBSD to exclude streamtodev and > devtostream. If you wanted to adjust the github README and source to > only build xstreamtodev and xdevtostream I'd be entirely happy with > that, but that's obviously not a blocker from the NetBSD side. > > > Tangentially related, documentation will eventually have to be updated > > to reflect the current state of the port, as e.g. the install > > documentation claims that it is not possible to install netbsd to > > partitions above 32bit boundary due to xstreamtodev's limitations. > > > > This no longer holds true when AmigaOS has 64bit support, and while it > > is not possible to boot netbsd in such a system with bootblocks, using > > loadbsd to boot a kernel from AmigaOS bypasses this. Of course, my own > > install is well above 32bit, with AmigaOS and related partitions > > occupying the beginning of the disk. > > If anyone would like to look at the install notes and suggest updates, > that's a great way to help without having to write code or anything > else technical (hint hint to the list :) > > > As I understand it, it should also be possible to update the > > bootblocks to support TD64 and possibly also NSD, but it is a > > considerably involved task. > > > > With these improvements, together with the newer loadbsd, pcmcia > > bugfix, Xorg support improvements on AGA and OCS/ECS chipsets, faster > > decompression of package indexes and other changes, netbsd-10's amiga > > port is looking good. > > I think if I can work through testing a miniroot with the sysinst > installer we could also make the install process a lot nicer (it's > further complicated as networking doesn't work for me in fs-uae, and I > really need time to look at that) > > Thanks > > David