FWIW, I still use bzdisk images frequently, and the 1MB limit really
is a serious problem for 2.5 kernels, and 2.4 kernels build with gcc-3.
I'm currently using a patched kernel where `make bzdisk' invokes a
user-specified script, which in my case goes roughly like:
===snip===
BOOTIMAGE=$1
LIBDIR=/home/mikpe/pkgs/linux-x86/make-zdisk/lib
FDIMAGE=/tmp/fdimage.$$
MTOOLSRC=/tmp/mtools.conf.$$
cat > $MTOOLSRC << EOF
drive v:
file="$FDIMAGE" cylinders=80 heads=2 sectors=18 filter
EOF
dd if=/dev/zero bs=72k count=20 of=$FDIMAGE
MTOOLSRC=$MTOOLSRC mformat v:
MTOOLSRC=$MTOOLSRC mcopy $LIBDIR/ldlinux.sys v:
MTOOLSRC=$MTOOLSRC mcopy $BOOTIMAGE v:linux
dd bs=512 count=1 conv=notrunc if=$LIBDIR/bootsect.img of=$FDIMAGE
dd bs=72k if=$FDIMAGE of=/dev/fd0
===snip===
The latest mtools are supposed to have direct support for image files,
which should eliminate the MTOOLSRC kludge.
All I'm really missing is a version of syslinux that understands enough
of MS-DOS FS layout to populate the FS and update the boot block without
having to mount the damn thing. That would eliminate the ldlinux.sys and
bootsect.img files, which I extracted from a syslinux-prepared floppy.
You can kill bootsect.S right now, IF you allow a user-specified script
to control how the boot floppy is prepared. Something like:
zdisk: $(BOOTIMAGE)
make-zdisk.sh $(BOOTIMAGE)
should be enough.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/