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 is the driver for Intel's new line of desktop-class ethernet
controllers, from FreeBSD. Not yet included in the builds as it
is untested.
Part of #17212.
Now that there is also a "tap" driver in here, and the WiFi drivers
are also in a subdirectory, moving the physical ethernet device drivers
to a subdirectory also makes sense.
(Briefly) discussed on the mailing lists.
This cuts out almost 40,000 lines of these headers. (I did something similar
in the atheroswifi AR93xx/94xx driver when importing it from FreeBSD,
which had a lot more than 40,000 lines.)
The code in this module was derived from the one in driver/tty. However,
the driver uses a shared lock between the master and slave side of a
TTY, and this was changed to use two separate locks. The approach with
two locks does not work. It seems the change was unfinished and the
second TTY was never locked. But attempting to lock it will result in
lock inversion problems, unless we do complicated things (try to find
which of the two TTY is the master side, and lock that first, for
example). It is simpler to restore the shared lock as used in the
driver.
To set up the shared lock, I modified the tty_create function to take a
pointer to the master TTY when creating the slave. Maybe it makes more
sense to create both sides in the same call, create_tty_pair?
However, this does not work as easily as I wanted, because there is some
recursion going on: at least in one case, the tty_control function is
calling the driver's tty_service function, which in turns attempts to
call back into tty_control for the "other side" TTY. To handle this
case, replace the mutex with a recursive_lock.
Fixes #17091, where the root problem was access to
other_tty->select_pool without locking. This was also made unconvenient
to debug because select_pool objects are self-deleting, when the last
item in the pool is removed. As a result, the code accessing it without
log would suddenly find out that the data it was accessing had been
freed and erased.
This also makes the TTY code in driver/tty and generic/tty a bit more
similar than it was before, and brings us one step closer to merging the
two together. There are still two main differences and I don't know
enough about TTY to decide if they are important, and which version
should be kept:
- The driver has extra code for "background" read and write. I don't
know what this is used for.
- The driver has a single "settings" instance shared by a master and
slave TTY, while the module has two separate instances, but seems to
copy one to the other. I'm not sure which approach is correct.
Change-Id: Ie2daddd027859ce32ba395af76b4f109f8b984b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4604
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There is no need to construct and destruct nested objects. The new and
delete calls on the struct will take care of it. However, some fields
have C functions for construction/destruction and these should be
called.
Change-Id: I09d5930f499ef3fa4ff580d482c682172b00b6a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4603
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Suggested by axeld on the mailing list a while back.
strlcpy/strlcat NULL-terminate within the passed buffer size,
so we have no need to subtract 1 here.
The changes for iflib reorganized some things that these drivers used,
so here we upgrade them as well.
One new chipset is supported in rtl81xx, the rest should all just be
API changes.
In 47404f12f2, a MemoryDeleter was added
to manage this memory instead of doing it manually; most of the free()s
were removed in that commit, but these were somehow missed.
It will be needed in the VESA driver to locate things in the VESA BIOS.
Change-Id: Iab42886beb99414fec4d1ad99a08299be679b4d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4623
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These will be needed to implement custom modes in the VESA driver.
Change-Id: I9b52de691baa14e1f1a3ccce500ced9bb040b113
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4622
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This will be used for live patching of the VESA BIOS.
Change-Id: I66c2dfd950262b5ba4d1e7b424eac46f0695297a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4621
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should resolve the problems where the framebuffer driver was
getting picked instead of the "real" graphics driver, when available,
which led to the framebuffer driver getting merged back into the VESA
driver.
Change-Id: I4ad00d2ac3b5dda34aa63f8691d4cbb85e4f6bb5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4616
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit a0db7ef272.
This reverts commit 40cdf7d607.
This reverts commit 2ff22d6734.
This reverts commit b9eacd390d.
This partially reverts commit 5ae7ac5fd9.
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>
This reverts commit 72fc5e6a71.
They were removed because app_server often picked them instead of
a better graphics driver, and fallbacks merged into VESA instead.
That seems to have created more problems than it solved, in the long run,
and so the intent now is to change app_server to understand the
framebuffer driver as a fallback one instead.
Change-Id: I6edd97fb29ed2b9c13c6c540569695c8426ecfd7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4614
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Do not rely on symbols overriding other symbols, which is
not a safe assumption and not good practice either. Instead,
move all methods into FlatControlLook.
* Reorganize class structures somewhat.
* Remove unused variables.
The bootloader is larger after adding zstd and needs more space now.
384 is the value used already on PPC and SPARC. Fixes generating
floppyboot archives for anyboot images following recent changes.
any ordering is legal, but some devices don't cope with what we do.
thus we reorder sack_permitted before timestamp, this doesn't cost us anything.
noticed by Sikk: https://dev.haiku-os.org/ticket/13681#comment:11
Change-Id: Ic2e1589945dd74e3034a653427a2ff45626b3a76
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4598
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Now that it is not used anywhere in the source tree following
previous commits.
Change-Id: Id2fc417a0658d09148e99587c613a928f1fbe4c2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4611
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Augustin Cavalier