Date: Fri, 18 Jan 2002 23:48:31 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Maxime Henrion <mux@sneakerz.org> Cc: freebsd-arch@FreeBSD.ORG, Alexander Kabaev <ak03@gte.com> Subject: Re: Proposal for a new mount API Message-ID: <18157.1011394111@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 18 Jan 2002 16:44:57 CST." <20020118164457.B52542@sneakerz.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me try to clarify how the new mount api is much stronger and completely abolishes the 32 bit thing. If I issue the command: mount -t devfs -o thisopt -o thatopt=3 -o yetanopt=DTRT /home/dev A uiovec will be passed into the kernel which looks like this: uiovec[0] = "thisopt" uiovec[1] = "" uiovec[2] = "thatopt" uiovec[3] = "3" uiovec[4] = "yetanopt" uiovec[5] = "DTRT" uiovec[6] = "vfstype" uiovec[7] = "devfs" uiovec[8] = "mountpoint" uiovec[9] = "/home/dev" As you can see this is extensible in all directions: As long as I stay with ascii options, I don't have to write a "mount_devfs" program, and I can introduce new options and filesystems without rewriting the current mount program. Now, it may be that a particular filesystem needs to pass binary data, a UNIcode table has been mentioned as an example, in that case you can do that, but then you need to write a mount_foofs program to do that. Does that address your concerns ? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18157.1011394111>