History log of /haiku/src/libs/compat/freebsd_network/device_hooks.c
Revision Date Author Comments
# 97d55ad4 17-Apr-2023 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Add missing LOCKGIANT to the close() hook.

Should fix #18363.


# 78eb4676 30-Jan-2023 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: NULL-check if_init before calling.

All FreeBSD drivers set it; not all OpenBSD drivers do.


# 44fa45df 13-Jun-2022 Augustin Cavalier <waddlesplash@gmail.com>

net/if: Drop ifmediareq and just use the regular ifreq for SIOCGIFMEDIA.

This was introduced into the main API in 2010 (d72ede75fb252c24c8a5fcc39395f9ae1c202322),
but was actually only fully used for the past month (c2a9a890f3ac7795602d11c0edaa20ac2db48202)
when SIOCGIFMEDIA was supported for all *BSD drivers and not just WiFi.
Most userland consumers of this structure did not use it correctly,
as was the case in #17770, and only worked because in the fallback case
the network stack just treated it as if it were an ifreq.

Nothing actually used the ifm_count/ifm_ulist (though tentative APIs
were exposed for it) as noted by previous commits; and the fact that
Haiku's IFM_* declarations are so spartan makes most of the returned
values unintelligible to userland without using FreeBSD compat headers.

If, in the future, we decide to implement ifmedia listing and selection
properly, that should likely be done with separate ioctls instead of
having multi-function ones like this.

This is technically an ABI break, but in practice it should not matter:
ifmediareq::ifm_current aligns with ifreq::ifr_media, so the things
that used this structure like our in-tree code did will continue to work.
Until this past May, the only other field that was usually set was
ifm_active, but in the absence of setting ifm_status all non-Haiku
consumers should ignore it completely.

The only consumer of this ioctl that I know of out of the tree,
wpa_supplicant, still works after these changes.


# ecf18ba4 13-Jun-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Cleanup around ifmedia handling.

* Remove unused variable.

* Use original value for IFM_AVALID, we do not need to remap this one.
(Actually we do not need to remap IFM_ACTIVE here either, but it makes
some things slightly easier to work with rather than remapping it
in a different location.)


# 8548a4ad 12-May-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Adaptations in preparation for the OpenBSD layer.

Most of these changes however add things that FreeBSD has (with a few
exceptions noted in comments) which the OpenBSD shim layer merely needs
to make use of.

(FreeBSD used to have support for IFF_NEEDSGIANT but removed it. The
support instated here is very similar to what FreeBSD used to have.)


# 44d08ffc 07-Jun-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Add another MTU to attempt to set devices to.

IEEE 802.11 has its own maximum MTU which is smaller than PAGESIZE
but larger than the ETHERMTU default. So we now attempt to set this
as well. In doing so, refactor the set into a loop based off an array
of possible MTUs.


# d765574f 07-Jun-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Adjust too-large packet handling in read().

Before ca6a44c1333c467706a7ceae2842d0de380139cb, this function returned
whatever amount of the buffer it could and silently discarded the rest.
After that change and before this one, it would refuse to return anything,
which meant that as soon as we got one packet too large to handle,
we would never receive any more packets (and the errors displayed in
e.g. ifconfig would go up forever.)

Now, we discard too-large packets so RX will not stall completely
and still return E2BIG (so error counts will go up), but we also
print an error to syslog, so that precisely what has gone wrong
will be easily known.


# 44604448 27-May-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Automatically switch to jumbo-sized MTUs if possible.

Unfortunately there is no way to ask if a device supports jumbo MTUs
besides actually activating it. But that's fine, because for now,
Haiku's own network stack does not actually support changing MTUs
at the device level! Probably that should be fixed, too, but that
is a problem for another day.

With preceding commits, this fixes #17728, and all BSD network drivers
will use jumbo frames if possible by default.


# ca6a44c1 27-May-2022 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Overhaul device read/write functions.

* In read, check that we actually have enough buffer capacity
to read the next buffer on the queue. Otherwise return E2BIG.
(This fixes data being silently discarded if the mbuf was larger
than the passed read buffer, but that should not usually happen
anyway based on MTU buffer sizing.)

* In write, use m_get2 to get an appropriately sized mbuf (which may
be up to 16K) instead of clamping all writes to the cluster size.

These changes are needed for jumbo-frames to be actually read and written
as one unit. However, they are not yet enabled, as more changes are needed
above this point both in ioctl() here and in the stack.


# c2a9a890 05-May-2022 Alexander von Gluck IV <kallisti5@unixzen.com>

compat/freebsd_network: Catch BSD socket ioctl and act on within stack

Change-Id: Iaf7e645836ffee58b3a8a8e5352048412035ab32
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5296
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# b943b993 30-Nov-2020 Jérôme Duval <jerome.duval@gmail.com>

freebsd_network: Use user_memcpy() for ETHER_ADDMULTI/ETHER_REMMULTI

Change-Id: Id0a7e50f9ae38bff42faf1d6c4a62f702347bda3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3446
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# a3dc96a3 23-Nov-2019 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Use ifmedia_baudrate to compute the link speed.

This is much more accurate than testing only 2 IFM_* types.


# 56cb682b 22-Nov-2019 Augustin Cavalier <waddlesplash@gmail.com>

freebsd_network: Moderate reorganization.

* Rename device.c to device_hooks.c, as this is what it really contains.
* Rename compat.c to device.c, as it implements the generic "device"
related functions, both for compat layer internals and FreeBSD
public ones.
* Move malloc and related operations out of the now-device.c,
and place them in a new "malloc.cpp", which also incorporates
compat_cpp.cpp.

No functional change intended.