boot from softraid, backspace in passphrase prompt
I want correct typing mistakes when booting from softraid crypto disks.
Can we handle at least the backspace key, plz^Hease? :)
diff --git sys/arch/amd64/stand/libsa/softraid.c
sys/arch/amd64/stand/libsa/softraid.c
index 336865a..801cec4 100644
--- sys/arch/amd64/stand/libsa/softraid.c
+++ sys/arch/amd64/stand/libsa/softraid.c
@@ -557,6 +557,10 @@ sr_crypto_decrypt_keys(struct sr_boot_volume *bv)
c = cngetc();
if (c == '\r' || c == '\n')
break;
+ else if (c == '\b') {
+ i = i > 0 ? i - 2 : -1;
+ continue;
+ }
passphrase[i] = (c & 0xff);
}
passphrase[i] = 0;
diff --git sys/arch/i386/stand/libsa/softraid.c
sys/arch/i386/stand/libsa/softraid.c
index 336865a..801cec4 100644
--- sys/arch/i386/stand/libsa/softraid.c
+++ sys/arch/i386/stand/libsa/softraid.c
@@ -557,6 +557,10 @@ sr_crypto_decrypt_keys(struct sr_boot_volume *bv)
c = cngetc();
if (c == '\r' || c == '\n')
break;
+ else if (c == '\b') {
+ i = i > 0 ? i - 2 : -1;
+ continue;
+ }
passphrase[i] = (c & 0xff);
}
passphrase[i] = 0;
diff --git sys/arch/sparc64/stand/ofwboot/softraid.c
sys/arch/sparc64/stand/ofwboot/softraid.c
index 1dadfdb..7654194 100644
--- sys/arch/sparc64/stand/ofwboot/softraid.c
+++ sys/arch/sparc64/stand/ofwboot/softraid.c
@@ -572,6 +572,10 @@ sr_crypto_decrypt_keys(struct sr_boot_volume *bv)
c = getchar();
if (c == '\r' || c == '\n')
break;
+ else if (c == '\b') {
+ i = i > 0 ? i - 2 : -1;
+ continue;
+ }
passphrase[i] = (c & 0xff);
}
passphrase[i] = 0;
Re: [patch] fix sdmmc bug affecting strictly sector-addressable eMMC chips
On Fri, Aug 28, 2015 at 02:13:44AM -0400, kremlin wrote: sdmmc gives up configuring the card after 100 failed CMD1 commands. My patch starts asserting the MMC_OCR_SECTOR_MODE bit after 50 failed attempts. This fixes the bug on my BBB with Micron chip: Nice work! I wonder why you chose to be so conservative (or arbitrary) about the after 50 failed attempts condition. :) Since sector mode is supported by the host software, shouldn't we always set the MMC_OCR_SECTOR_MODE bit and check the returned OCR value to see if the card also supports sector mode addressing? Related thread: http://marc.info/?l=linux-mmcm=129419687808618 Cheers, Uwe
Re: hide kernel threads in ps?
On Sun, Sep 18, 2011 at 04:28:28PM -0700, Philip Guenther wrote: If there are no objections, I'll commit this with the ps.1 diff reduced to: ... +.It Fl H +Also display information about kernel visible threads. The distinction betwen kernel threads and kernel visible threads is certainly obvious to everyone, but this also seems more consise to me. Having said that, I'm fine with the shortened paragraph. Cheers
hide kernel threads in ps?
Help! My Nagios checks failed. :)
This fixes them by hiding kernel threads from ps output.
I'd also like to show the main process ID in the PID column as
otherwise there is no way of knowing which threads belong together.
Likely struct kinfo_proc would need a change for that... Maybe in
another step.
comments?
Index: bin/ps/ps.1
===
RCS file: /cvs/src/bin/ps/ps.1,v
retrieving revision 1.76
diff -u -p -r1.76 ps.1
--- bin/ps/ps.1 6 Jul 2011 21:42:11 - 1.76
+++ bin/ps/ps.1 30 Aug 2011 22:58:12 -
@@ -39,7 +39,7 @@
.Sh SYNOPSIS
.Nm ps
.Sm off
-.Op Fl aCcehjkLlmrSTuvwx
+.Op Fl aCceHhjkLlmrSTuvwx
.Sm on
.Op Fl M Ar core
.Op Fl N Ar system
@@ -89,6 +89,10 @@ scripts will show as
.Dq sh .
.It Fl e
Display the environment as well.
+.It Fl H
+Also display information about kernel visible process threads.
+This flag only applies when the `kern.rthreads' sysctl variable is
+non-zero and there are processes that use kernel threading.
.It Fl h
Repeat the information header as often as necessary to guarantee one
header per page of information.
Index: bin/ps/ps.c
===
RCS file: /cvs/src/bin/ps/ps.c,v
retrieving revision 1.49
diff -u -p -r1.49 ps.c
--- bin/ps/ps.c 10 Apr 2011 03:20:58 - 1.49
+++ bin/ps/ps.c 30 Aug 2011 22:03:26 -
@@ -99,7 +99,7 @@ main(int argc, char *argv[])
pid_t pid;
uid_t uid;
int all, ch, flag, i, fmt, lineno, nentries, mib[6];
- int prtheader, wflag, kflag, what, Uflag, xflg;
+ int prtheader, showthreads, wflag, kflag, what, Uflag, xflg;
char *nlistf, *memf, *swapf, errbuf[_POSIX2_LINE_MAX];
size_t size;
@@ -114,13 +114,14 @@ main(int argc, char *argv[])
if (argc 1)
argv[1] = kludge_oldps_options(argv[1]);
- all = fmt = prtheader = wflag = kflag = Uflag = xflg = 0;
+ all = fmt = prtheader = showthreads = wflag = kflag = Uflag = 0;
+ xflg = 0;
pid = -1;
uid = 0;
ttydev = NODEV;
memf = nlistf = swapf = NULL;
while ((ch = getopt(argc, argv,
- acCeghjkLlM:mN:O:o:p:rSTt:U:uvW:wx)) != -1)
+ acCegHhjkLlM:mN:O:o:p:rSTt:U:uvW:wx)) != -1)
switch (ch) {
case 'a':
all = 1;
@@ -136,6 +137,9 @@ main(int argc, char *argv[])
break;
case 'g':
break; /* no-op */
+ case 'H':
+ showthreads = 1;
+ break;
case 'h':
prtheader = ws.ws_row 5 ? ws.ws_row : 22;
break;
@@ -336,6 +340,8 @@ main(int argc, char *argv[])
* for each proc, call each variable output function.
*/
for (i = lineno = 0; i nentries; i++) {
+ if (showthreads == 0 (kinfo[i]-p_flag P_THREAD) != 0)
+ continue;
if (xflg == 0 ((int)kinfo[i]-p_tdev == NODEV ||
(kinfo[i]-p_flag P_CONTROLT ) == 0))
continue;
Re: hide kernel threads in ps?
On Wed, Aug 31, 2011 at 11:50 PM, Philip Guenther guent...@gmail.com wrote: As is -L, which is used for threads (LWPs) by Solaris and FreeBSD. B sigh Part of me would be tempted to reuse -k, changing it from unsuppressing P_SYSTEM procs to unsuppressing P_THREAD procs. B Then process 0 would show up by default too... Hmm. I agree that it may not be necessary to control the display of P_SYSTEM procs separately, but as mnemonic, -k sounds like kernel, kthread, and there's no k in tHread. :) If -k would become free for other uses, just for consideration: - in FreeBSD and Solaris, -k is unused - in NetBSD, -k specifies the sort order - in Linux' procps, k specifies the sort order As for -H: - in FreeBSD, -H shows kernel visible threads (and ps -Hx shows threads of kernel threads as well, whereas ps -x shows just the main thread/proc) - in NetBSD, -H is unused - in Linux, -H switches to a tree display - in Solaris, -H enables the locality group column (LGRP) (I've done just a quick cross-check. Maybe I missed something.)
