From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 7 22:51:58 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2A0816A422 for ; Mon, 7 Nov 2005 22:51:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDC0343D95 for ; Mon, 7 Nov 2005 22:51:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1544751 for multiple; Mon, 07 Nov 2005 17:53:40 -0500 Received: from localhost.baldwin.cx (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA7MpX4o019534; Mon, 7 Nov 2005 17:51:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Devon O'Dell" Date: Mon, 7 Nov 2005 17:49:47 -0500 User-Agent: KMail/1.8.2 References: <200511072000.jA7K0Whm032639@freefall.freebsd.org> <200511071632.50696.jhb@freebsd.org> <20051107141919.B23692@knight.ixsystems.net> In-Reply-To: <20051107141919.B23692@knight.ixsystems.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511071749.48761.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/88249: getdents syscall fails for devfs on amd64 linuxalator X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2005 22:51:58 -0000 On Monday 07 November 2005 05:19 pm, Devon O'Dell wrote: > On Mon, Nov 07, 2005 at 04:32:49PM -0500, John Baldwin wrote: > > On Monday 07 November 2005 03:00 pm, Devon O'Dell wrote: > > > The long discussion ended up implying several things: > > > > > > d) The issue probably isn't limited to linuxulator, but to any > > > filesystem that uses cookies and exports devfs. Thus, panics (or > > > hangs) will probably occur for devfs being exported over AFS or > > > NFS. > > > > Well, it shouldn't panic, that's for sure. > > It currently does in linuxulator; I'm only assuming it'd do so as well when > trying to export the devfs over another cookie-enabled filesystem, just > from how devfs works when you give it cookies (i.e. not at all). My point there is that some sort of fix should be committed certainly. panics bad. :) > > > The attached patch does two things: > > > > > > a) If we are provided with cookie information in devfs, we currently > > > do not support this. This means we cannot export devfs over network > > > mounts, which I don't view as a problem (but would be a cool > > > feature). > > > > Actually, it would be a worse than useless feature when you consider > > dynamic major number allocation (so that /dev/cuad0 on one machine might > > map to /dev/acd0 on another machine) not to mention the fact that on > > FreeBSD, at least, we don't have specfs anymore, so you can't look > > devices up by just major/minor, but it has to be by their name through an > > instance of devfs. So, only non-FreeBSD clients could even use the > > exported char devs, and FreeBSD char devs are less than useless on > > non-FreeBSD operating systems. > > Ah, ok. I was thinking in a Plan 9-ish sense: being able to export devices > to another system and give the remote system the ability to control those > devices, but I guess I was misinterpreting how that'd work. Yeah, I think that would be a substantially more complex task, but I could be wrong I suppose. phk@ would really be best able to address this. The only way it could work is if the client OS knows to forward requests to exported devices via NFS to the server, in which case I think you'd end up with all sorts of weird edge cases (but that's beside the point). The issues above have to do with when the client OS decides to interpret the block devices natively via specfs rather than forwarding them across via NFS. Given that this might require changes in various clients of arbitrary OSs I'm not sure if it is worth persuing. > Do you think that the attached patch is the correct behavior? I have > another patch that begins work on some of the architectural changes, but it > allows devfs to make use of cookies. I suppose this would imply that you > could then export devfs, but it wouldn't ever work due to the points you > describe above. Any ideas on how to get around or disallow this behavior > altogether? I haven't really gone and read enough vfs code to give the specific patch a competent review. > From the standpoint of how the linuxulator works with the cookies (also > apparently not very well at all), would it be better to do: > > a) Make linux_file.c:getdents_common() be a wrapper around our own > dirent syscall, or > > b) Update linux_file.c: getdents_common() to look more like our syscall? > > It seems to me that it should be possible to do point a; indeed, I don't > understand why most of the linux file syscall translation code > re-implements a lot of the code (almost verbatim) that we have in other > syscalls, when it appears that we could just wrap them. a) would certainly be preferable. As for why there's a lot of duplicated code, it seems that the initial work on compat ABIs used the cut 'n' paste 'n' hack method to implement emulated syscalls rather than wrappers and the use of wrappers is actually a relatively recent change. Thus, there's still a lot of room for more cleanup via more widespread use of wrappers. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org