Re: [[Patch mdadm] 2/5] Move the files mdmon opens into /dev/ to support handoff after pivotroot

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

On 02/06/2010 04:07 PM, Dan Williams wrote:

> This comment makes me see Neil's argument in a different light,
> (hopefully I am not mischaracterizing it), but essentially we are
> waiting for the standards to catch up with this new class of program.
> FUSE, CUSE, and mdmon belong to a class of programs that move
> traditionally exclusive kernel space functionality to userspace.
> Debian's /lib/init/rw looks to be a response to this grey area of the
> standards (not that I have any familiarity with the LSB).

So if we want to argue that the standards are simply behind the times,
and we need to do something that makes sense regardless of the
standards, then I don't think anything in /dev or /lib makes sense.  The
files that need to be created pre-rw-root are varied in their type and
purpose between different things.  What we really need is simply an
early boot /tmp area.  So, why not make a top level directory that
clearly delineates this nature?  Something like /pre-init or /early-tmp
or whatever?  Or possibly /tmp/pre-boot or /tmp/pre-init or
/tmp/pre-pivot-root (the pre-pivot-root naming is awfully linux
specific, so maybe /tmp/pre-init or /tmp/pre-boot would be better for
possible standards acceptance later)?  I was thinking that mdmon's files
would be stuck there, but then I remembered that we are doing option #3
for mdmon, restarting after the system is up and running, so only the
mdmon instances from the initramfs would put their files there, the
final ones would be on the real /var/run area.  So, since as far as I
know the mdmon .sock files were the only pre-boot files that couldn't be
moved later (but effectively get moved by restarting mdmon after r/w
/var/run), any and all files in /tmp/pre-pivot-root should be removed
once the system is up and running, and quite possibly the filesystem
could be entirely done away with.  At least then the naming would be to
Neil's satisfaction I think, and mine.  And personally, when the
standards are simply behind the times, I have no problem blazing ahead
and letting them catch up when they get off their asses.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]