Virus intercepted

2004-10-21 Thread hackers
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

2004-10-21 Thread Peter Pentchev
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?


pgp3X8mkPAcXL.pgp
Description: PGP signature


USB OHCI problems...

2004-10-21 Thread Barry Bouwsma
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

2004-10-21 Thread Simon L. Nielsen
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

2004-10-21 Thread Ruslan Ermilov
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

2004-10-21 Thread Simon L. Nielsen
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

2004-10-21 Thread Brooks Davis
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

2004-10-21 Thread Brooks Davis
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

2004-10-21 Thread Robert Watson
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, 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 @@
  

Re: [PATCH] Re: Linksys PCM200

2004-10-21 Thread Brooks Davis
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

2004-10-21 Thread Peter Pentchev
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);
 
@@ -109,8 +124,19 @@