Virus intercepted
A message you sent to <[EMAIL PROTECTED]> contained Worm.SomeFool.X and has not been delivered. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[CFR] Specify the lock(1) timeout unit
Hi, Here's a little patch that teaches lock(1) about timeouts specified in seconds, hours, or days in addition to the minutes it currently assumes. I could commit this in a week if there are no objections. G'luck, Peter Index: src/usr.bin/lock/lock.1 === RCS file: /home/ncvs/src/usr.bin/lock/lock.1,v retrieving revision 1.11 diff -u -r1.11 lock.1 --- src/usr.bin/lock/lock.1 2 Jul 2004 22:22:27 - 1.11 +++ src/usr.bin/lock/lock.1 21 Oct 2004 10:39:13 - @@ -42,6 +42,7 @@ .Nm .Op Fl npv .Op Fl t Ar timeout +.Op Fl u Ar unit .Sh DESCRIPTION The .Nm @@ -63,7 +64,22 @@ .It Fl t Ar timeout The time limit (default 15 minutes) is changed to .Ar timeout -minutes. +minutes, or units specified by the +.Fl u +option. +.It Fl u Ar unit +Specify the time measurement unit for the time limit. +The +.Ar unit +argument may be one of +.Sq s +for seconds, +.Sq m +for minutes (the default), +.Sq h +for hours, or +.Sq d +for days. .It Fl v Disable switching virtual terminals while this terminal is locked. This option is implemented in a way similar to the Index: src/usr.bin/lock/lock.c === RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v retrieving revision 1.18 diff -u -r1.18 lock.c --- src/usr.bin/lock/lock.c 22 Jan 2004 04:24:15 - 1.18 +++ src/usr.bin/lock/lock.c 21 Oct 2004 11:07:36 - @@ -85,6 +85,20 @@ long nexttime; /* keep the timeout time */ intno_timeout; /* lock terminal forever */ intvtyunlock; /* Unlock flag and code. */ +const char *timeout_str = "minute"; +inttimeout_mul = 60; + +struct timeout_spec { + char spec; + int mul; + const char *str; +} timeout_spec[] = { + {'s', 1, "second"}, + {'m',60, "minute"}, + {'h', 3600, "hour"}, + {'d', 86400, "day"}, + {'\0',0, NULL}, +}; /*ARGSUSED*/ int @@ -98,20 +112,31 @@ int ch, failures, sectimeout, usemine, vtylock; char *ap, *mypw, *ttynam, *tzn; char hostname[MAXHOSTNAMELEN], s[BUFSIZ], s1[BUFSIZ]; + struct timeout_spec *ts; openlog("lock", LOG_ODELAY, LOG_AUTH); sectimeout = TIMEOUT; + timeout_mul = 60; mypw = NULL; usemine = 0; no_timeout = 0; vtylock = 0; - while ((ch = getopt(argc, argv, "npt:v")) != -1) + while ((ch = getopt(argc, argv, "npt:u:v")) != -1) switch((char)ch) { case 't': if ((sectimeout = atoi(optarg)) <= 0) errx(1, "illegal timeout value"); break; + case 'u': + for (ts = timeout_spec; ts->spec != '\0'; ts++) + if (ts->spec == optarg[0]) + break; + if (ts->spec == '\0') + errx(1, "illegal timeout unit specifier"); + timeout_mul = ts->mul; + timeout_str = ts->str; + break; case 'p': usemine = 1; if (!(pw = getpwuid(getuid( @@ -128,7 +153,7 @@ default: usage(); } - timeout.tv_sec = sectimeout * 60; + timeout.tv_sec = sectimeout * timeout_mul; setuid(getuid()); /* discard privs */ @@ -139,7 +164,7 @@ errx(1, "not a terminal?"); if (gettimeofday(&timval, (struct timezone *)NULL)) err(1, "gettimeofday"); - nexttime = timval.tv_sec + (sectimeout * 60); + nexttime = timval.tv_sec + (sectimeout * timeout_mul); timval_sec = timval.tv_sec; timp = localtime(&timval_sec); ap = asctime(timp); @@ -200,8 +225,8 @@ if (no_timeout) (void)printf(" no timeout."); else - (void)printf(" timeout in %d minute%s.", sectimeout, - sectimeout != 1 ? "s" : ""); + (void)printf(" timeout in %d %s%s.", sectimeout, + timeout_str, sectimeout != 1 ? "s" : ""); if (vtylock) (void)printf(" vty locked."); (void)printf("\ntime now is %.20s%s%s", ap, tzn, ap + 19); @@ -243,7 +268,7 @@ static void usage(void) { - (void)fprintf(stderr, "usage: lock [-npv] [-t timeout]\n"); + (void)fprintf(stderr, "usage: lock [-npv] [-t timeout] [-u unit]\n"); exit(1); } -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence?
USB OHCI problems...
Apologies for this posting, as so far as I know it's a known issue that the USB OHCI code has some problems, or perhaps that there have been code commits in the last weeks so this is no longer a problem... Anyway, under FreeBSD-4 with kernel modules built 10.August from source that I believe is based on FreeBSD-5-current of that era, I'm seeing corruption of data read from umass devices attached to an OHCI controller card. Use of a UHCI controller card instead seems mostly free of problems. In comparison, I accessed the data with NetBSD-current of similar vintage, and in the files copied with the identical hardware, the data is intact. The point at which the corruption begins is at some multiple of 16384 bytes into the file. The corruption is not consistent, as it is less likely to occur when the machine is somewhat idle, and as the below shows, also occurs at different points into the same file. I haven't looked to see for how long this corruption is present (it's more than a few hundred bytes, at least) or how the file appears after this, or whether this corruption follows any particular pattern of the rest of the file. The below is `cmp' output under my FreeBSD, compared against the files previously downloaded with NetBSD (and verified that all the images are intact). /cdrom/dcim/100dscim/pict0681.jpg pict0681.jpg differ: char 524289, line 2284 /cdrom/dcim/100dscim/pict0683.jpg pict0683.jpg differ: char 507905, line 2116 /cdrom/dcim/100dscim/pict0684.jpg pict0684.jpg differ: char 1163265, line 3323 /cdrom/dcim/100dscim/pict0685.jpg pict0685.jpg differ: char 294913, line 1402 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 393217, line 1716 /cdrom/dcim/100dscim/pict0687.jpg pict0687.jpg differ: char 753665, line 2606 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 983041, line 3648 This is just a sample -- note that the last line is the same file that I had previously `cmp'ed two lines above. In fairness, the files copied from NetBSD were done with the machine mostly idle, so I don't know if NetBSD suffers the same if I were pounding the machine. If this issue hasn't been handled, perhaps the fact that NetBSD doesn't seem to have problems might give someone some ideas as to where the problem might lie. As usual, apologies for the untimeliness of this, as well as my lack of detailed testing with fresh -current or with code fresher than two months ago. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CFR] Specify the lock(1) timeout unit
On 2004.10.21 14:37:10 +0300, Peter Pentchev wrote: > Here's a little patch that teaches lock(1) about timeouts specified in > seconds, hours, or days in addition to the minutes it currently assumes. > I could commit this in a week if there are no objections. Wouldn't it be more natural to just append the time-unit type to the argument given to -t, e.g. "-t 10s" or "-t 10h". That just seem like the more intuitive way to handle it to me... Note: this is a suggestion, not an objection to the original patch. -- Simon L. Nielsen FreeBSD Documentation Team pgplLx6xiPz8q.pgp Description: PGP signature
Re: [CFR] Specify the lock(1) timeout unit
On Thu, Oct 21, 2004 at 04:32:08PM +0200, Simon L. Nielsen wrote: > On 2004.10.21 14:37:10 +0300, Peter Pentchev wrote: > > > Here's a little patch that teaches lock(1) about timeouts specified in > > seconds, hours, or days in addition to the minutes it currently assumes. > > I could commit this in a week if there are no objections. > > Wouldn't it be more natural to just append the time-unit type to the > argument given to -t, e.g. "-t 10s" or "-t 10h". That just seem like > the more intuitive way to handle it to me... > > Note: this is a suggestion, not an objection to the original patch. > Yes, please. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp1k9I6rgODg.pgp Description: PGP signature
Re: [PATCH] Re: Linksys PCM200
On 2004.10.20 22:59:50 -0600, [EMAIL PROTECTED] wrote: > > [got no answer on [EMAIL PROTECTED] > > I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts. > So could someone review those patches and add them to the source tree? > It's probably a good idea to update dc(4) and supported hw list also. > > /usr/src/sys/pci/if_dc.c udiff: [...] Unless a src committer picks this up within the next couple of days I would suggest filing a PR with the patch so it does not get lost. -- Simon L. Nielsen FreeBSD Documentation Team pgp6hW4GpGJZ3.pgp Description: PGP signature
Re: [PATCH] Re: Linksys PCM200
On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote: > > [got no answer on [EMAIL PROTECTED] > > I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts. > So could someone review those patches and add them to the source tree? > It's probably a good idea to update dc(4) and supported hw list also. I'm looking at this, though I have no hardware to test with. This patch suffers from cut-n-paste dammage and can not be applied directly. Please be more careful with this sort of thing in the future. > @@ -1978,6 +1982,7 @@ > case DC_DEVICEID_3CSOHOB: > case DC_DEVICEID_MSMN120: > case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision with PNIC*/ > + case DC_DEVICEID_PCM200_AB09: > sc->dc_type = DC_TYPE_AN985; > sc->dc_flags |= DC_64BIT_HASH; > sc->dc_flags |= DC_TX_USE_TX_INTR; Should there be an DC_DEVICEID_PCM200_AB08 here? It certaintly looks like it won't work otherwise. Thanks for you submission. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp9XXHOq9oKT.pgp Description: PGP signature
Re: [PATCH] Re: Linksys PCM200
On Thu, Oct 21, 2004 at 10:34:56AM -0700, Brooks Davis wrote: > On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote: > > @@ -1978,6 +1982,7 @@ > > case DC_DEVICEID_3CSOHOB: > > case DC_DEVICEID_MSMN120: > > case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision with PNIC*/ > > + case DC_DEVICEID_PCM200_AB09: > > sc->dc_type = DC_TYPE_AN985; > > sc->dc_flags |= DC_64BIT_HASH; > > sc->dc_flags |= DC_TX_USE_TX_INTR; > > Should there be an DC_DEVICEID_PCM200_AB08 here? It certaintly looks > like it won't work otherwise. Eww, I see why this works. I'll see if I can't at least document this bit. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpAblmD1zOga.pgp Description: PGP signature
Re: [CFR] Specify the lock(1) timeout unit
On Thu, 21 Oct 2004, Peter Pentchev wrote: > Here's a little patch that teaches lock(1) about timeouts specified in > seconds, hours, or days in addition to the minutes it currently assumes. > I could commit this in a week if there are no objections. I think the normal convention here (see also shutdown(8), etc) is to have the unit be specified as part of the time specification rather than as a separate argument. I.e., lock -t 5m rather than lock -t 5 -u m. If we don't already have it, maybe we need humanize and dehumanize functions for time as well as disk storage? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research > > G'luck, > Peter > > Index: src/usr.bin/lock/lock.1 > === > RCS file: /home/ncvs/src/usr.bin/lock/lock.1,v > retrieving revision 1.11 > diff -u -r1.11 lock.1 > --- src/usr.bin/lock/lock.1 2 Jul 2004 22:22:27 - 1.11 > +++ src/usr.bin/lock/lock.1 21 Oct 2004 10:39:13 - > @@ -42,6 +42,7 @@ > .Nm > .Op Fl npv > .Op Fl t Ar timeout > +.Op Fl u Ar unit > .Sh DESCRIPTION > The > .Nm > @@ -63,7 +64,22 @@ > .It Fl t Ar timeout > The time limit (default 15 minutes) is changed to > .Ar timeout > -minutes. > +minutes, or units specified by the > +.Fl u > +option. > +.It Fl u Ar unit > +Specify the time measurement unit for the time limit. > +The > +.Ar unit > +argument may be one of > +.Sq s > +for seconds, > +.Sq m > +for minutes (the default), > +.Sq h > +for hours, or > +.Sq d > +for days. > .It Fl v > Disable switching virtual terminals while this terminal is locked. > This option is implemented in a way similar to the > Index: src/usr.bin/lock/lock.c > === > RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v > retrieving revision 1.18 > diff -u -r1.18 lock.c > --- src/usr.bin/lock/lock.c 22 Jan 2004 04:24:15 - 1.18 > +++ src/usr.bin/lock/lock.c 21 Oct 2004 11:07:36 - > @@ -85,6 +85,20 @@ > long nexttime; /* keep the timeout time */ > intno_timeout; /* lock terminal forever */ > int vtyunlock; /* Unlock flag and code. */ > +const char *timeout_str = "minute"; > +int timeout_mul = 60; > + > +struct timeout_spec { > + char spec; > + int mul; > + const char *str; > +} timeout_spec[] = { > + {'s', 1, "second"}, > + {'m',60, "minute"}, > + {'h', 3600, "hour"}, > + {'d', 86400, "day"}, > + {'\0',0, NULL}, > +}; > > /*ARGSUSED*/ > int > @@ -98,20 +112,31 @@ > int ch, failures, sectimeout, usemine, vtylock; > char *ap, *mypw, *ttynam, *tzn; > char hostname[MAXHOSTNAMELEN], s[BUFSIZ], s1[BUFSIZ]; > + struct timeout_spec *ts; > > openlog("lock", LOG_ODELAY, LOG_AUTH); > > sectimeout = TIMEOUT; > + timeout_mul = 60; > mypw = NULL; > usemine = 0; > no_timeout = 0; > vtylock = 0; > - while ((ch = getopt(argc, argv, "npt:v")) != -1) > + while ((ch = getopt(argc, argv, "npt:u:v")) != -1) > switch((char)ch) { > case 't': > if ((sectimeout = atoi(optarg)) <= 0) > errx(1, "illegal timeout value"); > break; > + case 'u': > + for (ts = timeout_spec; ts->spec != '\0'; ts++) > + if (ts->spec == optarg[0]) > + break; > + if (ts->spec == '\0') > + errx(1, "illegal timeout unit specifier"); > + timeout_mul = ts->mul; > + timeout_str = ts->str; > + break; > case 'p': > usemine = 1; > if (!(pw = getpwuid(getuid( > @@ -128,7 +153,7 @@ > default: > usage(); > } > - timeout.tv_sec = sectimeout * 60; > + timeout.tv_sec = sectimeout * timeout_mul; > > setuid(getuid()); /* discard privs */ > > @@ -139,7 +164,7 @@ > errx(1, "not a terminal?"); > if (gettimeofday(&timval, (struct timezone *)NULL)) > err(1, "gettimeofday"); > - nexttime = timval.tv_sec + (sectimeout * 60); > + nexttime = timval.tv_sec + (sectimeout * timeout_mul); > timval_sec = timval.tv_sec; > timp = localtime(&timval_sec); > ap = asctime(timp); > @@ -200,8 +225,8 @@ > if (no_timeout) > (void)printf(" no timeout."); > else > - (void)printf(" timeout in %d minute%s.", sectimeout, > - sectimeout != 1 ? "s" : ""); > + (void)printf(" timeout in %d %s%s.", sectimeout, > + timeout_str, sec
Re: [PATCH] Re: Linksys PCM200
On Thu, Oct 21, 2004 at 10:34:56AM -0700, Brooks Davis wrote: > On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote: > > > > [got no answer on [EMAIL PROTECTED] > > > > I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts. > > So could someone review those patches and add them to the source tree? > > It's probably a good idea to update dc(4) and supported hw list also. > > I'm looking at this, though I have no hardware to test with. Could some people with dc(4) devices please test the following patch? It compiles for me and is trivial, but a quick test is probalby in order before I commit it. This differs from soralx's patch in that it adds comments on the 0xab08 collisions and shortens the description string to something that will fit in one line on the console. Thanks, Brooks Index: if_dc.c === RCS file: /home/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.152 diff -u -p -r1.152 if_dc.c --- if_dc.c 1 Oct 2004 15:23:31 - 1.152 +++ if_dc.c 21 Oct 2004 22:32:39 - @@ -218,6 +218,10 @@ static struct dc_type dc_devs[] = { "Microsoft MN-130 10/100" }, { DC_VENDORID_MICROSOFT, DC_DEVICEID_MSMN130_FAKE, "Microsoft MN-130 10/100" }, + { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB08, + "Linksys PCM200 EtherFast CardBus 10/100" }, + { DC_VENDORID_LINKSYS, DC_DEVICEID_PCM200_AB09, + "Linksys PCM200 EtherFast CardBus 10/100" }, { 0, 0, NULL } }; @@ -1917,10 +1921,16 @@ dc_attach(device_t dev) case DC_DEVICEID_FA511: case DC_DEVICEID_FE2500: case DC_DEVICEID_EN2242: - case DC_DEVICEID_HAWKING_PN672TX: + case DC_DEVICEID_HAWKING_PN672TX: +#if 0 /* DC_DEVICEID_HAWKING_PN672TX has the same ID as the following */ + case DC_DEVICEID_FE2500MX: + case DC_DEVICEID_FNW3602T: + case DC_DEVICEID_PCM200_AB08: +#endif case DC_DEVICEID_3CSOHOB: case DC_DEVICEID_MSMN120: case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision with PNIC*/ + case DC_DEVICEID_PCM200_AB09: sc->dc_type = DC_TYPE_AN985; sc->dc_flags |= DC_64BIT_HASH; sc->dc_flags |= DC_TX_USE_TX_INTR; Index: if_dcreg.h === RCS file: /home/ncvs/src/sys/pci/if_dcreg.h,v retrieving revision 1.42 diff -u -p -r1.42 if_dcreg.h --- if_dcreg.h 29 Jun 2004 20:38:44 - 1.42 +++ if_dcreg.h 21 Oct 2004 22:32:40 - @@ -998,6 +998,17 @@ struct dc_softc { #define DC_DEVICEID_MSMN130_FAKE 0xFFF2 /* + * Linksys vendor ID + */ +#define DC_VENDORID_LINKSYS0x1737 + +/* + * Linksys device IDs + */ +#define DC_DEVICEID_PCM200_AB080xab08 +#define DC_DEVICEID_PCM200_AB090xab09 + +/* * PCI low memory base and low I/O base register, and * other PCI registers. */ -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpiL9M0SHITq.pgp Description: PGP signature
Re: [CFR] Specify the lock(1) timeout unit
On Thu, Oct 21, 2004 at 04:38:10PM -0400, Robert Watson wrote: > On Thu, 21 Oct 2004, Peter Pentchev wrote: > > > Here's a little patch that teaches lock(1) about timeouts specified in > > seconds, hours, or days in addition to the minutes it currently assumes. > > I could commit this in a week if there are no objections. > > I think the normal convention here (see also shutdown(8), etc) is to have > the unit be specified as part of the time specification rather than as a > separate argument. I.e., lock -t 5m rather than lock -t 5 -u m. If we > don't already have it, maybe we need humanize and dehumanize functions for > time as well as disk storage? [randomly picking this message to reply to, since the others voiced the same concern and suggestion] Yep, on second thought it only seems natural to append the unit to the time specification; guess I wasn't thinking straight earlier today when I whipped this up in a hurry... Thanks everyone for pointing out the blindingly obvious - in this case, it *was* needed! :) Attached is an almost trivial patch that implements this, parsing things like '10s', '2m', '15h', or '2d' just as the previous version did - seconds, minutes, hours, days. As to factoring out the time specification parsing, it may not be just as easy as with disk storage units. The main problem here is that the utilites that parse time specifiers do so for a variety of different reasons, and then use the result in different ways. The secondary problem, maybe even more severe, is that the different utilities parse very different time formats, e.g. date(1) pretty much only understands +/-num[ymwdHMS], shutdown(8) takes either +minutes or a full or partial [[[yy]mm]dd]hhmmss specification, and find(1) and cvs(1) use the GNU getdate.y thing which is... well, let me say 'hairy' lest I use a stronger word. (As a side note, wow, I never knew that find(1) could do 'last year', 'a fortnight ago', or '22:00 IDLW'; makes sense, though, since they use the same code.) Sooo.. if we should create a unified time parsing function, what should it parse - an interval, an absolute time, or what? That is, what should it *return* - an interval in seconds, or the absolute time (time_t or struct tm) that the input specifies either directly or as an offset from the current time, both, neither, or the air velocity of an unladen swallow? How should it deal with nonexistent times - return an error, try to round them up, try to round them down, or silently convert them to the Antartica/South_Pole zone and snicker behind the curtain? How should it deal with month specifications? (gee, I hope no one tries to use a month unit as a lock(1) timeout, but you never know with some people) Anyway, here's the lock(1) patch that lets it handle 's', 'm', 'h', or 'd' appended to the timeout value. G'luck, Peter Index: src/usr.bin/lock/lock.1 === RCS file: /home/ncvs/src/usr.bin/lock/lock.1,v retrieving revision 1.11 diff -u -r1.11 lock.1 --- src/usr.bin/lock/lock.1 2 Jul 2004 22:22:27 - 1.11 +++ src/usr.bin/lock/lock.1 21 Oct 2004 23:05:25 - @@ -64,6 +64,21 @@ The time limit (default 15 minutes) is changed to .Ar timeout minutes. +The timeout value may optionally be followed by a time unit specifier, +one of +.Sq s +for seconds, +.Sq m +for minutes (the default), +.Sq h +for hours, or +.Sq d +for days. +Thus, +.Sq -t 2 +would specify a timeout of two minutes, while +.Sq -t 10s +would specify a timeout of ten seconds. .It Fl v Disable switching virtual terminals while this terminal is locked. This option is implemented in a way similar to the Index: src/usr.bin/lock/lock.c === RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v retrieving revision 1.18 diff -u -r1.18 lock.c --- src/usr.bin/lock/lock.c 22 Jan 2004 04:24:15 - 1.18 +++ src/usr.bin/lock/lock.c 21 Oct 2004 23:06:59 - @@ -85,6 +85,20 @@ long nexttime; /* keep the timeout time */ intno_timeout; /* lock terminal forever */ intvtyunlock; /* Unlock flag and code. */ +const char *timeout_str = "minute"; +inttimeout_mul = 60; + +struct timeout_spec { + char spec; + int mul; + const char *str; +} timeout_spec[] = { + {'s', 1, "second"}, + {'m',60, "minute"}, + {'h', 3600, "hour"}, + {'d', 86400, "day"}, + {'\0',0, NULL}, +}; /*ARGSUSED*/ int @@ -96,8 +110,9 @@ struct itimerval ntimer, otimer; struct tm *timp; int ch, failures, sectimeout, usemine, vtylock; - char *ap, *mypw, *ttynam, *tzn; + char *ap, *mypw, *ttynam, *tzn, *endarg; char hostname[MAXHOSTNAMELEN], s[BUFSIZ], s1[BUFSIZ]; + struct timeout_spec *ts; openlog("lock", LOG_ODELAY, LOG_AUTH