--R10gueRtU1pFqy+X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Nov 19, 2004 at 02:56:05PM -0800, Jonathan Stone wrote:
> I know of certain applications where old-style nodes in the fs is an
> absolute, non-negotiable requirement, and for which the proposed devfs
> is an absolute non-starter.

I'm curious, perhaps you could elaborate on the pertinent points of
your case?

I have some concerns of my own, which may or may not be problems under
some devfs variant, and which may or may not be similar to yours.

The chroot case is a clear and obvious one: you want only very
particular devices to exist, or not, and perhaps also with different
permissions that their equivalents in the "real" /dev.  Adding a bunch
of smart "filtering" to duplicated devfs submounts is possible, but
seems excessive, complex and error-prone.  However, as a separate
discussion, stronger virtualisation and isolation tools than chroot
would also be good (systrace gets us quite a way further, but there's
still plenty more could be done), and their benefits may more than
compensate.

Another concern is how a dynamic devfs might interact with
integrity-checking tools (tripwire, et al.)  If device numbers,
permissions, ownerships, times, or indeed any stat members are
changing, these tools will rightly get upset, and it becomes hard or
impossible to distinguish harmless from harmful changes.  Some of
these machines I'd presently build on physically read-only media,
which an in-memory devfs isn't. I haven't seen a proposal to make
devfs the mandatory and only way to do device access, at least not
unless it can be shown to be a strict improvement for all cases (and
not just the common default). These systems are in any case already
heavily customised and also unlikely to have the "plug and play"
requirements that motivate a devfs for user-friendly workstations.

Please add to this list, it's a good set of requirements to guide
potential design.

> Are you saying that for such applications, we should use another OS?

I certainly hope not!

--
Dan.
--R10gueRtU1pFqy+X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBnodVEAVxvV4N66cRAhMMAKCJeH9z+FJMWh/8i3HTUJ3+9rR7WgCfcyDu
OVSOTCw8UTiV3r8URe5KmR8=
=fHJL
-----END PGP SIGNATURE-----

--R10gueRtU1pFqy+X--