5321 Convenience scripts to build/clean smbsrv, idmap, zfs

Review Request #23 — Created April 10, 2015 and submitted


These are some convenience scripts we use for developer "partial builds".
It makes my life a little easier upstreaming the rest of our SMB work
if I can integrate these, because later changes add to them.

In use for quite a while at Nexenta.

  • 0
  • 0
  • 6
  • 2
  • 8
Description From Last Updated
  2. usr/src/tools/quick/make-smbsrv (Diff revision 1)

    whitespace nit?

  3. usr/src/tools/quick/make-zfs (Diff revision 1)
  1. I mostly just looked at the make-zfs script, but it looks good to me. I think we'll try replace our internal script and instead use the 'make-zfs' included here after this lands.

    The only thing I don't like is the fact that there's so much code duplication between the scripts. At some point (in a later patch) it might be good to move the common code to another file, and then "source" it into the actual scripts.

    1. Some of the differences you point our are things where I agree that make-zfs should do a little more.
      I can take a stab a those and update this review.

      Several of the others sound like a difference in goals and requirements.
      The goal of these make-* scripts is to provide a fast and easy way to
      re-run those parts of the build needed to support the "make-* tar" target.
      The implementation was intentionally "minimalist", rebuilding only what is
      actually required in the tar, not all dependents etc.

      The developer is expected to setup the needed dependents by either:
      (a) building on a machine where the native libraries etc. are sufficient,
      or (b) running a full build at least once before using quick/make-* ...

      It sounds like the script you're using a Delphix might be implementing
      a different goal, perhaps described as: Build everthing used directly or
      indirectly, including all libraries etc. with no assmption that a full
      build was ever run, and no assumption that the build system provides
      compabible libraries.

      Those would both be quite reasonable goals; however, I find the
      "quick" aspect the more valuable, because I typically use these
      in an "edit, compile, (load), debug" cycle and want that fast.

      Am I understanding both our goals correctly?

      Perhaps we could make one script serve both goals by adding a
      new target to build the additional dependent libraries that
      your script builds. The developer would only need to run that
      (at least) once per work space.

      Thoughts on that?

    2. Yup, I think that sums it up perfectly. We didn't want to have the full build requirement (that takes much too long ;), so it sounds like that's where the descrepancy is coming from.

      I'm all for only rebuilding as little as possible, to speed up the cycle.

      It'd be great if you added another target to fit our goal of not requiring a full build! That'd save me some work, since I'd have to do that regardless if we wanted to start using this.

  2. usr/src/tools/quick/make-zfs (Diff revision 1)

    at delphix, we're also building:


    in our list of kernel directories. should those two be added to the list here? (probably with s/intel/$x/)

    1. Agreed, should build those too.

    2. Actually, I just looked, and those build kmdb and the devfs support,
      both of which are not currently delivered by the tar.
      Should they be? And if so, why?

      I think we just want to build the ZFS mdb modules (for both
      mdb and kmdb) but not the rest of mdb or kmdb.

  3. usr/src/tools/quick/make-zfs (Diff revision 1)

    I think we may have accumulated some cruft here, but we're also building these libs:


    should any of these be listed here too?

    I see there's some overlap between my list and the list in 'do_hdrs' so maybe we were just being lazy and doing a 'make install' when we really just needed a 'make install_h'...

    1. See my comments about goals above.

    2. I believe the "deplibs" target covers these now.

  4. usr/src/tools/quick/make-zfs (Diff revision 1)

    Our script at delphix is also building the cmds:


    does it make sense to pull these directories in here too? I can't remember why we build all of these, but I think we'd definitely need to add zinject and mdb if we were to move over to using this tool instead our internal one.

    1. Agreed about zinject.

      Not sure we need the others, depending on which goal we're trying to achieve.
      As for mdb, I want to build the ZFS mdb module, but not much else.

    2. I added isaexec (which is needed when installing zdb etc)
      also zinject. Don't think the others are needed.

  5. usr/src/tools/quick/make-zfs (Diff revision 1)

    should this be moved into the 'for cmd in' list above? is it split out here for a special reason?

    1. Hm. I'm not sure ZFS needs this. I'll check.
      It might have been left over from copying...

    2. Yeah, we need to build (at least) SUNW_zfs_link.o
      This was separated because I was trying to pass:
      but that didn't work (then I gave up on that:)

    3. I figured out how to build just the ZFS mod.

  6. usr/src/tools/quick/make-zfs (Diff revision 1)

    similar to mdb, is this "better" than doing 'cd $SRC/cmd/syseventd && $make $1' ? just curious..

    1. Is there a ZFS component of syseventd that the tar should deliver?

  7. usr/src/tools/quick/make-zfs (Diff revision 1)

    is this "better" than just 'cd $SRC/cmd/mdb && $make $1' ? that's what we're doing at delphix, so I'm just curious what the different is..

    1. Again about goals: If you try to build all of mdb, there are a ton more dependencies you need.
      I wanted to build just the mdb modules each make-* script needs to deliver in its tar.
      In this case, I think it's just the ZFS mdb module.
      (Are there more mdb modules this needs to deliver?)

  8. usr/src/tools/quick/make-zfs (Diff revision 1)

    how about adding the directories for zdb, zinject and mdb too?

Review request changed

Status: Closed (submitted)