* mmc might be not ideal. But raw is just a single partition and
anyboot is heavily x86. MMC will technically work for now to get
bootable images.
* floppyboot isn't used on EFI platforms, since we call two different
actions, just drop floppyboot altogether on EFI SD Images.
Change-Id: Idabb5483304007dd601bf8a1158036ffd24f73aa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3165
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This patch fixes the following issues:
The cat command in fs_shell only printed 10 bytes instead of the entire
file. Also, when the number of bytes to be read from file was large it would
cause segmentation fault because of stackoverflow.
This was noticed while testing xfs and ufs filesystems and has now been
fixed.
Change-Id: I3891f2834c5b76330f666ebee97b20bd5529742a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3157
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Had to abbreviate the trailing 's' to make it fit the alignment...
Change-Id: Iae88c4cd92c3f54bf3ea3433ea3dafe5df90a8e8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3168
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For areas >= 32TiB the page protection array size would overflow.
Change-Id: Ic95d9a6e35bbedb165c2bbd382f6c47edde07ac2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3167
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When copying an area with vm_copy_area only the new protection would be
applied and any possibly existing page protections on the source area
were ignored.
For areas with stricter area protection than page protection, this lead
to faults when accessing the copy. In the opposite case it lead to too
relaxed protection. The currently only user of vm_copy_area is
fork_team which goes through all areas of the parent and copies them to
the new team. Hence page protections were ignored on all forked teams.
Remove the protection argument and instead always carry over the source
area protection and duplicate the page protections when present.
Also make sure to take the page protections into account for deciding
whether or not the copy is writable and therefore needs to have copy on
write semantics.
Change-Id: I52f295f2aaa66e31b4900b754343b3be9a19ba30
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3166
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Ia386d9155dda37ff6608a33dee349bf5332890c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3162
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: François Revol <revol@free.fr>
Change-Id: Id050fad59ede444f2eab7eca681c6ec44612aaf9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3160
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: François Revol <revol@free.fr>
Somehow the first review merged only the commit log.
FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.
Change-Id: I6372af6679e6773fbb6bf4c8b5b30512971a97a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3161
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Note it is not enough to fit, you also need to disable USB boot.
Change-Id: I5159c9ddebb242c4d4874d70430da6852073fdb4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3102
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
For some reason the kernel ended up with a bunch of .text.foo or
.data.rel.bar sections, each with their own ELF section headers and
other metadata. Forcing them into the base sections drops the binary
size by about 100kB, even for the stripped one.
I suspect it should work on other archs as well.
Change-Id: I7a8f46480d71267c07b75325423a0f5bfd2d12fb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3101
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
We don't have room for disklabel copies anymore.
+ style fixes
Change-Id: I22502167a4f5f8bc3df1b017072461d77a299b16
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3100
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Next floppies actually do have a "disk label" (partitionning scheme),
the boot block being later on the disk.
This commit generates an identical label to the image I have here (but
not the copies at other sectors), including the checksum.
Change-Id: I7f939c26e70e3626d9af7a3eb342cfd32c298e3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3098
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Doesn't work yet though:
- we don't implement heap yet,
- non-color machines have 2bpp, so we'll have to hack this in some way.
Change-Id: Idf8f69c2256837db3915949d93265decbb43a524
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3097
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Those were found in the official headers in the NeXTstep ISO, how come I
didn't even look there in the first place?
We do get enough info to use the framebuffer, but sadly the SCSI IO
seems invalid. Both the NetBSD and even NeXTstep bootblock have their
own embedded drivers, maybe they didn't trust their own rom?
Change-Id: I0a47c433da89b15091644cd5c69ffff24d0cdd1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3096
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Since the boot ROM API structure is declared with a custom alignment, we
simulate it with padding bytes around, and use aligntest.prg to verify
using ARAnyM + TOS/MiNT as we know how to link simple PRG files.
It now prints something to the screen then panics when initializing the
heap.
For now one must insert the loader manually into an existing floppy
image:
dd if=generated-m68k/objects/haiku/m68k/release/system/boot/next_m68k/haiku_loader.next_m68k bs=$((0x8000)) seek=1 of=next_floppy.img conv=notrunc
Change-Id: I06d74e9d85a352aab68dedce545bbe5fe9e990d5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2220
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.
Not sure the 'hidden' define should go there.
Change-Id: I343f72d61dcacf7dfc180d112529f5a6521d7e3b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2213
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
This enables generation of exceptions that are due to uncorrected
hardware errors. The exception handlers were already in place and will
now actually trigger kernel panics.
Note that this is the simplest form of MCE "handling" and does not add
anything of the broader machine check architecture (MCA) that also allow
reporting of corrected errors. As MCEs are generally hard to decode due
to their hardware specifity, this merely makes such problems more
obvious.
Might help to discern hardware issues in cases that would otherwise just
triple fault and cause a reboot.
Change-Id: I9e3a2640458f7c562066478d0ca90e3a46c3a325
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... with the replicant tray below the menu bar.
Deskbar now has four modes:
1. vertical mini-mode (old mini-mode)
2. horizontal mini-mode (new mini-mode, was vertical)
3. vertical expando-mode (default)
4. horizonal expando-mode
Horizontal mini-mode gets the corner, then it switches to vertical
mini-mode above or below that, then to vertical expando-mode after
that. Horizontal expando mode is in center-screen top and bottom.
Clock vertical centering simplification.
Change-Id: I216008c20feb28f793693046792bbcfdf1e703e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3146
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Without it, the device can't operate at all. Whether or not this is
enabled already is firmware dependent. It was off under QEMU when used
with "-soundhw ac97" and this makes the driver work there.
Fixes#10551 where the syslog shows that this can also happen on real
hardware that is otherwise fully configured.
The BGradient class is a bit strange as it can store any gradient on its
own, butonly the subclasses allow to set some of the fields.
In the asignment operator, the non-base data (which is in an union) was
not copied over.
More importantly, the missing copy constructor led to the default
implementation being used, and BList (used for the color stops) was
being copied using its default copy constructor, resulting in the two
BGradient (original and copy) poinitng to the same stops data. Heap
corruption resulted whenever one of them was deleted.
Having a working copy ocnstructor fixes this. The alternative is making
the copy constructor private or protected to make sure gradients are not
copied, since normally you'd copy only the subclasses, preserving the
C++ type. However there is nothing enforcing that, and manipulating a
BGradient copied from a subclass works just fine.
Change-Id: I28e733eb8a2970b76ae623eabb75ef8435f508af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The level parameter in the CopyEngine::CollectCopyInfo() and
CopyEngine::Copy() methods was introduced in hrev30395 to allow the CopyEngine
to decide which directories should be copied. Since then, this
class has been rewritten and it is no longer necessary for that purpose.
This change refactors the CopyEngine and removes the
level parameter from the class interface. Furthermore, it was broken to begin
with; it was passed as reference to the internal recursive _Copy() and
_CollectCopyInfo() methods, meaning they acted like a global counter. The
global counter was increased at the beginning and decreased at the end of those
methods. Execution could terminate early though, leaving the level counter out
of sync with the recursion level.
There is one use of the level parameter, namely in the
WorkerThread::EntryFilter::ShouldClobberFolder() method, but the use of the
parameter was wrong (it would have been at level 3 at the point of the check,
not level 2) and the logic is functional without the level check.
Change-Id: Id92ef89b015e9b1185bde061273f61e492664bce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3139
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
This was removed in hrev33708 when enabling the "double click to raise"
feature. It results in all clicks after the first one just raising the
team again.
Fixes#8471
Change-Id: I2c7a7bd25401900ee22f6bb953d055e28670776e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3108
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Preserve passed in text rect in fTextRext (unless in layout)
and create an internal version fAlignedTextRect which is used
in place of fTextRect. fAlignedTextRext is aligned to fit the
text rect bounds and grows to fit. fAlignedTextRect always grows
vertically but only grows horizontally if wrap is off.
Left-aligned text view's grow right, right-aligned ones grow left,
and center center aligned ones grow out.
Set fTextRect to bounds in _DoLayout().
Reduce left and right padding inside text views from full label
spacing to half label spacing. Unify padding between BTextControl
and BTextView.
Fixing padding also fixes right and center-aligned BTextViews.
Undo extra scrolling for non-left text views from hrev24130 fixing
a scrolling left and right with mouse bug when it shouldn't.
Replace max_c and min_c with std::max and std::min respectively.
Remove scrolling from one instance of BTextView::SetText as it
produced undesired results while editing a scrolled text view.
Set text rect in BTextControl::DoLayout() and ScreenSaver
PreviewView::AddPreview().
Don't add padding if BTextView::SetInsets() is called. Set insets
to 0 in Tracker "Edit name" setting which prevents default padding
from being added. This is so that when you rename a file in Tracker
the TextView appears on top of the file name text with no padding.
80 char limit fixes.
Fixes#1651#12608#13796#15189#15688
Change-Id: I8c6106effc612f49aff374f29742471628b5df86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3054
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is no point in computing line breaks for a 10px wide text view and
it takes a long time because it needs a lot of linebreaks. The view
eventually gets laid out properly.
This may cause regressions, the TODO here is very old and I don't know
to which "other parts of the code" it refers. Possibly they were
rewritten, possibly not. In any case, there is no point in keeping this
nonsense initial text rect computation, it's better to fix the actual
problems.
Fixes#5582 (which was not locale-related, after all)
