From owner-freebsd-arch Sun May 27 2:12:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id DA34637B423; Sun, 27 May 2001 02:12:26 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4R9F9K26211; Sun, 27 May 2001 12:15:10 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l110.uic-in.net [212.35.189.237]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4R9CJo02995; Sun, 27 May 2001 12:12:20 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Sun, 27 May 2001 12:12:20 +0300 (EEST) Message-Id: <200105270912.f4R9CJo02995@mail.uic-in.net> To: dd@FreeBSD.ORG, arch@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c X-Mailer: Pygmy (v0.5.8) In-Reply-To: <200105270047.f4R0lcX23459@freefall.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 26 May 2001 17:47:38 -0700 (PDT), Dima Dorfman wrote: > dd 2001/05/26 17:47:38 PDT > > Modified files: > usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c > Log: > Add a -c option which clears the history buffer using the new > CONS_CLRHIST ioctl. Does it really belong to kbdcontrol(1)? For me it looks counter-intuitive as this feature has nothing to do with keyboard at all. IMO this (and `-h' BTW) option should be moved into vidcontrol(1). This also would solve bootstrap issue. What do people think? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 5:58:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9C9E037B43C; Sun, 27 May 2001 05:58:14 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id OAA10763; Sun, 27 May 2001 14:58:13 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: {kbd,vid}control insanity patch From: Dag-Erling Smorgrav Date: 27 May 2001 14:58:13 +0200 Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= The attached patch moves the history buffer controls out of kbdcontrol and into vidcontrol where they belong. It also fixes some indentation issues in {kbd,vid}control, removes the allscreens_kbdflags knob from rc.syscons and rc.conf, and corrects some of the poor language in the man pages. (because of the indentation changes, the best way to view this patch is to apply it, then 'cvs diff -b' the patched files) DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=vidcontrol.diff Index: etc/rc.syscons =================================================================== RCS file: /home/ncvs/src/etc/rc.syscons,v retrieving revision 1.3 diff -u -r1.3 rc.syscons --- etc/rc.syscons 2001/04/28 20:56:52 1.3 +++ etc/rc.syscons 2001/05/27 12:41:41 @@ -180,13 +180,4 @@ done fi -# set this keyboard more for all virtual terminals -# -if [ -n "${allscreens_kbdflags}" ]; then - echo -n ' allscreens_kbd' - for ttyv in /dev/ttyv*; do - kbdcontrol ${allscreens_kbdflags} < ${ttyv} > ${ttyv} 2>&1 - done -fi - echo '.' Index: etc/defaults/rc.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.108 diff -u -r1.108 rc.conf --- etc/defaults/rc.conf 2001/05/25 01:46:39 1.108 +++ etc/defaults/rc.conf 2001/05/27 12:41:57 @@ -299,8 +299,6 @@ # language code table, specify alternative range # start like mousechar_start=3, see vidcontrol(1) allscreens_flags="" # Set this vidcontrol mode for all virtual screens -allscreens_kbdflags="" # Set this kbdcontrol mode for all virtual screens - ############################################################## ### Miscellaneous administrative options ################### Index: usr.sbin/kbdcontrol/kbdcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.1,v retrieving revision 1.29 diff -u -r1.29 kbdcontrol.1 --- usr.sbin/kbdcontrol/kbdcontrol.1 2001/05/27 00:47:38 1.29 +++ usr.sbin/kbdcontrol/kbdcontrol.1 2001/05/27 12:55:42 @@ -13,15 +13,15 @@ .\" @(#)kbdcontrol.1 .\" $FreeBSD: src/usr.sbin/kbdcontrol/kbdcontrol.1,v 1.29 2001/05/27 00:47:38 dd Exp $ .\" -.Dd May 24, 2001 +.Dd May 27, 2001 .Dt KBDCONTROL 1 .Os .Sh NAME .Nm kbdcontrol -.Nd a utility for manipulating the syscons console driver +.Nd keyboard control and configuration utility .Sh SYNOPSIS .Nm -.Op Fl cdFKix +.Op Fl dFKix .Oo .Fl b .Ar duration . Ns Ar pitch | Ar belltype @@ -32,7 +32,6 @@ .Oc .Op Fl l Ar keymap_file .Op Fl f Ar # Ar string -.Op Fl h Ar size .Op Fl k Ar keyboard_device .Op Fl L Ar keymap_file .Sh DESCRIPTION @@ -97,8 +96,6 @@ .Ar keymap_file . You may load the keyboard map file from a menu-driven command, .Xr kbdmap 1 . -.It Fl c -Clear the history buffer. .It Fl d Dump the current keyboard map onto stdout. The output may be redirected to a file and can be loaded @@ -117,10 +114,6 @@ Set function keys back to the standard definitions. .It Fl x Use hexadecimal numbers in keyboard map dump. -.It Fl h Ar size -Set history buffer size to -.Ar size -lines. .It Fl i Print brief information about the keyboard. .It Fl K Index: usr.sbin/kbdcontrol/kbdcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v retrieving revision 1.39 diff -u -r1.39 kbdcontrol.c --- usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/27 06:28:08 1.39 +++ usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/27 12:37:10 @@ -965,33 +965,6 @@ } } - -void -set_history(char *opt) -{ - int size; - - size = atoi(opt); - if ((*opt == '\0') || size < 0) { - warnx("argument must be a positive number"); - return; - } - if (ioctl(0, CONS_HISTORY, &size) == -1) - warn("setting history buffer size"); -} - -void -clear_history() -{ - -#ifdef CONS_CLRHIST - if (ioctl(0, CONS_CLRHIST) == -1) - warn("clear history buffer"); -#else - warnx("clearing history not supported"); -#endif -} - static char *get_kbd_type_name(int type) { @@ -1091,9 +1064,9 @@ usage() { fprintf(stderr, "%s\n%s\n%s\n", -"usage: kbdcontrol [-cdFKix] [-b duration.pitch | [quiet.]belltype]", +"usage: kbdcontrol [-dFKix] [-b duration.pitch | [quiet.]belltype]", " [-r delay.repeat | speed] [-l mapfile] [-f # string]", -" [-h size] [-k device] [-L mapfile]"); +" [-k device] [-L mapfile]"); exit(1); } @@ -1103,50 +1076,44 @@ { int opt; - while((opt = getopt(argc, argv, "b:cdf:h:iKk:Fl:L:r:x")) != -1) + while((opt = getopt(argc, argv, "b:df:iKk:Fl:L:r:x")) != -1) switch(opt) { - case 'b': - set_bell_values(optarg); - break; - case 'c': - clear_history(); - break; - case 'd': - print_keymap(); - break; - case 'l': - load_keymap(optarg, 0); - break; - case 'L': - load_keymap(optarg, 1); - break; - case 'f': - set_functionkey(optarg, - nextarg(argc, argv, &optind, 'f')); - break; - case 'F': - load_default_functionkeys(); - break; - case 'h': - set_history(optarg); - break; - case 'i': - show_kbd_info(); - break; - case 'K': - release_keyboard(); - break; - case 'k': - set_keyboard(optarg); - break; - case 'r': - set_keyrates(optarg); - break; - case 'x': - hex = 1; - break; - default: - usage(); + case 'b': + set_bell_values(optarg); + break; + case 'd': + print_keymap(); + break; + case 'l': + load_keymap(optarg, 0); + break; + case 'L': + load_keymap(optarg, 1); + break; + case 'f': + set_functionkey(optarg, + nextarg(argc, argv, &optind, 'f')); + break; + case 'F': + load_default_functionkeys(); + break; + case 'i': + show_kbd_info(); + break; + case 'K': + release_keyboard(); + break; + case 'k': + set_keyboard(optarg); + break; + case 'r': + set_keyrates(optarg); + break; + case 'x': + hex = 1; + break; + default: + usage(); } if ((optind != argc) || (argc == 1)) usage(); Index: usr.sbin/vidcontrol/vidcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v retrieving revision 1.37 diff -u -r1.37 vidcontrol.1 --- usr.sbin/vidcontrol/vidcontrol.1 2001/05/20 11:39:53 1.37 +++ usr.sbin/vidcontrol/vidcontrol.1 2001/05/27 12:55:50 @@ -13,34 +13,31 @@ .\" @(#)vidcontrol.1 .\" $FreeBSD: src/usr.sbin/vidcontrol/vidcontrol.1,v 1.37 2001/05/20 11:39:53 ru Exp $ .\" -.Dd June 30, 1999 +.Dd May 27, 2001 .Dt VIDCONTROL 1 .Os .Sh NAME .Nm vidcontrol -.Nd "a utility for manipulating the syscons console driver" +.Nd system console control and configuration utility .Sh SYNOPSIS .Nm +.Op Fl CdLPpx .Op Fl b Ar color .Op Fl c Ar appearance -.Op Fl d .Oo .Fl f .Op Ar size .Ar file .Oc .Op Fl g Ar geometry +.Op Fl h Ar size .Op Fl i Cm adapter | mode .Op Fl l Ar screen_map -.Op Fl L .Op Fl M Ar char .Op Fl m Cm on | off -.Op Fl p -.Op Fl P .Op Fl r Ar foreground Ar background .Op Fl s Ar number .Op Fl t Ar N | Cm off -.Op Fl x .Op Ar mode .Op Ar foreground Op Ar background .Op Cm show @@ -110,13 +107,15 @@ Set border color to .Ar color . This option may not be always supported by the video driver. +.It Fl C +Clear the history buffer. .It Fl c Cm normal | blink | destructive Change the cursor appearance. The cursor is either an inverting block .Pq Cm normal -that eventually can -.Cm blink . -Or it can be like the old hardware cursor +that can optionally +.Cm blink , +or it can be like the old hardware cursor .Pq Cm destructive . The latter is actually a simulation. .It Fl d @@ -166,6 +165,10 @@ and .Sx EXAMPLES below. +.It Fl h Cm size +Set the size of the history (scrollback) buffer to +.Cm size +lines. .It Fl i Cm adapter Shows info about the current video adapter. .It Fl i Cm mode Index: usr.sbin/vidcontrol/vidcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v retrieving revision 1.38 diff -u -r1.38 vidcontrol.c --- usr.sbin/vidcontrol/vidcontrol.c 2001/05/20 12:17:31 1.38 +++ usr.sbin/vidcontrol/vidcontrol.c 2001/05/27 12:51:58 @@ -73,10 +73,10 @@ usage() { fprintf(stderr, "%s\n%s\n%s\n%s\n", -"usage: vidcontrol [-b color] [-c appearance] [-d] [-f [size] file] [-g geometry]", -" [-i adapter | mode] [-l screen_map] [-L] [-m on | off]", -" [-M char] [-p] [-P] [-r foreground background] [-s number]", -" [-t N | off] [-x] [mode] [foreground [background]] [show]"); +"usage: vidcontrol [-CdLPpx] [-b color] [-c appearance] [-f [size] file]", +" [-g geometry] [-h size] [-i adapter | mode] [-l screen_map]", +" [-m on | off] [-M char] [-r foreground background] [-s num]", +" [-t N | off] [mode] [foreground [background]] [show]"); exit(1); } @@ -714,6 +714,32 @@ return; } +void +set_history(char *opt) +{ + int size; + + size = atoi(opt); + if ((*opt == '\0') || size < 0) { + warnx("argument must be a positive number"); + return; + } + if (ioctl(0, CONS_HISTORY, &size) == -1) + warn("setting history buffer size"); +} + +void +clear_history() +{ + +#ifdef CONS_CLRHIST + if (ioctl(0, CONS_CLRHIST) == -1) + warn("clear history buffer"); +#else + warnx("clearing history not supported"); +#endif +} + int main(int argc, char **argv) { @@ -727,68 +753,74 @@ /* Not reached */ if (ioctl(0, CONS_GETINFO, &info) < 0) err(1, "must be on a virtual console"); - while((opt = getopt(argc, argv, "b:c:df:g:i:l:LM:m:pPr:s:t:x")) != -1) + while((opt = getopt(argc, argv, "b:Cc:df:g:h:i:l:LM:m:pPr:s:t:x")) != -1) switch(opt) { - case 'b': - set_border_color(optarg); - break; - case 'c': - set_cursor_type(optarg); - break; - case 'd': - print_scrnmap(); - break; - case 'f': - type = optarg; - font = nextarg(argc, argv, &optind, 'f', 0); - if (font == NULL) { - type = NULL; - font = optarg; - } - load_font(type, font); - break; - case 'g': - if (sscanf(optarg, "%dx%d", &vesa_cols, - &vesa_rows) != 2) { - warnx("incorrect geometry: %s", optarg); - usage(); - } - break; - case 'i': - show_info(optarg); - break; - case 'l': - load_scrnmap(optarg); - break; - case 'L': - load_default_scrnmap(); - break; - case 'M': - set_mouse_char(optarg); - break; - case 'm': - set_mouse(optarg); - break; - case 'p': - dump_screen(DUMP_RAW); - break; - case 'P': - dump_screen(DUMP_TXT); - break; - case 'r': - set_reverse_colors(argc, argv, &optind); - break; - case 's': - set_console(optarg); - break; - case 't': - set_screensaver_timeout(optarg); - break; - case 'x': - hex = 1; - break; - default: + case 'b': + set_border_color(optarg); + break; + case 'C': + clear_history(); + break; + case 'c': + set_cursor_type(optarg); + break; + case 'd': + print_scrnmap(); + break; + case 'f': + type = optarg; + font = nextarg(argc, argv, &optind, 'f', 0); + if (font == NULL) { + type = NULL; + font = optarg; + } + load_font(type, font); + break; + case 'g': + if (sscanf(optarg, "%dx%d", &vesa_cols, + &vesa_rows) != 2) { + warnx("incorrect geometry: %s", optarg); usage(); + } + break; + case 'h': + set_history(optarg); + break; + case 'i': + show_info(optarg); + break; + case 'l': + load_scrnmap(optarg); + break; + case 'L': + load_default_scrnmap(); + break; + case 'M': + set_mouse_char(optarg); + break; + case 'm': + set_mouse(optarg); + break; + case 'p': + dump_screen(DUMP_RAW); + break; + case 'P': + dump_screen(DUMP_TXT); + break; + case 'r': + set_reverse_colors(argc, argv, &optind); + break; + case 's': + set_console(optarg); + break; + case 't': + set_screensaver_timeout(optarg); + break; + case 'x': + hex = 1; + break; + default: + usage(); } video_mode(argc, argv, &optind); set_normal_colors(argc, argv, &optind); --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 8:53:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 3A92137B422 for ; Sun, 27 May 2001 08:53:11 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4RFtOK50460; Sun, 27 May 2001 18:55:25 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l110.uic-in.net [212.35.189.237]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4RFqSo03736; Sun, 27 May 2001 18:52:31 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Sun, 27 May 2001 18:52:31 +0300 (EEST) Message-Id: <200105271552.f4RFqSo03736@mail.uic-in.net> To: des@ofug.org, arch@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: {kbd,vid}control insanity patch X-Mailer: Pygmy (v0.5.8) In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 27 May 2001 14:58:13 +0200, Dag-Erling Smorgrav wrote: > The attached patch moves the history buffer controls out of kbdcontrol > and into vidcontrol where they belong. It also fixes some indentation > issues in {kbd,vid}control, removes the allscreens_kbdflags knob from > rc.syscons and rc.conf, and corrects some of the poor language in the > man pages. > > (because of the indentation changes, the best way to view this patch > is to apply it, then 'cvs diff -b' the patched files) Looks fine to me, though you may remove #ifdef CONS_CLRHIST - vidcontrol(1) is not a cross-tool, so you don't have to care if it builds on anything but 5-STABLE or not. -Maxim P.S. Please next time don't remove me from CC list. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 8:54: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id C1B5F37B423 for ; Sun, 27 May 2001 08:53:58 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4RFufK50527; Sun, 27 May 2001 18:56:41 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l110.uic-in.net [212.35.189.237]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4RFroo03743; Sun, 27 May 2001 18:53:50 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Sun, 27 May 2001 18:53:50 +0300 (EEST) Message-Id: <200105271553.f4RFroo03743@mail.uic-in.net> To: des@ofug.org, arch@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: {kbd,vid}control insanity patch X-Mailer: Pygmy (v0.5.8) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 May 2001 18:52:24 EEST, Maxim Sobolev wrote: > On 27 May 2001 14:58:13 +0200, Dag-Erling Smorgrav wrote: > > The attached patch moves the history buffer controls out of kbdcontrol > > and into vidcontrol where they belong. It also fixes some indentation > > issues in {kbd,vid}control, removes the allscreens_kbdflags knob from > > rc.syscons and rc.conf, and corrects some of the poor language in the > > man pages. > > > > (because of the indentation changes, the best way to view this patch > > is to apply it, then 'cvs diff -b' the patched files) > > it builds on anything but 5-STABLE or not. Hehe, funny typo - 5-CURRENT I mean. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 11:56: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id B18B737B422; Sun, 27 May 2001 11:55:58 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id E96703E28; Sun, 27 May 2001 11:55:57 -0700 (PDT) To: sobomax@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c In-Reply-To: <200105270912.f4R9CJo02995@mail.uic-in.net>; from sobomax@mail-in.net on "Sun, 27 May 2001 12:12:20 +0300 (EEST)" Date: Sun, 27 May 2001 11:55:57 -0700 From: Dima Dorfman Message-Id: <20010527185557.E96703E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev writes: > On Sat, 26 May 2001 17:47:38 -0700 (PDT), Dima Dorfman wrote: > > dd 2001/05/26 17:47:38 PDT > > > > Modified files: > > usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c > > Log: > > Add a -c option which clears the history buffer using the new > > CONS_CLRHIST ioctl. > > Does it really belong to kbdcontrol(1)? For me it looks > counter-intuitive as this feature has nothing to do with > keyboard at all. IMO this (and `-h' BTW) option should be > moved into vidcontrol(1). I agree, but please think of backwards compatibility. -c is young enough that moving it to vidcontrol is no problem. -h, however, is different; it's already in -stable, and has been there for a long time. I suggest that we move both to vidcontrol, and have `kbdcontrol -h` print a "this option is now option -X in vidcontrol" or something similar. I'll do the necessary work for this. > This also would solve bootstrap issue. Not quite. It would just hide it until somebody adds an option to kbdcontrol which really does belong there. The fact that we have a highly system-specific (i.e., depends on intricacies in the kernel) tool being used to bootstrap the system is still a problem. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 13:43:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 5ECDB37B424 for ; Sun, 27 May 2001 13:43:23 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4RKk2K65747; Sun, 27 May 2001 23:46:03 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l39.uic-in.net [212.35.189.166]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4RKgro04676; Sun, 27 May 2001 23:43:06 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Sun, 27 May 2001 23:43:06 +0300 (EEST) Message-Id: <200105272043.f4RKgro04676@mail.uic-in.net> To: dima@unixfreak.org Cc: arch@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c X-Mailer: Pygmy (v0.5.8) In-Reply-To: <20010527185557.E96703E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 May 2001 11:55:57 -0700, Dima Dorfman wrote: > Maxim Sobolev writes: > > On Sat, 26 May 2001 17:47:38 -0700 (PDT), Dima Dorfman wrote: > > > dd 2001/05/26 17:47:38 PDT > > > > > > Modified files: > > > usr.sbin/kbdcontrol kbdcontrol.1 kbdcontrol.c > > > Log: > > > Add a -c option which clears the history buffer using the new > > > CONS_CLRHIST ioctl. > > > > Does it really belong to kbdcontrol(1)? For me it looks > > counter-intuitive as this feature has nothing to do with > > keyboard at all. IMO this (and `-h' BTW) option should be > > moved into vidcontrol(1). > > I agree, but please think of backwards compatibility. -c is young > enough that moving it to vidcontrol is no problem. -h, however, is > different; it's already in -stable, and has been there for a long > time. I suggest that we move both to vidcontrol, and have `kbdcontrol > -h` print a "this option is now option -X in vidcontrol" or something > similar. I do not see a big problem here. `-h' option in kbdcontrol(1) is not an option that used by luser very frequently. Just a entry in appropriate relnotes could be sufficient IMO. > I'll do the necessary work for this. Des already done this work. Please see -arch archives. > > This also would solve bootstrap issue. > > Not quite. It would just hide it until somebody adds an option to > kbdcontrol which really does belong there. The fact that we have a > highly system-specific (i.e., depends on intricacies in the kernel) > tool being used to bootstrap the system is still a problem. Yes, I understand this. Actually I was talking about this specific problem. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 19:18:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 911FA37B43F for ; Sun, 27 May 2001 19:18:12 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id MAA12230; Mon, 28 May 2001 12:18:08 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K43I6AZTJ4VF8ZKA@cim.alcatel.com.au>; Mon, 28 May 2001 12:18:05 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f4S2I5M99331; Mon, 28 May 2001 12:18:05 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 28 May 2001 12:18:05 +1000 From: Peter Jeremy Subject: Re: PAM, S/Key and authentication schemes. In-reply-to: <200105251240.f4PCeO612402@gratis.grondar.za>; from mark@grondar.za on Fri, May 25, 2001 at 02:42:40PM +0200 To: Mark Murray Cc: arch@FreeBSD.ORG Mail-Followup-To: Mark Murray , arch@FreeBSD.ORG Message-id: <20010528121804.Q89950@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200105251240.f4PCeO612402@gratis.grondar.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2001-May-25 14:42:40 +0200, Mark Murray wrote: >I'd like to properly PAM-ize the things that need it, and simplify >where possible and where appropriate. In most cases, this means >gutting out the convoluted logic if favour of pam _only_. Sounds good. The only danger area I can see is the need to check root password to get to single-user if the console is not secure. This needs to work even if (and especially when) the system is hosed. I wouldn't like to see init become dependent on the dynamic loader and various PAM libraries in this case. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 27 20:49:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5649037B43F for ; Sun, 27 May 2001 20:49:38 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id EF2973E28; Sun, 27 May 2001 20:49:37 -0700 (PDT) To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch In-Reply-To: ; from des@ofug.org on "27 May 2001 14:58:13 +0200" Date: Sun, 27 May 2001 20:49:37 -0700 From: Dima Dorfman Message-Id: <20010528034937.EF2973E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > The attached patch moves the history buffer controls out of kbdcontrol > and into vidcontrol where they belong. It also fixes some indentation > issues in {kbd,vid}control, removes the allscreens_kbdflags knob from ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Why? It's still useful; -h isn't the only option kbdcontrol has. It at may still be desirable to be able to set -b or -r on all virtual terminals. Otherwise, looks good! Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 2:43:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6DA5D37B42C for ; Mon, 28 May 2001 02:43:24 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA14860; Mon, 28 May 2001 11:43:17 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch References: <20010528034937.EF2973E28@bazooka.unixfreak.org> From: Dag-Erling Smorgrav Date: 28 May 2001 11:43:16 +0200 In-Reply-To: <20010528034937.EF2973E28@bazooka.unixfreak.org> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman writes: > Why? It's still useful; -h isn't the only option kbdcontrol has. It > at may still be desirable to be able to set -b or -r on all virtual > terminals. Damn, yet another kbdcontrol bug. This - like every other vty- specific knob - should be in vidcontrol. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 9:26:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 0A2CA37B423 for ; Mon, 28 May 2001 09:26:28 -0700 (PDT) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 8899 invoked by uid 1000); 28 May 2001 16:25:27 -0000 Date: 28 May 2001 16:24:54 -0000 Message-ID: <20010528162454.8895.qmail@ringworld.nanolink.com> From: Cy Schubert To: arch Subject: arch procmail test Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG and stuff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 9:29: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 2694D37B42C for ; Mon, 28 May 2001 09:28:54 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 8922 invoked by uid 1000); 28 May 2001 16:27:56 -0000 Date: Mon, 28 May 2001 19:27:56 +0300 From: Peter Pentchev To: arch@FreeBSD.org Subject: arch procmail test Message-ID: <20010528192756.A8556@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Errrrr... Please ignore the previous message with this subject.. I'm testing a newly setup procmail, and.. well.. sorry! :) (Yes, I'm using a random subset of names and addresses from my mail folders.. I apologize for any confusion this may have caused..) G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 11:54:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 8803637B422; Mon, 28 May 2001 11:54:48 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f4SIsh649433; Mon, 28 May 2001 20:54:45 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200105281854.f4SIsh649433@gratis.grondar.za> To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <20010526145521.D11876@dragon.nuxi.com> In-Reply-To: <20010526145521.D11876@dragon.nuxi.com> ; from "David O'Brien" "Sat, 26 May 2001 14:55:21 MST." Date: Mon, 28 May 2001 20:57:03 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Fri, May 25, 2001 at 02:42:40PM +0200, Mark Murray wrote: > > We currently have a slew of authentication schemes in FreeBSD. There > > is the usual lot in getpwent(3) and friends, OPIE, S/Key and PAM, and > > Is there some reason we cannot `cvs rm' S/Key and only use OPIE? OPIE > was intended as a replacement for S/Key. I want to do this. > > S/Key is OBE in my opinion and needs to be entirely replaced by OPIE. > > (And in the majority of cases pam_opie will do the job). > > Do you know why ?ache? did not totally replace S/Key when he imported > OPIE? It was PST IIRC, and it looked like he was starting to get busy with Juniper. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 11:56:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 5CB5C37B422 for ; Mon, 28 May 2001 11:56:18 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f4SItq649486; Mon, 28 May 2001 20:55:52 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200105281855.f4SItq649486@gratis.grondar.za> To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <20010528121804.Q89950@gsmx07.alcatel.com.au> In-Reply-To: <20010528121804.Q89950@gsmx07.alcatel.com.au> ; from Peter Jeremy "Mon, 28 May 2001 12:18:05 +1000." Date: Mon, 28 May 2001 20:58:13 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On 2001-May-25 14:42:40 +0200, Mark Murray wrote: > >I'd like to properly PAM-ize the things that need it, and simplify > >where possible and where appropriate. In most cases, this means > >gutting out the convoluted logic if favour of pam _only_. > > Sounds good. > > The only danger area I can see is the need to check root password to > get to single-user if the console is not secure. This needs to work > even if (and especially when) the system is hosed. I wouldn't like to > see init become dependent on the dynamic loader and various PAM > libraries in this case. No problem. init(8) is pretty safe from ever being PAMized. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 17:43:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id F318037B43E for ; Mon, 28 May 2001 17:43:38 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id A25933E2F; Mon, 28 May 2001 17:43:38 -0700 (PDT) To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch In-Reply-To: ; from des@ofug.org on "28 May 2001 11:43:16 +0200" Date: Mon, 28 May 2001 17:43:38 -0700 From: Dima Dorfman Message-Id: <20010529004338.A25933E2F@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Dima Dorfman writes: > > Why? It's still useful; -h isn't the only option kbdcontrol has. It > > at may still be desirable to be able to set -b or -r on all virtual > > terminals. > > Damn, yet another kbdcontrol bug. This - like every other vty- > specific knob - should be in vidcontrol. Are keymaps vty-specific? If they are, we should just merge kbdcontrol and vidcontrol, perhaps with the excetion of whatever sysinstall needs; that can be made a separate program (we can still call that kbdcontrol; I don't care). Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 17:47:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-122.dsl.lsan03.pacbell.net [63.207.60.122]) by hub.freebsd.org (Postfix) with ESMTP id D0C4137B424 for ; Mon, 28 May 2001 17:47:32 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9AC2C675B2; Mon, 28 May 2001 17:47:31 -0700 (PDT) Date: Mon, 28 May 2001 17:47:29 -0700 From: Kris Kennaway To: Peter Jeremy Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. Message-ID: <20010528174728.A39588@xor.obsecurity.org> References: <200105251240.f4PCeO612402@gratis.grondar.za> <20010528121804.Q89950@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010528121804.Q89950@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Mon, May 28, 2001 at 12:18:05PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 28, 2001 at 12:18:05PM +1000, Peter Jeremy wrote: > On 2001-May-25 14:42:40 +0200, Mark Murray wrote: > >I'd like to properly PAM-ize the things that need it, and simplify > >where possible and where appropriate. In most cases, this means > >gutting out the convoluted logic if favour of pam _only_. >=20 > Sounds good. >=20 > The only danger area I can see is the need to check root password to > get to single-user if the console is not secure. This needs to work > even if (and especially when) the system is hosed. I wouldn't like to > see init become dependent on the dynamic loader and various PAM > libraries in this case. We also compile all of the PAM modules included in the base system into a static libpam which allows statically-linked binaries to work, up to a point (they won't work if the system administrator tries to use a third-party PAM module) Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7EvGfWry0BWjoQKURAlXgAKCWwtp7fejPKr9Fo3oO9UeMQ5AxXQCg6pkb xXLilEj7eGZJ9RkLmfyrMG0= =qs4k -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 19:44:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 75F0337B423 for ; Mon, 28 May 2001 19:44:48 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4T2iX091488; Mon, 28 May 2001 19:44:33 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4T2iNP21562; Mon, 28 May 2001 19:44:23 -0700 (PDT) (envelope-from jdp) Date: Mon, 28 May 2001 19:44:23 -0700 (PDT) Message-Id: <200105290244.f4T2iNP21562@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Cc: kris@obsecurity.org Subject: Re: PAM, S/Key and authentication schemes. In-Reply-To: <20010528174728.A39588@xor.obsecurity.org> References: <200105251240.f4PCeO612402@gratis.grondar.za> <20010528121804.Q89950@gsmx07.alcatel.com.au> <20010528174728.A39588@xor.obsecurity.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20010528174728.A39588@xor.obsecurity.org>, Kris Kennaway wrote: > > We also compile all of the PAM modules included in the base system > into a static libpam which allows statically-linked binaries to work, > up to a point (they won't work if the system administrator tries to > use a third-party PAM module) We used to do this and probably still do. But I haven't tried it lately. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 23: 2:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 1104937B423 for ; Mon, 28 May 2001 23:02:29 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.3/8.11.3) with ESMTP id f4T62A654885; Tue, 29 May 2001 08:02:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200105290602.f4T62A654885@gratis.grondar.za> To: Kris Kennaway Cc: arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <20010528174728.A39588@xor.obsecurity.org> In-Reply-To: <20010528174728.A39588@xor.obsecurity.org> ; from Kris Kennaway "Mon, 28 May 2001 17:47:29 MST." Date: Tue, 29 May 2001 08:04:27 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The only danger area I can see is the need to check root password to > > get to single-user if the console is not secure. This needs to work > > even if (and especially when) the system is hosed. I wouldn't like to > > see init become dependent on the dynamic loader and various PAM > > libraries in this case. > > We also compile all of the PAM modules included in the base system > into a static libpam which allows statically-linked binaries to work, > up to a point (they won't work if the system administrator tries to > use a third-party PAM module) I'll stay out of the static stuff as long as I can for exactly this reason. Init(8) will be especially left alone. :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 28 23:53:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id F309737B422 for ; Mon, 28 May 2001 23:53:53 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id QAA14512; Tue, 29 May 2001 16:53:51 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01K45639W00GVF92ZY@cim.alcatel.com.au>; Tue, 29 May 2001 16:53:38 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f4T6rce13260; Tue, 29 May 2001 16:53:39 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Tue, 29 May 2001 16:53:38 +1000 From: Peter Jeremy Subject: Re: PAM, S/Key and authentication schemes. In-reply-to: <200105290602.f4T62A654885@gratis.grondar.za>; from mark@grondar.za on Tue, May 29, 2001 at 08:04:27AM +0200 To: Mark Murray Cc: arch@FreeBSD.ORG Mail-Followup-To: Mark Murray , arch@FreeBSD.ORG Message-id: <20010529165338.I89950@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010528174728.A39588@xor.obsecurity.org> <200105290602.f4T62A654885@gratis.grondar.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2001-May-29 08:04:27 +0200, Mark Murray wrote: >> > The only danger area I can see is the need to check root password to >> > get to single-user if the console is not secure. This needs to work >> > even if (and especially when) the system is hosed. I wouldn't like to >> > see init become dependent on the dynamic loader and various PAM >> > libraries in this case. >> >> We also compile all of the PAM modules included in the base system >> into a static libpam which allows statically-linked binaries to work, >> up to a point (they won't work if the system administrator tries to >> use a third-party PAM module) > >I'll stay out of the static stuff as long as I can for exactly this >reason. Init(8) will be especially left alone. :-) Which means that somewhere there needs to be a note that if your console is marked 'insecure' then /etc/master.passwd must contain a root password that crypt(3) can understand (irrespective of how eg login(1) might authenticate a root login attempt). Otherwise, someone is sure to get bitten. The init(8) man page is one possibility, but I'm not sure it's the obvious place to look when you discover you're locked out of single-user mode. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 1:11:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 83CEE37B423 for ; Tue, 29 May 2001 01:11:12 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 154eap-0003ho-00; Tue, 29 May 2001 10:11:07 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id KAA05723; Tue, 29 May 2001 10:11:06 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 5691; Tue May 29 10:10:32 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 154eaG-000O2a-00; Tue, 29 May 2001 10:10:32 +0200 From: Sheldon Hearn To: Peter Jeremy Cc: Mark Murray , arch@freebsd.org Subject: Re: PAM, S/Key and authentication schemes. In-reply-to: Your message of "Tue, 29 May 2001 16:53:38 +1000." <20010529165338.I89950@gsmx07.alcatel.com.au> Date: Tue, 29 May 2001 10:10:32 +0200 Message-ID: <92415.991123832@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 29 May 2001 16:53:38 +1000, Peter Jeremy wrote: > Which means that somewhere there needs to be a note that if your > console is marked 'insecure' then /etc/master.passwd must contain a > root password that crypt(3) can understand (irrespective of how eg > login(1) might authenticate a root login attempt). Otherwise, someone > is sure to get bitten. The init(8) man page is one possibility, but > I'm not sure it's the obvious place to look when you discover you're > locked out of single-user mode. I reckon /etc/ttys and the release notes ought to do it. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 3:45:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 76B8737B424 for ; Tue, 29 May 2001 03:45:55 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA20482; Tue, 29 May 2001 12:45:48 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch References: <20010529004338.A25933E2F@bazooka.unixfreak.org> From: Dag-Erling Smorgrav Date: 29 May 2001 12:45:47 +0200 In-Reply-To: <20010529004338.A25933E2F@bazooka.unixfreak.org> Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman writes: > Dag-Erling Smorgrav writes: > > Damn, yet another kbdcontrol bug. This - like every other vty- > > specific knob - should be in vidcontrol. > Are keymaps vty-specific? No, they're global. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 4: 2:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-66.dsl.lsan03.pacbell.net [63.207.60.66]) by hub.freebsd.org (Postfix) with ESMTP id 5F42F37B446; Tue, 29 May 2001 04:02:52 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3C22B66D37; Tue, 29 May 2001 04:02:51 -0700 (PDT) Date: Tue, 29 May 2001 04:02:50 -0700 From: Kris Kennaway To: "David E. O'Brien" Cc: arch@FreeBSD.org Subject: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) Message-ID: <20010529040250.A81586@xor.obsecurity.org> Reply-To: arch@FreeBSD.org References: <200105290954.f4T9skF86521@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105290954.f4T9skF86521@freefall.freebsd.org>; from obrien@FreeBSD.org on Tue, May 29, 2001 at 02:54:46AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 29, 2001 at 02:54:46AM -0700, David E. O'Brien wrote: > obrien 2001/05/29 02:54:46 PDT >=20 > Modified files: > contrib/gcc.295 gcc.c=20 > Log: > Support the environmental var "GCC_OPTIONS". Which can hold a set of > default options for GCC. These options are interpreted first and can be > overwritten by explicit command line parameters. This provides one way= of > adding [temporary] options to your world build w/o editing /etc/make.co= nf. Hmm. We now have a number of ways of achieving this (some of these only work in some contexts): Defining CFLAGS with ?=3D instead of =3D in /etc/make.conf COPTS in CWARNFLAGS in (included from ) DEBUG_FLAGS in The latter three obviously don't cover general code, but the plethora of options is starting to get ugly. Kris --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7E4HZWry0BWjoQKURAnIQAKDqrc9kJy7dKWGt9SMCP9fHIoxapQCffkGp H3q41MvVsRweHdSy/zc6xjU= =8vBq -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 9:31:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id AB29037B422 for ; Tue, 29 May 2001 09:31:39 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f4TGVdl53147 for ; Tue, 29 May 2001 09:31:39 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4TGVcn34387 for arch@FreeBSD.org; Tue, 29 May 2001 09:31:38 -0700 (PDT) (envelope-from obrien) Date: Tue, 29 May 2001 09:31:38 -0700 From: "David O'Brien" To: arch@FreeBSD.org Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) Message-ID: <20010529093138.D34199@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200105290954.f4T9skF86521@freefall.freebsd.org> <20010529040250.A81586@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010529040250.A81586@xor.obsecurity.org>; from kris@obsecurity.org on Tue, May 29, 2001 at 04:02:50AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 29, 2001 at 04:02:50AM -0700, Kris Kennaway wrote: > On Tue, May 29, 2001 at 02:54:46AM -0700, David E. O'Brien wrote: > > obrien 2001/05/29 02:54:46 PDT > > > > Modified files: > > contrib/gcc.295 gcc.c > > Log: > > Support the environmental var "GCC_OPTIONS". Which can hold a set of > > default options for GCC. These options are interpreted first and can be > > overwritten by explicit command line parameters. This provides one way of > > adding [temporary] options to your world build w/o editing /etc/make.conf. ... > The latter three obviously don't cover general code, but the plethora > of options is starting to get ugly. I just mentioned the use of GCC_OPTIONS I did figuring that one would interest people the most. I added GCC_OPTIONS to be orthoginal with DIFF_OPTIONS, CVS_OPTIONS, and GREP_OPTIONS. GCC_OPTIONS could also be used when building third party software and you dont' want to edit their Makefiles, etc. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 14:43:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 244FD37B422; Tue, 29 May 2001 14:43:43 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4TLhZf33927; Tue, 29 May 2001 23:43:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org, arch@freebsd.org Subject: MFS gone... From: Poul-Henning Kamp Date: Tue, 29 May 2001 23:43:35 +0200 Message-ID: <33925.991172615@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG MFS is gone now except from the newfs(8) manpage. If anybody better at mdoc than me would take on the surgical task of censoring that page I would be most happy. The command name "mount_mfs" is now available for use for other purposes like a md(4) based facility, I'm not happy about "stealing" a name from the mount_*(8) api for doing something which isn't really that. The opposite argument could be made successfully though, that by stealing the name we allow people to write something sensible in their /etc/fstab and then later when we get a _real_ memory filesystem, they will not have to fiddle it again. As usual I revert to the safety of "whoever writes the code make decisions as well..." -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 19:55:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id C043D37B422; Tue, 29 May 2001 19:55:54 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U2trY73524; Wed, 30 May 2001 03:55:53 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U2tqH13615; Wed, 30 May 2001 03:55:52 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105300255.f4U2tqH13615@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: freebsd-arch@FreeBSD.org, phk@FreeBSD.org Cc: Brian Somers Subject: How to handle cloning in a pseudo device. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 May 2001 03:55:52 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I've been working on making tun clone properly and have come up with a perplexing problem (well, perplexing to me). As tun currently works, it calls make_dev() from the clone routine. If a non-root user does (say) ``touch /dev/tun100'', the clone routine is called, /dev/tun100 is make_dev()d with root/wheel/600 permissions and the d_open routine is never called because the user doesn't have permission to open. One way to solve this might be to allocate the softc from the clone routine, but this means that a rogue user can go into /dev and potentially run the system out of memory with a quick ``touch'' loop. Another way would be to keep a light weight list of make_dev()d-but- not-yet-created units. rman springs to mind (8*D), but there's no mechanism in rman for retrieving used resources - just for retrieving unused ones, and besides, a thoughtful user could touch every even numbered tun device and provide the same benefits. Perhaps the best way is to introduce a failed-to-open EVENTHANDLER that'll get called when d_open isn't called for whatever reason. Thoughts ? Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 22: 3:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id E7DB637B423 for ; Tue, 29 May 2001 22:03:19 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 9506F3E28; Tue, 29 May 2001 22:03:19 -0700 (PDT) To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch In-Reply-To: ; from des@ofug.org on "29 May 2001 12:45:47 +0200" Date: Tue, 29 May 2001 22:03:19 -0700 From: Dima Dorfman Message-Id: <20010530050319.9506F3E28@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > Dima Dorfman writes: > > Dag-Erling Smorgrav writes: > > > Damn, yet another kbdcontrol bug. This - like every other vty- > > > specific knob - should be in vidcontrol. > > Are keymaps vty-specific? > > No, they're global. Okay, then that leaves -f, -F, -b, and -r in kbdcontrol. The patch attached below moves those to vidcontrol as -F, -G, -B, and -R, respectively. If this ends up getting committed I'll gladly nuke allscreens_kbdflags. Comments? Thanks, Dima Dorfman dima@unixfreak.org Index: kbdcontrol/kbdcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.1,v retrieving revision 1.30 diff -u -r1.30 kbdcontrol.1 --- kbdcontrol/kbdcontrol.1 2001/05/28 11:05:26 1.30 +++ kbdcontrol/kbdcontrol.1 2001/05/30 04:59:43 @@ -13,7 +13,7 @@ .\" @(#)kbdcontrol.1 .\" $FreeBSD: src/usr.sbin/kbdcontrol/kbdcontrol.1,v 1.30 2001/05/28 11:05:26 des Exp $ .\" -.Dd May 27, 2001 +.Dd May 29, 2001 .Dt KBDCONTROL 1 .Os .Sh NAME @@ -21,17 +21,8 @@ .Nd keyboard control and configuration utility .Sh SYNOPSIS .Nm -.Op Fl dFKix -.Oo -.Fl b -.Ar duration . Ns Ar pitch | Ar belltype -.Oc -.Oo -.Fl r -.Ar delay . Ns Ar repeat | Ar speed -.Oc +.Op Fl dKix .Op Fl l Ar keymap_file -.Op Fl f Ar # Ar string .Op Fl k Ar keyboard_device .Op Fl L Ar keymap_file .Sh DESCRIPTION @@ -52,45 +43,6 @@ .Pp The following command line options are supported: .Bl -tag -width indent -.It Fl b Xo -.Ar duration . Ns Ar pitch | Ar belltype -.Xc -Set the bell duration in milliseconds and pitch in hertz. -If a -.Ar belltype -argument is specified, it may be one of -.Cm normal -which sets sound parameters back to normal values, -.Cm off -which disables the bell entirely, or -.Cm visual -which sets the bell to visual mode, i.e. flashes the screen instead. -If -.Ar belltype -is preceded by the word -.Cm quiet. , -the bell will not be rung when the ringing process is in the background vty. -.It Fl r Xo -.Ar delay . Ns Ar repeat | Ar speed -.Xc -Set keyboard -.Ar delay -(250, 500, 750, 1000) -and -.Ar repeat -(34, 38, 42, 46, 50, 55, 59, 63, 68, 76, 84, 92, 100, 110, 118, 126, -136, 152, 168, 184, 200, 220, 236, 252, 272, 304, 336, 368, 400, 440, -472, 504) -rates, or if a -.Ar speed -argument is specified, it may be one of -.Cm slow -(1000.504), -.Cm fast -(250.34) -or -.Cm normal -(500.126). .It Fl l Ar keymap_file Install keyboard map file from .Ar keymap_file . @@ -102,16 +54,6 @@ back to the kernel later by the .Fl l option above. -.It Fl f Ar # Ar string -Set function key number -.Ar # -to send -.Ar string . -Refer to the man page for the keyboard driver -.Pq e.g. Xr atkbd 4 -for available function keys and their numbers. -.It Fl F -Set function keys back to the standard definitions. .It Fl x Use hexadecimal numbers in keyboard map dump. .It Fl i Index: kbdcontrol/kbdcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v retrieving revision 1.41 diff -u -r1.41 kbdcontrol.c --- kbdcontrol/kbdcontrol.c 2001/05/29 13:59:02 1.41 +++ kbdcontrol/kbdcontrol.c 2001/05/30 04:59:44 @@ -70,40 +70,6 @@ "DCAR", }; -char fkey_table[96][MAXFK] = { -/* 01-04 */ "\033[M", "\033[N", "\033[O", "\033[P", -/* 05-08 */ "\033[Q", "\033[R", "\033[S", "\033[T", -/* 09-12 */ "\033[U", "\033[V", "\033[W", "\033[X", -/* 13-16 */ "\033[Y", "\033[Z", "\033[a", "\033[b", -/* 17-20 */ "\033[c", "\033[d", "\033[e", "\033[f", -/* 21-24 */ "\033[g", "\033[h", "\033[i", "\033[j", -/* 25-28 */ "\033[k", "\033[l", "\033[m", "\033[n", -/* 29-32 */ "\033[o", "\033[p", "\033[q", "\033[r", -/* 33-36 */ "\033[s", "\033[t", "\033[u", "\033[v", -/* 37-40 */ "\033[w", "\033[x", "\033[y", "\033[z", -/* 41-44 */ "\033[@", "\033[[", "\033[\\","\033[]", -/* 45-48 */ "\033[^", "\033[_", "\033[`", "\033[{", -/* 49-52 */ "\033[H", "\033[A", "\033[I", "-" , -/* 53-56 */ "\033[D", "\033[E", "\033[C", "+" , -/* 57-60 */ "\033[F", "\033[B", "\033[G", "\033[L", -/* 61-64 */ "\177", "\033[J", "\033[~", "\033[}", -/* 65-68 */ "" , "" , "" , "" , -/* 69-72 */ "" , "" , "" , "" , -/* 73-76 */ "" , "" , "" , "" , -/* 77-80 */ "" , "" , "" , "" , -/* 81-84 */ "" , "" , "" , "" , -/* 85-88 */ "" , "" , "" , "" , -/* 89-92 */ "" , "" , "" , "" , -/* 93-96 */ "" , "" , "" , "" , - }; - -const int delays[] = {250, 500, 750, 1000}; -const int repeats[] = { 34, 38, 42, 46, 50, 55, 59, 63, - 68, 76, 84, 92, 100, 110, 118, 126, - 136, 152, 168, 184, 200, 220, 236, 252, - 272, 304, 336, 368, 400, 440, 472, 504}; -const int ndelays = (sizeof(delays) / sizeof(int)); -const int nrepeats = (sizeof(repeats) / sizeof(int)); int hex = 0; int number; char letter; @@ -835,139 +801,6 @@ } - -void -load_default_functionkeys() -{ - fkeyarg_t fkey; - int i; - - for (i=0; i NUM_FKEYS) { - warnx("function key number must be between 1 and %d", - NUM_FKEYS); - return; - } - if ((fkey.flen = strlen(string)) > MAXFK) { - warnx("function key string too long (%d > %d)", - fkey.flen, MAXFK); - return; - } - strcpy(fkey.keydef, string); - fkey.keynum -= 1; - if (ioctl(0, SETFKEY, &fkey) < 0) - warn("setting function key"); -} - - -void -set_bell_values(char *opt) -{ - int bell, duration, pitch; - - bell = 0; - if (!strncmp(opt, "quiet.", 6)) { - bell = 2; - opt += 6; - } - if (!strcmp(opt, "visual")) - bell |= 1; - else if (!strcmp(opt, "normal")) - duration = 5, pitch = 800; - else if (!strcmp(opt, "off")) - duration = 0, pitch = 0; - else { - char *v1; - - bell = 0; - duration = strtol(opt, &v1, 0); - if ((duration < 0) || (*v1 != '.')) - goto badopt; - opt = ++v1; - pitch = strtol(opt, &v1, 0); - if ((pitch < 0) || (*opt == '\0') || (*v1 != '\0')) { -badopt: - warnx("argument to -b must be duration.pitch or [quiet.]visual|normal|off"); - return; - } - if (pitch != 0) - pitch = 1193182 / pitch; /* in Hz */ - duration /= 10; /* in 10 m sec */ - } - - ioctl(0, CONS_BELLTYPE, &bell); - if ((bell & ~2) == 0) - fprintf(stderr, "[=%d;%dB", pitch, duration); -} - - -void -set_keyrates(char *opt) -{ - int arg[2]; - int repeat; - int delay; - int r, d; - - if (!strcmp(opt, "slow")) { - delay = 1000, repeat = 500; - d = 3, r = 31; - } else if (!strcmp(opt, "normal")) { - delay = 500, repeat = 125; - d = 1, r = 15; - } else if (!strcmp(opt, "fast")) { - delay = repeat = 0; - d = r = 0; - } else { - int n; - char *v1; - - delay = strtol(opt, &v1, 0); - if ((delay < 0) || (*v1 != '.')) - goto badopt; - opt = ++v1; - repeat = strtol(opt, &v1, 0); - if ((repeat < 0) || (*opt == '\0') || (*v1 != '\0')) { -badopt: - warnx("argument to -r must be delay.repeat or slow|normal|fast"); - return; - } - for (n = 0; n < ndelays - 1; n++) - if (delay <= delays[n]) - break; - d = n; - for (n = 0; n < nrepeats - 1; n++) - if (repeat <= repeats[n]) - break; - r = n; - } - - arg[0] = delay; - arg[1] = repeat; - if (ioctl(0, KDSETREPEAT, arg)) { - if (ioctl(0, KDSETRAD, (d << 5) | r)) - warn("setting keyboard rate"); - } -} - static char *get_kbd_type_name(int type) { @@ -1066,10 +899,8 @@ void usage() { - fprintf(stderr, "%s\n%s\n%s\n", -"usage: kbdcontrol [-dFKix] [-b duration.pitch | [quiet.]belltype]", -" [-r delay.repeat | speed] [-l mapfile] [-f # string]", -" [-k device] [-L mapfile]"); + fprintf(stderr, "%s\n", +"usage: kbdcontrol [-dKix] [-l mapfile] [-k device] [-L mapfile]"); exit(1); } @@ -1081,9 +912,6 @@ while((opt = getopt(argc, argv, "b:df:iKk:Fl:L:r:x")) != -1) switch(opt) { - case 'b': - set_bell_values(optarg); - break; case 'd': print_keymap(); break; @@ -1093,13 +921,6 @@ case 'L': load_keymap(optarg, 1); break; - case 'f': - set_functionkey(optarg, - nextarg(argc, argv, &optind, 'f')); - break; - case 'F': - load_default_functionkeys(); - break; case 'i': show_kbd_info(); break; @@ -1108,9 +929,6 @@ break; case 'k': set_keyboard(optarg); - break; - case 'r': - set_keyrates(optarg); break; case 'x': hex = 1; Index: vidcontrol/vidcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v retrieving revision 1.39 diff -u -r1.39 vidcontrol.1 --- vidcontrol/vidcontrol.1 2001/05/29 18:48:13 1.39 +++ vidcontrol/vidcontrol.1 2001/05/30 04:59:44 @@ -13,7 +13,7 @@ .\" @(#)vidcontrol.1 .\" $FreeBSD: src/usr.sbin/vidcontrol/vidcontrol.1,v 1.39 2001/05/29 18:48:13 sobomax Exp $ .\" -.Dd May 27, 2001 +.Dd May 29, 2001 .Dt VIDCONTROL 1 .Os .Sh NAME @@ -21,9 +21,14 @@ .Nd system console control and configuration utility .Sh SYNOPSIS .Nm -.Op Fl CdLPpx +.Op Fl CdGLPpx +.Oo +.Fl B +.Ar duration . Ns Ar pitch | Ar belltype +.Oc .Op Fl b Ar color .Op Fl c Ar appearance +.Op Fl F Ar # Ar string .Oo .Fl f .Op Ar size @@ -35,6 +40,10 @@ .Op Fl l Ar screen_map .Op Fl M Ar char .Op Fl m Cm on | off +.Oo +.Fl R +.Ar delay . Ns Ar repeat | Ar speed +.Oc .Op Fl r Ar foreground Ar background .Op Fl s Ar number .Op Fl t Ar N | Cm off @@ -103,6 +112,24 @@ command below to see available colors. .It Cm show See the supported colors on a given platform. +.It Fl B Xo +.Ar duration . Ns Ar pitch | Ar belltype +.Xc +Set the bell duration in milliseconds and pitch in hertz. +If a +.Ar belltype +argument is specified, it may be one of +.Cm normal +which sets sound parameters back to normal values, +.Cm off +which disables the bell entirely, or +.Cm visual +which sets the bell to visual mode, i.e. flashes the screen instead. +If +.Ar belltype +is preceded by the word +.Cm quiet. , +the bell will not be rung when the ringing process is in the background vty. .It Fl b Ar color Set border color to .Ar color . @@ -120,6 +147,14 @@ The latter is actually a simulation. .It Fl d Print out current output screen map. +.It Fl F Ar # Ar string +Set function key number +.Ar # +to send +.Ar string . +Refer to the man page for the keyboard driver +.Pq e.g. Xr atkbd 4 +for available function keys and their numbers. .It Xo .Fl f .Op Ar size @@ -152,6 +187,8 @@ .Sx EXAMPLES below and the man page for .Xr syscons 4 . +.It Fl G +Set function keys back to the standard definitions. .It Fl g Ar geometry Set the .Ar geometry @@ -207,6 +244,27 @@ but dump contents of the video buffer in a plain text format ignoring nonprintable characters and information about text attributes. +.It Fl R Xo +.Ar delay . Ns Ar repeat | Ar speed +.Xc +Set keyboard +.Ar delay +(250, 500, 750, 1000) +and +.Ar repeat +(34, 38, 42, 46, 50, 55, 59, 63, 68, 76, 84, 92, 100, 110, 118, 126, +136, 152, 168, 184, 200, 220, 236, 252, 272, 304, 336, 368, 400, 440, +472, 504) +rates, or if a +.Ar speed +argument is specified, it may be one of +.Cm slow +(1000.504), +.Cm fast +(250.34) +or +.Cm normal +(500.126). .It Fl r Ar foreground background Change reverse mode colors to .Ar foreground Index: vidcontrol/vidcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v retrieving revision 1.39 diff -u -r1.39 vidcontrol.c --- vidcontrol/vidcontrol.c 2001/05/28 11:05:28 1.39 +++ vidcontrol/vidcontrol.c 2001/05/30 04:59:45 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -55,12 +56,46 @@ #define DUMP_FMT_REV 1 +char fkey_table[96][MAXFK] = { +/* 01-04 */ "\033[M", "\033[N", "\033[O", "\033[P", +/* 05-08 */ "\033[Q", "\033[R", "\033[S", "\033[T", +/* 09-12 */ "\033[U", "\033[V", "\033[W", "\033[X", +/* 13-16 */ "\033[Y", "\033[Z", "\033[a", "\033[b", +/* 17-20 */ "\033[c", "\033[d", "\033[e", "\033[f", +/* 21-24 */ "\033[g", "\033[h", "\033[i", "\033[j", +/* 25-28 */ "\033[k", "\033[l", "\033[m", "\033[n", +/* 29-32 */ "\033[o", "\033[p", "\033[q", "\033[r", +/* 33-36 */ "\033[s", "\033[t", "\033[u", "\033[v", +/* 37-40 */ "\033[w", "\033[x", "\033[y", "\033[z", +/* 41-44 */ "\033[@", "\033[[", "\033[\\","\033[]", +/* 45-48 */ "\033[^", "\033[_", "\033[`", "\033[{", +/* 49-52 */ "\033[H", "\033[A", "\033[I", "-" , +/* 53-56 */ "\033[D", "\033[E", "\033[C", "+" , +/* 57-60 */ "\033[F", "\033[B", "\033[G", "\033[L", +/* 61-64 */ "\177", "\033[J", "\033[~", "\033[}", +/* 65-68 */ "" , "" , "" , "" , +/* 69-72 */ "" , "" , "" , "" , +/* 73-76 */ "" , "" , "" , "" , +/* 77-80 */ "" , "" , "" , "" , +/* 81-84 */ "" , "" , "" , "" , +/* 85-88 */ "" , "" , "" , "" , +/* 89-92 */ "" , "" , "" , "" , +/* 93-96 */ "" , "" , "" , "" , + }; + char legal_colors[16][16] = { "black", "blue", "green", "cyan", "red", "magenta", "brown", "white", "grey", "lightblue", "lightgreen", "lightcyan", "lightred", "lightmagenta", "yellow", "lightwhite" }; +const int delays[] = {250, 500, 750, 1000}; +const int repeats[] = { 34, 38, 42, 46, 50, 55, 59, 63, + 68, 76, 84, 92, 100, 110, 118, 126, + 136, 152, 168, 184, 200, 220, 236, 252, + 272, 304, 336, 368, 400, 440, 472, 504}; +const int ndelays = (sizeof(delays) / sizeof(int)); +const int nrepeats = (sizeof(repeats) / sizeof(int)); int hex = 0; int number; int vesa_cols = _VESA_800x600_DFL_COLS; @@ -72,11 +107,14 @@ static void usage() { - fprintf(stderr, "%s\n%s\n%s\n%s\n", -"usage: vidcontrol [-CdLPpx] [-b color] [-c appearance] [-f [size] file]", -" [-g geometry] [-h size] [-i adapter | mode] [-l screen_map]", -" [-m on | off] [-M char] [-r foreground background] [-s num]", -" [-t N | off] [mode] [foreground [background]] [show]"); + fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n%s\n%s\n", +"usage: vidcontrol [-CdGLPpx] [-B duration.pitch | [quiet.]belltype] ", +" [-b color] [-c appearance] [-F # string] [-f [size] file]", +" [-g geometry] [-h size] [-i adapter | mode]", +" [-l screen_map] [-m on | off] [-M char]", +" [-R delay.repeat | speed] [-r foreground background]", +" [-s num] [-t N | off]", +" [mode] [foreground [background]] [show]"); exit(1); } @@ -736,6 +774,136 @@ warn("clear history buffer"); } +void +set_bell_values(char *opt) +{ + int bell, duration, pitch; + + bell = 0; + if (!strncmp(opt, "quiet.", 6)) { + bell = 2; + opt += 6; + } + if (!strcmp(opt, "visual")) + bell |= 1; + else if (!strcmp(opt, "normal")) + duration = 5, pitch = 800; + else if (!strcmp(opt, "off")) + duration = 0, pitch = 0; + else { + char *v1; + + bell = 0; + duration = strtol(opt, &v1, 0); + if ((duration < 0) || (*v1 != '.')) + goto badopt; + opt = ++v1; + pitch = strtol(opt, &v1, 0); + if ((pitch < 0) || (*opt == '\0') || (*v1 != '\0')) { +badopt: + warnx("argument to -B must be duration.pitch or [quiet.]visual|normal|off"); + return; + } + if (pitch != 0) + pitch = 1193182 / pitch; /* in Hz */ + duration /= 10; /* in 10 m sec */ + } + + ioctl(0, CONS_BELLTYPE, &bell); + if ((bell & ~2) == 0) + fprintf(stderr, "[=%d;%dB", pitch, duration); +} + +void +set_keyrates(char *opt) +{ + int arg[2]; + int repeat; + int delay; + int r, d; + + if (!strcmp(opt, "slow")) { + delay = 1000, repeat = 500; + d = 3, r = 31; + } else if (!strcmp(opt, "normal")) { + delay = 500, repeat = 125; + d = 1, r = 15; + } else if (!strcmp(opt, "fast")) { + delay = repeat = 0; + d = r = 0; + } else { + int n; + char *v1; + + delay = strtol(opt, &v1, 0); + if ((delay < 0) || (*v1 != '.')) + goto badopt; + opt = ++v1; + repeat = strtol(opt, &v1, 0); + if ((repeat < 0) || (*opt == '\0') || (*v1 != '\0')) { +badopt: + warnx("argument to -R must be delay.repeat or slow|normal|fast"); + return; + } + for (n = 0; n < ndelays - 1; n++) + if (delay <= delays[n]) + break; + d = n; + for (n = 0; n < nrepeats - 1; n++) + if (repeat <= repeats[n]) + break; + r = n; + } + + arg[0] = delay; + arg[1] = repeat; + if (ioctl(0, KDSETREPEAT, arg)) { + if (ioctl(0, KDSETRAD, (d << 5) | r)) + warn("setting keyboard rate"); + } +} + +void +load_default_functionkeys() +{ + fkeyarg_t fkey; + int i; + + for (i=0; i NUM_FKEYS) { + warnx("function key number must be between 1 and %d", + NUM_FKEYS); + return; + } + if ((fkey.flen = strlen(string)) > MAXFK) { + warnx("function key string too long (%d > %d)", + fkey.flen, MAXFK); + return; + } + strcpy(fkey.keydef, string); + fkey.keynum -= 1; + if (ioctl(0, SETFKEY, &fkey) < 0) + warn("setting function key"); +} + int main(int argc, char **argv) { @@ -749,8 +917,12 @@ /* Not reached */ if (ioctl(0, CONS_GETINFO, &info) < 0) err(1, "must be on a virtual console"); - while((opt = getopt(argc, argv, "b:Cc:df:g:h:i:l:LM:m:pPr:s:t:x")) != -1) + while((opt = getopt(argc, argv, + "B:b:Cc:dF:f:Gg:h:i:l:LM:m:pPR:r:s:t:x")) != -1) switch(opt) { + case 'B': + set_bell_values(optarg); + break; case 'b': set_border_color(optarg); break; @@ -763,6 +935,10 @@ case 'd': print_scrnmap(); break; + case 'F': + set_functionkey(optarg, + nextarg(argc, argv, &optind, 'f', 1)); + break; case 'f': type = optarg; font = nextarg(argc, argv, &optind, 'f', 0); @@ -772,6 +948,9 @@ } load_font(type, font); break; + case 'G': + load_default_functionkeys(); + break; case 'g': if (sscanf(optarg, "%dx%d", &vesa_cols, &vesa_rows) != 2) { @@ -802,6 +981,9 @@ break; case 'P': dump_screen(DUMP_TXT); + break; + case 'R': + set_keyrates(optarg); break; case 'r': set_reverse_colors(argc, argv, &optind); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 22:26:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [204.69.232.69]) by hub.freebsd.org (Postfix) with ESMTP id 0D2EF37B423 for ; Tue, 29 May 2001 22:26:28 -0700 (PDT) (envelope-from jonathan@graehl.org) Received: from case (root@localhost [127.0.0.1]) by molly.straylight.com (8.11.0/8.10.0) with ESMTP id f4U5QH824659 for ; Tue, 29 May 2001 22:26:17 -0700 From: "Jonathan Graehl" To: Subject: Ipf license woes Date: Tue, 29 May 2001 22:27:20 -0700 Message-ID: <001e01c0e8c9$3398db20$6dfeac40@straylight.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From Theo (OpenBSD): "sometime in the next 20 hours, i will be removing ipf from the source tree since it does not meet our freedom requirements, as have been outlined in policy.html and goals.html since the start of our project. we will have to work on an alternative." I've used netfilter/iptables (Linux 2.4 and on) fairly extensively, and it seems to be a good ipf-alike. -- Jonathan Graehl http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 22:37:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-66.dsl.lsan03.pacbell.net [63.207.60.66]) by hub.freebsd.org (Postfix) with ESMTP id C017F37B422 for ; Tue, 29 May 2001 22:37:56 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A5E79671A4; Tue, 29 May 2001 22:37:55 -0700 (PDT) Date: Tue, 29 May 2001 22:37:55 -0700 From: Kris Kennaway To: Jonathan Graehl Cc: freebsd-arch@freebsd.org Subject: Re: Ipf license woes Message-ID: <20010529223755.A14304@xor.obsecurity.org> References: <001e01c0e8c9$3398db20$6dfeac40@straylight.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001e01c0e8c9$3398db20$6dfeac40@straylight.com>; from jonathan@graehl.org on Tue, May 29, 2001 at 10:27:20PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 29, 2001 at 10:27:20PM -0700, Jonathan Graehl wrote: > >From Theo (OpenBSD): >=20 > "sometime in the next 20 hours, i will be removing ipf from the source > tree since it does not meet our freedom requirements, as have been > outlined in policy.html and goals.html since the start of our project.=20 >=20 > we will have to work on an alternative." >=20 > I've used netfilter/iptables (Linux 2.4 and on) fairly extensively, and > it seems to be a good ipf-alike. Sorry, but how is the above relevant to FreeBSD? The licensing flame-war isn't news, and it's something we've already been clarifying with Darren. My own perspective is that it's been badly mishandled by a lot of people and blown out of all proportion. Kris --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7FIczWry0BWjoQKURAi/cAKCWc1A50wUW4MR/e5Ce/tRvMH+AiwCcCpgO MHr6T1kGHX/cW0CLgnE5ViQ= =rbKY -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 29 22:42:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 7E0D637B42C for ; Tue, 29 May 2001 22:42:27 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f4U5ma200860; Tue, 29 May 2001 22:48:36 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200105300548.f4U5ma200860@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jonathan Graehl" Cc: freebsd-arch@freebsd.org Subject: Re: Ipf license woes In-reply-to: Your message of "Tue, 29 May 2001 22:27:20 PDT." <001e01c0e8c9$3398db20$6dfeac40@straylight.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 May 2001 22:48:36 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Just to keep these threads short; FreeBSD's core team is talking with Darren Reed to ensure that we understand his position. There's likely to be a more formal announcement on the subject shortly, but in the meantime I'd like to ask people not to panic, or to say or do anything silly. The goal here is to work out something sensible, and the best way for us to achieve this is for everyone to stay calm. I think that -core has a good idea of what the FreeBSD community would like to see out of IPFilter, and I'm confident that we can resolve this without any untoward drama. Thanks for your patience until then. Regards, Mike (not speaking officially for -core) > >From Theo (OpenBSD): > > "sometime in the next 20 hours, i will be removing ipf from the source > tree since it does not meet our freedom requirements, as have been > outlined in policy.html and goals.html since the start of our project. > > we will have to work on an alternative." > > I've used netfilter/iptables (Linux 2.4 and on) fairly extensively, and > it seems to be a good ipf-alike. > > > -- > Jonathan Graehl > http://jonathan.graehl.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 1:36:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id 9F45F37B422 for ; Wed, 30 May 2001 01:36:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0246.cvx7-bradley.dialup.earthlink.net [209.178.164.246]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA26251; Wed, 30 May 2001 04:35:59 -0400 (EDT) Message-ID: <3B14B109.C08F1970@mindspring.com> Date: Wed, 30 May 2001 01:36:25 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <89661.990794824@axl.fw.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > On Fri, 25 May 2001 14:42:40 +0200, Mark Murray wrote: > > I have already tested this on my home cluster with su(1) (I just > > made su a PAM-only thing), and this makes the code a whole lot > > simpler. Simpler code == safer code. > > I think that the real win here is that we come out with a > FreeBSD that uses a flexible authentication management system > that requires once-off learning that can then be applied to > the configuration of policies for multiple tools. > > Of course there are other benefits. One is the ease of > implementation of new authentication schemes that, once > deployed, are immediately available in all the appropraite > tools). > > I think where you're going with this is excellent. What's > your anticipated time frame for getting what we have today > rationalized? We talked to the Sun guy who came up with PAM at the last FreeBSD user's group meeting, in Foster City, CA, last month. The PAM API, as it currently sits, is incapable of correctly supporting Kerberos, and several other authentication schemes. Apparently, the only way to fix this is to change the PAM API. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 1:39: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 9D8BA37B43C; Wed, 30 May 2001 01:38:49 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U8cRY74935; Wed, 30 May 2001 09:38:27 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U8cQH31659; Wed, 30 May 2001 09:38:26 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: freebsd-arch@FreeBSD.org, phk@FreeBSD.org, brian@Awfulhak.org Subject: Re: How to handle cloning in a pseudo device. In-Reply-To: Message from Brian Somers of "Wed, 30 May 2001 03:55:52 BST." <200105300255.f4U2tqH13615@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 May 2001 09:38:26 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hi, > > I've been working on making tun clone properly and have come up with > a perplexing problem (well, perplexing to me). > > As tun currently works, it calls make_dev() from the clone routine. > If a non-root user does (say) ``touch /dev/tun100'', the clone routine > is called, /dev/tun100 is make_dev()d with root/wheel/600 permissions > and the d_open routine is never called because the user doesn't have > permission to open. > > One way to solve this might be to allocate the softc from the clone > routine, but this means that a rogue user can go into /dev and > potentially run the system out of memory with a quick ``touch'' loop. > > Another way would be to keep a light weight list of make_dev()d-but- > not-yet-created units. rman springs to mind (8*D), but there's no > mechanism in rman for retrieving used resources - just for retrieving > unused ones, and besides, a thoughtful user could touch every even > numbered tun device and provide the same benefits. > > Perhaps the best way is to introduce a failed-to-open EVENTHANDLER > that'll get called when d_open isn't called for whatever reason. I guess another alternative is to use dev_depends and depend on a not-otherwise-used (tunctl?) device. > Thoughts ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 1:49: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CFC7937B422 for ; Wed, 30 May 2001 01:48:56 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4U8mlf39757; Wed, 30 May 2001 10:48:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How to handle cloning in a pseudo device. In-Reply-To: Your message of "Wed, 30 May 2001 09:38:26 BST." <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org> Date: Wed, 30 May 2001 10:48:47 +0200 Message-ID: <39755.991212527@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org>, Brian Somers write s: >> Hi, >> >> I've been working on making tun clone properly and have come up with >> a perplexing problem (well, perplexing to me). >> >> As tun currently works, it calls make_dev() from the clone routine. >> If a non-root user does (say) ``touch /dev/tun100'', the clone routine >> is called, /dev/tun100 is make_dev()d with root/wheel/600 permissions >> and the d_open routine is never called because the user doesn't have >> permission to open. Right. So far I have refrained from examining modes in the clone routine and if we can continue to avoid it I would prefer to. My take on it is that all people can do is create a vnode which they can "ls -l", and the "CHEAP_CLONE" trick makes sure that they can't DoS the system. As for your specific problem, it's pointless to allow regular users to open a tunnel device because they are not allowed to do the necessary ifconfig anyway... >> One way to solve this might be to allocate the softc from the clone >> routine, but this means that a rogue user can go into /dev and >> potentially run the system out of memory with a quick ``touch'' loop. Right, that is exactly what you don't want to do. You need to check for collisions in open, nomatter what you do, it will always be possible for races to happen between two or more processes. What you should do when people try to acccess /dev/tun is to create a hitherto unopened unit on the tunnel and mark the dev_t "CHEAP_CLONE". If people just do an ls -l /dev/tun they get a random line and that dev_t will be GC'ed pretty quickly. If they open /dev/tun they get a device and the tunopen allocates a softc and the dev_t stays. When you close, remove the softc and the dev_t should be reclaimed again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 2:15:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id A04AD37B422 for ; Wed, 30 May 2001 02:15:20 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U9F9Y75201; Wed, 30 May 2001 10:15:10 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4U9F9H32416; Wed, 30 May 2001 10:15:09 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105300915.f4U9F9H32416@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: Brian Somers , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: How to handle cloning in a pseudo device. In-Reply-To: Message from Poul-Henning Kamp of "Wed, 30 May 2001 10:48:47 +0200." <39755.991212527@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 May 2001 10:15:09 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > What you should do when people try to acccess /dev/tun is to > create a hitherto unopened unit on the tunnel and mark the > dev_t "CHEAP_CLONE". > > If people just do an ls -l /dev/tun they get a random line > and that dev_t will be GC'ed pretty quickly. The problem I had was this: $ sudo kldload if_tun $ touch /dev/tun $ sudo kldunload if_tun $ ls -l /dev/tun* The machine froze at that point - I assumed because if_tun hadn't destroy_dev()d tun0 (I haven't got the code any more so I can't give any more info right now). I'm not clear about when devfs_reclaim() gets called (resulting in an auto-destroy_dev)) ? Is that done by the syncer or something ? I've mucked about with setting a 5 second timeout after calling make_dev() from the clone routine, but it doesn't exactly give me a warm feeling of doing things right :-/ > If they open /dev/tun they get a device and the tunopen allocates > a softc and the dev_t stays. When you close, remove the softc > and the dev_t should be reclaimed again. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 2:21:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 99E1037B424 for ; Wed, 30 May 2001 02:21:49 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4U9Lfj00600; Wed, 30 May 2001 11:21:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How to handle cloning in a pseudo device. In-Reply-To: Your message of "Wed, 30 May 2001 10:15:09 BST." <200105300915.f4U9F9H32416@hak.lan.Awfulhak.org> Date: Wed, 30 May 2001 11:21:41 +0200 Message-ID: <598.991214501@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200105300915.f4U9F9H32416@hak.lan.Awfulhak.org>, Brian Somers write s: >> What you should do when people try to acccess /dev/tun is to >> create a hitherto unopened unit on the tunnel and mark the >> dev_t "CHEAP_CLONE". >> >> If people just do an ls -l /dev/tun they get a random line >> and that dev_t will be GC'ed pretty quickly. > >The problem I had was this: > > $ sudo kldload if_tun > $ touch /dev/tun > $ sudo kldunload if_tun > $ ls -l /dev/tun* > >The machine froze at that point - I assumed because if_tun hadn't >destroy_dev()d tun0 (I haven't got the code any more so I can't give >any more info right now). You shouldn't need timeouts or anything it should be all transparent. The only thing we may be missing is to silence the "Driver mistake" warning if you make_dev() a CHEAP_CLONE device twice... But the easiest way to get further is probably if you show me your patches... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 4:30:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id B096237B422; Wed, 30 May 2001 04:30:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.139.3.Dial1.SanJose1.Level3.net [209.245.139.3]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id HAA24462; Wed, 30 May 2001 07:30:34 -0400 (EDT) Message-ID: <3B14D9F4.930D82B2@mindspring.com> Date: Wed, 30 May 2001 04:31:00 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: MFS gone... References: <33925.991172615@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > MFS is gone now except from the newfs(8) manpage. Well, that and ffs_vfsops.c checking the _MFS flags in two places, so it won't compile... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 4:32:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 3C93E37B422 for ; Wed, 30 May 2001 04:32:09 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 1554Cl-0007QQ-00; Wed, 30 May 2001 13:31:59 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id NAA24762; Wed, 30 May 2001 13:31:55 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 24617; Wed May 30 13:31:16 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 1554C3-0003wE-00; Wed, 30 May 2001 13:31:15 +0200 From: Sheldon Hearn To: Dima Dorfman Cc: Dag-Erling Smorgrav , arch@freebsd.org Subject: Re: {kbd,vid}control insanity patch In-reply-to: Your message of "Tue, 29 May 2001 22:03:19 MST." <20010530050319.9506F3E28@bazooka.unixfreak.org> Date: Wed, 30 May 2001 13:31:15 +0200 Message-ID: <15141.991222275@axl.fw.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 29 May 2001 22:03:19 MST, Dima Dorfman wrote: > Okay, then that leaves -f, -F, -b, and -r in kbdcontrol. The patch > attached below moves those to vidcontrol as -F, -G, -B, and -R, > respectively. If this ends up getting committed I'll gladly nuke > allscreens_kbdflags. I understand where this is going, but it "feels weird" to have something called kbdcontrol that you don't use to set the typematic rate of your keyboard, and something called vidcontrol that does the job instead. Now if vidcontrol were called sccontrol, that'd be a different story. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 5:48: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 6ABD037B422 for ; Wed, 30 May 2001 05:48:02 -0700 (PDT) (envelope-from nectar@nectar.com) Received: by gw.nectar.com (Postfix, from userid 1001) id 044F818C98; Wed, 30 May 2001 07:47:57 -0500 (CDT) Date: Wed, 30 May 2001 07:47:57 -0500 From: "Jacques A. Vidrine" To: Terry Lambert Cc: Sheldon Hearn , Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. Message-ID: <20010530074757.A53937@spawn.nectar.com> References: <89661.990794824@axl.fw.uunet.co.za> <3B14B109.C08F1970@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B14B109.C08F1970@mindspring.com>; from tlambert2@mindspring.com on Wed, May 30, 2001 at 01:36:25AM -0700 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 30, 2001 at 01:36:25AM -0700, Terry Lambert wrote: > We talked to the Sun guy who came up with PAM at the last > FreeBSD user's group meeting, in Foster City, CA, last > month. > > The PAM API, as it currently sits, is incapable of correctly > supporting Kerberos, and several other authentication schemes. > > Apparently, the only way to fix this is to change the PAM API. Hey, I'm glad that has sunk in. We debated about this back in February (thread in this forum containing Message-ID <20010217190800.A38833@spawn.nectar.com>). Moreover, I think Mark already understands this, and in this thread when `authentication' appears, it should almost always be read as `interactive authentication' e.g. enter a secret or respond to a challenge or such. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 6:15:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id AFEFB37B422 for ; Wed, 30 May 2001 06:15:09 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA13460; Wed, 30 May 2001 23:14:53 +1000 Date: Wed, 30 May 2001 23:13:20 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dima Dorfman Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: {kbd,vid}control insanity patch In-Reply-To: <20010530050319.9506F3E28@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 29 May 2001, Dima Dorfman wrote: > Dag-Erling Smorgrav writes: > > Dima Dorfman writes: > > > Dag-Erling Smorgrav writes: > > > > Damn, yet another kbdcontrol bug. This - like every other vty- > > > > specific knob - should be in vidcontrol. > > > Are keymaps vty-specific? > > > > No, they're global. > > Okay, then that leaves -f, -F, -b, and -r in kbdcontrol. The patch > attached below moves those to vidcontrol as -F, -G, -B, and -R, > respectively. If this ends up getting committed I'll gladly nuke > allscreens_kbdflags. Not OK. The "vid" in vidcontrol means "video", not "vty". The keyboard functions were intentionally split off from the video functions when vidcontrol(1) and kbdcontrol(1) were spawned from syscons(1). Everything may belong in syscons(1) again, but the interfaces should not be gratuitously different from those in the utilities for other console drivers. pcvt already has enough gratuitous differences in its scon(1) and kcon(1) utilities. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 6:24:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D0BEB37B422 for ; Wed, 30 May 2001 06:24:54 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA14052; Wed, 30 May 2001 23:24:43 +1000 Date: Wed, 30 May 2001 23:23:09 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Polstra Cc: arch@FreeBSD.ORG, kris@obsecurity.org Subject: Re: PAM, S/Key and authentication schemes. In-Reply-To: <200105290244.f4T2iNP21562@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 May 2001, John Polstra wrote: > In article <20010528174728.A39588@xor.obsecurity.org>, > Kris Kennaway wrote: > > > > We also compile all of the PAM modules included in the base system > > into a static libpam which allows statically-linked binaries to work, > > up to a point (they won't work if the system administrator tries to > > use a third-party PAM module) > > We used to do this and probably still do. But I haven't tried it > lately. I build the entire world static (except for the broken perl part), so I try this (without third-party PAM modules) most days. Support for this in -unpatched-current is only broken in a few places now (including in a central place so it may be broken everywhere). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 6:29:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D283C37B424; Wed, 30 May 2001 06:29:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA14402; Wed, 30 May 2001 23:29:19 +1000 Date: Wed, 30 May 2001 23:27:46 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: arch@FreeBSD.ORG Cc: "David E. O'Brien" Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) In-Reply-To: <20010529040250.A81586@xor.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 29 May 2001, Kris Kennaway wrote: > Hmm. We now have a number of ways of achieving this (some of these > only work in some contexts): > > Defining CFLAGS with ?= instead of = in /etc/make.conf This is a no-op, because CFLAGS is always defined in /etc/make.conf. > COPTS in > CWARNFLAGS in (included from ) > DEBUG_FLAGS in > > The latter three obviously don't cover general code, but the plethora > of options is starting to get ugly. I agree. It got ugly already :-). And we don't even install the specs file in /usr/libdata/gcc. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 9:26:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id DA0EC37B422 for ; Wed, 30 May 2001 09:26:28 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 82963 invoked by uid 1000); 30 May 2001 16:25:20 -0000 Date: Wed, 30 May 2001 19:25:20 +0300 From: Peter Pentchev To: Bruce Evans Cc: arch@FreeBSD.ORG, "David E. O'Brien" Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) Message-ID: <20010530192520.H74837@ringworld.oblivion.bg> Mail-Followup-To: Bruce Evans , arch@FreeBSD.ORG, "David E. O'Brien" References: <20010529040250.A81586@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Wed, May 30, 2001 at 11:27:46PM +1000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 30, 2001 at 11:27:46PM +1000, Bruce Evans wrote: > On Tue, 29 May 2001, Kris Kennaway wrote: > > > Hmm. We now have a number of ways of achieving this (some of these > > only work in some contexts): > > > > Defining CFLAGS with ?= instead of = in /etc/make.conf > > This is a no-op, because CFLAGS is always defined in /etc/make.conf. This is not a no-op, if CFLAGS is already defined in the environment or on the make(1) command line. A CFLAGS=.. line in /etc/make.conf is a lot less user-friendly than a CFLAGS?=.. line. G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 9:39: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 53DA837B423; Wed, 30 May 2001 09:39:06 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4UGd6M20522; Wed, 30 May 2001 09:39:06 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 27321380E; Wed, 30 May 2001 09:39:06 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: arch@FreeBSD.ORG, "David E. O'Brien" Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) In-Reply-To: Date: Wed, 30 May 2001 09:39:06 -0700 From: Peter Wemm Message-Id: <20010530163906.27321380E@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Tue, 29 May 2001, Kris Kennaway wrote: [..] > > The latter three obviously don't cover general code, but the plethora > > of options is starting to get ugly. > > I agree. It got ugly already :-). And we don't even install the specs > file in /usr/libdata/gcc. Yes, because it just slows things down since gcc has to parse the file. Maybe we should install /usr/libdata/gcc/specs.default or something? I have found using the specs file *very* useful in the past when working on toolchain issues. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 12: 9:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A57F537B422; Wed, 30 May 2001 12:09:25 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA31612; Thu, 31 May 2001 05:09:18 +1000 Date: Thu, 31 May 2001 05:07:44 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Pentchev Cc: arch@FreeBSD.ORG, "David E. O'Brien" Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) In-Reply-To: <20010530192520.H74837@ringworld.oblivion.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 30 May 2001, Peter Pentchev wrote: > On Wed, May 30, 2001 at 11:27:46PM +1000, Bruce Evans wrote: > > On Tue, 29 May 2001, Kris Kennaway wrote: > > > > > Hmm. We now have a number of ways of achieving this (some of these > > > only work in some contexts): > > > > > > Defining CFLAGS with ?= instead of = in /etc/make.conf > > > > This is a no-op, because CFLAGS is always defined in /etc/make.conf. Oops, I meant that CFLAGS it is always defined in sys.mk. > This is not a no-op, if CFLAGS is already defined in the environment > or on the make(1) command line. A CFLAGS=.. line in /etc/make.conf > is a lot less user-friendly than a CFLAGS?=.. line. It's the "?=" setting that is a no-op. This unfortunately means that you have to use an "=" setting to be sure of canceling the default in sys.mk, although this is bad if the setting is actually in the environment. BTW, "make -e -V CFLAGS" doesn't work right. It reports the value that is assigned to CFLAGS by assignments in makefiles, but not the value of CFLAGS that will actually be used (if it is set differently in the environment). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 13:54:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 2739A37B423 for ; Wed, 30 May 2001 13:54:17 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f4UKsAl60897; Wed, 30 May 2001 13:54:11 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4UKs9603648; Wed, 30 May 2001 13:54:09 -0700 (PDT) (envelope-from obrien) Date: Wed, 30 May 2001 13:54:09 -0700 From: "David O'Brien" To: Peter Wemm Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) Message-ID: <20010530135408.A3587@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010530163906.27321380E@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010530163906.27321380E@overcee.netplex.com.au>; from peter@wemm.org on Wed, May 30, 2001 at 09:39:06AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 30, 2001 at 09:39:06AM -0700, Peter Wemm wrote: > > I agree. It got ugly already :-). And we don't even install the specs > > file in /usr/libdata/gcc. > > Yes, because it just slows things down since gcc has to parse the file. > Maybe we should install /usr/libdata/gcc/specs.default or something? I have > found using the specs file *very* useful in the past when working on > toolchain issues. I personally don't want to install any specs. I want to keep things deterministic. When Peter uses specs I can be assured that any bug reports or "something is wrong" emails were tested with the stock case, or clearly identified as not being stock. I cannot depend on this from all users. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 30 22:29:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 890F537B422; Wed, 30 May 2001 22:29:23 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 21EE03E0B; Wed, 30 May 2001 22:29:23 -0700 (PDT) To: Bruce Evans Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, sheldonh@freebsd.org Subject: Re: {kbd,vid}control insanity patch In-Reply-To: ; from bde@zeta.org.au on "Wed, 30 May 2001 23:13:20 +1000 (EST)" Date: Wed, 30 May 2001 22:29:22 -0700 From: Dima Dorfman Message-Id: <20010531052923.21EE03E0B@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans writes: > On Tue, 29 May 2001, Dima Dorfman wrote: > > > Dag-Erling Smorgrav writes: > > > Dima Dorfman writes: > > > > Dag-Erling Smorgrav writes: > > > > > Damn, yet another kbdcontrol bug. This - like every other vty- > > > > > specific knob - should be in vidcontrol. > > > > Are keymaps vty-specific? > > > > > > No, they're global. > > > > Okay, then that leaves -f, -F, -b, and -r in kbdcontrol. The patch > > attached below moves those to vidcontrol as -F, -G, -B, and -R, > > respectively. If this ends up getting committed I'll gladly nuke > > allscreens_kbdflags. > > Not OK. The "vid" in vidcontrol means "video", not "vty". The keyboard > functions were intentionally split off from the video functions when > vidcontrol(1) and kbdcontrol(1) were spawned from syscons(1). Everything > may belong in syscons(1) again, but the interfaces should not be > gratuitously different from those in the utilities for other console > drivers. pcvt already has enough gratuitous differences in its scon(1) > and kcon(1) utilities. I'm not quite sure what you're objecting to here; is it the option names (the fact that they'd have to be different) or that keyboard-related options are going into vid[eo]control? Perhaps both? Anyway, the option names are different simply because vidcontrol already has options with the orignal letters. I agree with your assertion that keyboard stuff shouldn't be in a program that's supposed to control video. However, DES is right that it is needlessly confusing to have two programs for vty-specific syscons stuff. So what do you (and Sheldon) suggest? Rename vidcontrol to control? Is the reason for splitting syscons(1) into kbdcontrol(1) and vidcontrol(1) still valid (what was the reason, anyway?)? Regards, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 31 3: 9:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from newsguy.com (perry.pathlink.com [209.155.233.33]) by hub.freebsd.org (Postfix) with ESMTP id D67DA37B50B; Thu, 31 May 2001 03:09:43 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp039-bsace7002.telebrasilia.net.br [200.181.81.39]) by newsguy.com (8.11.0/8.9.1) with ESMTP id f4VA8qq94576; Thu, 31 May 2001 03:08:53 -0700 (PDT) Message-ID: <3B161858.CDBA562C@newsguy.com> Date: Thu, 31 May 2001 07:09:28 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: Dima Dorfman Cc: Bruce Evans , Dag-Erling Smorgrav , arch@FreeBSD.ORG, sheldonh@FreeBSD.ORG Subject: Re: {kbd,vid}control insanity patch References: <20010531052923.21EE03E0B@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dima Dorfman wrote: > > Anyway, the option names are different simply because vidcontrol > already has options with the orignal letters. I agree with your > assertion that keyboard stuff shouldn't be in a program that's > supposed to control video. However, DES is right that it is > needlessly confusing to have two programs for vty-specific syscons > stuff. So what do you (and Sheldon) suggest? Rename vidcontrol to > control? Is the reason for splitting syscons(1) into > kbdcontrol(1) and vidcontrol(1) still valid (what was the reason, > anyway?)? I don't see any confusion here. Do I want to change some display property? vidcontrol. Do I want to change some keyboard property? kbdcontrol. To me it's absolutely irrelevant whether the property is per-vty or not. That's something to be documented on the man page and grumbled about elsewhere (like the fact that I wish I could use different keyboard maps on different vtys). Perhaps from a programmer's point of view, one familiar with syscon&cia, the vty-specificness of a function is of rather more importance, but kbdcontrol(1) and vidcontrol(1) are not programm interfaces. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 31 5:14: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3CD4737B424; Thu, 31 May 2001 05:13:57 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA05655; Thu, 31 May 2001 22:13:41 +1000 Date: Thu, 31 May 2001 22:12:07 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dima Dorfman Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG, sheldonh@FreeBSD.ORG Subject: Re: {kbd,vid}control insanity patch In-Reply-To: <20010531052923.21EE03E0B@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 30 May 2001, Dima Dorfman wrote: > Bruce Evans writes: > > Not OK. The "vid" in vidcontrol means "video", not "vty". The keyboard > > functions were intentionally split off from the video functions when > > vidcontrol(1) and kbdcontrol(1) were spawned from syscons(1). Everything > > may belong in syscons(1) again, but the interfaces should not be > > gratuitously different from those in the utilities for other console > > drivers. pcvt already has enough gratuitous differences in its scon(1) > > and kcon(1) utilities. > > I'm not quite sure what you're objecting to here; is it the option > names (the fact that they'd have to be different) or that > keyboard-related options are going into vid[eo]control? Perhaps both? > Anyway, the option names are different simply because vidcontrol > already has options with the orignal letters. I agree with your > assertion that keyboard stuff shouldn't be in a program that's > supposed to control video. I'm mostly objecting to this. (Only bell control doesn't really belong in kdbcontrol, but it doesn't really belong in vidcontrol either.) > However, DES is right that it is > needlessly confusing to have two programs for vty-specific syscons > stuff. It doesn't seem confusing to me. You use kbdcontrol for keyboard things vidcontrol for screen things. There are actually 4 programs -- there are also vidfont(1) and kbdmap(1). (BUG: the BUGS section of kbdmap.1 refers to wrong programs). pcvt has even more programs: scon(1), cursor(1) and loadfont(1) for the screen, kcon(1) and vt220keys(1) for the screen, and ispcvt(1) to check for console correctness. > So what do you (and Sheldon) suggest? Rename vidcontrol to > control? Is the reason for splitting syscons(1) into > kbdcontrol(1) and vidcontrol(1) still valid (what was the reason, > anyway?)? I'm happy with things where they are now (only history buffer control was very misplaced). I think the split had something to to with splitting the device drivers and or with plans to use the same interfaces for different console drivers where possible. From the FreeBSD-1 log messages: RCS file: /home/ncvs/src1/usr.sbin/vidcontrol/vidcontrol.c,v Working file: vidcontrol.c head: 1.4 ... ---------------------------- revision 1.1 date: 1994/05/20 12:20:38; author: sos; state: Exp; New vidcontrol utility replaces old syscons(1) Font files are now uuencoded, and so are the scrnmaps. Also allows changing colors and cursor type Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 1 10: 0:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id 8617A37B424 for ; Fri, 1 Jun 2001 10:00:34 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.21.Dial1.SanJose1.Level3.net [209.245.138.21]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA22728; Fri, 1 Jun 2001 13:00:01 -0400 (EDT) Message-ID: <3B17CA2C.D68B9583@mindspring.com> Date: Fri, 01 Jun 2001 10:00:28 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" Cc: Sheldon Hearn , Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: <89661.990794824@axl.fw.uunet.co.za> <3B14B109.C08F1970@mindspring.com> <20010530074757.A53937@spawn.nectar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Jacques A. Vidrine" wrote: > On Wed, May 30, 2001 at 01:36:25AM -0700, Terry Lambert wrote: > > We talked to the Sun guy who came up with PAM at the last > > FreeBSD user's group meeting, in Foster City, CA, last > > month. > > > > The PAM API, as it currently sits, is incapable of correctly > > supporting Kerberos, and several other authentication schemes. > > > > Apparently, the only way to fix this is to change the PAM API. > > Hey, I'm glad that has sunk in. We debated about this back in February > (thread in this forum containing Message-ID > <20010217190800.A38833@spawn.nectar.com>). Knowing about the problem, and actually revising the API to deal with it, are two very different things, unfortuantely. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 1 11:30: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4C83F37B424 for ; Fri, 1 Jun 2001 11:29:59 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f51ITw019215 for ; Fri, 1 Jun 2001 11:29:58 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f51ITve29452; Fri, 1 Jun 2001 11:29:57 -0700 (PDT) (envelope-from jdp) Date: Fri, 1 Jun 2001 11:29:57 -0700 (PDT) Message-Id: <200106011829.f51ITve29452@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Subject: Re: Overriding compiler flags (Re: cvs commit: src/contrib/gcc.295 gcc.c) In-Reply-To: <20010530135408.A3587@dragon.nuxi.com> References: <20010530163906.27321380E@overcee.netplex.com.au> <20010530135408.A3587@dragon.nuxi.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20010530135408.A3587@dragon.nuxi.com>, David O'Brien wrote: > On Wed, May 30, 2001 at 09:39:06AM -0700, Peter Wemm wrote: > > Maybe we should install /usr/libdata/gcc/specs.default or something? I have > > found using the specs file *very* useful in the past when working on > > toolchain issues. > > I personally don't want to install any specs. I want to keep things > deterministic. When Peter uses specs I can be assured that any bug > reports or "something is wrong" emails were tested with the stock case, > or clearly identified as not being stock. I cannot depend on this from > all users. I like Peter's idea. It would be handy to have a template specs file for those who know what they're doing. There are many ways users can make their systems "not stock". I can't see that putting an unused specs template in /usr/libdata/gcc is going to make that any worse. Users can still build strange specs files whether or not we install an unused template. Personally, I'd rather have them start from a known-good template if they're going to mess with the specs. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 1 14: 8:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 3582A37B423; Fri, 1 Jun 2001 14:08:36 -0700 (PDT) (envelope-from mike@q9media.com) Received: from [192.168.1.10] (vega.tct.net [216.94.230.13]) by coffee.q9media.com (8.11.2/8.11.2) with ESMTP id f51LHYL89393; Fri, 1 Jun 2001 17:17:35 -0400 (EDT) (envelope-from mike@q9media.com) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 01 Jun 2001 17:08:30 -0400 Subject: Removing __P() (was Re: whois(1) patch) From: Mike Barcroft To: Cc: Mike Heffner Message-ID: In-Reply-To: Mime-version: 1.0 Organization: q9 media Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Moved to -arch, BCC'd to -audit] On 5/31/01 6:26 PM, Mike Heffner at mheffner@novacoxmail.com wrote: > On 31-May-2001 Mike Barcroft wrote: > | > | I originally made the ANSI C change to silence a warning, but is there any > | reason not to bring the code up to ANSI C spec? Is it likely that anyone > | will need to compile whois with a K&R compiler? > > It's not likely, but I'm not sure on what the consensus is on ANSI-fication. > Technically, style(9) says it shouldn't be done in this case, but people > (myself included) have been removing K&R support in small patches like this > one. I think there was also talk of doing a full sweep to remove __P. Does anyone have any objections to removing __P() and converting prototypes to ANSI C, as part of binary cleaning up/auditing? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 1 14:13:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 671E637B422 for ; Fri, 1 Jun 2001 14:13:50 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f51LDYE05212; Fri, 1 Jun 2001 15:13:34 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200106012113.f51LDYE05212@harmony.village.org> To: Mike Barcroft Subject: Re: Removing __P() (was Re: whois(1) patch) Cc: freebsd-arch@FreeBSD.ORG, Mike Heffner In-reply-to: Your message of "Fri, 01 Jun 2001 17:08:30 EDT." References: Date: Fri, 01 Jun 2001 15:13:34 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message Mike Barcroft writes: : Does anyone have any objections to removing __P() and converting prototypes : to ANSI C, as part of binary cleaning up/auditing? So long as it is only on the binaries and not the header (/usr/include) files. Make sure that you convert int foo __P((xxx)) to int foo(xxx) (Note no space). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 6:24:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 33CFC37B423 for ; Sat, 2 Jun 2001 06:24:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA22054; Sat, 2 Jun 2001 23:24:36 +1000 Date: Sat, 2 Jun 2001 23:23:00 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mike Barcroft Cc: freebsd-arch@FreeBSD.ORG, Mike Heffner Subject: Re: Removing __P() (was Re: whois(1) patch) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Jun 2001, Mike Barcroft wrote: > Does anyone have any objections to removing __P() and converting prototypes > to ANSI C, as part of binary cleaning up/auditing? Yes. It subtracts value and gives more changes to audit. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 10:39:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 39EEA37B422; Sat, 2 Jun 2001 10:39:10 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52Hd9V03943; Sat, 2 Jun 2001 10:39:09 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 10:39:09 -0700 (PDT) From: Matt Dillon Message-Id: <200106021739.f52Hd9V03943@earth.backplane.com> To: "David O'Brien" Cc: David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: :> Yes, I know all that. The problem isn't that you couldn't have an :> unsigned time_t, the problem is that there are vast amounts of software :> already out there that would "break mysteriously" if you did. So, :> like the int<->long problem, the best thing to do is not rock the boat. :> That means for maximum portability time_t has to be a signed long. Not :> int, not unsigned int, not unsigned long... just 'long'. : :There is not enough context here for me to get any idea what the issue :is. This email argued signed vs. unsigned, and that has nothing to do :with time_t being an int. : :Since on IA-32 int == long, the only issue is what ones uses in printf() :and scanf(). I have not seen anyone having a problem with this yet. : :So I ask you to bring this up on freebsd-arch@freebsd.org why time_t :needs to be a long. If you had more multi-platform concerns you would :understand why having as consistent defintions of things is best for :FreeBSD. : :-- :-- David (obrien@FreeBSD.org) Consistency is best, but breaking IA32 to match the already broken Alpha port is the wrong solution. For consistency we should match what Solaris, Linux, and most other UNIX operating systems use, which is 'long'. Our Alpha port is improperly using an int for time_t where nearly every other 64 bit cpu port uses a (64 bit) long. The Alpha guys may decide that it's too late to fix our Alpha port (though personally I think they should just take their lumps and fix it now before it really is too late), but we should absolutely not break the IA32 port because of that. The IA32 port had it correct when it was 'long', allowing software to be written in a portable manner between platforms and OSs (except for our broken Alpha port) without any aches or pains. The commit log says something about catching people who are improperly assuming that time_t is a long. That makes no sense whatsoever since changing it to an int will simply result in not catching people who improperly assume time_t is an int. At least as a long programmers know that there is something special about time_t, even if they still use it improperly. As an int god only knows what kind of assumptions people are going to begin making. time_t is a core type. It has been long from time immemorial and you need a whole lot better explanation then 'improper assumptions of it being a long' to change it. I consider this change totally gratuitous and ungendering totally unnecessary confusion between our use of time_t and other operating system's (such as Linux and Solaris). It not only creates confusion, it also creates portability issues for software (at the very least results in a lot of unnecessary compiler warnings for third party software developed under non-FreeBSD OSs), and perpetuates an already flawed approach to our 64 bit model. It should be backed out. Back in the 16 bit days there was a similar argument about int vs long for things like off_t, and (not so much time_t but the argument was there on the 32 bit side).. and so forth. long won, and for damn good reason. The reasons are still good today. Certain core types like time_t have serious limitations when declared as a fixed width type (int nowadays). long is the perfect solution and you just blew that all to hell with this commit. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:33:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 51A1537B422; Sat, 2 Jun 2001 12:33:13 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f52JX6S127618; Sat, 2 Jun 2001 15:33:06 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200106021739.f52Hd9V03943@earth.backplane.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> Date: Sat, 2 Jun 2001 15:33:03 -0400 To: Matt Dillon , "David O'Brien" From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:39 AM -0700 6/2/01, Matt Dillon wrote: >: >:On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: >:> Yes, I know all that. The problem isn't that you couldn't >:> have an unsigned time_t, the problem is that there are vast >:> amounts of software already out there that would "break >:> mysteriously" if you did. So, like the int<->long problem, >:> the best thing to do is not rock the boat. That means for >:> maximum portability time_t has to be a signed long. Not >:> int, not unsigned int, not unsigned long... just 'long'. >: >:There is not enough context here for me to get any idea what the >:issue is. This email argued signed vs. unsigned, and that has >:nothing to do with time_t being an int. >: >:Since on IA-32 int == long, the only issue is what ones uses in >:printf() and scanf(). I have not seen anyone having a problem >:with this yet. >: >:So I ask you to bring this up on freebsd-arch@freebsd.org why >:time_t needs to be a long. If you had more multi-platform >:concerns you would understand why having as consistent >:definitions of things is best for FreeBSD. > > Consistency is best, but breaking IA32 to match the already > broken Alpha port is the wrong solution. For consistency > we should match what Solaris, Linux, and most other UNIX > operating systems use, which is 'long'. I can't help but think that sometime soon Garrett is going to kick me off the freebsd-standards list because how often I tend to refer questions on other lists to that list. Still, it seems to me that a topic like this must come up in discussions by the standards bodies. SingleUnixSpec seems to have nothing useful to say about time_t, but maybe the latest draft of Posix does. I don't have any strong feeling about what is "right" in this case, but I do think it would be appropriate to back out the change to time_t until the question *is* correctly sorted out. This change could effect a wide variety of programs in a way which will not be immediately obvious. If what we have is wrong, then we should make the change and fix whatever breaks, but I don't think we should start that process until we KNOW that what we have (and have had for quite some time) is wrong. So, I've included freebsd-standards on this, although I wouldn't blame anyone for being exasperated with me after seeing this topic bounce across multiple mailing lists... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:47:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id AC77737B422 for ; Sat, 2 Jun 2001 12:47:33 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52JlXl83584; Sat, 2 Jun 2001 12:47:33 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52JlWa82955; Sat, 2 Jun 2001 12:47:32 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 12:47:32 -0700 From: "David O'Brien" To: Matt Dillon Cc: David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <20010602124732.F31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106021739.f52Hd9V03943@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 10:39:09AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: > Consistency is best, but breaking IA32 to match the already broken > Alpha port is the wrong solution. For consistency we should match Why is the Alpha port broken? time_t is 32-bits without question. Thus it must be an `int' on Alpha, IA-64, and sparc64. > what Solaris, Linux, and most other UNIX operating systems use, which > is 'long'. Our Alpha port is improperly using an int for time_t where > nearly every other 64 bit cpu port uses a (64 bit) long. I 100% disagree -- we should be consistent with FreeBSD and that matters more than other non-FreeBSD OS's. To get the same wrap around characteristics on our 64-bit platforms as our 32-bit ones, time_t must be an `int' on 64-bit platforms. BTW, NetBSD Alpha and sparc64 (ie, all their 64-bit platforms) have _BSD_TIME_T_ as `int'. HP-UX 11 defines it as `int32_t' so it is consistent across their 32-bit and 64-bit machines. > but we should absolutely not break the IA32 port because of that. > The IA32 port had it correct when it was 'long', allowing software > to be written in a portable manner between platforms and OSs > (except for our broken Alpha port) without any aches or pains. Why do you consider time_t == `int' on i386 broken? Just because of the printf() format string? > Certain core types like time_t > have serious limitations when declared as a fixed width type (int > nowadays). long is the perfect solution and you just blew that all to > hell with this commit. I am more than willing to define time_t as `long long' so it is 64-bits across the board. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:49:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id D0CE037B422 for ; Sat, 2 Jun 2001 12:49:09 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52Jn7l83595; Sat, 2 Jun 2001 12:49:08 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52Jn7Z82970; Sat, 2 Jun 2001 12:49:07 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 12:49:07 -0700 From: "David O'Brien" To: Garance A Drosihn Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602124907.G31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Sat, Jun 02, 2001 at 03:33:03PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 03:33:03PM -0400, Garance A Drosihn wrote: > > I don't have any strong feeling about what is "right" in this > case, but I do think it would be appropriate to back out the > change to time_t until the question *is* correctly sorted out. I don't see why? We can't even agree there is a problem. And if dangous kernel commits can stay in, so can this one. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:51:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 261A037B423; Sat, 2 Jun 2001 12:51:54 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f52Jpe139983; Sat, 2 Jun 2001 21:51:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: obrien@FreeBSD.ORG Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: Your message of "Sat, 02 Jun 2001 12:47:32 PDT." <20010602124732.F31257@dragon.nuxi.com> Date: Sat, 02 Jun 2001 21:51:39 +0200 Message-ID: <39981.991511499@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010602124732.F31257@dragon.nuxi.com>, "David O'Brien" writes: >On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: >> Consistency is best, but breaking IA32 to match the already broken >> Alpha port is the wrong solution. For consistency we should match > >Why is the Alpha port broken? time_t is 32-bits without question. Thus >it must be an `int' on Alpha, IA-64, and sparc64. Uhm, time_t must be signed and at least 32 bits. It would be neat if all platforms had it longer than 32 bits in the next decade some time. >> Certain core types like time_t >> have serious limitations when declared as a fixed width type (int >> nowadays). long is the perfect solution and you just blew that all to >> hell with this commit. > >I am more than willing to define time_t as `long long' so it is 64-bits >across the board. We'll have to do this before 2038 anyway... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:54:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id CF68037B422; Sat, 2 Jun 2001 12:54:18 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f52JsIS93650; Sat, 2 Jun 2001 15:54:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010602124907.G31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> Date: Sat, 2 Jun 2001 15:54:16 -0400 To: obrien@FreeBSD.ORG From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:49 PM -0700 6/2/01, David O'Brien wrote: >On Sat, Jun 02, 2001, Garance A Drosihn wrote: > > >> I don't have any strong feeling about what is "right" in this >> case, but I do think it would be appropriate to back out the >> change to time_t until the question *is* correctly sorted out. > >I don't see why? We can't even agree there is a problem. And >if dangerous kernel commits can stay in, so can this one. In my opinion, this is different from more-dangerous kernel commits because the kernel-commits only affect the kernel in freebsd-current. This affects the include files used by everything on the system, which means it will affect ports on -current, which means it may effect those same ports on freebsd-stable. Obviously nobody has put me in charge of such decisions. That is just my opinion of why it's different. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:56:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 4992437B422; Sat, 2 Jun 2001 12:56:13 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f52JuCS15604; Sat, 2 Jun 2001 15:56:12 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010602124907.G31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> Date: Sat, 2 Jun 2001 15:56:10 -0400 To: obrien@FreeBSD.ORG From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:49 PM -0700 6/2/01, David O'Brien wrote: >On Sat, Jun 02, 2001, Garance A Drosihn wrote: > > I don't have any strong feeling about what is "right" in this > > case, but I do think it would be appropriate to back out the >> change to time_t until the question *is* correctly sorted out. > >I don't see why? We can't even agree there is a problem. And if >dangerous kernel commits can stay in, so can this one. ...also, in situations where "we can't agree there is a problem", I thought we were supposed to favor the status quo (ie, pre-update) over rushing in to fix something which we can not agree is broken. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 12:59: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 36C6337B422 for ; Sat, 2 Jun 2001 12:58:59 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52Jwvl83644; Sat, 2 Jun 2001 12:58:57 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52Jwui83219; Sat, 2 Jun 2001 12:58:56 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 12:58:56 -0700 From: "David O'Brien" To: Garance A Drosihn Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602125856.L31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Sat, Jun 02, 2001 at 03:56:10PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 03:56:10PM -0400, Garance A Drosihn wrote: > At 12:49 PM -0700 6/2/01, David O'Brien wrote: > >On Sat, Jun 02, 2001, Garance A Drosihn wrote: > > > I don't have any strong feeling about what is "right" in this > > > case, but I do think it would be appropriate to back out the > >> change to time_t until the question *is* correctly sorted out. > > > >I don't see why? We can't even agree there is a problem. And if > >dangerous kernel commits can stay in, so can this one. > > ...also, in situations where "we can't agree there is a problem", > I thought we were supposed to favor the status quo (ie, pre-update) > over rushing in to fix something which we can not agree is broken. We've just *started* the disucussion. If we can decide on it in 48-hours why toss the repo back and forth. Also show me the errors in other programs from this. We need to fix them anyway as Alpha and i386 will have same sized time_t. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13: 5:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1E83037B422; Sat, 2 Jun 2001 13:05:16 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52K5FR04823; Sat, 2 Jun 2001 13:05:15 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 13:05:15 -0700 (PDT) From: Matt Dillon Message-Id: <200106022005.f52K5FR04823@earth.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Sat, Jun 02, 2001 at 03:33:03PM -0400, Garance A Drosihn wrote: :> :> I don't have any strong feeling about what is "right" in this :> case, but I do think it would be appropriate to back out the :> change to time_t until the question *is* correctly sorted out. : :I don't see why? We can't even agree there is a problem. And if dangous :kernel commits can stay in, so can this one. : :-- :-- David (obrien@FreeBSD.org) It is really the person making the commit (you) that has the burden of justification here, not those of us who object to it. Explain why you believe changing the long to int can be justified in light of the fact that Solaris and Linux use long (and all the other reasons I iterated!). Your reasoning so far is extremely weak and not very forward looking. It is certainly not sufficient to make such a basic change to a core type stick I think! It also seems to me that nobody has really considered what is going to happen 15 years down the line when the importance of being able to write 203x-safe software becomes paramount. I am concerned about it *right* *now*, so much so that all the software I write (e.g. Backplane Inc's billing system software) stores time stamps in text form. The linux/Solaris/everyone-else crowd uses 'long' precisely because they assume (rightly) that by the time it matters cpu's will be 64 bit native. When that time comes (oh wait, it's already here!) the standard time functions (e.g. time(), gmtime(), localtime()) will already be using 64 bit time_t's on 64 bit cpu and there will be no need at all for creating a new API. What about us? Are we going to introduce time64_t functions for 64 bit platforms with different function names and force people to use them? Where will our portability to other platforms be then? Nobody but us will have to use the new API because everyone else will still be using localtime() and friends. Remember linux's lseek64()? Remember SGI's? Remember what happened to them? We don't want to be in that boat. As much as I would love to change IA32 to use long long, it would be a disaster to make that sort of change. While long<->int on IA32 does not involve a change in type size, long<->longlong does. But because 'long' is the defacto standard for time_t, and because it translates extremely well to 64 bit platforms, we should keep things consistent and keep using 'long' even on IA32. I can see an intermediate fix for IA32 64 bit time_t's and that would be to have a -DTIME64_T compiler flag and then have the time header files do the right thing (including #define renaming standard time functions to the 64 bit versions of same). That way people who wanted 64 bit time functions on IA32 could get them. But for any 64 bit platform, a 64 bit time_t should be standard. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13: 7:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A905937B423; Sat, 2 Jun 2001 13:07:06 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52K76S04853; Sat, 2 Jun 2001 13:07:06 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 13:07:06 -0700 (PDT) From: Matt Dillon Message-Id: <200106022007.f52K76S04853@earth.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Sat, Jun 02, 2001 at 03:33:03PM -0400, Garance A Drosihn wrote: :> :> I don't have any strong feeling about what is "right" in this :> case, but I do think it would be appropriate to back out the :> change to time_t until the question *is* correctly sorted out. : :I don't see why? We can't even agree there is a problem. And if dangous :kernel commits can stay in, so can this one. : :-- :-- David (obrien@FreeBSD.org) This is no justification for your commit, Dave. By that reasoning you could justify everything under the sun simply by saying that someone, somewhere else, at some time in the past, did something that was more dangerous. Give me a break. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13:14: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 0348A37B424 for ; Sat, 2 Jun 2001 13:14:07 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52KE5l83720; Sat, 2 Jun 2001 13:14:05 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52KE4Z83545; Sat, 2 Jun 2001 13:14:04 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 13:14:04 -0700 From: "David O'Brien" To: Matt Dillon Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602131404.M31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106022005.f52K5FR04823@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 01:05:15PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 01:05:15PM -0700, Matt Dillon wrote: > It is really the person making the commit (you) that has the burden > of justification here, not those of us who object to it. 1. I feel I have. You keep saying "breakage" but aren't telling me what specifically it is. You have not argued a single *functional* point here -- only the spelling of the 32-bit type used. 2. We really don't operate that way around here any more. Sad to say, but true. For some reason the burdon is now on the receiver. > Explain why you > believe changing the long to int can be justified in light of the fact > that Solaris and Linux use long (and all the other reasons I iterated!). NetBSD, OpenBSD, and HP-UX uses 32bit types for time_t. > Your reasoning so far is extremely weak and not very forward looking. Forward looking is to make time_t 'long long'. We can do that if you like. > It is certainly not sufficient to make such a basic change to a core > type stick I think! I do have backing from another committer for this. In fact one that we look to for guidance on these things. > It also seems to me that nobody has really considered what is going to > happen 15 years down the line when the importance of being able to > write 203x-safe software becomes paramount. Well, if you are concerned about 15 years from you, you would be pushing for a 'long long' time_t, not a `long' one. > The linux/Solaris/everyone-else crowd uses 'long' precisely because > they assume (rightly) that by the time it matters cpu's will be 64 bit > native. Uh.. I've got $100 that says embedded CPUs will still be 32-bit, not 64. FreeBSD does have a goal of running on some embedded CPUs -- PPC and StrongARM. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13:27: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by hub.freebsd.org (Postfix) with ESMTP id DB9D737B422 for ; Sat, 2 Jun 2001 13:26:58 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maila.telia.com (8.11.2/8.11.0) with ESMTP id f52KQvk28607 for ; Sat, 2 Jun 2001 22:26:57 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id WAA04561 for ; Sat, 2 Jun 2001 22:26:52 +0200 (CEST) Received: (qmail 26684 invoked by uid 1001); 2 Jun 2001 20:26:27 -0000 Date: Sat, 2 Jun 2001 22:26:27 +0200 From: Erik Trulsson To: arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <20010602222626.A26556@student.uu.se> Mail-Followup-To: arch@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124732.F31257@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010602124732.F31257@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Jun 02, 2001 at 12:47:32PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 12:47:32PM -0700, David O'Brien wrote: > On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: > > Consistency is best, but breaking IA32 to match the already broken > > Alpha port is the wrong solution. For consistency we should match > > Why is the Alpha port broken? time_t is 32-bits without question. Thus > it must be an `int' on Alpha, IA-64, and sparc64. > > > > what Solaris, Linux, and most other UNIX operating systems use, which > > is 'long'. Our Alpha port is improperly using an int for time_t where > > nearly every other 64 bit cpu port uses a (64 bit) long. > > I 100% disagree -- we should be consistent with FreeBSD and that matters > more than other non-FreeBSD OS's. To get the same wrap around > characteristics on our 64-bit platforms as our 32-bit ones, time_t must > be an `int' on 64-bit platforms. > > BTW, NetBSD Alpha and sparc64 (ie, all their 64-bit platforms) have > _BSD_TIME_T_ as `int'. HP-UX 11 defines it as `int32_t' so it is > consistent across their 32-bit and 64-bit machines. > > > > but we should absolutely not break the IA32 port because of that. > > The IA32 port had it correct when it was 'long', allowing software > > to be written in a portable manner between platforms and OSs > > (except for our broken Alpha port) without any aches or pains. > > Why do you consider time_t == `int' on i386 broken? Just because of the > printf() format string? > > > Certain core types like time_t > > have serious limitations when declared as a fixed width type (int > > nowadays). long is the perfect solution and you just blew that all to > > hell with this commit. > > I am more than willing to define time_t as `long long' so it is 64-bits > across the board. > I did a bit of searching in the archives and it seems that this very question was discussed on the freebsd-alpha list in late Dec./early Jan 1998/1999. As expected there doesn't seem to have been any consensus on what the "right" thing is. (Since there obviously are valid arguments on both sides.) One thing that was mentioned in that discussion though was that FFS uses time_t in some of the on-disk structures. This means that one should probably be careful when changing the size of time_t to stay compatible with existing filesystems. My take on the situation is as follows: While it will be necessary to make time_t a 64-bit type eventually to avoid wrap-around in 2038 I am afraid that this will break many programs and will require quite a bit of work to fix all problems. (Yes, it is the Y2K problem all over but with another breakage-date.) So until everybody is prepared to make that change it is probably a good idea to continue having time_t as a 32-bit type. This means that time_t must be defined as 'int' on Alpha. On i386 it can be either 'int' or 'long'. It is probably a good idea to have a consistent definition on all the platforms that FreeBSD runs on. This means that time_t == 'int' is probably the right thing for now. When using a time_t in printf(3) or similar situations the 'correct' thing is to cast the time_t value to a long and treat it is a long. I.e. time_t t; ... printf("%ld",(long)t); Then the code will work regardless of whether time_t is defined as an int or as a long. (And regardless of wether sizeof(int) == sizeof(long) or not.) (If time_t is defined as a long long then the above code won't work unless sizeof(long) == sizeof(long long). Code like the above that assumes that a time_t can fit in a long probably exists in *many* programs. Changing time_t to a 'long long' might therefore break quite a lot of things.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13:40:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 4EDFD37B423; Sat, 2 Jun 2001 13:40:28 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52KeSJ05088; Sat, 2 Jun 2001 13:40:28 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 13:40:28 -0700 (PDT) From: Matt Dillon Message-Id: <200106022040.f52KeSJ05088@earth.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :On Sat, Jun 02, 2001 at 01:05:15PM -0700, Matt Dillon wrote: :> It is really the person making the commit (you) that has the burden :> of justification here, not those of us who object to it. : :1. I feel I have. You keep saying "breakage" but aren't telling me what : specifically it is. You have not argued a single *functional* point : here -- only the spelling of the 32-bit type used. You have not justifed to any reasonable degree why you believe changing time_t from a long to an int should be done. You have not argued a single *functional* point for making that change beyond your commit message, which makes no sense because the problem you site is even *WORSE* if time_t is an int. I have repeateed the salient points of my argument several times now. If you didn't read them, then I recommend you go back to my postings and read them again. I will summarize: * Changing from long to int only makes the problems you site as fixing in your commit message worse. Not better. * The defacto standard for two decades+ is 'long'. You need a damn good reason to change it now and so far you haven't presented one. The onus of proof here is not on me, Brian, it is on you. Explain why you believe this change, which effects thousands of programs and goes against the grain of two decades of progress is important enough to make on IA32. * The two other platforms we have to maintain compatibility with the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not an issue for us. In fact, NetBSD seems to be well on their way to having an alternate API judging by the kernel changes they've made. We do not want to follow that path. * We have the ability to stay consistent between 32 and 64 bit platforms by defining time_t as 'long' on both, reducing portability headaches. This is what Solaris is doing. This is what Linux is doing. This maintains a defacto standard that has been around forever. We damn well ought to be doing it to. * Our IA32 implementation is not broken. Breaking it to match the already broken Alpha distribution is inappropriate. If you are going to break anything you should break (fix) the Alpha distribution to use long (64 bits). :> Explain why you :> believe changing the long to int can be justified in light of the fact :> that Solaris and Linux use long (and all the other reasons I iterated!). : :NetBSD, OpenBSD, and HP-UX uses 32bit types for time_t. : : :> Your reasoning so far is extremely weak and not very forward looking. : :Forward looking is to make time_t 'long long'. We can do that if you :like. Huh? I'm not sure where you got this rot from. I would certainly never advocate changing the size of the existing time_t on IA32. That would be virtually guarenteed to create all sorts of breakage. Nor would I advocate a new API. I would advocate a compiler flag or #define constant that turns the existing API and time_t into a 64 bit API so only programs that have been specifically ported to the new standard on IA32 will use the new standard. :> It is certainly not sufficient to make such a basic change to a core :> type stick I think! : :I do have backing from another committer for this. In fact one that we :look to for guidance on these things. Yes, I saw that. This is a case where Bruce is wrong. And so are you. :> It also seems to me that nobody has really considered what is going to :> happen 15 years down the line when the importance of being able to :> write 203x-safe software becomes paramount. : :Well, if you are concerned about 15 years from you, you would be pushing :for a 'long long' time_t, not a `long' one. : :> The linux/Solaris/everyone-else crowd uses 'long' precisely because :> they assume (rightly) that by the time it matters cpu's will be 64 bit :> native. : :Uh.. I've got $100 that says embedded CPUs will still be 32-bit, not 64. :FreeBSD does have a goal of running on some embedded CPUs -- PPC and :StrongARM. : :-- :-- David (obrien@FreeBSD.org) Embedded CPUs have other issues that generally require serious finesse in regards to program porting. You can hardly use an embedded cpu as a justification for your change. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13:43:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5B93B37B424 for ; Sat, 2 Jun 2001 13:43:18 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f52KhF028540; Sat, 2 Jun 2001 13:43:15 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f52KhFh35078; Sat, 2 Jun 2001 13:43:15 -0700 (PDT) (envelope-from jdp) Date: Sat, 2 Jun 2001 13:43:15 -0700 (PDT) Message-Id: <200106022043.f52KhFh35078@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Cc: drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article , Garance A Drosihn wrote: > Still, it seems to me that a topic like this must come up in > discussions by the standards bodies. SingleUnixSpec seems to have > nothing useful to say about time_t, but maybe the latest draft of > Posix does. Actually the type of time_t was addressed by the original version of the ANSI/ISO C standard. The only requirement is that it be an "arithmetic type capable of representing times." That means it could be a signed or unsigned integer type or a floating point type, but not a pointer, struct, union, or function (duh). I'd prefer to keep it as "long" at least on the i386, because that's what the type was for years before ANSI renamed it to "time_t". John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 13:49: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7FEBE37B423 for ; Sat, 2 Jun 2001 13:49:05 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f52Kn1028572; Sat, 2 Jun 2001 13:49:01 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f52Kn1W35106; Sat, 2 Jun 2001 13:49:01 -0700 (PDT) (envelope-from jdp) Date: Sat, 2 Jun 2001 13:49:01 -0700 (PDT) Message-Id: <200106022049.f52Kn1W35106@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Cc: ertr1013@student.uu.se Subject: Re: time_t definition is worng In-Reply-To: <20010602222626.A26556@student.uu.se> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124732.F31257@dragon.nuxi.com> <20010602222626.A26556@student.uu.se> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20010602222626.A26556@student.uu.se>, Erik Trulsson wrote: > > I did a bit of searching in the archives and it seems that this very > question was discussed on the freebsd-alpha list in late Dec./early Jan > 1998/1999. As expected there doesn't seem to have been any consensus > on what the "right" thing is. (Since there obviously are valid > arguments on both sides.) > > One thing that was mentioned in that discussion though was that FFS > uses time_t in some of the on-disk structures. This means that one > should probably be careful when changing the size of time_t to stay > compatible with existing filesystems. Hmm, that's an excellent point. Thank you for researching the previous discussions. Since only the kernel mess with the filesystem bits directly, the fact that a 32-bit time_t is used in FFS needn't be a show-stopper for moving to a 64-bit type in userland. (A few utilities such as newfs, fsck, and tunefs might need to be tweaked too.) Though if we didn't eventually increase time_t's size in FFS too, it wouldn't do us much good to widen it anywhere else. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 14:20:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 6796C37B423 for ; Sat, 2 Jun 2001 14:20:18 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52LKBl83998; Sat, 2 Jun 2001 14:20:11 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52LKB084083; Sat, 2 Jun 2001 14:20:11 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 14:20:11 -0700 From: "David O'Brien" To: Matt Dillon Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602142011.N31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106022040.f52KeSJ05088@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 01:40:28PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 01:40:28PM -0700, Matt Dillon wrote: > You have not justifed to any reasonable degree why you believe changing > time_t from a long to an int should be done. You have not argued a time_t needs to be consistent across all FreeBSD platforms. Otherwise we get in consistent behavior across our platforms. This includes both the size of it, and the spelling of the printf() format specifier. > single *functional* point for making that change beyond your commit > message, which makes no sense because the problem you site is even > *WORSE* if time_t is an int. > > I have repeateed the salient points of my argument several times now. > If you didn't read them, then I recommend you go back to my postings and > read them again. I will summarize: > > * Changing from long to int only makes the problems you site as > fixing in your commit message worse. Not better. How is it worse?!?!? You have yet to show me a compiler warning caused by this (I am sure there are some to fix); nor a piece of code that is now broken. > * The defacto standard for two decades+ is 'long'. You need a damn > good reason to change it now and so far you haven't presented one. I think I have. I would like to hear from others over the weekend what they think. > The onus of proof here is not on me, Brian, it is on you. Explain The name is O'Brien dammit. David also works. Brian and Dave do not. > * The two other platforms we have to maintain compatibility with > the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not > an issue for us. I *totally* disagree with your choice of who we need to maintain compatibility with the most. In fact several commits are made to make us more like NetBSD and OpenBSD. So freebsd-arch will need to decide who we should most be like. > In fact, NetBSD seems to be well on their way > to having an alternate API judging by the kernel changes they've > made. We do not want to follow that path. If they have, why don't we? > * We have the ability to stay consistent between 32 and 64 bit > platforms by defining time_t as 'long' on both, reducing portability > headaches. How is it consistent? It is consistent *only* in spelling, not storage size nor bit-wrapping characteristics. > This is what Solaris is doing. This is what Linux is > doing. This maintains a defacto standard that has been around > forever. We damn well ought to be doing it to. Should also also follow every other mistake Sun and Linux have made because they are the "defacto" standard? I see enough "defacto" standard things in the Linuxism I have to deal with daily. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 14:23:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C63C037B42C; Sat, 2 Jun 2001 14:23:25 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA17186; Sat, 2 Jun 2001 17:23:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f52LMtR64944; Sat, 2 Jun 2001 17:22:55 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15129.22831.64860.325847@grasshopper.cs.duke.edu> Date: Sat, 2 Jun 2001 17:22:55 -0400 (EDT) To: obrien@FreeBSD.ORG Cc: arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong In-Reply-To: <20010602131404.M31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien writes: > > NetBSD, OpenBSD, and HP-UX uses 32bit types for time_t. You can add Tru64 (aka OSF/1), where a time_t is an int. As far as I'm concerned, Tru64 is the gold standard for 64-bit platforms. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 14:30:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B6FC37B423 for ; Sat, 2 Jun 2001 14:30:34 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA17216; Sat, 2 Jun 2001 17:30:33 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f52LU3F64962; Sat, 2 Jun 2001 17:30:03 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15129.23259.647389.909649@grasshopper.cs.duke.edu> Date: Sat, 2 Jun 2001 17:30:03 -0400 (EDT) To: Matt Dillon Cc: arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong In-Reply-To: <200106022040.f52KeSJ05088@earth.backplane.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matt Dillon writes: > * The two other platforms we have to maintain compatibility with > the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not > an issue for us. In fact, NetBSD seems to be well on their way You forgot osf/1 (compat code in sys/alpha/osf1). Where, indeed, a time_t is an int. > * Our IA32 implementation is not broken. Breaking it to match the > already broken Alpha distribution is inappropriate. If you are > going to break anything you should break (fix) the Alpha > distribution to use long (64 bits). I couldn't care less what you people do on 32-bit platforms where you're just talking about a name change. But please keep your hands off alpha. Its been broken far too frequently. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 16:21:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 921B137B424; Sat, 2 Jun 2001 16:21:37 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52NLbu05712; Sat, 2 Jun 2001 16:21:37 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 16:21:37 -0700 (PDT) From: Matt Dillon Message-Id: <200106022321.f52NLbu05712@earth.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Sat, Jun 02, 2001 at 01:40:28PM -0700, Matt Dillon wrote: :> You have not justifed to any reasonable degree why you believe changing :> time_t from a long to an int should be done. You have not argued a : : :time_t needs to be consistent across all FreeBSD platforms. :Otherwise we get in consistent behavior across our platforms. :This includes both the size of it, and the spelling of the printf() :format specifier. I had to go through this rigamorale getting Diablo to work on 32 and 64 bit platforms. long is the only way to get consistent behavior across platforms and across operating systems. By making the native type for time_t be 'long' we virtually guarentee that porting problems between FreeBSD and other OS's and platforms will be minimized. But making it an 'int' virtually guarentees the reverse... now people who write code under FreeBSD may mistakenly assume that time_t can be treated as an int when, in fact, it can't, and the result will be mysterious failures and porting headaches when those people try to compile their programs on other platforms. Porting issues exist no matter how time_t is typedef'd, but they are a whole lot worse with int verses long. Your assumption that turning time_t into an int somehow makes it more consistent and better all around is severely flawed. And, for your information, NetBSD typedef's time_t as a long on IA32, not an int. It's still 32 bits on IA32 of course. But it's a long. So your changing FreeBSD's time_t to an int goes against other FreeBSD distribution's grains as well as against Linux and Solaris. NetBSD unfortunately decided to go with 32 bit time_t's on alpha and sparc64, but I don't think it is appropriate for us to follow in their footsteps there. All they are doing is creating a huge mess for themselves down the line, a mess that we can avoid if we look forward now. :.. :> If you didn't read them, then I recommend you go back to my postings and :> read them again. I will summarize: :> :> * Changing from long to int only makes the problems you site as :> fixing in your commit message worse. Not better. : :How is it worse?!?!? :You have yet to show me a compiler warning caused by this (I am sure :there are some to fix); nor a piece of code that is now broken. Think, damn it! You site people using printf("%ld", time_t) has being an improper use of time_t and that is your excuse for turning it into an int. With it int, now people can do printf("%d", time_t) without generating a warning, which is at least as flawed as using %ld and far more likely to occur considering how much more predominately 'int' is declared in source code verses 'long'. At least with it a long people know it has to be treated specially. GCC makes a (small) distinction between int and long on 32 bit platforms precisely to generate warnings that help people with porting issues. They had to back down a bit on the warnings, but there are a few still in the compiler (like format string warnings). :> * The two other platforms we have to maintain compatibility with :> the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not :> an issue for us. : :I *totally* disagree with your choice of who we need to maintain :compatibility with the most. In fact several commits are made to make us :more like NetBSD and OpenBSD. So freebsd-arch will need to decide who we :should most be like. In 15 years we are *completely* *fucked* if we go with 32 bit time_t's on 64 bit platforms. Completely and utterly fucked. We should fix this now while we still have the chance. I do not buy any effort to try to keep time_t the same physical size between platform ports. It is a totally inappropriate argument that will only get us into major trouble down the road on 64 bit platforms. We have enough problems already figuring out how to give 32 bit platforms 64 bit time functions without breaking upgrade compatibility for major subsystems like databases. We do not need to invite the same problems on our 64 bit platform portrs. So the argument that time_t should be made a 32 bit quantity on IA32 so it can be an 'int' on 64 bit FreeBSD ports is completely bogus. If you guys want to leave the Alpha port in a screwed up 32 bit time_t state, I can't do much about it. But I do not want it to bleed over into a decision to break IA32's use of long to try to maintain compatibility with the already broken Alpha port. :> In fact, NetBSD seems to be well on their way :> to having an alternate API judging by the kernel changes they've :> made. We do not want to follow that path. : :If they have, why don't we? off64_t ? lseek64? Do you want FreeBSD to go down the same path that SGI went down? It's been proven to be a huge fraggin mess and we absolutely do not want to follow in their footsteps. We were lucky with off_t being 64 bits... look what happened there? Do you see FreeBSD programmers using weird-looking lseek64() function calls? No. Do you honestly believe that FreeBSD coders will start using FreeBSD-only 64 bit time functions en-mass? It isn't going to happen. People will move away from our platform first and start calling it obsolete or weird. That's what happened to IRIX to a degree. :> * We have the ability to stay consistent between 32 and 64 bit :> platforms by defining time_t as 'long' on both, reducing portability :> headaches. : :How is it consistent? It is consistent *only* in spelling, not storage :size nor bit-wrapping characteristics. It is consistent in source code. 'long' may mean different things on different platforms, but when writing portable source you expect it to be 32 or 64 bits and the code can be written properly to be portable without all sorts of nasty #ifdef's. That is why 'long' is more consistent across platforms for time_t purposes. People have come to use long time_t's on 64 bit platforms to solve the 203x problem because it's a whole lot easier and more portable then changing the API. : :> This is what Solaris is doing. This is what Linux is :> doing. This maintains a defacto standard that has been around :> forever. We damn well ought to be doing it to. : :Should also also follow every other mistake Sun and Linux have made :because they are the "defacto" standard? I see enough "defacto" standard :things in the Linuxism I have to deal with daily. : :-- :-- David (obrien@FreeBSD.org) This is one case where Sun and Linux are doing exactly the right thing. Linux learned their lessons with off_t and didn't repeat them for time_t. Solaris also learned its lessons with off_t, though many years earlier. I'll bet they wish now that they had gone to 64 bit off_t's in the CSRG 4.4 timeframe rather then the mess they wound up with! This commit you've made uses reasoning that has proven to be a mistake many times over in past years on other platforms. It needs to be backed out. And I would also strongly recommend to the Alpha people that they fix their time_t to properly use a long now. Be that as it may, my concern right now is primarily that the commit made to i386 should be backed out. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 17:44:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 68C6037B422 for ; Sat, 2 Jun 2001 17:44:28 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA58011; Sat, 2 Jun 2001 20:44:24 -0400 (EDT) (envelope-from wollman) Date: Sat, 2 Jun 2001 20:44:24 -0400 (EDT) From: Garrett Wollman Message-Id: <200106030044.UAA58011@khavrinen.lcs.mit.edu> To: jdp@polstra.com Subject: Re: time_t definition is worng X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <200106022049.f52Kn1W35106@vashon.polstra.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124732.F31257@dragon.nuxi.com> <20010602222626.A26556@student.uu.se> Organization: MIT Laboratory for Computer Science Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200106022049.f52Kn1W35106@vashon.polstra.com> you write: >Since only the kernel mess with the filesystem bits directly, the fact >that a 32-bit time_t is used in FFS needn't be a show-stopper for >moving to a 64-bit type in userland. According to Kirk, the space in FFS that is now used by microsecond timestamps was originally originally put there to prepare for 64-bit time_t. If we made such a change now, we would be stuck translating inode formats back and forth for the forseeable future. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 21:24:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 33C3237B423; Sat, 2 Jun 2001 21:24:18 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f534OHS43926; Sun, 3 Jun 2001 00:24:17 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010602125856.L31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <20010602125856.L31257@dragon.nuxi.com> Date: Sun, 3 Jun 2001 00:24:13 -0400 To: obrien@FreeBSD.org From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.org, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:58 PM -0700 6/2/01, David O'Brien wrote: >On Sat, Jun 02, 2001, Garance A Drosihn wrote: > > ...also, in situations where "we can't agree there is a problem", >> I thought we were supposed to favor the status quo (ie, pre-update) >> over rushing in to fix something which we can not agree is broken. > >We've just *started* the disucussion. If we can decide on it in >48-hours why toss the repo back and forth. I didn't mean to trigger an impassioned debate over this on the freebsd standards list. It was just that I suspect that any "standards checking" will take a little time. Time enough to read up on various positions, or send a few messages to other members of Posix to try to get a good, consistent answer to this issue. As such, I assumed it would take more than 48 hours, particularly since the issue has popped up on a weekend. This is why it seemed best to back out the update. Right or wrong, time_t has been the way it is for a long time, and there is no burning need to have it changed right this minute (even if it is the right change). The other side of the debate should also note that I (personally) really do not have a clue which definition is the best. All I'm saying is that I would think we might be better off waiting a little longer before deciding which change (if any) is the best change. We are talking about a change to a Standard system type, which will effect programs across-hardware-platforms and across- operating-systems. No matter WHICH way we address this, there is going to be a little work involved, and we might as well try to minimize how many times we have to redo that work. If anyone DID want my opinion, the real problem here is the printf %-codes. Here we have include files which explicitly use a non-size-specific type (ie, they say 'size_t', instead of 'int'), but printf-commands have to know the exact size of that type. Flawed by design. But then, no one did ask me... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 23:40:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id DA19B37B422 for ; Sat, 2 Jun 2001 23:40:20 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f536e8144561; Sun, 3 Jun 2001 08:40:08 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Erik Trulsson Cc: arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: Your message of "Sat, 02 Jun 2001 22:26:27 +0200." <20010602222626.A26556@student.uu.se> Date: Sun, 03 Jun 2001 08:40:08 +0200 Message-ID: <44559.991550408@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010602222626.A26556@student.uu.se>, Erik Trulsson writes: >My take on the situation is as follows: > >While it will be necessary to make time_t a 64-bit type eventually to >avoid wrap-around in 2038 I am afraid that this will break many >programs and will require quite a bit of work to fix all problems. >(Yes, it is the Y2K problem all over but with another breakage-date.) > >So until everybody is prepared to make that change it is probably a >good idea to continue having time_t as a 32-bit type. Bad choice. There will never be a time where "everybody is prepared". Instead lets set a deadline: The longest commonly used time interval is 30 years for mortgages, so lets be safe and say that on january 1st 2005 00:00 UTC we will transition time_t to be at least 33 bits. Until then it is 32 bits. In practice this will probably be 64 bits on most arch's but let us use the 33 bit goal rather than mandate 64bits which might be prohibitively expensive on some architecturs. Any objections ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 2 23:43: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 77F2037B422 for ; Sat, 2 Jun 2001 23:42:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f536gi144612; Sun, 3 Jun 2001 08:42:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Polstra Cc: arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: Your message of "Sat, 02 Jun 2001 13:43:15 PDT." <200106022043.f52KhFh35078@vashon.polstra.com> Date: Sun, 03 Jun 2001 08:42:44 +0200 Message-ID: <44610.991550564@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra writes: >I'd prefer to keep it as "long" at least on the i386, because that's >what the type was for years before ANSI renamed it to "time_t". That, in my mind, is actually a good argument for making it "int" so that we can flush out those places which don't use time_t well in advance of the unaviodable change to >32 bits... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message