Some of the functions moved lower in this commit use functions
that were previously defined below them, which was a warning in
GCC but an error in Clang.
It warns when you try to use some standard library functions
without including the system headers, which we don't
care about as we are providing the system headers in the tree.
This just stops the errors from occuring rather than trying to
rebuild the files at all. This is much cleaner, and solves
a few cases that the other method did not.
Since NULL is not considered a user address anymore, we must check for
it first.
This fixes the "mount: Bad address" error after hrev52905.
Change-Id: If60ea58bb81b6c35c6bf27ecfa9b29bd7a25d8aa
The x86_64 buildmaster was only updated past the R1~beta1 version
a few weeks ago, so most packages still have a R1~alpha4_pm dependency.
Thus thus broke the build. Revert it for now so we don't do that.
- Bump year to 2019
- Adjust compat version, use alpha1 for x86 and generic packages, and
beta1 for other architectures since that's where they first appeared
(we will probably bump to beta2 for arm/sparc/ppc when we release
them for real?)
Change-Id: Ibb0968feb28731898776335eba01d34dcb758625
Reviewed-on: https://review.haiku-os.org/c/1069
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is technically only a functional change following the previous
commit, which unconditionally made sure the address was larger than
the base except for B_EXACT_ADDRESS. Essentially this makes sure
that if an address is passed which is smaller than the base is
passed in, it won't immediately fail just by being too small.
Checked against BeOS (0x0 passed to create_area with B_BASE_ADDRESS
succeeds, and returns 0x2000 consistently.) This is also needed
to not break userland initialization following the next commit.
VM86 was removed in 2012, so these are no longer needed.
The USER_BASE vs. USER_BASE_ANY distinction still seems like a
potentially useful one, though, so I've left all those changes in.
This reverts commit 58ed2965d0.
This reverts commit 055d49b1fd.
I was mistaken, it is perfectly legal to block a pinned thread.
It seems we'll need some other way to detect invalid context
switches.
int_io_* functions do not touch the thread state, but we already have
it here as we will modify its contents later, so it makes more sense
to set this flag here.
This is mostly only relevant following the previous commit, i.e.
finding interrupt handlers that brokenly try to context-switch.
Preventing "normal" context switches caused by a time interrupt
is the primary reason for pinning threads. "thread_block" and friends,
however, cause an explicit context switch and will not return until
another thread unblocks us.
Calling these while a thread is pinned is thus undefined behavior,
and so we should just panic in the case anyone attempts to do so.
Previously they would just get -1, as the BusManager class
would request their ID before they had been added to the Stack.
Now we add them to the stack inside ::Start(), rather than letting
the individual drivers do that just after ::Start(), and then assign
the ID there directly.
The Jam build logic for HaikuDepot was potentially creating
a dummy file that was newer than the generated .cpp/.h files.
This then, in turn, caused the dependent .o files to be
considered needing to be re-built. This change will ensure
that the dummy file is touched first so it is not newer than
the generated sources and also if the dummy does end up
being newer then the generated sources will be touched.
trac #14853
Change-Id: Ieefb0b2aa14bf43b7cbbdfee4228c215cad5b6fa
Reviewed-on: https://review.haiku-os.org/c/1070
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Let's make the nightly builds consistent in a way that they would always
be recognized by libosinfo (and, consequently, by GNOME Boxes,
virt-manager, virt-install, ...) by explictly using "nightly" instead
of the $(HAIKU_VERSION) when generating nightly builds.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I6fc4f15be1e8e9244abf14e75308fc825f37b2e8
Reviewed-on: https://review.haiku-os.org/c/1053
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Another FileSystemVisitor implementation will be used for resizing
Change-Id: I2d5f47dcbefb4c76834487b194a99c6f5ae7de50
Reviewed-on: https://review.haiku-os.org/c/923
Reviewed-by: Jérôme Duval <jerome.duval@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>
Older cards did not implement CMD8, so handle the command stalling, and
proceed with initialization (not querying about SDHC support in that
case, as per the spec).
Change-Id: Ie842effc2f99e1adf1990b3215be79db493138b5
Reviewed-on: https://review.haiku-os.org/c/1056
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>
result)
* Altered to avoid use of sprintf/snprintf to copy between the same
source and destination. (This is an undefined result since c99)
* (consequential trailing whitespace removal & line length adjustment)
Change-Id: I43976af43fe99d15b6c2677c5ab05db46fd6a8c0
Reviewed-on: https://review.haiku-os.org/c/1036
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Fix potential leak of 'cookie' at line 2206, which is allocated
at line 2203. Pointed out by Clang Static Analyzer.
* Add NULL check to 'cookie'.
Change-Id: Ibfdbe3a52ceb0d29adf1acca51fb7b27d2c532f3
Reviewed-on: https://review.haiku-os.org/c/1065
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Fix potential leak of 'node' at line 147, which is allocated
at line 123. Pointed out by Clang Static Analyzer.
* Remove trailing tabs.
Change-Id: I2289dfb5a9d0ada1fd7fc3854906d66a730b5bcb
Reviewed-on: https://review.haiku-os.org/c/1058
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
... just like BeOS R5 did.
In 3123432674 (hrev52122) I wrote:
"Undraw the bottom left and top right corners of bitmaps in the
unpressed state. BeOS did not do this (usually), but it should
have as it closes the ring."
This was a bad idea, draw like BeOS R5 instead.
Change-Id: I4eba7566bb31d3e208bc30439b0221b70eeb2bbe
Reviewed-on: https://review.haiku-os.org/c/1066
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Use launch daemon to autostart Launchbox if enabled in settings.
Change-Id: Id0aaf454cfbc0cc42db2dbb54d6788c79dae6949
Reviewed-on: https://review.haiku-os.org/c/917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Private semaphores will have a key of -1, but IPC_PRIVATE is 0,
meaning it is possible to wind up here and get a NULL semaphoreSet
if someone passes us an argument of -1.
Reported on Twitter.
* This is an initial implementation of the DVD streamer.
It needs various development to actually work, so can be
considered as a begin.
* Navigation is not implemented, this needs some work to
add hooks in the BMediaStreamer to allow mouse tracking.
* Stop/Reset/Set was commented out because it caused invalid context
states. This was because we cannot run those commands until after
we have configured the endpoint. Moving them to after that
makes it work properly.
* Add the endpoint to the context after configuring it, not before.
* After configuration, we need to issue either an EvaluateContext
or a ConfigureEndpoint, but not both, depending on whether
this is endpoint number 1 (Control) or not.
All cross-checked against FreeBSD (the last change in particular comes
directly from a change of theirs.)
Tested with usb_disk and usb_hid on already-working hardware, no
obvious regressions. Possibly helps with #13834, among other
initialization problems.
