This is especially important for non-leaf functions; GCC optimizes codes
based on assumption that sp is aligned properly.
Mostly fix broken earmv5 userland compiled by GCC10 due to alignment
faults in ld.elf_so, where {ld,st}rd are used for [sp, #8x].
No regression for ATF is observed for earmv[67]{,hf}{,eb}.
Cloning devices (and also things like /dev/stderr) work by allocating
a struct file, stuffing it in the file table (which is a layer
violation), stuffing the file descriptor number for it in a magic
field of struct lwp (which is gross), and then "failing" with one of
two magic errnos, EDUPFD or EMOVEFD.
Before this commit, all callers of vn_open in the kernel (there are
quite a few) were expected to check for these errors and handle the
situation. Needless to say, none of them except for open() itself did,
resulting in internal negative errnos being returned to userspace.
This hack is fairly deeply rooted and cannot be eliminated all at
once. This commit adds logic to handle the magic errnos inside
vn_open; now on success vn_open returns either a vnode or an integer
file descriptor, along with a flag that says whether the underlying
code requested EDUPFD or EMOVEFD. Callers not prepared to cope with
file descriptors can pass NULL for the extra return values, in which
case if a file descriptor would be produced vn_open fails with
EOPNOTSUPP.
Since I'm rearranging vn_open's signature anyway, stop exposing struct
nameidata. Instead, take three arguments: an optional vnode to use as
the starting point (like openat()), the path, and additional namei
flags to use, restricted to NOCHROOT and TRYEMULROOT. (Other namei
behavior, e.g. NOFOLLOW, can be requested via the open flags.)
This change requires a kernel bump. Ride the one an hour ago.
(That was supposed to be coordinated; did not intend to let an hour
slip by. My fault.)
This change requires a kernel bump.
Note though that I'm not going to version the VOP_LOOKUP args
structure (or any other args structure) as code that doesn't touch
cn_consume doesn't need attention and code that does will fail on it
without further intervention.
other cases underneath it.
The solution here is not really very good (take the longer
path-to-consume if they're different) but it will serve for the cases
that exist.
(If we were to add a fs that really uses different naming semantics,
we'd have to take additional steps; probably it doesn't make sense to
allow unionfs to union such a thing with a normal fs and attempting it
should fail at mount time.)
Update fs/unionfs as well to avoid increasing the current set of
compile failures there. Though maybe it's time to just remove
fs/unionfs.
This checks for a following "/rsrc" at the end of the pathname (to
indicate the resource fork of a file) and assimilates it into the
component name to be looked up. Then cn_namelen will already include
this text in lookup, and it's no longer necessary to muck with
cn_consume.
Invalid uses of "/rsrc" are ignored rather than rejected, which
appears to be the same as the old behavior. It is possible that the
parsepath logic should only consume the "/rsrc" if the name names a
file and not a directory, which would require looking it up in
parsepath and be a general nuisance; I hope not. It's also possible
that the whole thing doesn't work at all now, or it didn't before, as
I don't have any way to test it.
- Move namei_getcomponent to genfs_vnops.c and call it genfs_parsepath.
- Add a parsepath entry to every vnode ops table.
VOP_PARSEPATH takes a directory vnode to be searched and a complete
following path and chooses how much of that path to consume. To begin
with, all parsepath calls are genfs_parsepath, which locates the first
'/' as always.
Note that the call doesn't take the whole struct componentname, only
the string. The other bits of struct componentname should not be
needed and there's no reason to cause potential complications by
exposing them.
the pathname. (Basically, this means change the signature of
namei_getcomponent(), and thus lookup_parsepath(), to pass in the
directory vnode and to allow failures.)
This is a very small step towards having all shared type_t objects only
referenced via const pointers. Since the types may be shared, it is a
bad idea to try to modify them, so better let the compiler check this.
It's a long way to reach this goal, but this small step is already
possible.
No functional change.
verbose mechanism with MIIVERBOSE. This reduces some duplicated code
and allows us to once again permit auto-unload of MIIVERBOSE.
Change details:
* Update dev/devlist2h.awk to accomodate miidevs, including generation
of MII_STR_oui_model definitions and use of oui and model rather than
vendor and product. This also changes the compressed data in the
xxxdevs_data.h files to uint32_t (since mii oui's are up to 6 hex
digits long)
* Update a couple of phy drivers to use new calls to get verbose data
* Regen all of the xxxdevs{,_data}.h files (separate commit, coming
very soon)
* Update mii/mii_verbose.[ch] and mii/mii_physubr.c to use the various
DEV_VERBOSE_xxx macros
* Update the pci, usb, and hdaudio code as needed, to #include the
xxxdevs.h files (in order to get the proper printf format strings)
* Since dev/dev_verbose.c now uses non-literal printf format strings,
(to deal with the vendor/product vs oui/model issue), we need to
make sure it gets compiled with -Wno-error=format-nonliteral, even
in userland's libpci and librumpdev!
* Bump kernel version for the change in module interfaces
Welcome to 9.99.86!
XXX It might be useful in the future to extend the MII_STR_oui_model
XXX definitions to PCI as well (and perhaps USB and HDAUDIO). This
XXX would allow for a single centralized location for the products'
XXX descriptions, rather than being dispersed among individual
XXX drivers' xxx_match tables.
There a 4 regular NetBSD builds where lint is activated. All these
builds run on platforms where char == signed char.
The official test runs from https://releng.netbsd.org/test-results.html
mostly have char == signed char as well.
However, lint behaves differently on platforms with char == unsigned
char. On these platforms, a simple "char ch = '\xff'" leads to the
bogus warning that "conversion of 'int' to 'char' is out of range".
This exists for compatibility with a Linux interface which was apparently
deprecated in Linux 2.6. There are various mailing list threads going
back to 2004 where the usefulness of this driver is discussed, but
the conclusion is that scanner software has all moved to using ugen(4)
instead, and enabling this driver will not help you scan things.
Previously, all tests for lint had to produce the exact same output, no
matter which platform they ran on. This differs from practical needs
since lint is intended to produce different results depending on whether
the platform is ILP32 or LP64.
Examples for these are type conversions and the widths of the integer
types during lexical analysis.
sysinst messages. Closes PR toolchain/56181.
2. Whilst here, change some shell clauses to be more portable.
Patch developed by kre. Also reviewed by martin. Cross-builds tested
on NetBSD, OpenBSD, FreeBSD and Darwin.
The 'identifier' in type_direct_decl is necessary, as demonstrated in
the test d_typename_as_var. Replacing T_NAME with 'identifier' in
notype_direct_decl would increase the shift/reduce conflicts by 6. To
keep this number low, keep everything as-is.
Some tests simply do not work in some environments.
Eg. shell-ksh on macos/arm64
Allow local site to set BROKEN_TESTS to skip those they know
will not work.
Reviewed by: rillig
Originally I only needed a message that would output the type name from
an abstract-declarator (C99 6.7.6), to see whether lint interprets the
types correctly.
Message 155 looked like a good candidate, but it only revealed more
incomplete and untested code in lint.
The previous name 'decl' was ambiguous, it could have meant declaration
as well as declarator. The new names are aligned with C99.
No functional change.
skrll