the 9000 series uses a new receive descriptor format
wich appears to reqire 4k aligned buffers. the old
format "halfworks" and just makes the firmware not
respond to any commands after the enable paging command.
the smartfifo command appears to causes problems.
but apparently not issuing it at all seems to work
fine on both the 8265 and 9260. so removing the code
for now.
issuing the bindingquota command before associated
makes association impossible. but enabling afterwards
works fine. (tested in 8265 and 9260).
the prph access functions now mask the address with
0xfffff. it is unclear why linux and openbsd drivers
specify addresses beyond that in ther register constants.
the timeevent change is interesting. the timeevent
needs to be restarted when it has stoped to make sure
probing/association packets are sent during the evnet.
Complete the conversion of upas to remove ctime,
use the new date library, and print time zones
in +hhmm format, instead of NNN format.
This may affect code that expects specific names
for timezones. Fix that code.
Recently the script which generates tab.h and the code including it got
incompatibly changed. People reported problems involving syntax errors
when trying to rebuild the system following a sysupdate.
The problem was with the script being embedded within a mkfile rule,
meaning that mk didn't notice it changing and therefore didn't rebuild
the target file. For people who were rebuilding the system this meant
that the old tab.h got included, causing syntax errors.
This patch moves the codegen script into a file and tells mk about this
new dependency, so that tab.h will get rebuilt for everyone. I also
took an opportunity to rewrite the script, hopefuly making it easier to
follow.
RFC959 says:
"The ALLO command should be treated as a NOOP (no
operation) by those servers which do not require
that the maximum size of the file be declared
beforehand..."
Ignoring '?' when formatting date strings allows
the format strings to be reused for parsing. This
is convenient, since we don't need to duplicate
the format strings.
Import the following improvements and bugfixes from plan9port:
4650064a acme: scale window bodies on resize, not including tag space
d28913a9 acme: save/restore multiline tags in Dump/Load
d2df5d6c acme: fix crash in X |cat with multiple windows
3d6e5cb5 acme: preserve window position and selection during Get
The format produced by `diff -u` is inferior to that
produced by `diff -c`, but it's what ape/patch and
unix patch expect, so it's useful to generate it.
This patch adds `diff -u`.
Following is a list of functional changes:
* The -o flag outputs the entire buffer to the length returned
by the syscall, or, in case of fd2path(2) and errstr(2), to '\0'.
* The -x flag is removed; the above makes it possible to pipe
into xd(1) to get the same result.
* The -s flag uses dirfmt(2) to format the stat message, instead
of trying to imitate ls(1).
* Stderr reports are normalized and made easier to parse.
The code also suffered a number of stylistic changes.
Right now, upasfs exposes header lines as is, without stripping
out new lines. It also documents that it provides one header per
line in the info file.
As a result, when we get a mail with headers that span lines,
our tools get confused.
These split lines are not semantically meaningful. From RFC5322:
2.2.3. Long Header Fields
Each header field is logically a single line of characters comprising
the field name, the colon, and the field body. For convenience
however, and to deal with the 998/78 character limitations per line,
the field body portion of a header field can be split into a
multiple-line representation; this is called "folding". The general
rule is that wherever this specification allows for folding white
space (not simply WSP characters), a CRLF may be inserted before any
WSP.
As a result, to simplify processing, we should just strip out the
line separators when exposing the headers from upasfs.
The new pci code is moved to port/pci.[hc] and shared by
all ports.
Each port has its own PCI controller implementation,
providing the pcicfgrw*() functions for low level pci
config space access. The locking for pcicfgrw*() is now
done by the caller (only port/pci.c).
Device drivers now need to include "../port/pci.h" in
addition to "io.h".
The new code now checks bridge windows and membars,
while enumerating the bus, giving the pc driver a chance
to re-assign them. This is needed because some UEFI
implementations fail to assign the bars for some devices,
so we need to do it outselfs. (See pcireservemem()).
While working on this, it was discovered that the pci
code assimed the smallest I/O bar size is 16 (pcibarsize()),
which is wrong. I/O bars can be as small as 4 bytes.
Bit 1 in an I/O bar is also reserved and should be masked off,
making the port mask: port = bar & ~3;
There were a number of ideas that were tried out as the tmdate
api evolved. As a result, there were some references in the
manpage to things that are no more.
Fix them.
Ctime is defined as printing a 3-character timezone
name. The timezone name is ambiguous. For example,
EST refers to both Australian and American eastern
time. On top of that, we don't want to make the
tzabbrev table exhaustive. So, we put in this hack:
Before we consult the well known table of timezones,
we check if the local time matches the timezone name.
On top of that, tm2sec
If you want unambiguous timezone parsing, use numeric
timezone offsets (Z, ZZ formats).
do not try to parse the m->unixfrom field, it only contains
the unix mail address.
instead, have parseunix() save a pointer into the unixheader
after the unix mail address for the unixdate, and later use
it to derive the mails timestamp.
Our ctype.h mistakenly ommitted isblank. Add it in.
While we're here, the make the 'isfoo()' functions
are broken: they're offsetting into the array, and
don't work with negative character values.
Sync the function bodies with the macros, and make
them produce correct results.
In addition to being more code, this date parser would
treat local times as local, but anything that wasn't a
local time would get parsed as gmt, due to a quirk of
how tm2sec used to work.
This moves the code to tmparse, and fixes timezone parsing
at the same time.
We almost always want to skip leading whitespace in time
formats, so make tmparse just do it. This fixes upas mbox
parsing, which leaves a leading whitespace at the start of
the date.
Old users of the time APIs would hand-craft
time structs without first zeroing all the
members. When this got into tmnorm(), we
would try to access the new members, and
things would go off the rails.
This makes tm2sec() clear the new fields
before passing them to the new APIs, so
that the hand-crafted structs remain
valid.
The Abind case in namec() needs to cunique() the chan
before attaching the umh mount head pointer onto it.
This is because we cannot give a reference to the mount
head to any of the mh->mount...->to channels, as they
will never go away until the mount head goes away.
This is a cyclic reference.
This could be reproduced with:
@{rfork n; mount -a '#s/boot' /mnt/root; bind /mnt/root /}
Also, fix memory leaks around cunique(), which can
error, leaking the mount head we got from domount().
Move the umh != nil check inside cunique().
The putc macro is specified as returning an int, but our
type conversion rules turned it into a uint. Put in the
appropriate cast to make the type what we want.
aux/na was comparing the return of putc with <0, when it should
have been comparing against EOF, which is not specified as -ve.
aux/ms2 was zero-extending the mask for the address when it
should have been sign extended.
The current date and time APIs on Plan 9 are not good. They're
inflexible, non-threadsafe, and don't expose timezone information.
This commit adds new time APIs that allow parsing arbitrary
dates, work from multiple threads, and can handle timezones
effectively.
C99 integer constants with no type suffix promote differently
depending on the way that they're written: hex and oct consts
promote as int => uint => long => ulong => vlong => uvlong.
Decimal constants are always signed.
We used to promote all values to uint on overflow, and never
went wider. This change fixes that, and adds a warning when
a decimal constant that would have been promoted to uint in
the past gets promoted to int.
The de-duplication of txt, nullrr, cert, key and sig records
reduced all records to a single one.
Also, dblookup1() missed the txt record case and did not return
a unique list of rr's.
Now we consider these records unique if their value is different.
The new txtequiv() function does that for TXT records, which is
a bit tricky as it needs to take different segmentation into account.
the previous patch broke 64-bit ops as the type for the
operation is determined from the first argument to
gopcode() (nod1.type), not the type the result (nod.type).
so we need to include the conversion of nod1 type to
the type of nod.
the bug can be reproduced with the following test case:
#include <u.h>
#include <libc.h>
void
main()
{
int size = 1;
size*=1.5;
exits(0);
}
this produces the following assembly:
TEXT main+0(SB),0,$16
MOVW $1,R1
FCVTZSDW $1.50000000000000000e+00,R2 <- tries to convert rhs to int??
MULW R2,R1,R2 <- multiplication done in int? bug!
MOV $0,R0
BL ,exits+0(SB)
RETURN ,
END ,
the confusion comes from the *= operation using the wrong type
for the multiplication. in this case we should use the float
type of the rhs, do the operation, and then convert the result
back to int type of the lhs.
this change ports the same logic from 5c's getasop().
Characters greater than 0X80 will cause a read beyond the bounds of the
array chars[]. For particular unicode characters this can cause deroff
to segfault.
A minimal example:
$ deroff
.EQ
u∈
Segmentation fault
Throughout deroff, charclass() is used instead of directly indexing
chars[] so I presume this was just missed.
version(5) says:
If the server does not understand the client's version
string, it should respond with an Rversion message (not
Rerror) with the version string the 7 characters
``unknown''.
Pre-lib9p file servers -- all except cwfs(4) -- do return Rerror.
lib9p(2) follows the above spec, although ignoring the next part
concerning comparison after period-stripping. It assumes an
Fcall.version starting with "9P" is correctly formed and returns
the only supported version of the protocol, which seems alright.
This patch brings pre-lib9p servers in accordance with the spec.
The current logging prints a debug line for every
message in an inbox, which is unusably verbose.
This removes the prints for unchanged messages,
and adds a print for flag changes.
