On Sat, 28 Oct 2000, Jarom=EDr Dolecek wrote:
> Matthew Orgass wrote:
> > > > is still far from optimal.  Far too much code is duplicated and mou=
nt
> > > > still execs mount_foo even if it is the same binary.
>=20
> Well, I don't see (m)any more code which could be shared between
> individual mount_*/mount_*.c files.

  I misremembered the size of the code involved, so you are right that it
is ok the way it is.

  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.

> The overhead of exec(2) call is minimal (even lower now that it
> would execute the same file as the one running) and is IMHO worth
> the flexibility - it's possible to replace individual /sbin/mount_FOO
> with some other binary without surprises. It's not like mount(8)
> is performance-critical tool.

  Why would you want to replace mount_foo?

> I think that admin utilities can just exec mount_FOO(8). IMHO no
> mount_FOO(3) is really needed.

  It isn't really needed, but is cleaner if you want to do anything more
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 an
error message when what you are expecting has been changed.

Matthew Orgass
darkstar@pgh.net