From owner-freebsd-hackers Wed Apr 19 11:15:56 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25181 for hackers-outgoing; Wed, 19 Apr 1995 11:15:56 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA25175 for ; Wed, 19 Apr 1995 11:15:54 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19232; Wed, 19 Apr 95 12:09:28 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504191809.AA19232@cs.weber.edu> Subject: Re: [DEVFS] your opinions sought! To: dufault@hda.com (Peter Dufault) Date: Wed, 19 Apr 95 12:09:27 MDT Cc: dufault@hda.com, hackers@freefall.cdrom.com In-Reply-To: <199504191735.NAA05522@hda.com> from "Peter Dufault" at Apr 19, 95 01:35:12 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > BTW: How the heck do permissions work? Ownership and permissions should be specified by the device itself as part of the registration information. Since the device must be there for the device nodes to be valid and present, and since the devfs is updated by the kernel and can be tied to kernel events (like load/unload), there is actully no good reason that this information should be copied to be stored seperately... the only valid argument is templating of device permissions -- and it is not very supportable to argue that templating is a better soloution that simply unloading and reloading the devices (how frequently do you forsee resetting device permissions?). Permissions changed ater that (or ownership changes) can occur in the device itself. One issue here is in multiple targets for a single driver; the fact is that for each instance, there must be a name record generated anyway which will result in a device selector on lookup; the ownership can be stored as part of that record. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.