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.
Change-Id: I7aef31e72a826936c45e3644a72eb0598386f1ae
Reviewed-on: https://review.haiku-os.org/c/1309
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
We need these only for gcc2, which doesn't have builtins.
Only swapping floats and doubles remains to implement for all
architectures.
Change-Id: I60e39ad42d4ef762f3324f934f2996dde1412f1a
Reviewed-on: https://review.haiku-os.org/c/1182
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
- Add 128 bit long double support from current glibc and a few headers
they need
- Move the existing 80 bit float support in a sub directory of generic,
it is not universal to all archs (see file added in docs/develop/arch).
Also include some new .h files for x86 that are needed after these
changes (from newer versions of the glibc).
- Adjust Jamfiles for m68k, x86 and x86_64 to use the 80bit format
- Do not adjust arm jamfiles, it was wrongly using 80bit long double and
should be fixed to use 64bit instead (which means the double functions
can be used with aliases)
- Do not adjust powerpc jamfiles, because it uses yet another format and
we build it without long double support anyways.
Note that I moved only the files that were creating compile errors,
quite likely more of the s_* and e_* files need to be moved to the
specific directories, see glibc list here:
https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/ieee754/ldbl-128https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/ieee754/ldbl-96
Change-Id: Ic2d8a454ba9a3b99638e4fbb63daf02df0fea403
Reviewed-on: https://review.haiku-os.org/c/1143
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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>
We allowed a delay only for few DHCP states. As a result, DHCP requests
would timeout immediately after sending the initial discover, and
moreover the code would then switch to "renew" state, trying to renew
without an assigned address.
The result is a quick succession of DISCOVER and empty REQUEST messages.
Eventually, the server could send us an OFFER as reply to our DISCOVER,
unless it decided that the empty REQUEST means "I'm requesting from
another server", which would lead it to cancelling its lease.
This would only work by luck on unbusy networks unlike the one I'm using
today.
Change-Id: I86905b341dc70f7dbcc780b954005e39e7c39ee0
Reviewed-on: https://review.haiku-os.org/c/1296
Reviewed-by: waddlesplash <waddlesplash@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>
I tried to use the feature stuff to relocate objects but didn't managed
to get it to work, having another subdir seems to be the simplest
solution.
I managed to mount a clone of my BeBox' drive, but it KDLed shortly when mouting
read-write.
Change-Id: Ia4f126673e553e4f3e524a40218e6c623527b96d
Reviewed-on: https://review.haiku-os.org/c/645
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Actually use the global mutex instead of creating useless MutexLockers.
* Don't delete the device object on _free(), then it can't be opened again,
which we want to be possible. Matches the behavior of other audio drivers.
* Clean up device detection code to better match other drivers.
At least under XHCI, multi_audio_test throws a variety of errors and then
crashes while attempting to use this driver. But following implementing
CancelQueuedTransfers, the system no longer KDLs after that. Progress!
Seems to work OK on my hardware now. Possibly helps with device unplug/replug
issues; though that worked on my hardware before this change, too. This is
now more correct at least.
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>
No sparc implementation actually has "long double" implemented in
hardware. The instructions are defined in the spec, but they are caught
and emulated by traps.
gcc even bypasses the traps and calls the support functions directly.
Import the required functions from FreeBSD (they implement the
operations as specified in the sparc ABI) and link them into the kernel,
for now (they will also need to be in libroot).
Change-Id: Ifc21faa29fffa4bf5d3941468b62d81229a44971
Reviewed-on: https://review.haiku-os.org/c/1137
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's trying to set a field that doesn't exist.
Change-Id: Ic45b966585486d5da07ee8dace35160dac9355ed
Reviewed-on: https://review.haiku-os.org/c/1106
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It is cast to a struct with 64bit fields, so it should be aligned
properly.
Change-Id: I513cfba4d8fc4f4286b13edabc47fbbda3227bf6
Reviewed-on: https://review.haiku-os.org/c/1089
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These changes had been on review on Gerrit for a few weeks, why do the
comment come only after they were merged?
Change-Id: I54064973e08b8b4dc0624f4c09c7cafb7f04e437
Reviewed-on: https://review.haiku-os.org/c/1185
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This went through review way too fast once again. I did warn that these
changes were completely untested, and indeed this one was broken. Be
very careful when pressing the submit button, please!
Change-Id: I6e0230efe94830033f5427451f67fe6ce29a28e6
Reviewed-on: https://review.haiku-os.org/c/1184
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Check "endpoint == NULL" instead of the ID for this pipe; as
_InsertEndpointForPipe will have already done the check for us.
* Store the endpoint's ID (our internal ID) in the structure, and
then move the doorbell-ring into _LinkDescriptorForPipe. Now all
variables named "id" are actually that, and not the endpoint number
(which is "id + 1".)
* Return actual statuses in NotifyPipeChange, among other tweaks.
* All things which set the usb_request_data structure also set data,
so we can just use ReadDescriptor to do copies like normal, simplifying
the finish-transfers code.
No (major) functional change intended.
