Re: bin/20767

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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