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.