Date: Tue, 16 Mar 2004 14:29:51 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Maxime Henrion <mux@FreeBSD.org> Cc: Tim Robbins <tjr@FreeBSD.org> Subject: Re: cvs commit: src/lib/libc/sys Makefile.inc mount.2 Message-ID: <97436.1079443791@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 16 Mar 2004 11:11:14 %2B0100." <20040316101114.GN35475@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20040316101114.GN35475@elvis.mu.org>, Maxime Henrion writes: >Tim Robbins wrote: >> On Tue, Mar 16, 2004 at 01:45:38AM -0800, Tim J. Robbins wrote: >> >> > tjr 2004/03/16 01:45:38 PST >> > >> > FreeBSD src repository >> > >> > Modified files: >> > lib/libc/sys Makefile.inc mount.2 >> > Log: >> > Add fairly minimal documentation for the nmount() syscall. >> >> BTW, I am not at all happy with the fact that we have two syscalls >> to mount filesystems. One of them needs to go before 5-stable, >> and personally, I don't see the point of keeping nmount(). > >I entirely agree, and I actually feel quite guilty for that. I couldn't >find time to finish nmount and I'm the only one to blame here. I'm not >even particularly happy with how nmount(2) looks right now. I wanted to >remove nmount from the CVS repository, and suggested that to Poul, since >I wrote this code under his guidance some time ago now. He didn't want >me to remove the code so I just left it as is. The mount(2) systemcall is not scalable and we had already run out of magic bits in the arguments and several filesystems had to use weird tricks to bypass these limitations. nmount(2) solves these issues, and if anything, we should get nmount completed an nuke mount(2) before 5-stable. -- 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?97436.1079443791>