Re: netbsd-10, merging device-streams (xstreamtodev, rdbinfo)

Awesome, thanks!

I checked README.md, then checked the MD5 file and compared the hashes
of the binaries with the 2.2.1 gcc-built ones, they match. I think
we're good.

Roc

On Wed, 22 Mar 2023 at 04:43, David Brownlee <[email protected]> wrote:
>
> 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]> wro=
te:
> > >
> > > 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 t=
he
> > > > 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 o=
n
> > > > 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 update=
d
> > > 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 i=
t
> > > is not possible to boot netbsd in such a system with bootblocks, usin=
g
> > > loadbsd to boot a kernel from AmigaOS bypasses this. Of course, my ow=
n
> > > 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