--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 20, 2004 at 05:08:56PM +1100, Daniel Carosone wrote:
> On Fri, Nov 19, 2004 at 06:41:13PM -0800, Bill Studenmund wrote:
> > Note: while I've mentioned some aspects of a devfs that help
> > "user-friendly workstations," I also am thinking of server-class machin=
es=20
> > too. These changes will really help with disks on SANs.
>=20
> Elsewhere in this thread, I specifically used the example of WWN-based
> locators for FC-AL disks, possibly with multi-pathing, in recognition
> of exactly this point. :-)

Yep, my main thought was just to make it clear that I think these changes=
=20
will help all classes of NetBSD install, not just "desktop" style ones.

> > I expect we'll come up with something like "dstat"(2). This idea is
> > quite rough, and certainly open to comment. The idea is to permit
> > userland to querry the bindings (locators) for a device. Thus
> > tripwire will be able to make sure the locators for a node won't
> > move around.
>=20
> See my "symdev" proposal for one representation of essentially this
> idea.

I saw that. My initial reaction is one of great reversion, but let me=20
think about it. Truth be told, it wouldn't be hard to make an "overlay"=20
style fs that handles this. The only needed change would be: 1) upon=20
return from lookup, we examine the type of the underlying node, and if=20
it's a symlink, we transform it into the correct device vnode. 2) support=
=20
for "overlay" and "non-overlay" nodes in the same fs. As each node will=20
have its own vop dispatch table, this distinction wouldn't be too bad.

However we still have the "name space in fs as primary key" issue. I find=
=20
myself very enamored with the idea that we can have two different nodes=20
with the same name and with distinct permissions. Yes, we can have only=20
one of them around at once. But part of my idea is that we can retain info=
=20
about the absent device, so that when it shows up again we handle it=20
correctly.

Consider a case like a wedge named "Accounting info" (or some other
specific name) bound to a specific WWN or other disk ID. Now say the=20
system reboots, and for whatever config ordering reason, a different=20
"Accounting info" partition/wedge gets found. I'd like the system to be=20
able to realise that this one is different, react appropriately (*), _and_=
=20
not forget about the original "Accounting info" in the process.

(*) What is appropriate is a local policy decision, but I think a good=20
option should be to make the "duplicate" show up with permissions 000 (no=
=20
read, no write, no nothing) and to log BIG NASTY messages in syslog.=20
Perhaps even not completely booting, since we can't mount a file system=20
from that partition. But that's the policy I'd want; other folks or other=
=20
cases may want different.

So my concern with using magic nodes in the root fs /dev (the symlink=20
idea) is that we are constrained by the fact the fs will use node name as=
=20
a primary key, so we'd not be able to retain the duplicate.

> For the purposes of illustration, i'm imagining that locator strings
> in these symlinks are analogous to LDAP query search strings.  Lest
> anyone get hung up on the syntax of the example, perhaps I'll suggest
> that they instead be SQL strings, just to make it clear that I'm not
> presuming any particular syntax, but that they should be simple
> strings that can be handled and stored easily, whether in symlinks, a
> devfs-persistence-file, or a config-assist daemon config file.
>=20
> They're a way to express matching against a "locators database" in the
> config namespace in the kernel. A device might have a number of names
> in this namespace, to help itself get found by these search strings
> (c/b,major,minor being one of the forms of its name, verily).

Yep. And I also agree that the tuple of (c/b, major, minor) will be=20
important for quite a while.

> Depending how the search strings are written, they might be entirely
> and utterly specific to a particular node, or they might be a looser
> search that permits variations: "a msdosfs wedge called 'my pics' on a
> umass device, in any slot" or "the first scsi tape drive found" or
> perhaps even "the first nic found, any driver".

Indeed. These directions are some of the ones I have in the back of my=20
head.

> If you want a locked down system, you use highly specific search
> strings; if you want a more flexible set of names in /dev, you use a
> looser set of searches.  In much the same way that you might hardwire
> or wildcard devices to locators in config(8) files now.  In either
> case, if someone changes your search strings on you, tripwire can
> squeal.

Yep. And as I think we both agree, a truly-wired-down system may also=20
forbid "new" devices from showing up at all (which would mean in my=20
example above, the other "Accounting Info" wedge wouldn't even have been=20
visible).

Take care,

Bill

--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBn85fWz+3JHUci9cRAmebAKCMeg/mEG3+NisO0METoInii5UUVQCfbPyd
14eltdNXS2Li94XOjpQhHPE=
=/Ikv
-----END PGP SIGNATURE-----

--3MwIy2ne0vdjdPXF--