bioctl(8) with duid
Teach bioctl(8) to resolve disks via duid. The realpath provided by opendev()
cannot be used since bioctl internally uses the volume name (e.g. "sd0")
rather than the full path to the device node. Mapping a duid to a volume
name with an extra BIOCVOL call is not pretty but works.
Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.109
diff -u -p -r1.109 bioctl.c
--- bioctl.c22 Jan 2012 11:00:39 - 1.109
+++ bioctl.c22 Apr 2012 22:57:11 -
@@ -95,7 +95,7 @@ main(int argc, char *argv[])
extern char *optarg;
u_int64_t func = 0;
char*devicename = NULL;
- char*realname = NULL, *al_arg = NULL;
+ char*al_arg = NULL;
char*bl_arg = NULL, *dev_list = NULL;
char*key_disk = NULL;
const char *errstr;
@@ -103,6 +103,7 @@ main(int argc, char *argv[])
int ss_func = 0;
u_int16_t cr_level = 0;
int biodev = 0;
+ struct bioc_vol bv;
if (argc < 2)
usage();
@@ -210,7 +211,7 @@ main(int argc, char *argv[])
if (devicename == NULL)
errx(1, "need device");
- devh = opendev(devicename, O_RDWR, OPENDEV_PART, &realname);
+ devh = opendev(devicename, O_RDWR, OPENDEV_PART, NULL);
if (devh == -1) {
devh = open("/dev/bio", O_RDWR);
if (devh == -1)
@@ -225,6 +226,10 @@ main(int argc, char *argv[])
biodev = 1;
devicename = NULL;
+ } else if (isduid(devicename, OPENDEV_PART)) {
+ if (ioctl(devh, BIOCVOL, &bv))
+ err(1, "BIOCVOL");
+ devicename = bv.bv_dev;
}
if (diskinq) {
Re: amd64: Check cpu_vendor instead of using CPUID.
This has already been committed...
On Sun, Apr 22, 2012 at 3:16 PM, Franco Fichtner wrote:
> On Apr 22, 2012, at 9:32 PM, Christiano F. Haesbaert wrote:
>
>> On Sun, Apr 22, 2012 at 09:16:57PM +0200, Franco Fichtner wrote:
>>> On Apr 22, 2012, at 7:58 PM, Christiano F. Haesbaert wrote:
>>>
On Sun, Apr 22, 2012 at 06:36:41PM +0200, Franco Fichtner wrote:
> Just being paranoid... strncmp?
Why ? It's a terminated string vs a string literal, what do you wanna
use as the third argument: strlen("AuthenticAmd") ? . 100% pointless.
>>>
>>> I can see your point and yet it is being used in the line below your
> change. Do you want to call that author's intent '100% pointless' as well
just
> for the sake of winning an argument or do you simply not care about the
depth
> and inherent wisdom of the code base you are working on?
>>>
>>
>> You rush into conclusions, cpu_model is different, he actually wants
>> the first 5 bytes to evaluate to "Intel", not the whole string, which
>> could be something like:
>>
>> hw.model=Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
>
> Since my first mail I am talking about the mycpu_model line in the
> diff. It's there. I am asking why it differs from your added line.
>
> It's fine when you feel other people do pointless work or point out
> pointless things. On the other hand, other people may not like the
> level of hostility and resistance to advice (as bad as it may be
> in this case). I am no expert on OpenBSD and if this is how tech
> discussions are handled, I'm not sure if I ever will.
>
> The intent of your patch is very good, especially with legibility
> in mind. But if you touch that line, why do it half-heartedly? And
> why ask for comments in the first place?
>
> And how about consolidating style while at it? "!" vs. "== 0" - see
code
> bits below change.
Consolidating how ? Are you suggesting we change all strcmp calls in
kernel to use "== 0" ? Please.
>>>
>>> Personally, I don't care either way, but it's bad style to ignore the
> context and change styles. It makes the code harder to read, understand and
> maintain. Take a look. Ok?
>>>
>>
>> You care enough to send an email without even checking the other uses,
>> if you did, you'll see that !strcmp is more consistent for this case
>> than strncmp.
>
> I care enough to point out an inconsistency in your patch...
>
>>
>> *You* are ignoring the context and trying to change styles.
>
> ... and now we are talking about me being the evil guy who is trying
> to change you and the context. Not gonna happen. :)
>
>> + B B if (!strcmp(cpu_vendor, "AuthenticAMD"))
>> B B B amd64_errata(ci);
>>
>> B if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
>
>
> Franco
Re: amd64: Check cpu_vendor instead of using CPUID.
On Apr 22, 2012, at 9:32 PM, Christiano F. Haesbaert wrote:
> On Sun, Apr 22, 2012 at 09:16:57PM +0200, Franco Fichtner wrote:
>> On Apr 22, 2012, at 7:58 PM, Christiano F. Haesbaert wrote:
>>
>>> On Sun, Apr 22, 2012 at 06:36:41PM +0200, Franco Fichtner wrote:
Just being paranoid... strncmp?
>>>
>>> Why ? It's a terminated string vs a string literal, what do you wanna
>>> use as the third argument: strlen("AuthenticAmd") ? . 100% pointless.
>>
>> I can see your point and yet it is being used in the line below your
change. Do you want to call that author's intent '100% pointless' as well just
for the sake of winning an argument or do you simply not care about the depth
and inherent wisdom of the code base you are working on?
>>
>
> You rush into conclusions, cpu_model is different, he actually wants
> the first 5 bytes to evaluate to "Intel", not the whole string, which
> could be something like:
>
> hw.model=Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
Since my first mail I am talking about the mycpu_model line in the
diff. It's there. I am asking why it differs from your added line.
It's fine when you feel other people do pointless work or point out
pointless things. On the other hand, other people may not like the
level of hostility and resistance to advice (as bad as it may be
in this case). I am no expert on OpenBSD and if this is how tech
discussions are handled, I'm not sure if I ever will.
The intent of your patch is very good, especially with legibility
in mind. But if you touch that line, why do it half-heartedly? And
why ask for comments in the first place?
And how about consolidating style while at it? "!" vs. "== 0" - see code
bits below change.
>>>
>>> Consolidating how ? Are you suggesting we change all strcmp calls in
>>> kernel to use "== 0" ? Please.
>>
>> Personally, I don't care either way, but it's bad style to ignore the
context and change styles. It makes the code harder to read, understand and
maintain. Take a look. Ok?
>>
>
> You care enough to send an email without even checking the other uses,
> if you did, you'll see that !strcmp is more consistent for this case
> than strncmp.
I care enough to point out an inconsistency in your patch...
>
> *You* are ignoring the context and trying to change styles.
... and now we are talking about me being the evil guy who is trying
to change you and the context. Not gonna happen. :)
> +if (!strcmp(cpu_vendor, "AuthenticAMD"))
> amd64_errata(ci);
>
> if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
Franco
Re: amd64: Check cpu_vendor instead of using CPUID.
On Sun, Apr 22, 2012 at 09:16:57PM +0200, Franco Fichtner wrote:
> On Apr 22, 2012, at 7:58 PM, Christiano F. Haesbaert wrote:
>
> > On Sun, Apr 22, 2012 at 06:36:41PM +0200, Franco Fichtner wrote:
> >> Just being paranoid... strncmp?
> >
> > Why ? It's a terminated string vs a string literal, what do you wanna
> > use as the third argument: strlen("AuthenticAmd") ? . 100% pointless.
>
> I can see your point and yet it is being used in the line below your change.
> Do you want to call that author's intent '100% pointless' as well just for
> the sake of winning an argument or do you simply not care about the depth and
> inherent wisdom of the code base you are working on?
>
You rush into conclusions, cpu_model is different, he actually wants
the first 5 bytes to evaluate to "Intel", not the whole string, which
could be something like:
hw.model=Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
> >
> >> And how about consolidating style while at it? "!" vs. "== 0" - see code
> >> bits below change.
> >
> > Consolidating how ? Are you suggesting we change all strcmp calls in
> > kernel to use "== 0" ? Please.
>
> Personally, I don't care either way, but it's bad style to ignore the context
> and change styles. It makes the code harder to read, understand and maintain.
> Take a look. Ok?
>
You care enough to send an email without even checking the other uses,
if you did, you'll see that !strcmp is more consistent for this case
than strncmp.
*You* are ignoring the context and trying to change styles.
> >>> +if (!strcmp(cpu_vendor, "AuthenticAMD"))
> >>> amd64_errata(ci);
> >>>
> >>> if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
>
>
> Franco
Re: amd64: Check cpu_vendor instead of using CPUID.
On Apr 22, 2012, at 7:58 PM, Christiano F. Haesbaert wrote:
> On Sun, Apr 22, 2012 at 06:36:41PM +0200, Franco Fichtner wrote:
>> Just being paranoid... strncmp?
>
> Why ? It's a terminated string vs a string literal, what do you wanna
> use as the third argument: strlen("AuthenticAmd") ? . 100% pointless.
I can see your point and yet it is being used in the line below your change.
Do you want to call that author's intent '100% pointless' as well just for the
sake of winning an argument or do you simply not care about the depth and
inherent wisdom of the code base you are working on?
>
>> And how about consolidating style while at it? "!" vs. "== 0" - see code
bits below change.
>
> Consolidating how ? Are you suggesting we change all strcmp calls in
> kernel to use "== 0" ? Please.
Personally, I don't care either way, but it's bad style to ignore the context
and change styles. It makes the code harder to read, understand and maintain.
Take a look. Ok?
>>> +if (!strcmp(cpu_vendor, "AuthenticAMD"))
>>> amd64_errata(ci);
>>>
>>> if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
Franco
Re: amd64: Check cpu_vendor instead of using CPUID.
On Sun, Apr 22, 2012 at 06:36:41PM +0200, Franco Fichtner wrote:
> Just being paranoid... strncmp?
Why ? It's a terminated string vs a string literal, what do you wanna
use as the third argument: strlen("AuthenticAmd") ? . 100% pointless.
> And how about consolidating style while at it? "!" vs. "== 0" - see code bits
> below change.
>
Consolidating how ? Are you suggesting we change all strcmp calls in
kernel to use "== 0" ? Please.
> Franco
>
> On 22.04.2012, at 15:12, "Christiano F. Haesbaert"
> wrote:
>
> > There's no need for doing that somewhat strange comparison, the rest
> > of the code already uses cpu_vendor.
> >
> > ok ?
> >
> > Index: identcpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> > retrieving revision 1.35
> > diff -d -u -p -r1.35 identcpu.c
> > --- identcpu.c27 Mar 2012 02:23:04 -1.35
> > +++ identcpu.c22 Apr 2012 12:59:10 -
> > @@ -302,7 +302,6 @@ identifycpu(struct cpu_info *ci)
> >u_int64_t last_tsc;
> >u_int32_t dummy, val, pnfeatset;
> >u_int32_t brand[12];
> > -u_int32_t vendor[4];
> >char mycpu_model[48];
> >int i, max;
> >char *brandstr_from, *brandstr_to;
> > @@ -433,11 +432,7 @@ identifycpu(struct cpu_info *ci)
> >
> > #endif
> >
> > -vendor[3] = 0;
> > -CPUID(0, dummy, vendor[0], vendor[2], vendor[1]);/* yup, 0 2 1 */
> > -/* AuthenticAMD:h t u Ai t n e */
> > -if (vendor[0] == 0x68747541 && vendor[1] == 0x69746e65 &&
> > -vendor[2] == 0x444d4163)/* DMAc */
> > +if (!strcmp(cpu_vendor, "AuthenticAMD"))
> >amd64_errata(ci);
> >
> >if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
Séjour original à prix discount
Untitled Document Offres spéciales printemps / été : une semaine sur le CANAL DU MIDI (Agde >> Carcassonne) 480 € au lieu de 1219 € sur un bateau de 6 / 8 personnes (Triton 1050) Croisière en individuel du 30 avril au 7 mai 2012 Soumis à disponibilité, hors frais de carburant ou via notre formulaire de contact (réponse rapide) une caquette offerte pour toute réservation code à nous transmettre Promos internet jusqu'à -60% Allers simples pour avril et mai au départ de la Camargue, du Canal du Midi de Bourgogne, de la Mayenne, de la Charente et de l'Aquitaine. Cliquez ici pour réserver Remises : nous n'oubions personne ! Que vous soyez en couple, en famille, entre amis, séniors ou si vous optez pour une croisière longue durée, vous bénéficierez d'une de nos remises (jusqu'à -15%) Cliquez ici pour consulter les remises Découvrez ce concept de croisière en individuel sur www.france-passion-plaisance.fr CATALOGUE 2012 - Visualiser en ligne - Télécharger - Tarifs 2012 - Commandez gratuitement votre brochure papier (envoi par courrier) Suivez notre actualité et nos promos sur : France Passion Plaisance / Les Canalous - BP 89 - 71602 Paray-le-Monial Cedex - France Tél : 03 85 53 76 70 (appel non surtaxé) - Contact par formulaire Retrouvez notre brochure sur : www.france-passion-plaisance.fr
Re: amd64: Check cpu_vendor instead of using CPUID.
Just being paranoid... strncmp? And how about consolidating style while at it?
"!" vs. "== 0" - see code bits below change.
Franco
On 22.04.2012, at 15:12, "Christiano F. Haesbaert"
wrote:
> There's no need for doing that somewhat strange comparison, the rest
> of the code already uses cpu_vendor.
>
> ok ?
>
> Index: identcpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> retrieving revision 1.35
> diff -d -u -p -r1.35 identcpu.c
> --- identcpu.c27 Mar 2012 02:23:04 -1.35
> +++ identcpu.c22 Apr 2012 12:59:10 -
> @@ -302,7 +302,6 @@ identifycpu(struct cpu_info *ci)
>u_int64_t last_tsc;
>u_int32_t dummy, val, pnfeatset;
>u_int32_t brand[12];
> -u_int32_t vendor[4];
>char mycpu_model[48];
>int i, max;
>char *brandstr_from, *brandstr_to;
> @@ -433,11 +432,7 @@ identifycpu(struct cpu_info *ci)
>
> #endif
>
> -vendor[3] = 0;
> -CPUID(0, dummy, vendor[0], vendor[2], vendor[1]);/* yup, 0 2 1 */
> -/* AuthenticAMD:h t u Ai t n e */
> -if (vendor[0] == 0x68747541 && vendor[1] == 0x69746e65 &&
> -vendor[2] == 0x444d4163)/* DMAc */
> +if (!strcmp(cpu_vendor, "AuthenticAMD"))
>amd64_errata(ci);
>
>if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
amd64: Check cpu_vendor instead of using CPUID.
There's no need for doing that somewhat strange comparison, the rest
of the code already uses cpu_vendor.
ok ?
Index: identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.35
diff -d -u -p -r1.35 identcpu.c
--- identcpu.c 27 Mar 2012 02:23:04 - 1.35
+++ identcpu.c 22 Apr 2012 12:59:10 -
@@ -302,7 +302,6 @@ identifycpu(struct cpu_info *ci)
u_int64_t last_tsc;
u_int32_t dummy, val, pnfeatset;
u_int32_t brand[12];
- u_int32_t vendor[4];
char mycpu_model[48];
int i, max;
char *brandstr_from, *brandstr_to;
@@ -433,11 +432,7 @@ identifycpu(struct cpu_info *ci)
#endif
- vendor[3] = 0;
- CPUID(0, dummy, vendor[0], vendor[2], vendor[1]); /* yup, 0 2 1 */
- /* AuthenticAMD:h t u Ai t n e */
- if (vendor[0] == 0x68747541 && vendor[1] == 0x69746e65 &&
- vendor[2] == 0x444d4163)/* DMAc */
+ if (!strcmp(cpu_vendor, "AuthenticAMD"))
amd64_errata(ci);
if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
diff: small diff for pipex.c
Remove redundant returns from functions returning void. Wrap return
values in () for consistency.
diff from Michael W. Bombardieri.
ok?
Index: sys/net/pipex.c
===
RCS file: /cvs/src/sys/net/pipex.c,v
retrieving revision 1.27
diff -u -p -r1.27 pipex.c
--- sys/net/pipex.c 4 Apr 2012 04:31:38 - 1.27
+++ sys/net/pipex.c 22 Apr 2012 09:21:21 -
@@ -203,8 +203,6 @@ pipex_iface_stop(struct pipex_iface_cont
pipex_destroy_session(session);
}
splx(s);
-
- return;
}
/* called from tunioctl() with splnet() */
@@ -759,8 +757,6 @@ pipex_ppp_dequeue(void)
if (!IF_IS_EMPTY(&pipexinq) || !IF_IS_EMPTY(&pipexoutq))
softintr_schedule(pipex_softintr);
splx(s);
-
- return;
}
Static int
@@ -962,7 +958,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.oerrors++;
- return;
}
Static void
@@ -1016,7 +1011,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.oerrors++;
- return;
}
Static void
@@ -1097,8 +1091,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.ierrors++;
-
- return;
}
Static void
@@ -1190,8 +1182,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.ierrors++;
-
- return;
}
#ifdef INET6
@@ -1265,8 +1255,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.ierrors++;
-
- return;
}
#endif
@@ -1465,8 +1453,6 @@ pipex_pppoe_output(struct mbuf *m0, stru
over_ifp->if_output(over_ifp, m0, (struct sockaddr *)&session->peer,
NULL);
-
- return;
}
#endif /* PIPEX_PPPOE */
@@ -1558,7 +1544,6 @@ pipex_pptp_output(struct mbuf *m0, struc
return;
drop:
session->stat.oerrors++;
- return;
}
struct pipex_session *
@@ -2029,8 +2014,6 @@ pipex_l2tp_output(struct mbuf *m0, struc
return;
drop:
session->stat.oerrors++;
-
- return;
}
struct pipex_session *
@@ -2574,8 +2557,6 @@ drop:
if (m0 != NULL)
m_freem(m0);
session->stat.ierrors++;
-
- return;
}
Static void
@@ -2980,8 +2961,6 @@ pipex_session_log(struct pipex_session *
vsnprintf(logbuf, sizeof(logbuf), fmt, ap);
va_end(ap);
addlog("%s\n", logbuf);
-
- return;
}
Static uint32_t
@@ -2995,7 +2974,7 @@ pipex_sockaddr_hash_key(struct sockaddr
.s6_addr32[3]);
}
panic("pipex_sockaddr_hash_key: unknown address family");
- return 0;
+ return (0);
}
/*
Re: diff: IUTF8 support
This makes sense to me.
I think there is no sane way to handle UTF-8 characters of width != 1...
On Thu, Apr 12, 2012 at 05:44:19AM -0700, Matthew Dempsky wrote:
> While reading the mosh research paper[1], I noticed we don't have
> IUTF8, which is necessary for backspace to work correctly in canonical
> mode (ICANON) with UTF-8 characters.
>
> [1] http://mosh.mit.edu/mosh-paper-draft.pdf
>
> I took a quick stab at implementing it, and it didn't seem too bad.
> See kernel diff below along with a corresponding fix to xterm(1) to
> actually make use of it on OpenBSD.
>
> I've only played with it for a little while, but I haven't noticed any
> issues with various mixes of backspace, ^W, and tabs. I'm going to
> try to write some regress tests for it now, so I'm very interested if
> anyone notices any issues or differences in behavior from Linux.
>
> I suspect Unicode combining characters behave oddly, but Linux doesn't
> worry about those either as far as I can tell.
>
>
> Index: src/sys/sys/termios.h
> ===
> RCS file: /cvs/src/sys/sys/termios.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 termios.h
> --- src/sys/sys/termios.h 26 Dec 2009 09:46:17 - 1.11
> +++ src/sys/sys/termios.h 12 Apr 2012 12:33:04 -
> @@ -101,7 +101,8 @@
> #if __BSD_VISIBLE
> #define IXANY 0x0800 /* any char will restart after
> stop */
> #define IUCLC 0x1000 /* translate upper to lower
> case */
> -#define IMAXBEL 0x2000 /* ring bell on input queue
> full */
> +#define IMAXBEL 0x2000 /* ring bell on input queue
> full */
> +#define IUTF8 0x4000 /* input stream is UTF-8
> encoded */
> #endif /* __BSD_VISIBLE */
>
> /*
> Index: src/sys/kern/tty.c
> ===
> RCS file: /cvs/src/sys/kern/tty.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 tty.c
> --- src/sys/kern/tty.c23 Mar 2012 15:51:26 - 1.94
> +++ src/sys/kern/tty.c12 Apr 2012 12:33:04 -
> @@ -163,6 +163,8 @@ u_char const char_type[] = {
> #define tolower(c) ((c) - 'A' + 'a')
> #define toupper(c) ((c) - 'a' + 'A')
>
> +#define iscont(tp, c)(((tp)->t_iflag & IUTF8) && (c) >= 0x80 && (c)
> < 0xc0)
> +
> struct ttylist_head ttylist; /* TAILQ_HEAD */
> int tty_count;
>
> @@ -441,8 +443,12 @@ parmrk: (void)putc(0377 |
> TTY_QUOTE,
>* erase (^H / ^?)
>*/
> if (CCEQ(cc[VERASE], c)) {
> - if (tp->t_rawq.c_cc)
> - ttyrub(unputc(&tp->t_rawq), tp);
> + do {
> + c = unputc(&tp->t_rawq);
> + if (c == -1)
> + break;
> + ttyrub(c, tp);
> + } while (iscont(tp, c));
> goto endcase;
> }
> /*
> @@ -698,7 +704,8 @@ ttyoutput(int c, struct tty *tp)
> col = 0;
> break;
> case ORDINARY:
> - ++col;
> + if (!iscont(tp, c))
> + ++col;
> break;
> case TAB:
> col = (col + 8) & ~7;
> @@ -1874,6 +1881,8 @@ ttyrub(int c, struct tty *tp)
> int tabc, s;
>
> if (!ISSET(tp->t_lflag, ECHO) || ISSET(tp->t_lflag, EXTPROC))
> + return;
> + if (iscont(tp, c))
> return;
> CLR(tp->t_lflag, FLUSHO);
> if (ISSET(tp->t_lflag, ECHOE)) {
> Index: xenocara/app/xterm/main.c
> ===
> RCS file: /cvs/xenocara/app/xterm/main.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 main.c
> --- xenocara/app/xterm/main.c 16 Nov 2011 21:14:25 - 1.22
> +++ xenocara/app/xterm/main.c 12 Apr 2012 12:33:04 -
> @@ -3836,7 +3836,7 @@ spawnXTerm(XtermWidget xw)
> /* input: nl->nl, don't ignore cr, cr->nl */
> UIntClr(tio.c_iflag, (INLCR | IGNCR));
> tio.c_iflag |= ICRNL;
> -#if OPT_WIDE_CHARS && defined(linux) && defined(IUTF8)
> +#if OPT_WIDE_CHARS && defined(IUTF8)
> #if OPT_LUIT_PROG
> if (command_to_exec_with_luit == 0)
> #endif
