Borrowed from FreeBSD with some changes to get it building.
Now we need to rebuild the gcc package...
Change-Id: I6b8dfd7fb6ca912c76e2ff10fbe01ad583a09aec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2131
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Get enough of the mmu working to be able to allocate memory.
Unlike on PowerPC, we get both address and size as 64bit values. So
adjust of_region to allow this.
Also unlike the PPC port, we do not drive the hardware directly, instead we
rely on the openboot primitives to manage the translation table. This
allows staying independant of the hardware, which is a good idea at
least for the bootloader (we can do actual hardware things in the
kernel)
Change-Id: Ifa57619d3a09b8f707e1f8640d8b4f71bb717e2a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1482
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Gets call-method working for sparc, and fix more places where we
accidentally truncate 64bit values or sign-extend 32 bit ones.
Change-Id: Ic79c55ffa8d2b475858def1639004412f17dd0c1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1986
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
glibc does the same. Technically, some of these builtins did
not exist / did not work before GCC 4.4, but the source tree
cannot be compiled with a version that old anyway.
x86_64 and _x86 need to keep the old functions for now, of
course; but all other architectures can probably feel free
to drop the s_isnan, etc. functions from their glibc.
This will make upcoming patches easier...
Change-Id: Ifb76ea74076553228c9741a8ee3ecb0e1cf736a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- The name for the registers were swapped
- The width and height were also swapped in one of them
- Remove some old #if 0 code that touched these registers but has been
disabled for a while.
LVDS panels must really be driven at their native resolution, otherwise
they will simply not work. This means we should basically never touch
the video timings on that side. We need to only set the source size in
the pipe configuration, and let the panel fitter figure out the scaling.
On my G45 laptop, this allows me to use non-native resolutions on the
laptop display. This also means when booting with a VGA display
connected, I do get a valid display on the internal panel (using the VGA
resolution). VGA still gets "out of range", so we're still not setting
up something there.
If I switch to VGA display in the BIOS, I get a working picture there
and garbage on the internal display, which is progress (before I would
get a black screen on the internal display)
Fixes#12723.
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Drop gnu-efi
Change-Id: Ib601fc8ced49b18281b6b98cf861a5aef1b9c065
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2026
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
enable to check whether a shutdown process is in progress.
Change-Id: I8efdddb3caa80e9fd188f202b6e92a888a7608e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There is no reason to not allow this, and it makes it possible to load
data from eg. a BResource instead of a file, which is very useful.
Remove some unused members in the class and dead code, and fix style
issues.
Change-Id: I94cbd0c13c469ea80f55028cf33dfde2de4365ef
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2001
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
- Remove duplicate and otherwise unused lendian_bitfield.h
- Adjust listusb jamfile to use lendian_bitfield.h
- Fix various typos in usb_video.h and restore some fields to make
listusb happy
- Factor in types changes (introduction of intptr_t)
- Align JamFiles syntax with in progress architectures (arm/sparc)
- Xorriso doesn't support much of the mkisofs options (anymore ?)
- (After a correct bootstrap) one should be able to build @minimum-raw and haiku-boot-cd again
Change-Id: I4f779ad8f2210389fa9b7f7c0a98c3652a64c257
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1983
Reviewed-by: François Revol <revol@free.fr>
Using the geonames.org API, so we will need an API key for it (similar
to the one used for MLS, deployed by the buildbot)
The unit tests uses the "demo" user, which is restricted to 20000 API
call credits and often expired. But we cannot use our secret key here as
it would need to be available to anyone running the test. If we ever get
to automate running the tests on a buildserver we could probably make it
use the secret username known by our buildbot instead.
Change-Id: Ia16880db82555ce85505ad28e1c623f692f46be0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1873
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Move x86 hpet behind timer interface.
* Add a few if x86,x86_64 macros to start.cpp.
Change-Id: I583ec1b064785182e6d48dfbcd91b1bb2ead4b44
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1929
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The tab frame is drawn behind the tabs.
Create a new DrawTabFrame method in BControlLook and HaikuControlLook
that draws the tab frame background.
Until now we've been reusing the DrawInactiveTab method to draw the tab frame
in BTabView. While this works on HaikuControlLook, it doesn't work on other
ControlLook's (such as BeControlLook) that draw their tab frame differently.
Add FBC method to preserve binary compatibility on gcc2 and gcc4.
Move DrawTabFrame method to where _ReservedControlLook1 was in header.
Set rect to area of tab frame in TabView instead of doing the
calculation in HaikuControlLook so that others may benefit.
Change-Id: I513e238914f6d680f495659b6ec902df15555015
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1936
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use the gcc builtin instead, which generates more efficient code (it
saves a function call) and means less platform specific code to write
for us.
Change-Id: I1d55b5703027b2ea4ecde2438ea306bd4850eb32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1859
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This class is not implemented in our code. It is not documented in the BeBook.
Change-Id: Id3a48dbd2039005f69998567dcc26548612f3e9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1876
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Non-KDEBUG kernels and kernel add-ons use atomic operations to acquire
and release the locks inline, so non-KDEBUG kernels/addons are only
compatible with other non-KDEBUG kernels/addons.
Following this change, though, KDEBUG kernels/addons should be able
to run under non-KDEBUG kernels/addons, too, since they always call
into the actual kernel functions and do not inline anything of
consequence.
It previously returned the cookie directly, which made it impossible
to distinguish between a NULL cookie and the function not having
anything to dequeue. This lead to some code setting a cookie that was
not actually used.
Return the dequeue status as a boolean and provide the cookie with an
optionally handed in pointer instead and adjust all users.
Change-Id: Iaac1726ac4bc7ae42bb96b8f0915852b6def5822
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1814
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes ARM64 target compile more files. This patch is one of
series of patches to support new architecture, as fixes in many
places are required just to compile the code.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia060612733cd3a0fcb781fec449da164ed635b8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1807
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds one (private) VFS function, and checks in all usages of
the vnode->cache as a VMVnodeCache that it really is one. (Generic
usages, for the moment just the ReleaseRef() calls in vnode
destruction, are intentionally not touched.)
This will be used by ramfs to set the cache from its own,
so that map_file() calls on a ramfs can work.
Refactored out of execvpe. Originally I did this for my attempted
change to posix_spawn, but that change turned out to be wrong and
actually not that beneficial. This bit seems potentially useful,
though, so here it is.
The patched errata are only the AMD ones FreeBSD patches
(it seems there are no Intel errata that can be patched
this way, they are all in microcode updates ... or can't
be patched in the CPU at all.)
This also seems to be roughly the point in the boot that
FreeBSD patches these, too, despite how "critical" some
of them seem.
Change-Id: I9065f8d025332418a21c2cdf39afd7d29405edcc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1740
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Define a new message, B_KEY_MAP_LOADED, that is broadcast to applications by
the Input Server each time a key map is loaded. This allows apps that cache
key-map data to know when their copy has become stale.
Change InputServer::HandleGetSetKeyMap() so it returns an error in the event
loading even the system (fallback) key map fails.
Change-Id: Icc6c884f695ca59c687d83c680bb2fb467dd90cc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1741
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.
No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)
Sparcv9 runs Openboot in 64 bit mode, which means the cell size is
64bit. Use intptr_t where appropriate to make the open firmware calls
work.
Beware, some values are still 32bit, this matters for example for
of_getprop, if you get 32bits into a 64bit variables it will be in the
MSB of it (big endian only weakness...) and confuse things. See for
example in console.cpp, where the input and output handles are retrieved
as 32bit values. It seems wise to check the expected size when using
of_getprop in these cases, instead of just checking for errors.
Change-Id: Ie72ebc4afe7c6d7602a47478f0bfb6b8247004b8
Reviewed-on: https://review.haiku-os.org/c/1369
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Without this, even installed packages still get an "Install" button.
Fixes#14821.
This was implemented by adding BPackageRoster::IsPackageActive. I decided to
have this take a location since GetActivePackages also did, but as noted in my
TODO comment, I think this is awkward.
It would also be nice to show the user they have a different version of a
particular package, but that would require some changes to IsPackageActive.
Change-Id: Iab0d35eb6b671a17711b0214b15164d296927e5a
Reviewed-on: https://review.haiku-os.org/c/1694
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Consider this scenario:
* A userland thread puts its ID into some structure so that it
can be woken up later, sets its wait_status to initiate the
begin of the wait, and then calls _user_block_thread.
* A second thread finishes whatever task the first thread
intended to wait for, reads the ID almost immediately
after it was written, and calls _user_unblock_thread.
* _user_unblock_thread was called so soon that the first
thread is not yet blocked on the _user_block_thread block,
but is instead blocked on e.g. the thread's main mutex.
* The first thread's thread_block() call returns B_OK.
As in this example it was inside mutex_lock, it thinks
that it now owns the mutex.
* But it doesn't own the mutex, and so (until yesterday)
all sorts of mayhem and then a random crash occurs, or
(after yesterday) an assert-failure is tripped that
the thread does not own the mutex it expected to.
The above scenario is not a hypothetical, but is in fact the
exact scenario behind the strange panics in #15211.
The solution is to only have _user_unblock_thread actually
unblock threads that were blocked by _user_block_thread,
so I've introduced a new BLOCK_TYPE to differentiate these.
While I'm at it, remove the BLOCK_TYPE_USER_BASE, which was
never used (and now never will be.) If we want to differentiate
different consumers of _user_block_thread for debugging
purposes, we should use the currently-unused "object"
argument to thread_block, instead of cluttering the
relatively-clean block type debugging code with special
types.
One final note: The race condition which was the case of
this bug does not, in fact, imply a deadlock on the part
of the rw_lock here. The wait_status is protected by the
thread's mutex, which is acquired by both _user_block_thread
and _user_unblock_thread, and so if _user_unblock_thread
succeeds faster than _user_block_thread can initiate
the block, it will just see that wait_status is already
<= 0 and return immediately.
Fixes#15211.
* It's safe to assume that if the file is shorter than
the provided header, things will go poorly.
* Avoids a random vauge ReadBuffer error.
* This doesn't fix#15230, but makes the issue clearer.
Change-Id: I3471e6de384a0c9be94049ad891c01be980f7846
Reviewed-on: https://review.haiku-os.org/c/1679
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Before this commit, *all* ConditionVariable operations (yes, all;
even Wait, Notify, etc.) went through a single spinlock, that also
protected the sConditionVariableHash. This obviously does not scale
so well with core count, to say the least!
With this commit, we add spinlocks to each Variable and Entry.
This makes locking somewhat more complicated (and nuanced; see
inline comment), but the trade-off seems completely worth it:
(compile HaikuDepot in VMware, 2 cores)
before
real 1m20.219s
user 1m5.619s
sys 0m40.724s
after
real 1m12.667s
user 0m57.684s
sys 0m37.251s
The more cores there are, the more of an optimization this will
likely prove to be. But 10%-across-the-board is not bad to say
the least.
Change-Id: I1e40a997fff58a79e987d7cdcafa8f7358e1115a
Also do some cleanup in private headers, I can't imagine why the build
libraries would need this function.
Change-Id: Ib08810b6efe4738dad596a735d741582a3781b28
Reviewed-on: https://review.haiku-os.org/c/1670
Reviewed-by: Ryan Leavengood <leavengood@gmail.com>
In CodyCam, we attempt to cast the result of this macro to const char*.
However, the ternary operator has lower priority than the cast so it
doesn't work as expected.
Add some protective parentheses here.
Change-Id: I5e9875187cec67b9534b1bbe58d82217c6cd5524
Reviewed-on: https://review.haiku-os.org/c/1667
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unless __STRICT_ANSI__ is defined (as it is when running the compiler in
--std=c89 or --std=c99, but not when running it without any specific
args), we can enable these by default and behave like most other
systems. I don't know why no one has done this yet despite suggesting it
multiple times and people prefer to #define _BSD_SOURCE manually
everywhere.
Remove all places in our Jamfiles and sources where it had been defined.
_DEFAULT_SOURCE is now enabled by default for all sources of Haiku, since we
let the compiler use GNU extensions (no strict C standard specified on
command line)
Use _DEFAULT_SOURCE as the define name to match current versions of
glibc. Enable it if _BSD_SOURCE is #defined in compiler flags, for
backward compatibility.
Change-Id: I6db04da5f6db437723cdfba3478f5094a69d7727
Reviewed-on: https://review.haiku-os.org/c/1633
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
I assume the intent was the same as in other similar functions above.
Change-Id: I887cd73d846680a5a5ec5c90f678ad4b12122eb3
Reviewed-on: https://review.haiku-os.org/c/1655
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
My upcoming changes to use our "futexes" instead of semaphores
will obviously not work on non-Haiku platforms, so we now
need a copy of this class in libbe_build.
This defines the number of bits in a byte and is used in tnftpd.
Once this is merged, some patches to tnftpd can be removed.
Change-Id: Ie2d0c61ce1371daeeb8549281f4210147fb77197
Reviewed-on: https://review.haiku-os.org/c/1642
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's used by both Tracker and Codycam and others might find it useful.
Change-Id: I585d3a1bdc7f8fce7d36bedf6867464cd541ba2e
Reviewed-on: https://review.haiku-os.org/c/1637
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously, it identified all Zen CPUs as Ryzen 7. Since the model
and stepping information consist of microarchitecture information
and don't carry the model number, use the parse_amd based name,
which will remove any unnecessary details from the returned name.
Fixes#15153.
Change-Id: I1a20bf35a60b2fdd20d4cc90ec2dd95fd0e6439d
Reviewed-on: https://review.haiku-os.org/c/1634
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Discovered this while working on VLC, checked with other online sources too.
Change-Id: I114c20babda0ff0e90d0eeee299d8483700166bd
Reviewed-on: https://review.haiku-os.org/c/1628
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Even on 64bit CPUs it's a 32bit register.
Change-Id: I9a4de6eec225de19a90d70fae1382b662e530629
Reviewed-on: https://review.haiku-os.org/c/1625
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
B_OS_NAME_LENGTH is 32, char* is 8 (on x64), and this structure
has quite a lot of pointers in it so it is not like we really
needed to save those 24 bytes. Hitting malloc() in here is not
so great, especially because we usually have B_DONT_LOCK_KERNEL_SPACE
turned on, so just inline and avoid it.
Change-Id: I5c94955324cfda08972895826b61748c3b69096a
The idea was that the Media Extractor could wrap the original source
given by BMediaTrack, but all operations on the data go through
MediaExtractor anyway.
We could probably move ownership of the BDataIO completely into
MediaExtractor instead.
Change-Id: I846b34b543fb983e60f6adf86cb17e835303267b
Reviewed-on: https://review.haiku-os.org/c/1587
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
* Now matches the rest of the architectures.
Change-Id: I6699e0c8f729923770f136f2c9599185a685336a
Reviewed-on: https://review.haiku-os.org/c/1527
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
The previous hack, which as the comment (and __MWERKS__) implies
dates all the way back to the Be era, finally broke: int32 is "int"
on non-x86, not "long", and so this generated an undefined symbol
error on ARM.
The best solution seems to be to make StartMenuBar merely protected,
and then make a subclass where it is fully public to call it.
This is a lot less fragile (and much less ugly.)
Change-Id: I0519d0d9eeb1cc4523d0c6dd4fdfe8688ed1092c
Reviewed-on: https://review.haiku-os.org/c/1516
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Remove a currently unused copy of it from HaikuDepot.
Change-Id: Idb97fae8e7190da6bc1049b3c1f1df929ea91bab
Reviewed-on: https://review.haiku-os.org/c/1506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.
So instead we have to add explicit casts to void* here.
A lot of these classes are not *technically* "trivially copyable"
for one reason or another, but in all of these cases it seems
OK to me to use memcpy/memset on them. Adding a cast to void*
tells GCC that "I know what I'm doing here" and shuts up the
warning.
These worked in identical fashion to what the default copy
constructors would be, but their mere presence marks the class
as being "non-trivially copyable," which means that memcpy'ing
it is now a -Werror on GCC 8.
We have to be careful when making this change, though: classes
which *are* trivially copyable can be passed inside registers
on x86_64, so changes like these break ABI in a dangerous way.
These classes is private, so it should not be a problem, but
for other classes (e.g. BRect, BPoint) we cannot fix them
properly right now.
should help for ports.
Change-Id: Id504bdb79cb68db4b615f58848e0e1a86ced8d2b
Reviewed-on: https://review.haiku-os.org/c/1467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
add-ons" is set.
Confirmed to fix#14361. It is finally possible to un-brick an install
with a bad system library in non-packaged without having to use another
install to do so.
Change-Id: Iafea7821f02cb34e77c766b1f97d1c19206b1081
Reviewed-on: https://review.haiku-os.org/c/1452
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
All of Barrett's individual reverts have been squashed into this
one commit, save a few actual bugfixes.
Change-Id: Ib0a7d0a841d3ac40b1fca7372c58b7f9229bd1f0
This allows cpu_type.h to be used in C-based software,
with the get_cpu_*() functions all accessible via C as well
as C++ code.
Tested changes with sysinfo, AboutHaiku and Pulse.
Change-Id: Ide87d8e3f2ba5f0f1890f385b1ac90c677bcc274
Reviewed-on: https://review.haiku-os.org/c/1453
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
app_server just passes the add-on path around.
Maybe we should make sure the add-on can be loaded when setting it.
Change-Id: I3acd3299782a22c1666bd5435dbf3d8053e359fa
Reviewed-on: https://review.haiku-os.org/c/1430
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
* Oops, there's a standard for these. Stick to the standard.
* Add a few that could be useful someday.
* Mention iana spec.
Change-Id: I4cf75e8c1e4b25f65d10921c7075fbd53f44e14e
Copied from PPC with the hooks for Apple hardware removed.
To be completed with the actual PCI bus implementation for Sun machines.
This is where we start doing machine specific stuff, apparently.
Change-Id: I06af4de9621e9d40593d153642478d928083e49a
Reviewed-on: https://review.haiku-os.org/c/1364
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* I added this early on, but to be honest, any interesting
workstation class hardware would be riscv64.
* Since riscv32 is mostly embedded or low power, just drop.
Change-Id: Id36274c882c46e766268f2ab53eb1bd5f95227be
Reviewed-on: https://review.haiku-os.org/c/1352
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
By default, all targets support the "haiku" platform, and we no longer
support building for BeOS, Dan0, Zeta, or other BeOS-compatible targets,
so this is no longer needed.
Also remove all references to the non-Haiku compatible platforms, and
change all BEOS_COMPATIBLE checks to HAIKU_COMPATIBLE. Removal of
all SetSubDirSupportedPlatformsBeOSCompatible invocations
will be in the next commit.
Declare and use the correct registers to define a stack frame.
Change-Id: Ice3ba8f8715313a715f6b1cb553a6883541f5cc4
Reviewed-on: https://review.haiku-os.org/c/1327
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Kernel is 64 bit, and we won't need a 32bit load base.
Change-Id: I729bab01c8f71083002db061e153b0e5052b9a1c
Reviewed-on: https://review.haiku-os.org/c/1326
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* firewire and freebsd_network expect the macros come from
sys/param.h, as this is one of the places FreeBSD defines them
* All others are Haiku-native and can use Be-style macros.
Fixes the build breakage caused by PulkoMandy's recent commit.
Remove these from ByteOrder.h now also, as per POSIX they should
come from netinet/in.h.
This is a small source compatibility breakage, but it will only
affect a small portion of non-POSIX, partially-Be applications.
If this triggers, it means something is using the "build" errors while
the build system thinks it is not, which is always an error. Nothing
triggers this at present, but some subtle bugs in the build system
a while back would have been caught by this.
Add a platform cleanup hook before starting the kernel. The openfirmware
and PXE loaders clean up their network stack there, while the other
loaders currently do nothing.
This closes ticket #6166
Change-Id: I34765892dfd9b2310c6af97c9ff7d414afae49e5
Reviewed-on: https://review.haiku-os.org/c/50
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: Ia2a86d8814d06950ea2d2d19d966c642d26f81d6
Reviewed-on: https://review.haiku-os.org/c/1302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
A bit of an explanation for these weirdly named functions:
LatestActivePackageInfos() returns the packages on the system that are
both installed and fully set up. When packages are in the middle of being
installed, LatestInactivePackageInfos() shows the packages in the process
of being installed. Once the installation process is done,
LatestInactivePackageInfos() returns nothing. If there are packages that
can't be fully activated without a reboot, CurrentlyActivePackageInfos()
will return the same information as LatestActivePackageInfos(), or if
everything has been installed and activated, it will return no packages.
Change-Id: Ia1814a5abda6d815c46e0b46dc812b4e7af81de3
Reviewed-on: https://review.haiku-os.org/c/1129
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Add various stubs to fix undefined references. No implementation for
anything yet.
Change-Id: I2d398bc2369d099e3a35f0713058d6a5edc6801d
Reviewed-on: https://review.haiku-os.org/c/1138
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This behaves mostly like a pointer, but pointer maths works in bytes,
not the native object size.
It avoids casting to char* and back when doing byte-based pointer math,
making the code easier to read.
Change-Id: I6a8681a398345f0c7d419a2cfe7244d972ffa62f
Reviewed-on: https://review.haiku-os.org/c/1086
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
non standard extension, but widely available to obtain attributes for a thread.
also provides an alias for pthread_getattr_np which is the bsd equivalent.
Change-Id: I26ef8245ed2537186f48c8b8bdf3e42b03e70892
Reviewed-on: https://review.haiku-os.org/c/1172
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
These are simple structs, so hopefully GCC8 will be OK with us
memsetting them. We can't use the standard = {} route because
GCC2 does not support that.
Initialize each class members instead of memset()
for clearing PackageInfoAttributeValue.
Pointed out by gcc8.
Change-Id: I8bdb328e2271e49e840b1294dba9cca544805e72
Reviewed-on: https://review.haiku-os.org/c/1114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Add empty implementation of timer, elf, vm, debugger support, to let the
kernel link.
Also add the kernel linker script.
Change-Id: If0795fa6554aea3df1ee544c25cc4832634ffd78
Reviewed-on: https://review.haiku-os.org/c/1108
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previous commit adding these was merged very quickly, so here's one
more...
Change-Id: I23c424db7631db1f0ec48e2d0ae47c8409ae6af2
Reviewed-on: https://review.haiku-os.org/c/1088
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
During the compilation of LLVM version 8, the build failed because it depends
on a constant in this file. In hrev49042 all BSD headers were feature-gated by
_BSD_SOURCE. This is not done (for this file) in glibc and (obviously) not in
BSD's libc.
Since this is not common practise, I would propose removing the feature gate
for this header file, as it would mean that we would have to upstream patches
for ports of other software that depends on the availability of these
constants.
Change-Id: I486f0c2e87eff489ce92d03589a6299ef1be6ca5
Reviewed-on: https://review.haiku-os.org/c/1144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The kernel version is only partially tested.
Change-Id: I9a2f6c78087154ab137eadbced99062a8a2dd688
Reviewed-on: https://review.haiku-os.org/c/918
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
sdhci:
- Add semaphore for interrupt management
- Add basic operations (setting clock, executing a command)
- Add early initialization (clocks and power up)
- Wrap the bus in a C++ class to ease usage
- Expose API to MMC bus manager
- TODO: manage card insertion and removal interrupts
- TODO: use MSI when available
mmc_bus:
- Implements SD card management independant of the way we access the bus
(later on different drivers can provide the same API as SDHCI)
- Worker thread to do the initialization
- Implement card initialization process up until getting an RCA from the
card. This is the generic part to assign an ID to the card, after this
point commands can be targetted at the specific card so it can be
handed over to the mmc_disk driver.
- TODO: initialization for non-SDHC cards which do not reply to CMD8.
Change-Id: I71950ca3ce206378a68fa7f97c19f638183d6cdd
Reviewed-on: https://review.haiku-os.org/c/1032
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Nothing that uses this API at present needs a const iterator (and
as far as I could see, nothing ever called Remove() on the iterator.)
But this is now how HashMap's API works, so let's be consistent.
Changes are pretty straightforward. The iterator is now const
again, but can be passed to the hash table itself for removal
of the current item.
Change-Id: Ifd3c8096ffb187a183ca5963ed69a256562a524f
Reviewed-on: https://review.haiku-os.org/c/1042
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The HashMap and HashSet classes are copied from userlandfs. The
HashMap one works as-is as it's already used in userlandfs; the
HashSet does not even compile yet.
Change-Id: I1deabb54deb3f289e266794ce618948b60be58c0
Reviewed-on: https://review.haiku-os.org/c/1041
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There isn't much use for a class that can only compute the dates of
two minor and one major holiday. Probably in the future the Locale Kit
could be extended to expose ICU holiday APIs, but seeing as that
is a less-used functionality, this can just be removed altogether
for now at least.
Change-Id: I18be044be7d5c6896295ed85d294abeea90b8bb0
Reviewed-on: https://review.haiku-os.org/c/1037
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* This indicates the view will manage whatever scrollbars are targeted
to it.
* Use _B_RESERVED7_ for this. It's been RESERVED since BeOS R5
(I guess it was probably something on some older BeOS version?)
and we don't really care about BeOS R4 ABI compatibility, so
that should be fine.
* Update BScrollView to not touch BScrollBar range/proportion
when the target view has this set.
* Update BListView to set this flag, always.
Fixes#14871.
Change-Id: I17027f3b63ef28da1e735c5393593496c415dce3
Reviewed-on: https://review.haiku-os.org/c/998
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
No "real" functional change, but this causes GCC7 to throw errors when
these functions are declared without the image_id argument, which
in some files they were (as this commit repairs.)
This change is largely inconsequential on x86, but on callee-cleanup-args
targets, leaving out the argument would probably cause stack corruption.
Previously, __haiku_init_before was a symbol that was included in
each (shared) object, and so it could be used to determine what
one we were in. Now, there are no such universal symbols that
are declared private to only the object, so we have to use
a different approach.
__func__ is defined as a const char* at the very beginning of
every function it's used in, set to a string of the function name
only, i.e., the arguments and return type are left off. So while
including that is perhaps not quite optimal, in practice this
definition is used extremely rarely (it was introduced by Haiku,
and it is used in only 2 applications at all that I could find --
WebKit and Canna.)
There really isn't any other way to get a pointer that we know
for certain is within the current object besides this one
without inserting one, but that really isn't merited just for this.
(__builtin_return_address() has problematic semantics wrt. inlining,
including linker-inlining.) So this will have to do.
It is only used as an argument to _kern_load_image directly, not to
any of the load_image functions in image.h, so it belongs in a syscall-
specific header like other such constants.
No functional change intended.
* This iSCSI implementation only worked on PPC big-endian atm.
* We're pretty sure iSCSI support in haiku_loader doesn't make
much sense anymore. iPXE on (on arm,x86,etc EFI/BIOS platforms)
supports iSCSI boot of disks.
* Haiku could use a iSCSI driver add-on, but it would exist much
higher up and likely use standard drivers vs bare-minimum iSCSI
target impementations.
* Leaving TCP and adding to all arches since it could make sense
for haiku's native network disk subsystem or network debugging?
Change-Id: Ic181b93a1d8ffd77f69e00e372b44b79abbddb42
Reviewed-on: https://review.haiku-os.org/c/899
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Better performance by using a single write, and some servers may not be
happy about getting so many TCP fragments for the HTTP header.
Change-Id: If7139e2a7748ea423d470676e70bd523a89031b2
Reviewed-on: https://review.haiku-os.org/c/909
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
Change-Id: Ie69f9399cab41d2d492d469b5d3dc88e6080c15c
Reviewed-on: https://review.haiku-os.org/c/876
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This seems to fit the "spirit of layout" better.
Change-Id: I7a75b58de4c9f703d828cdd292b7b91ee720c135
Reviewed-on: https://review.haiku-os.org/c/891
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The old fixed-rect method was very error-prone in corner-cases,
resulting in half-visible (cut off) parameters, incorrectly
sized controls, etc. on various devices, which often made it
impossible to use.
While there are still a few rough edges (scrollbar behavior could
be further improved, though it's already much better than it was before),
this method is much better than the previous one.
Fixes#11592 and related tickets.
Change-Id: I65175f760bda98e42d1fc68ba8e526470bf17c25
Reviewed-on: https://review.haiku-os.org/c/889
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Implemented against POSIX-1.2013.
The implementation POSIX requirement thats setpriority() shall affect the
priority of all system scope threads only extends to POSIX threads. This
is implemented by modifying the default attributes for newly spawned
pthreads.
It is not possible to modify the default pthread attributes for different
processes with the current implementation, as default pthread attributes
are implemented in user-space. As a result, PRIO_PROCESS for which and 0
for who is the only supported combination for setpriority().
While it is possible to move the default attributes to the kernel, it
is chosen not to so as to keep the pthread implementation user-space only.
POSIX requires that lowering the nice value (increasing priority) can be
done only by processes with appropriate privileges. However, as Haiku
currently doesn't harbor any restrictions in setting the thread priority,
this is not implemented.
It is possible to have small precision errors when converting from Unix-
style thread priority to Be-style. For example, the following program
outputs "17" instead of the expected "18":
#include <stdio.h>
#include <sys/resource.h>
int
main()
{
setpriority(PRIO_PROCESS, 0, 18);
printf("%d\n", getpriority(PRIO_PROCESS, 0));
return 0;
}
The underlying reason is because when you setpriority() both 18 and 19
are converted to the Be-style "2". This problem should not happen with
priority levels lower than or equal to 20, when the Be notation is more
precise than the Unix-style.
Done as a part of GCI 2014. Fixes#2817.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Co-authored-by: Leorize <leorize+oss@disroot.org>
Change-Id: Ie14f105b00fe8563d16b3562748e1c2e56c873a6
Reviewed-on: https://review.haiku-os.org/c/78
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Registrar schedules an event every second to do
fRoster-CheckSanity(). This uses 2.5% cpu on my machine
when idle. Changing it to five seconds lowers it to 0.1%
waddlesplash then pointed me to this bug which changes it
to watch for team deletion and call fRoster->CheckSanity()
As I know little in this area, it's mostly based on what
LaunchDaemon does in MessageRecieved.
Just use BControLook where appropriate. It already provides a nice arrow
drawing function (also used in DeskBar expander and in scrollbar
buttons).
Fix second part of #8900
Changes by John Scipione:
Update menu mark and submenu arrow color with menu text color
Use text color for checkmark and submenu arrow colors, tint less black.
This means that colored bg/white text menu item will also draw a white
checkmark and submenu arrow.
Break out BMenuItem::Draw functionality into private methods _IsActive,
_LowColor() and _HighColor() methods and use them to set the mark colors.
Scale submenu arrow and checkmark with item height (which scales with
font size.)
does not align shortcuts with submenu arrows... but if you were to do
that you'd add item->Bounds().Height() / 2.
Signed-off-by: John Scipione <jscipione@gmail.com>
Change-Id: I8299094ef88bf227510b116eb1b84c261dc94723
Reviewed-on: https://review.haiku-os.org/c/341
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().
Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
* I want to introduce a new way for plugins to
register for a format. Supporting the old FormatManager is
too painful at this point and not worth the effort.
* We don't aim to replicate this functionality. I don't
think this will be useful at all in future iterations.
Originally I planned to rewrite it on top of the new
BMediaFormat, but now I am of the hopinion this is
greatly unneeded.
* Adds some missing methods signatures.
* integer vs float framerate is a longstanging debate. In theory,
in digital a/v there should not be need for floating point framerates.
This is because unless the software is run on exoteric hardware, there
is not need for it. Unfortunately, some legacy from the past like the
29.7 hz debate (NTSC) still may need to work under floating point framerates.
Even if in pratice it'd be run at 30 hz anyway.
* In theory, to handle all those correctly we should use a rational framerate,
however most code should be rewritten to support that correctly, and
it'd add some excessive complexities.
* All integer types are reverted back to unsigned ones. There's really
no reason to use signed integers there, and more importantly the danger
for integer underflows and the attached security concerns is very big.
