From owner-freebsd-amd64@FreeBSD.ORG Mon Nov 7 23:14:14 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 A321416A41F; Mon, 7 Nov 2005 23:14:14 +0000 (GMT) (envelope-from dodell@knight.ixsystems.net) Received: from knight.ixsystems.net (knight.ixsystems.net [206.40.55.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB0CF43D48; Mon, 7 Nov 2005 23:13:55 +0000 (GMT) (envelope-from dodell@knight.ixsystems.net) Received: from knight.ixsystems.net (localhost [127.0.0.1]) by knight.ixsystems.net (8.12.10/8.11.6) with ESMTP id jA7NCMwF028678; Mon, 7 Nov 2005 15:12:22 -0800 (PST) (envelope-from dodell@knight.ixsystems.net) Received: (from dodell@localhost) by knight.ixsystems.net (8.12.10/8.12.9/Submit) id jA7NCMuq028677; Mon, 7 Nov 2005 15:12:22 -0800 (PST) (envelope-from dodell) Date: Mon, 7 Nov 2005 15:12:22 -0800 From: "Devon O'Dell" To: John Baldwin Message-ID: <20051107151222.C23692@knight.ixsystems.net> References: <200511072000.jA7K0Whm032639@freefall.freebsd.org> <200511071632.50696.jhb@freebsd.org> <20051107141919.B23692@knight.ixsystems.net> <200511071749.48761.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200511071749.48761.jhb@freebsd.org>; from jhb@freebsd.org on Mon, Nov 07, 2005 at 05:49:47PM -0500 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 23:14:14 -0000 On Mon, Nov 07, 2005 at 05:49:47PM -0500, John Baldwin wrote: > 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. :) Understood :) > > > > 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. OK. I wasn't sure what all would be involved in doing such a thing. Again, in Plan 9, it's a non-issue. You import the devices from a remote location and you can do standard file operations. I guess this might be a much more long-term project and I probably won't be able to address this immediately, but it would indeed be a fun thing to see -- if it's worth the work at all. > > 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. Ok. Hopefully someone who knows more about it can take a closer look then. I know I discussed this with scottl@, but I'm not sure what the plans are with regard to committing it (he said he would, but I don't know how busy he is with his cool amr work) in what timeframe. Doesn't really matter much, but I think it should get a competent review, considering that I'm a VFS newbie (and relatively new with kernel stuff as well, anyway). > > 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. Alright. I will make a point of trying to make more of the code use wrappers around our syscalls, at least for the VFS stuff (since I'm already working around that area anyway). > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org Thanks for the input! --Devon