Date: Sun, 09 Oct 2005 09:48:05 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] Teaching mount(8) to use nmount() Message-ID: <8254.1128844085@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 09 Oct 2005 09:33:44 %2B0200." <20051009073314.GA7463@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20051009073314.GA7463@garage.freebsd.pl>, Pawel Jakub Dawidek write s: >+> >- When it is called with '-t <fs>' switch, we look for >+> > /lib/mount/mount_<fs>.so and try to dlopen() it. >+> >+> No way. >+> >+> Doing that would take much more code than having separate mount >+> binaries because it would add yet another ABI which has to be >+> versioned and managed etc etc. > >So you think there will be more ABI changes to maintain than we have >mount_<fs> binaries at the moment? And where every binary have to >duplicate the same code? The mount_<fs> binaries only use existing system calls. If you start creating mount_foo.so objects, you need to define which function entrypoints and support functions they provide and function entry points and data structures they can rely on in the main mount program. For something as trivial as mount_foo(8) programs that is just pointless complexity because it doesn't buy us any benefit at all, and have several downsides when it comes to reliability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8254.1128844085>