arm is a little more complicated because it has three cases:
- big-endian data, big-endian instructions
- big-endian data, little-endian instructions
- little-endian data, little-endian instructions
Like dkopen, except it is possible for this to be called after the
wedge has transitioned to dying.
XXX sc_state read here races with sc_state write in dkwedge_detach.
Could change this to atomic_load/store.
This cannot be called before dkwedge_attach for the same unit
returns, so sc->sc_dev is guaranteed to be set to a nonnull device_t
and the state is guaranteed not to be larval.
And this cannot be called concurrently with dkwedge_detach, or after
dkwedge_detach does vdevgone until another wedge with the same number
is attached (which can't happen until dkwedge_detach completes), so
the state is guaranteed not to be dying or dead.
Hence sc->sc_dev != NULL and sc->sc_state == DKW_STATE_RUNNING.
Still races with parent detach but maybe this is better.
XXX Maybe we should ditch dkwedge_get_parent_name -- it's used only
by rf_containsboot, which kinda suggests it shouldn't exist.
These have not yet finished a concurent dkwedge_attach, so there's
nothing we can safely do with them. Just pretend they don't exist --
as if we had arrived at the lookup a moment earlier.
No longer necessary to go through the dkwedges array.
Currently device_lookup_private still involves touching other global
locks, but that will change eventually to a lockless pserialized fast
path.
This way, indexing of the dkwedges array coincides with numbering of
autoconf dk(4) instances.
As a side effect, this plugs a race in dkwedge_add with concurrent
drvctl -r. There are a lot of such races in dk(4) left -- to be
addressed with more device references.
New functions:
- config_found_acquire(dev, aux, print, cfargs)
- config_attach_acquire(parent, cf, aux, print, cfargs)
- config_attach_pseudo_acquire(cf, aux)
- config_detach_release(dev, flags)
- device_acquire(dev)
The config_*_acquire functions are like the non-acquire versions, but
they return a referenced device_t, which is guaranteed to be safe to
use until released. The device's detach function may run while it is
referenced, but the device_t will not be freed and the parent's
.ca_childdetached routine will not be called.
=> config_attach_pseudo_acquire additionally lets you pass an aux
argument to the device's .ca_attach routine, unlike
config_attach_pseudo which always passes NULL.
=> Eventually, config_found, config_attach, and config_attach_pseudo
should be made to return void, because use of the device_t they
return is unsafe without the kernel lock and difficult to use
safely even with the kernel lock or in a UP system. For now,
they require the caller to hold the kernel lock, while
config_*_acquire do not.
config_detach_release is like device_release and then config_detach,
but avoids the race inherent with that sequence.
=> Eventually, config_detach should be eliminated, because getting at
the device_t it needs is unsafe without the kernel lock and
difficult to use safely even with the kernel lock or in a UP
system. For now, it requires the caller to hold the kernel lock,
while config_detach_release does not.
device_acquire acquires a reference to a device. It never fails and
can be used in thread context (but not interrupt context, hard or
soft). Caller is responsible for ensuring that the device_t cannot
be freed; in other words, the device_t must be made unavailable to
any device_acquire callers before the .ca_detach function returns.
Typically device_acquire will be used in a read section (mutex,
rwlock, pserialize, &c.) in a data structure lookup, with
corresponding logic in the .ca_detach function to remove the device
from the data structure and wait for all read sections to complete.
Proposed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2023/05/10/msg028889.html
This allows a caller to grab some data, consume part of it, and
atomically update the uio with only the amount it consumed. This
way, the caller can use a buffer of a size that doesn't depend on how
much it will actually consume, which it may not know in advance --
e.g., because it depends on how much an underlying hardware tty
device will accept before it decides it has had too much.
Proposed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2023/05/09/msg028883.html
(Opinions were divided between `uioadvance' and `uioskip'. I stuck
with `uioskip' because that was less work for me.)
man0 creates files, so write to the the OBJDIR instead of the
source directory.
Use TOOL_ appropriately.
Add MAKEVERBOSE support.
Add separate rules to generate:
- all.files: the list of all man files to process (based on mkman)
- manNpages.files: per-section files from all.files. (based on mkman)
- manNpages.ps: per-section .ps from manNpages.files, with
per-file MAKEVERBOSE messages to stderr (as before, just prettier).
- manNpages.pdf: per-section .pdf from manNpages.ps.
Remove the now-obsolete mkman script.
Add TOOL_GROPS and _MKSHMSG_FORMAT to <bsd.own.mk>
Fix a bug that ifconfig ifN media auto doesn't change the setting when
the previous media setting used autonego. When the mii_phy_setmedia()
function is called to change the media to IFM_AUTO, the BMCR_AUTOEN bit was
used to check if the previous setting was IFM_AUTO. It's not correct.
IFM_1000_T also uses autonego. So if a previous setting is IFM_1000_T and
the next setting is IFM_AUTO, mii_phy_auto() is not called if neither
MIIF_FORCEANEG nor MIIF_DOPAUSE are set. As a result, after changing
IFM_AUTO, neither 10Mbps nor 100Mbps are not advertised.
Note that almost all drivers uses MIIF_DOPAUSE flags.
TODO: cleanup ciphy.c and rgephy.c. Those have #ifdef foo.
(Since a few minutes.)
If a line '#if 0' was followed by an unlikely line '#', the second line
was interpreted as '#if' as well.
To detect this bug automatically, a dynamic analysis tool would need to
know that only the memory between lab.mem and lab.mem + lab.len has
defined content. This constraint, in turn, would throw up at the bottom
of copy_comment_wrap, which for a brief moment intentionally violates
this constraint.
Lua reports more details when os.execute fails, which is useful when
running old versions of indent for comparison. The new test driver also
supports multiple test files in the same run.
riastradh