ifconfig magic number
Replace a magic number with the corresponding macro.
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.339
diff -u -p -r1.339 ifconfig.c
--- ifconfig.c 12 Mar 2017 03:18:57 - 1.339
+++ ifconfig.c 21 Mar 2017 05:12:26 -
@@ -1637,7 +1637,7 @@ setifnwkey(const char *val, int d)
nwkey.i_defkid = 1;
if (d == -1) {
/* disable WEP encryption */
- nwkey.i_wepon = 0;
+ nwkey.i_wepon = IEEE80211_NWKEY_OPEN;
i = 0;
} else if (strcasecmp("persist", val) == 0) {
/* use all values from persistent memory */
@@ -2120,7 +2120,7 @@ ieee80211_status(void)
}
}
- if (inwkey == 0 && nwkey.i_wepon > 0) {
+ if (inwkey == 0 && nwkey.i_wepon > IEEE80211_NWKEY_OPEN) {
fputs(" nwkey ", stdout);
/* try to retrieve WEP keys */
for (i = 0; i < IEEE80211_WEP_NKID; i++) {
Re: skeylogin.c: use arc4random_buf instead of /var/db/host.random
Theo Buehler wrote: > libskey reads directly from /var/db/host.random and falls back to the > ctime of /dev/mem or / for generating the fake prompt for the user. > This could be simplified a bit: yeesh, that's very silly. ok
wpa key vs wep key
I see no reason to leave WEP enabled if a WPA key is set, and leaving
WPA enabled when a WEP key is set.
Several cases of "my wifi suddenly stopped working" turned out to be due
to stale WEP keys interfering with WPA. I think it is better to let the
kernel handle this transition instead of requiring 'ifconfig -nwkey'.
Index: ieee80211_ioctl.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v
retrieving revision 1.50
diff -u -p -r1.50 ieee80211_ioctl.c
--- ieee80211_ioctl.c 12 Mar 2017 03:13:50 - 1.50
+++ ieee80211_ioctl.c 21 Mar 2017 05:03:46 -
@@ -55,6 +55,8 @@ void ieee80211_node2req(struct ieee8021
const struct ieee80211_node *, struct ieee80211_nodereq *);
voidieee80211_req2node(struct ieee80211com *,
const struct ieee80211_nodereq *, struct ieee80211_node *);
+voidieee80211_disable_wep(struct ieee80211com *);
+voidieee80211_disable_rsn(struct ieee80211com *);
void
ieee80211_node2req(struct ieee80211com *ic, const struct ieee80211_node *ni,
@@ -166,6 +168,32 @@ ieee80211_req2node(struct ieee80211com *
ni->ni_state = nr->nr_state;
}
+void
+ieee80211_disable_wep(struct ieee80211com *ic)
+{
+ struct ieee80211_key *k;
+ int i;
+
+ for (i = 0; i < IEEE80211_WEP_NKID; i++) {
+ k = &ic->ic_nw_keys[i];
+ if (k->k_cipher != IEEE80211_CIPHER_NONE)
+ (*ic->ic_delete_key)(ic, NULL, k);
+ memset(k, 0, sizeof(*k));
+ }
+ ic->ic_flags &= ~IEEE80211_F_WEPON;
+}
+
+void
+ieee80211_disable_rsn(struct ieee80211com *ic)
+{
+ ic->ic_flags &= ~(IEEE80211_F_PSK | IEEE80211_F_RSNON);
+ memset(ic->ic_psk, 0, sizeof(ic->ic_psk));
+ ic->ic_rsnprotos = 0;
+ ic->ic_rsnakms = 0;
+ ic->ic_rsngroupcipher = 0;
+ ic->ic_rsnciphers = 0;
+}
+
static int
ieee80211_ioctl_setnwkeys(struct ieee80211com *ic,
const struct ieee80211_nwkey *nwkey)
@@ -212,6 +240,8 @@ ieee80211_ioctl_setnwkeys(struct ieee802
ic->ic_def_txkey = nwkey->i_defkid - 1;
ic->ic_flags |= IEEE80211_F_WEPON;
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ieee80211_disable_rsn(ic);
return ENETRESET;
}
@@ -464,6 +494,8 @@ ieee80211_ioctl(struct ifnet *ifp, u_lon
if (psk->i_enabled) {
ic->ic_flags |= IEEE80211_F_PSK;
memcpy(ic->ic_psk, psk->i_psk, sizeof(ic->ic_psk));
+ if (ic->ic_flags & IEEE80211_F_WEPON)
+ ieee80211_disable_wep(ic);
} else {
ic->ic_flags &= ~IEEE80211_F_PSK;
memset(ic->ic_psk, 0, sizeof(ic->ic_psk));
@@ -496,6 +528,8 @@ ieee80211_ioctl(struct ifnet *ifp, u_lon
break;
kr = (struct ieee80211_keyrun *)data;
error = ieee80211_keyrun(ic, kr->i_macaddr);
+ if (error == 0 && (ic->ic_flags & IEEE80211_F_WEPON))
+ ieee80211_disable_wep(ic);
break;
case SIOCS80211POWER:
if ((error = suser(curproc, 0)) != 0)
Re: Add a "random" target to bsd.regress.mk
> On Mar 18, 2017, at 8:48 PM, trondd wrote: > > [...] > > Actually, rereading what I quoted, I see you're concerned with unmasking > false positives, which can be manually rerun in isolation to reproduce. > My thought still stands for the flip-side where a test fails due to a > previous test. I think determining a false negative *is* a false negative would require basically the same steps: * Run the test in isolation. * Did it fail? If yes, this is probably not a false negative. If not, you could have a false negative. * Try to reproduce the steps that caused it to fail the first time (you have a record, e.g., on your console, in your logs, etc.). * Can you reproduce it? If you can, you probably have a false negative. Otherwise, something else is off. Not an exact science by any means, but a start. Unless I misunderstood your question. -- Scott Cheloha
log.c warn severity
Hi,
>From a syslog perspective it does not make sense to log fatal and
warn with the same severity. I would like to switch log_warn() to
LOG_ERR and keep fatal() at LOG_CRIT.
ok?
bluhm
Index: /usr/src/sbin/dhclient/log.c
===
RCS file: /data/mirror/openbsd/cvs/src/sbin/dhclient/log.c,v
retrieving revision 1.1
diff -u -p -r1.1 log.c
--- /usr/src/sbin/dhclient/log.c12 Feb 2017 13:15:50 - 1.1
+++ /usr/src/sbin/dhclient/log.c17 Mar 2017 18:18:56 -
@@ -105,17 +105,17 @@ log_warn(const char *emsg, ...)
/* best effort to even work in out of memory situations */
if (emsg == NULL)
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ logit(LOG_ERR, "%s", strerror(saved_errno));
else {
va_start(ap, emsg);
if (asprintf(&nfmt, "%s: %s", emsg,
strerror(saved_errno)) == -1) {
/* we tried it... */
- vlog(LOG_CRIT, emsg, ap);
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ vlog(LOG_ERR, emsg, ap);
+ logit(LOG_ERR, "%s", strerror(saved_errno));
} else {
- vlog(LOG_CRIT, nfmt, ap);
+ vlog(LOG_ERR, nfmt, ap);
free(nfmt);
}
va_end(ap);
@@ -130,7 +130,7 @@ log_warnx(const char *emsg, ...)
va_list ap;
va_start(ap, emsg);
- vlog(LOG_CRIT, emsg, ap);
+ vlog(LOG_ERR, emsg, ap);
va_end(ap);
}
Index: /usr/src/sbin/iked/log.c
===
RCS file: /data/mirror/openbsd/cvs/src/sbin/iked/log.c,v
retrieving revision 1.11
diff -u -p -r1.11 log.c
--- /usr/src/sbin/iked/log.c9 Jan 2017 14:49:21 - 1.11
+++ /usr/src/sbin/iked/log.c17 Mar 2017 18:19:03 -
@@ -124,17 +124,17 @@ log_warn(const char *emsg, ...)
/* best effort to even work in out of memory situations */
if (emsg == NULL)
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ logit(LOG_ERR, "%s", strerror(saved_errno));
else {
va_start(ap, emsg);
if (asprintf(&nfmt, "%s: %s", emsg,
strerror(saved_errno)) == -1) {
/* we tried it... */
- vlog(LOG_CRIT, emsg, ap);
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ vlog(LOG_ERR, emsg, ap);
+ logit(LOG_ERR, "%s", strerror(saved_errno));
} else {
- vlog(LOG_CRIT, nfmt, ap);
+ vlog(LOG_ERR, nfmt, ap);
free(nfmt);
}
va_end(ap);
@@ -149,7 +149,7 @@ log_warnx(const char *emsg, ...)
va_list ap;
va_start(ap, emsg);
- vlog(LOG_CRIT, emsg, ap);
+ vlog(LOG_ERR, emsg, ap);
va_end(ap);
}
Index: /usr/src/usr.sbin/bgpd/log.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/bgpd/log.c,v
retrieving revision 1.63
diff -u -p -r1.63 log.c
--- /usr/src/usr.sbin/bgpd/log.c24 Jan 2017 04:22:42 - 1.63
+++ /usr/src/usr.sbin/bgpd/log.c17 Mar 2017 18:19:23 -
@@ -105,17 +105,17 @@ log_warn(const char *emsg, ...)
/* best effort to even work in out of memory situations */
if (emsg == NULL)
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ logit(LOG_ERR, "%s", strerror(saved_errno));
else {
va_start(ap, emsg);
if (asprintf(&nfmt, "%s: %s", emsg,
strerror(saved_errno)) == -1) {
/* we tried it... */
- vlog(LOG_CRIT, emsg, ap);
- logit(LOG_CRIT, "%s", strerror(saved_errno));
+ vlog(LOG_ERR, emsg, ap);
+ logit(LOG_ERR, "%s", strerror(saved_errno));
} else {
- vlog(LOG_CRIT, nfmt, ap);
+ vlog(LOG_ERR, nfmt, ap);
free(nfmt);
}
va_end(ap);
@@ -130,7 +130,7 @@ log_warnx(const char *emsg, ...)
va_list ap;
va_start(ap, emsg);
- vlog(LOG_CRIT, emsg, ap);
+ vlog(LOG_ERR, emsg, ap);
va_end(ap);
}
Index: /usr/src/usr.sbin/dhcpd/log.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/dhcpd/log.c,v
retrieving revision 1.1
diff -u -p -r1.1 log.c
--- /usr/src/usr.sbin/dhcpd/log.c 13 Feb 2017 19:13:14 - 1.1
+++ /usr/src/usr.sbin/dhcpd/log.c 17 Mar 2017 18:19:34 -
@@ -105,17 +105,17 @@ log_warn(const char *emsg, ...)
Re: skeylogin.c: use arc4random_buf instead of /var/db/host.random
On Mon, 20 Mar 2017 21:06:23 +0100, Theo Buehler wrote: > libskey reads directly from /var/db/host.random and falls back to the > ctime of /dev/mem or / for generating the fake prompt for the user. You should also remove SKEY_RAND_FILE_PATH from skey.h. OK millert@ with that removed. - todd
skeylogin.c: use arc4random_buf instead of /var/db/host.random
libskey reads directly from /var/db/host.random and falls back to the
ctime of /dev/mem or / for generating the fake prompt for the user.
This could be simplified a bit:
Index: skeylogin.c
===
RCS file: /var/cvs/src/lib/libskey/skeylogin.c,v
retrieving revision 1.59
diff -u -p -r1.59 skeylogin.c
--- skeylogin.c 20 Mar 2017 18:34:52 - 1.59
+++ skeylogin.c 20 Mar 2017 19:25:33 -
@@ -419,9 +419,8 @@ hash_collapse(u_char *s)
static void
skey_fakeprompt(char *username, char *skeyprompt)
{
- char hseed[SKEY_MAX_SEED_LEN], *secret, pbuf[SKEY_MAX_PW_LEN+1], *p, *u;
- u_char flg = 1, *up;
- size_t secretlen;
+ char secret[SKEY_MAX_SEED_LEN], pbuf[SKEY_MAX_PW_LEN+1], *p, *u;
+ u_char *up;
SHA1_CTX ctx;
u_int ptr;
int i;
@@ -443,46 +442,21 @@ skey_fakeprompt(char *username, char *sk
/* Hash the username if possible */
if ((up = SHA1Data(username, strlen(username), NULL)) != NULL) {
- struct stat sb;
- time_t t;
- int fd;
-
/* Collapse the hash */
ptr = hash_collapse(up);
explicit_bzero(up, strlen(up));
- /* See if the random file's there, else use ctime */
- if ((fd = open(_SKEY_RAND_FILE_PATH_, O_RDONLY)) != -1 &&
- fstat(fd, &sb) == 0 &&
- sb.st_size > (off_t)SKEY_MAX_SEED_LEN &&
- lseek(fd, ptr % (sb.st_size - SKEY_MAX_SEED_LEN),
- SEEK_SET) != -1 && read(fd, hseed,
- SKEY_MAX_SEED_LEN) == SKEY_MAX_SEED_LEN) {
- close(fd);
- fd = -1;
- secret = hseed;
- secretlen = SKEY_MAX_SEED_LEN;
- flg = 0;
- } else if (!stat(_PATH_MEM, &sb) || !stat("/", &sb)) {
- t = sb.st_ctime;
- secret = ctime(&t);
- secretlen = strlen(secret);
- flg = 0;
- }
- if (fd != -1)
- close(fd);
- }
+ /* Put that in your pipe and smoke it */
+ arc4random_buf(secret, sizeof(secret));
- /* Put that in your pipe and smoke it */
- if (flg == 0) {
/* Hash secret value with username */
SHA1Init(&ctx);
- SHA1Update(&ctx, secret, secretlen);
+ SHA1Update(&ctx, secret, sizeof(secret));
SHA1Update(&ctx, username, strlen(username));
SHA1End(&ctx, up);
/* Zero out */
- explicit_bzero(secret, secretlen);
+ explicit_bzero(secret, sizeof(secret));
/* Now hash the hash */
SHA1Init(&ctx);
Re: amd64 struct reg
On Mon, Mar 20, 2017 at 09:15:09AM -0700, Philip Guenther wrote: > On Mon, 20 Mar 2017, Dale Rahn wrote: > ... > > Including the thread pointer would seem to make sense, but there is there > > a proc vs process issue there (thread vs p > > Uh, the registers are _all_ per-thread! > > > Philip > Oops? I thought I had deleted that line of comment in the email. I had looked it up and realized my mistake already. Dale Rahn dr...@dalerahn.com
Re: amd64 struct reg
On Mon, 20 Mar 2017, Dale Rahn wrote: ... > Including the thread pointer would seem to make sense, but there is there > a proc vs process issue there (thread vs p Uh, the registers are _all_ per-thread! Philip
Re: amd64 struct reg
On Mon, Mar 20, 2017 at 11:54:03AM +0100, Mark Kettenis wrote:
> > Date: Mon, 20 Mar 2017 13:31:32 +1100
> > From: Jonathan Gray
> > Cc: tech@openbsd.org
> > Mail-Followup-To: Mark Kettenis , tech@openbsd.org
> > Content-Disposition: inline
> > X-XS4ALL-DNSBL-Checked: mxdrop306.xs4all.net checked 210.15.216.215 against
> > DNS blacklists
> > X-CNFS-Analysis: v=2.2 cv=eoad9chX c=1 sm=0 tr=0
> > a=0rbIscUo4apI/L6UuJIdkA==:117 a=0rbIscUo4apI/L6UuJIdkA==:17
> > a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=d_dndPjGE7KARIjjoGsA:9
> > a=CjuIK1q_8ugA:10
> > X-Virus-Scanned: by XS4ALL Virus Scanner
> > X-XS4ALL-Spam-Score: -0.5 () RP_MATCHES_RCVD, UNPARSEABLE_RELAY
> > X-XS4ALL-Spam: NO
> > Envelope-To: mark.kette...@xs4all.nl
> >
> > On Mon, Mar 20, 2017 at 01:35:04AM +0100, Mark Kettenis wrote:
> > > It turns out that pretty much all relevant aarch64 OSes use the same
> > > layout for transferring registers in their debug interfaces. Except
> > > for us. That doesn't make sense and would mean I'd have to do
> > > additional work in my lldb porting efforts.
> > >
> > > Diff below revises "struct reg" for amd64 to be compatible with what
> > > NetBSD provides. That just matches our naming conventions for struct
> > > reg better. The actual names are largely irrelevant as debuggers
> > > hardcode the layouts anyway to support cross-debugging.
> > >
> > > This struct isn't actually used yet, so these changes don't really
> > > have any ABI consequences. But once this is in, I'm planning on
> > > making core dumps and ptrace actually work on arm64.
> > >
> > > ok?
> >
> > It looks like NetBSD just has a cross compiled toolchain
> > nothing that runs on actual hardware.
> >
> > Given FreeBSD does I'd consider that more relevant, and it
> > has:
> >
> > struct reg {
> > uint64_t x[30];
> > uint64_t lr;
> > uint64_t sp;
> > uint64_t elr;
> > uint32_t spsr;
> > };
> >
> > struct fpreg {
> > __uint128_t fp_q[32];
> > uint32_tfp_sr;
> > uint32_tfp_cr;
> > };
>
> The FreeBSD definition is equivalent to the NetBSD one:
>
> lr == x30
> elr == pc
>
> It's just that the names assigned by NetBSD make a little bit more
> sense and follow the pattern we use on many other architectures.
>
> NetBSD also includes the userland per-thread-register which I think is
> a good idea.
>
Naming and order realistically doesn't matter that much, If it is easier to
move registers around to match a userland structure in process_*regs(),
that is reasonable. That said: the more I have followed NetBSD's lead in the
past, the more I have regretted it later.
Including the thread pointer would seem to make sense, but there is there
a proc vs process issue there (thread vs p
using __uint128_t for FPU is a lot better than the uint64 [64] that is there
now.
Dale Rahn dr...@dalerahn.com
Re: [PATCH] sensorsd - Command line switch for alternative configuration file
On Wed, Mar 15, 2017 at 08:49:17AM +0100, Silamael wrote: > On 14.03.2017 12:55, Alexander Bluhm wrote: > > All other error messages are lower case. I would write "err(1, > > "access configuration file %s", configfile)" as err(3) privides a > > reason anyway. > > > > apart from that OK bluhm@ > > > > Upated diff. commited, thanks bluhm
Re: Add a "random" target to bsd.regress.mk
On Sat, Mar 18, 2017 at 05:42:20PM -0500, Scott Cheloha wrote: > My thinking is that statically ordered regression runs can mask > bugs in the software under test and the tests themselves. I would expect to find more issues in the tests than in the software. > In general, a test can put your system into a state that allows a > subsequent test to pass when it would have otherwise failed. Unfortunately I fear a lot of our tests do that. > Randomly ordered regression runs could help to weed these issues > out. Even if no such bugs exist, your randomly ordered regression > runs are stronger statements about your software's correctness and > the independence of each test case. Independent tests cases are useful when fixing tests or doing test driven development. For finding regressions or getting more tests cases for the software they are not so relevant. Did you have a look how many of our regress tests have independent targets? Do you plan to improve this situation? Having a feature that would fail for 80% of our tests does not make sense. I think you try to implement the second step before the first. Look at the tests and figure out wether you want to fix all of them. I expect a lot of work. After this has happened, we could add your target. bluhm
Re: amd64 struct reg
> Date: Mon, 20 Mar 2017 13:31:32 +1100
> From: Jonathan Gray
> Cc: tech@openbsd.org
> Mail-Followup-To: Mark Kettenis , tech@openbsd.org
> Content-Disposition: inline
> X-XS4ALL-DNSBL-Checked: mxdrop306.xs4all.net checked 210.15.216.215 against
> DNS blacklists
> X-CNFS-Analysis: v=2.2 cv=eoad9chX c=1 sm=0 tr=0
> a=0rbIscUo4apI/L6UuJIdkA==:117 a=0rbIscUo4apI/L6UuJIdkA==:17
> a=kj9zAlcOel0A:10 a=6Iz7jQTuP9IA:10 a=d_dndPjGE7KARIjjoGsA:9
> a=CjuIK1q_8ugA:10
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.5 () RP_MATCHES_RCVD, UNPARSEABLE_RELAY
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kette...@xs4all.nl
>
> On Mon, Mar 20, 2017 at 01:35:04AM +0100, Mark Kettenis wrote:
> > It turns out that pretty much all relevant aarch64 OSes use the same
> > layout for transferring registers in their debug interfaces. Except
> > for us. That doesn't make sense and would mean I'd have to do
> > additional work in my lldb porting efforts.
> >
> > Diff below revises "struct reg" for amd64 to be compatible with what
> > NetBSD provides. That just matches our naming conventions for struct
> > reg better. The actual names are largely irrelevant as debuggers
> > hardcode the layouts anyway to support cross-debugging.
> >
> > This struct isn't actually used yet, so these changes don't really
> > have any ABI consequences. But once this is in, I'm planning on
> > making core dumps and ptrace actually work on arm64.
> >
> > ok?
>
> It looks like NetBSD just has a cross compiled toolchain
> nothing that runs on actual hardware.
>
> Given FreeBSD does I'd consider that more relevant, and it
> has:
>
> struct reg {
> uint64_t x[30];
> uint64_t lr;
> uint64_t sp;
> uint64_t elr;
> uint32_t spsr;
> };
>
> struct fpreg {
> __uint128_t fp_q[32];
> uint32_tfp_sr;
> uint32_tfp_cr;
> };
The FreeBSD definition is equivalent to the NetBSD one:
lr == x30
elr == pc
It's just that the names assigned by NetBSD make a little bit more
sense and follow the pattern we use on many other architectures.
NetBSD also includes the userland per-thread-register which I think is
a good idea.
> > Index: arch/arm64/include/reg.h
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/include/reg.h,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 reg.h
> > --- arch/arm64/include/reg.h17 Dec 2016 23:38:33 - 1.1
> > +++ arch/arm64/include/reg.h20 Mar 2017 00:27:12 -
> > @@ -19,11 +19,11 @@
> > #define _MACHINE_REG_H_
> >
> > struct reg {
> > - unsigned long x[30];
> > - unsigned long x_sp;
> > - unsigned long x_lr;
> > - unsigned long x_pc;
> > - unsigned long x_cpsr;
> > + unsigned long r_reg[31];
> > + unsigned long r_sp;
> > + unsigned long r_pc;
> > + unsigned long r_spsr;
> > + unsigned long r_tpidr;
> > };
> >
> > struct fpreg {
> >
>
efi: device i/o protocol has been replaced
Hi,
the Device I/O Protocol has been replaced by the PCI Root Bridge I/O
protocol. Since we don't make use of it I think it makes sense to
remove the protocol from our headers to actively discourage the use
of that protocol.
Instead it would make sense to add the PCI Root Bridge I/O protocol and
the PCI I/O protocol, but I wouldn't do it as part of this commit.
Opinions? ok?
Patrick
diff --git a/sys/stand/efi/include/efiprot.h b/sys/stand/efi/include/efiprot.h
index 6ed8a28692d..41315db5e44 100644
--- a/sys/stand/efi/include/efiprot.h
+++ b/sys/stand/efi/include/efiprot.h
@@ -371,116 +371,6 @@ typedef struct _EFI_LOAD_FILE_INTERFACE {
//
-// Device IO protocol
-//
-
-#define DEVICE_IO_PROTOCOL \
-{ 0xaf6ac311, 0x84c3, 0x11d2, { 0x8e, 0x3c, 0x00, 0xa0, 0xc9, 0x69, 0x72,
0x3b } }
-
-INTERFACE_DECL(_EFI_DEVICE_IO_INTERFACE);
-
-typedef enum {
-IO_UINT8,
-IO_UINT16,
-IO_UINT32,
-IO_UINT64,
-//
-// Specification Change: Copy from MMIO to MMIO vs. MMIO to buffer, buffer to
MMIO
-//
-MMIO_COPY_UINT8,
-MMIO_COPY_UINT16,
-MMIO_COPY_UINT32,
-MMIO_COPY_UINT64
-} EFI_IO_WIDTH;
-
-#define EFI_PCI_ADDRESS(bus,dev,func,reg) \
- ( (UINT64) ( (((UINTN)bus) << 24) + (((UINTN)dev) << 16) + (((UINTN)func) <<
8) + ((UINTN)reg) ))
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_DEVICE_IO) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN EFI_IO_WIDTH Width,
-IN UINT64 Address,
-IN UINTNCount,
-IN OUT VOID *Buffer
-);
-
-typedef struct {
-EFI_DEVICE_IO Read;
-EFI_DEVICE_IO Write;
-} EFI_IO_ACCESS;
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_PCI_DEVICE_PATH) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN UINT64 Address,
-IN OUT EFI_DEVICE_PATH **PciDevicePath
-);
-
-typedef enum {
-EfiBusMasterRead,
-EfiBusMasterWrite,
-EfiBusMasterCommonBuffer
-} EFI_IO_OPERATION_TYPE;
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_IO_MAP) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN EFI_IO_OPERATION_TYPEOperation,
-IN EFI_PHYSICAL_ADDRESS *HostAddress,
-IN OUT UINTN*NumberOfBytes,
-OUT EFI_PHYSICAL_ADDRESS*DeviceAddress,
-OUT VOID**Mapping
-);
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_IO_UNMAP) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN VOID *Mapping
-);
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_IO_ALLOCATE_BUFFER) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN EFI_ALLOCATE_TYPEType,
-IN EFI_MEMORY_TYPE MemoryType,
-IN UINTNPages,
-IN OUT EFI_PHYSICAL_ADDRESS *HostAddress
-);
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_IO_FLUSH) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This
-);
-
-typedef
-EFI_STATUS
-(EFIAPI *EFI_IO_FREE_BUFFER) (
-IN struct _EFI_DEVICE_IO_INTERFACE *This,
-IN UINTNPages,
-IN EFI_PHYSICAL_ADDRESS HostAddress
-);
-
-typedef struct _EFI_DEVICE_IO_INTERFACE {
-EFI_IO_ACCESS Mem;
-EFI_IO_ACCESS Io;
-EFI_IO_ACCESS Pci;
-EFI_IO_MAP Map;
-EFI_PCI_DEVICE_PATH PciDevicePath;
-EFI_IO_UNMAPUnmap;
-EFI_IO_ALLOCATE_BUFFER AllocateBuffer;
-EFI_IO_FLUSHFlush;
-EFI_IO_FREE_BUFFER FreeBuffer;
-} EFI_DEVICE_IO_INTERFACE;
-
-
-//
// Unicode Collation protocol
//
Re: acme-client doc diff
On 2017/03/18 15:07, Nick Holland wrote: > .It Fl A > -Create a new RSA account key if one does not already exist. > +Create a new RSA account (host) key if one does not already exist. The -A key is for the letsencrypt account, "host key" implies to me that it's the key for the cert you're applying for (i.e. the -D key).. > .It Fl D > Create a new RSA domain key if one does not already exist.
