On Fri, 21 Sep 2001, Ignatios Souvatzis wrote:

: > > >Note that this need not necessarily be based on some `background daemon'.  A
: > > >special device node with in-kernel emulation would also work; such a device
: > >
: > > but why do things in the kernel that can be implemented in userland?
: >
: > Don't we have a special filesystem which can be abused for this type of
: > stunts?
: I think PORTAL.

You're caught in the common misconception of what portalfs is and what it
can do.

The portalfs layer provides you a way of fetching *file descriptors* through
an abstract namespace.  But you get only that -- a file descriptor, which is
passed using unix domain socket "fd passing" from the portal daemon.  The
portal daemon does nothing else wrt the files.

Now, you probably think you could have portal send a pipe-fd to some "utmp
translator" program, but think more carefully:  Old-utmp users need to be
able to *SEEK* to arbitrary entries in the utmp file.  Pipes don't do seek,
and portal doesn't have real file operations and thus cannot emulate seek.
Unless and until we have a userland fs layer that has the full set of file
ops (...and is not a hackery of the NFS protocol a-la sharity-light 8-), you
can't do this easily in userland.

A device node doing the translation is my best suggestion at this point, as
it doesn't have the problems of Solaris's "update daemon":  it catches
old-utmp accesses where they happen, and needs no "cleanup" procedure.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5.2 available on CD-ROM soon!  --  http://www.wasabisystems.com/