The following reply was made to PR bin/20767; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: bin/20767
Date: Wed, 14 Oct 2009 12:10:49 +0700
Date: Tue, 13 Oct 2009 21:15:04 +0000 (UTC)
From: Jukka Ruohonen <jruohonen%iki.fi@localhost>
Message-ID: <20091013211504.6DE2A63B877%www.NetBSD.org@localhost>
| Here is my attempt for a fix.
I'd doubt that is going to get accepted, partly because ...
| - The patch uses kvm(3).
where I suspect that adding yet more kmem grovellers, where the
direction has been (for good reason) to eliminate them, is not going
to meet with much success.
But the real reason is that you're proposing adding data to the kernel
that the kernel doesn't need - if it did it would be there already.
That is, you're using the kernel as a data storage mechanism between
two (instances of) user applications. That's just not a good approach.
As best I can tell, the only way to make a cgd is via cgdconfig,
the only ways to unmake a cgd are via cgdconfig (-u) or a reboot.
If this data needs to be made available at all the right way to do it
(IMO) is to have cgdconfig manage it - just keep a record of what is
created and destroyed in a file somewhere (use file locking to avoid
race conditions with multiple instances of cgdconfig running in parallel,
which isn't likely, but ...). I'd stick it in /var/run so it gets
cleaned automatically on reboot.
If you're concerned about not having a filesystem to write in when
cgdconfig is run (boots from md's or something, that will switch root to
be inside a cgd filesystem) then use a shared mem segment instead,
that will also go away when the system reboots.
Or, have cgdconfig write the device name into somewhere in the header
of the mounted device, then all you need is to be able to iterate over
possible /dev/cgdN's and find which ones are configured (I suspect methods
do do that already exist) and upon finding a configured one, extract
the name from its data.
In any case, manage this (if it is needed at all) entirely from user space,
using only existing kernel file storage facilities, don't try to turn the
kernel into a whole bunch of separate little data storage boxes for stuff
that seemed simple of themselves, but end up being a huge mess when viewed
collectively.
[Aside: I'm not sure the data is really needed ... I use cgd, and I've never
encountered the need - on the other hand, if cgd could be made a cloneable
type device, so I don't need to pick the N in /dev/cgdN but it can be
picked for me, that would be great.]
kre