amd64/88249: getdents syscall fails for devfs on amd64 linuxalator

[Devon O'Dell]

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).
 
> >  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.

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?

>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.

Thanks for your input!

> -- 
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org