Tested with VMWare Workstation Pro 17.6.0 with Haiku x86_64 hrev58201.
To test, had to manually open the .vmx file associated with the VM and added the line:
ethernet0.virtualDev = "vmxnet3"
Change-Id: Ic76dcc61583707345bee46624814a38f66eb4f9f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8438
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It helps to simplify to view difference and apply patches.
No functional changes.
Change-Id: Ia29368eceaeb3306990c09da77c4527eff87c72a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7932
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's now at HaikuArchives and supplied in a package at HaikuPorts.
EXR images are rare and mostly used in pretty specific cases, so it
isn't re-added to the default install.
Catalogs are left in-tree until they are purged from Pootle.
Change-Id: I54e478a30e02bdefd1b8fa53c4b66d84ffb04185
(And surrounding portions of the "btCoreData" module.)
* Rewrote the main "l2cap.h" header representing protocol constants
and structures. Now conforms to general Haiku naming conventions
rather than BSD ones. Some more constants added/removed based
on the most recent Bluetooth specification.
* Rewrote all code derived from the BSDs to match Haiku conventions
and structures in the driver.
* Dropped the "channel" and "frame" structures from "btCoreData".
Channels are now managed by L2capEndpoints, and "frames" are
now just plain net_buffers without surrounding structures.
This also makes state management much simpler.
* Made it so that actual net_buffers are passed through to the
l2cap_receive function rather than another data structure.
A fake interface address is used to communicate connection
information. (This probably ought to be changed, though.)
* Get rid of l2cap_lower and l2cap_upper abstractions.
Everything related to channel/endpoint management is now
done in L2capEndpoint, while buffer reception is handled
directly in l2cap_receive and elsewhere, same as other drivers.
* Wire up more hooks and fix module flags (needed to be able to
get the module loaded and opening sockets at all.)
* Implement an actual locking strategy in L2capEndpoint
and HciConnection. There's still problems with lifetime
management, but at least thread-safety is mostly handled.
* Create an L2capEndpointManager and use it to manage
the endpoints, rather than having a single (unsafe)
linked-list.
And plenty of other refactorings and cleanups besides.
There's still more to be done for Bluetooth overall, though:
* The "btCoreData" and "hci" modules also badly need a major
overhaul, and should be merged into a single "bluetooth"
bus_manager. They also shouldn't be passing around pointers
to other modules like this.
* There's a number of TODOs/FIXMEs in the L2CAP module, most
notably around timeouts (especially command timeouts) and
parameter validation/specification.
Tested by myself with kallisti5's help. Incoming connections
(on the PSM for SDP) get all the way to the latter half
of the Configuration step before hanging.
* our ip modules don't support connect()/send(). Just use sendto().
* ping6 disappears, ping supports -4 or -6 to force IPv4 or IPv6
Change-Id: I1e982e354cc75d3a314c5bbbfffa0373e8f4d9af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7427
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Requires multiple media server restarts to switch
outputs to it, but that's a known media services
problem (#12777 and #12776.)
Input doesn't work quite right with the hardware
I've been testing with, but that's also a known
problem it seems (#9951). Meanwhile, output
seems to work pretty well, once it gets going.
* Rename the "tun" network device to "tunnel". FreeBSD calls theirs
"tuntap" but speaks of both TUN and TAP devices as interfaces for
tunnels. The other BSDs seem to do likewise.
* Fold the "tun" driver into the "tunnel" network device. The
network device now publishes entries in devfs when interfaces
are created, and unpublishes them when interfaces are destroyed.
This removes the need for the driver and device to communicate
through a file descriptor, and thus allows the receive queue
to be totally eliminated, massively simplifying that logic.
* Use standard net-stack FIFOs instead of TCP BufferQueue, which is
specialized to TCP's needs in far too many ways. Thanks to the
previous commit adding support for interrupting semaphore waits,
we can use the FIFO wait mechanisms, too.
* Restructure the TAP logic, and generate MAC addresses more like
Linux does.
* Actually set type = IFT_TUN, and use the "loopback" frame handler
instead of the "ethernet" frame handler. This allows significant
cleanup of the header handling logic.
* In TUN mode, reject packets that don't look like IP packets.
* Delete "tunconfig"; it was mostly stubs and is now unnecessary.
TUN mode tested and confirmed as working by kallisti5 with OpenVPN.
TAP mode partially tested, but not yet confirmed as working.
Fixes #18673.
Change-Id: Ibd803139474e8db556a4f567901da15ee4083621
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7143
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
* Assists on early boot platforms to install / upgrade when
no network is available.
* Doesn't introduce any additional dependencies
* Creates shine-though directories too.
Change-Id: I11dd207b2ffbae1768bab7a118a51034df238878
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6185
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
* We depend on FDT passed to the bootloader now
from EFI or u-boot via fdt_addr_r now
* We leave an fdt path within the boot partition
(for now) to allow / encourage users to optionally
plug in their own DTB's for troubleshooting. (only
on u-boot loader)
Change-Id: I3f2d81b60d46f388f333d5caa27aa77e6e36447d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6081
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Tested-by: Automation <automation@haiku-os.org>
It was used only for playing CDs via SCSI commands, which is what
CDPlayer also did; but this is not really much supported anymore,
so CDPlayer was removed years ago, and now this is too.
Its source code lives on at HaikuArchives.
Fixes #18236.
This will allow proper operation of POSIX SHM API (shm_open etc.).
Now memory files are stored fully in memory and do not affect disk
storage (except swap if enabled).
Change-Id: Iae3ce1afa968df72e82198e598a273cbf7cb0269
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5802
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
They are now created from a separate repository and via HaikuPorts.
Since the HaikuPorts packages are not yet in the BuildPackageRepository,
the actual section that adds the packages is commented out (but it only
runs for release-* targets anyway.)
The "welcome", "userguide", and "quicktour" scripts, which are symlinked
from the desktop in release builds, are added to the Haiku package's
"regular" profile instead (they do not actually require the other packages
to be installed but will detect if they are not and launch the online
versions instead.)
Building EFI partition for 32-bit anyboot ISO image was disabled
in hrev52443 to fix issue #14656.
As haiku_loader.efi is now available for the x86 architecture
since hrev55917, we can re-enable building EFI system partition
for the 32-bit ISO.
We can also remove the build rules related to HAIKU_ANYBOOT_LEGACY
as it is not used any more.
Change-Id: I9c2c272bcd0f9c1a98ee6cea300374dc26b4818d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5716
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
These were output to the root of the generated directory. There should
be nothing there except the final Haiku image.
Fixes #16750.
Change-Id: I132de939c70197c3f7cc306ac371965a0b7f38b3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5346
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Based on usb_ecm and other native USB ethernet drivers which share a
similar structure.
References used to implement this:
- FreeBSD urndis driver
- [MS-RNDIS].pdf v20140501
- Microsoft list of RNDIS OIDs
TODO:
- Better handling of "request id" field to make sure the replies we get
match up with the requests we sent, and it could allow to have
multiple requests in flight. However, the FreeBSD driver doesn't
bother to implement this, if you only ever have one request in flight
and wait for a reply before sending another, this isn't really needed.
- Endian safety, this code will only work on little endian systems for
now. Several structures sent/received to/from the device must be little
endian, so on big endian platforms a lot of byteswapping will be needed,
or the code rewritten to use some smarter object and not a plain
struct for all of these.
- Investigate if it's possible to send/receive multiple ethernet frames
in a single USB transaction for better performance. Our driver
structure doesn't really allow for it unless the driver implements
some buffering on its own.
Change-Id: I2c6dacf0c1aeb6c7c1c112e9b16a63e586ea979a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5281
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
-tar fs buffer upgraded to 9Mb
-adding some kernel addons
With this settings i was able to fully boot a gcc2hybrid.
The x86_64 started up to the rocket, but could'nt go into Tracker.
Change-Id: I8f9e1f803f4a918419305bce3068ffce027d2548
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5295
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It doesn't seem to work anymore, and it doesn't look to be particularly
maintained on FreeBSD's side of things. I think kallisti5 was the only
person who ever even attempted to use it.
* Move assets to new boot directory
* -hfsplus not valid anymore on cdrtools 3.02
* Throw down some forth I saw in an *old* fedora 12
chrp script. If we ever target ppc64 it might be
handy someday. The text output also lets you know
the cd booted successfully.
Change-Id: I169d887fe8373de1719b98305d01b714f6f6bcbe
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4681
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
libtermcap was deprecated in favor of terminfo in 2013; the library was
removed then, and this file was only left because not all optional
packages had yet been rebuilt against ncurses. Well, that has now
long been completed, and indeed all applications continue to function
even after removing /etc/termcap.
In case any legacy applications that I have missed still do need it,
it should be provided by HaikuPorts and not Haiku itself.
The other Atheros drivers are "atheros813x" and "atheroswifi",
so renaming this one (which is the oldest of the set) to match
the other two makes sense.
This reverts commit a0db7ef2729955d83f002b51034f0dedd39b4a0a.
This reverts commit 40cdf7d607211c5f27854cd3048ac00e8baf20ab.
This reverts commit 2ff22d6734176a2cf93a05c6842f69ef59d27a26.
This reverts commit b9eacd390dbdf776561062b324dab4c6f5a0dc80.
This partially reverts commit 5ae7ac5fd9957b3ff9faf211fd66976170c21b2c.
This was all added in the run-up to the removal of the framebuffer driver,
or was added since then to enhance framebuffer-only support in that driver.
Change-Id: I32ab8199f22cf6846545ae19e943c98012b2a1d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4615
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Translators and media-plugins are the main source of dependencies in haiku.hpkg,
and thus the main source of packages being pulled into chroots, especially
HaikuPorter chroots. (FFmpeg pulls in a rather large array of sub-
dependencies, itself.) So, here we break all the translators into their
own sub-package.
For now, haiku.hpkg is declared to depend on haiku_datatranslators,
so that users will not suddenly update and have no translators.
In the future, this will be dropped.
Note that this is only done for the primary arch at present.
Secondary architecture translators remain in the main secondary package
for now.
Change-Id: Id0b352f34f7110b79ec7787792bf3ae0edab4054
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4477
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I44211b3533f99338d7246e88593fc8838628904c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4485
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
