From owner-freebsd-current  Sat Feb 21 15:22:54 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA06136
          for freebsd-current-outgoing; Sat, 21 Feb 1998 15:22:54 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06090
          for <current@FreeBSD.ORG>; Sat, 21 Feb 1998 15:22:44 -0800 (PST)
          (envelope-from tlambert@usr04.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id QAA12913;
	Sat, 21 Feb 1998 16:22:36 -0700 (MST)
Received: from usr04.primenet.com(206.165.6.204)
 via SMTP by smtp03.primenet.com, id smtpd012901; Sat Feb 21 16:22:31 1998
Received: (from tlambert@localhost)
	by usr04.primenet.com (8.8.5/8.8.5) id QAA07185;
	Sat, 21 Feb 1998 16:22:29 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199802212322.QAA07185@usr04.primenet.com>
Subject: Re: devfs persistence
To: gibbs@plutotech.com (Justin T. Gibbs)
Date: Sat, 21 Feb 1998 23:22:29 +0000 (GMT)
Cc: tlambert@primenet.com, gibbs@plutotech.com, current@FreeBSD.ORG
In-Reply-To: <199802212302.QAA28366@pluto.plutotech.com> from "Justin T. Gibbs" at Feb 21, 98 03:59:53 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> >You must have missed the part about "rc.local".  8-) 8-).
> 
> No I didn't miss it.  rc.local only works if you want to differentiate
> "units" of a device among permission schemes where the class you define in
> the kernel is the one that applies to "new units", and the all other
> classes apply to units that are assured to exist at boot time.  Any
> situation that falls outside of this scope will fail.

Well, then let me ask a question:

	How do I know what permissions to assign a PCMCIA or a
	PCI-hot-pluggable card device that has never been plugged
	into the machine before?

Perhaps you have an argument for:

	If this device shows up, chmod and chown it thusly.

This is the daemon soloution.  You should feel free to start such
a deamon.  In your rc.local.

Devfs should probably provide an arrival interface for such a daemon,
in case one is registered, to allow it to vet/change defaults before
the device actually gets exported.

But should there be a requirement that such a daemon be written?  Or
that the interface be in the code before it becomes the default way
of accessing a device?

I say "no".  Just as someone wanting a GUI install, a feature
which does not currently exist, must write it, so must someone
wanting a vetting daemon write the code.


Notice that devices which have not arrived before rc.local can be
run are a new feature.  Therefore, there is no valid argument for
any "historical procedent" for imminenet (about to arrive but not
yet arrived) devices.

For historically extant devices, the devices will be there before
rc.local runs, and rc.local will suffice.

The one really missing feature here is a "-f" argument to chown/chmod
for use in rc.local.  But this can be simulated (better, even) with a
shell function:

#
# chcred: change credentials
#
# chmod and chown something only if it exists
#
# usage: chcred owner:group mode file ...
#
chcred()
{
	coarg=$1
	shift
	cmarg=$1
	shift

	for i in $*
	do
		if [ -e $i ]
		then
			chown ${coarg} ${i}
			chmod ${cmarg} ${i}
		fi
	done
}


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message