On Wed, 1 Nov 2000, Jarom=EDr Dolecek wrote:
> Matthew Orgass wrote:
> >   It seems wrong that the combined mount is the largest binary in /sbin=
 or
> > /bin, larger then dhclient and the shells, although this is mostly libc=
's
> > fault.  It would probably be worthwile to put umount in the same binary=
,
> > since it should use the same libc functions.
>=20
> It not so on my i386:

  Oh, right, because the number you gave earlier includes the separate
mount_portal.

> >   Why would you want to replace mount_foo?
>=20
> Testing or whatever - I needed to replace system binaries with a script
> couple of times on some systems (either when debugging something or
> because I needed to force some usage), for example.

  I think this is more of an argument against mount_foo being in the path,
although I guess if they are kept at all then execing would make things
easier in that case.  If all special mount_foo programs were in, say,
/sbin/mount.d then everything would just use mount -t, so there would only
be one thing to replace instead of nineteen.

> >   It isn't really needed, but is cleaner if you want to do anything mor=
e
> > then just pass the result to the user.  With a separate binary you need=
 to
> > interpret the result, while libraries are forced to have public
> > interfaces.  Further, libraries are versioned so you can at least get a=
n
> > error message when what you are expecting has been changed.
>=20
> Yes, though the advantages of library are typically worth the necessary
> efford only when the involved code is used on more than only one place :)

  I personally like to design the major parts of all programs as
libraries, since the extra effort usually results in cleaner code that
more than pays for itself later.  Of course, it does also have a
performance and code size penalty, but I think that also is a price worth
paying.

  Also, if you make it easier to share the code, more people will use it.=
=20
Anything worth doing once is worth doing twice :).

Matthew Orgass
darkstar@pgh.net