Look who's a committer now

[David Zeuthen]

On Wed, 2006-05-10 at 22:31 -0400, Joe Marcus Clarke wrote:
> Now that I have a HAL CVS account, I'd like to tackle the job of moving
> the tools scripts into OS subdirectories a la the hald backends.  In
> FreeBSD the way we handle such things is for a CVS administrator to do a
> repository copy so that the new files retain the history of their
> obsolete counterparts.  I'm not sure if that's the case with fd.o or
> HAL.

Yeah, that would make a lot of sense. Keeping history is good. But I'm
not so sure we need to move anything. See below.

> Basically, my plan is to create tools/solaris and tools/freebsd to go
> along with tools/linux.  I will then move the relevant tools into those
> subdirectories.  What I think must be moved are the following:
> 
> hal-luks* (linux only)
> hal-storage-mount.c
> hal-system*
> 
> The rest I don't necessarily thing need to be moved, but I will be
> willing to move anything people think is relevant.  Anything left in
> tools/ will be considered common.

So, the way I'd envision this to happen is

 1. tools/ contain all shared parts. Every method-helper (e.g. 
    hal-system-lcd-get-brightness) is also there and contains the
    stubs that are OS independent, e.g.

     1a. sanity checks that it's launched by hald
     1b. policy checks via PolicyKit

    I think even stuff like LUKS bits should live there. 

    Said method-helpers then just does

     if [ -x ./$0-$HAL_UNAME_S ]; then
       exec ./$0-$HAL_UNAME_S $@
     else
       echo "Not back-end for your implementation" >&2
       exit 1
     fi

    This requires 

     - hald-runner to set HAL_UNAME_S to `uname -s` (need patch) and I
       think that's fine; saves invocation of /bin/uname on every script
       and while we're at lowercase the string too.

     - I'm assuming that the script being exec'ed inherits
       stdin/stdout/stderr; I think that's true too and we need it for
       the arguments passed

     - tools/$OS to install scripts in the same place

    Of course, some scripts are simple and we don't need to exec an OS
    specific script. Also, some stuff in C like hal-storage-mount.c
    should just be patched so it works on FreeBSD and Solaris too. That
    shouldn't be a problem because it's C. Finally, some scripts we can
    just switch on HAL_UNAME_S directly in the script.

    The big wins we get is that 1) we don't need OS-conditionals in the
    fdi files (we really really don't want that); and 2) we centralize
    all shared checking in one place.

 2. tools/$OS contains the OS specific bits; so we would have

     tools/linux/hal-system-lcd-get-brightness-linux
     ...
     tools/freebsd/hal-system-lcd-get-brightness-freebsd
     ...
     tools/solaris/hal-system-lcd-get-brightness-freebsd

    and that's it. Obviously you don't install tools/linux on
    FreeBSD and so forth.

> Once I get the tools compartmentalized, I will start work on merging the
> FreeBSD-specific patches into our tools directory.
> 
> Is this something I can get permission to do?  If so, do you guys do the
> repocopy thing, or should I just cvs rm/cvs add?  Thanks.

I think with the approach I've outlined above we don't need to move
anything. 

Thoughts?

    David