Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: ACCESS TO SHARED TAPEDRIVES
Message-ID: <6802@brl-smoke.ARPA>
Date: Sat, 5-Dec-87 16:16:25 EST
Article-I.D.: brl-smok.6802
Posted: Sat Dec  5 16:16:25 1987
Date-Received: Thu, 10-Dec-87 19:56:36 EST
References: <10542@brl-adm.ARPA> <271@cunixc.columbia.edu> <6740@brl-smoke.ARPA> <3254@ulysses.homer.nj.att.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <3254@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes:
>..., I probably have to port all the Berkeley network and
>select stuff before there is any hope of turning it into a product.

Why in the world use networking stuff?  My idea was to have a list of
controlled resources, which would be file-locked by the allocator,
which in turn would not be a daemon but would run when necessary.
The allocator would need to be able to chown resources from a
"public" account to the requesting user.  (It would also check when
unable to satisfy a request to see if there were any vanished users
whose resources could be reclaimed.)  Explicitly deallocated resources
or those detected to be idle would be chowned back to "public".

It is also very handy for such a utility to be able to not only
allocate resources by specific name (not necessarily the same as
their filename) but also by class, e.g. "alloc magtape magtape".

I think a talk and perhaps BOF session would be valuable; UNIX has
needed some facility like this for ages and it would be good to have
one (and ONLY one, which must therefore be well-designed) available
as a standard part of the product.  There are a lot of uses for it
even in a single-user environment.