From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: mount syscall Date: Thu, 17 Nov 2016 10:47:31 +0100 Message-ID: <87a8cy780c.fsf@gnu.org> References: <87wpg8lpfc.fsf@gnu.org> <20161112152808.GA21994@jocasta.intra> <20161112170948.GA23070@jocasta.intra> <874m3cjoku.fsf@gnu.org> <20161113082110.GA6656@jocasta.intra> <877f87io95.fsf@gnu.org> <20161113140647.GA10548@jocasta.intra> <87h97abdel.fsf@gnu.org> <20161114174628.GA32053@jocasta.intra> <87inrpdnrq.fsf@gnu.org> <20161116210601.GA409@jocasta.intra> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7JIB-0008Dd-S1 for guix-devel@gnu.org; Thu, 17 Nov 2016 04:47:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7JI6-0003Dl-Vi for guix-devel@gnu.org; Thu, 17 Nov 2016 04:47:39 -0500 In-Reply-To: <20161116210601.GA409@jocasta.intra> (John Darrington's message of "Wed, 16 Nov 2016 22:06:01 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: John Darrington Cc: guix-devel@gnu.org John Darrington skribis: > On Tue, Nov 15, 2016 at 11:46:01AM +0100, Ludovic Court??s wrote: > John Darrington skribis: >=20=20=20=20=20=20 > > On Mon, Nov 14, 2016 at 10:48:18AM +0100, Ludovic Court??s wrote: > >=20=20=20=20=20=20 > > The ???mount??? system call; see (gnu build file-systems). > > > > I confess, I have not really thought about this before. But suppos= ing somebody has in their /etc/config.scm: > > > > (file-systems=20 > > (cons* > > (file-system > > (device "my-root") > > (title 'label) > > (mount-point "/") > > (type "ext4")) > > (file-system > > (device "fileserver.example.com:/home") > > (title 'device) > > (mount-point "/home") > > (type "nfs4")) > > %base-file-systems)) > > > > Would the /home filesystem then get mounted on boot? >=20=20=20=20=20=20 > Maybe not. :-) >=20=20=20=20=20=20 > The man page for mount(2) says: >=20=20=20=20=20=20 > --8<---------------cut here---------------start------------->8--- Va= lues > for the filesystemtype argument supported by the kernel are listed in > /proc/filesystems (e.g., "btrfs", "ext4", "jfs", "xfs", "vfat", "fus= e", > "tmpfs", "cgroup", "proc", "mqueue", "nfs", "cifs", "iso9660"). Fur= ther > types may become available when the appropriate modules are loaded. > --8<---------------cut here---------------end--------------->8--- >=20=20=20=20=20=20 > I don???t know what happens with NFS, you???ll have to tell us. > > The answer seems to be that it would fail unless we patch our mount sysca= ll > wrapper with something like: [...] > + (let ((xoptions > + (cond > + ((string-match "^nfs.*" type) > + (let* ((hosts (string-split source #\:)) > + (aa (car (getaddrinfo (car hosts) #= f))) > + (sa (addrinfo:addr aa)) > + (inet-addr (inet-ntop (sockaddr:fam = sa) > + (sockaddr:addr= sa)))) > + (string-append "addr=3D" > + inet-addr > + (if options > + (string-append "," opt= ions) > + "")))) > + (else > + options)))) The =E2=80=98mount=E2=80=99 binding shouldn=E2=80=99t try to be smart and d= o things like this IMO. However, we could have a separate helper procedure to do that, if needed and =E2=80=98file-system-shepherd-service=E2=80=99 would pick the ri= ght one. Now, we should add system tests for that, otherwise it sounds like we=E2=80= =99re adding code that will rarely be used and we=E2=80=99ll never know whether it actually works or how it=E2=80=99s supposed to be used. :-) Thanks, Ludo=E2=80=99.