though, so it's not really ready to be used in a real file system.
Found an off-by-one/some error in Be's BFS implementation: it doesn't use the log
array to its full extent.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14423 a95241bf-73f2-0310-859d-f6bbb57e9c96
1 - IOW using block_runs here is completely bogus.
Crippled our code to not create longer block_runs - at least, a dirty BFS image is
now a dirty BFS image - you can mount a dirty image on either system and it will
work :-)
The R5 version of our BFS is still incompatible though - ie. running bfs_shell or
copy_to_bfs_image on a dirty image will still potentially corrupt it. Maybe I'll
even port the changes over one day...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14418 a95241bf-73f2-0310-859d-f6bbb57e9c96
compatibility, though!
Writing is now combined into a few writev_pos() function calls to speed up log writing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14415 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since CD-ROMs let open themselves read/write, it now also checks the device
geometry, and will make sure the device is opened read-only if the geometry
structure says so - this should reduce the number of write errors you get
during boot :-)
Volume::fFlags is now always correctly maintained.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14414 a95241bf-73f2-0310-859d-f6bbb57e9c96
the read/write access was only correct for the first entry in the iovec.
These functions should be updated to use read_pages()/write_pages() where
possible, anyway - right now, they only save some kernel calls, while they
could be processed by the device at once.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14413 a95241bf-73f2-0310-859d-f6bbb57e9c96
tried to write from/read to the userland file descriptor instead of the one
of the kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14412 a95241bf-73f2-0310-859d-f6bbb57e9c96
it for us, but seems that we had a lock/memory-leak, here).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14411 a95241bf-73f2-0310-859d-f6bbb57e9c96
some heuristic: when you booted from a CD, CDs are preferred; else, volumes with
names like "Haiku" or "System" are preferred - if someone has better ideas, please
shout.
Note, this heuristic will only come into play if the boot loader was loaded from
an image (ie. floppy/CD/network), and you didn't choose any boot device.
Added evil methods to the Stack class that come in handy (you can now directly
access the array) for this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14410 a95241bf-73f2-0310-859d-f6bbb57e9c96
* takes an audio file as parameter
* should play with haiku media kit, provided the codec is supported
* tested ok on Haiku with mp3 and wav files
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14407 a95241bf-73f2-0310-859d-f6bbb57e9c96
Only works after having built the system once - could be greatly improved, but does its job for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14405 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku disk installed, you can now choose between them in the boot loader.
Also fixed build - obviously forgot to compile before a last minute change...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14404 a95241bf-73f2-0310-859d-f6bbb57e9c96
and into its own file vfs_boot.cpp.
Added basic support for booting from CD - it doesn't give CDs a higher priority,
so you could end up booting from HD when you didn't explicetly select "CD-ROM"
in the boot loader. Eventually, it should only boot from HD in this case, if
booting from CD failed (because of a missing boot partition or whatever).
fs_mount(), _kern_mount(), and _user_mount() will now return the dev_t of the
mounted device, and not just B_OK. Maybe we should have fs_unmount() work on
a dev_t instead of a path as well...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14403 a95241bf-73f2-0310-859d-f6bbb57e9c96
the boot process. Will experiment with larger sizes later (24k is the current
limit, due to the memory layout used by the platform dependent code).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14402 a95241bf-73f2-0310-859d-f6bbb57e9c96
is still the CD-ROM.
BIOSDrive::ReadAt() now tries to read a specific block up to 3 times before
failing - after the second retry, it will also reset the disk system.
get_ext_drive_parameters() will now fail if the BIOS fills in the device_parameters
structure incorrectly (just tested some values against zero, that at least helps
in the case of one of my systems).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14401 a95241bf-73f2-0310-859d-f6bbb57e9c96
boot message - unfortunately, it crashed when used this way until now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14399 a95241bf-73f2-0310-859d-f6bbb57e9c96
the spam classifier can handle those Russian HTML only spam messages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14395 a95241bf-73f2-0310-859d-f6bbb57e9c96
functions - it no longer terminates the CD-ROM emulation, but only checks the status,
and therefore, it's now called by platform_register_boot_device() instead of from
platform_start_kernel().
This also makes the devices.h header useless.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14390 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the adequate field in the kernel_args structure.
Renamed gCDFloppyBoot variable to gBootedFromImage (as network boot should look
similar).
The "kernel_args.boot_disk.cd" field is now maintained as well.
The print_item_at() menu function now prints the Menu::ChoiceText() instead
of that of its marked item.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14389 a95241bf-73f2-0310-859d-f6bbb57e9c96
"booted_from_image" in the kernel_args' boot_disk structure.
Also, added fields "cd" and "user_selected".
A CHOICE_MENU menu can now have a choice text - this is automatically updated
as entries in the menu get selected.
The boot volume menu now has the initial choice text "CD-ROM or hard drive"
in case the boot loader was loaded from an image. The "Rescan volumes" item
is no longer selected by default (only if there was no boot volume found) - but
it's still functionless anyway.
The TAR fs will now appear as "Boot from CD-ROM" in the boot volume menu.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14388 a95241bf-73f2-0310-859d-f6bbb57e9c96
loader will now respect the selection made by the boot image creator, and
just load every file system there is on that image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14381 a95241bf-73f2-0310-859d-f6bbb57e9c96
like floppy or CD boot.
This allows it to reduce the number of scans needed to identify the boot
partition - when booted from a real floppy, this speeds up the boot
process by a magnitude.
Also, the loader now has a fall back in case there were no "boot" links
on the disk - the current boot floppy script doesn't create them.
With these changes, I was able to boot into a HD based Haiku installation
from a floppy disk. It's not yet enough to boot from CD (as the boot
device selection is a bit too simplistic right now), but it will eventually
come next. Testing is a lot slower here, though, as neither qemu nor
Bochs support multi-session CDs (at least I have no idea how to get them
to do this).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14380 a95241bf-73f2-0310-859d-f6bbb57e9c96
have an effect on floppies or CD-ROMs, but would have on real hard drives that require
CHS access.
Changed the cylinder-to-regs conversion in BIOSDrive::ReadAt() (that one was actually
correct) to make it look similar to the conversion in the opposite direction in
get_drive_parameters().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14377 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed TarFS::Node to TarFS::File to correctly name the class hierarchy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14376 a95241bf-73f2-0310-859d-f6bbb57e9c96
