In message <20001128182015.A1395@rek.tjls.com> Thor Lancelot Simon writes:
: On Tue, Nov 28, 2000 at 04:06:27PM -0700, Warner Losh wrote:
: > 
: > The talk on the FreeBSD side of the world is that these calls should
: > quietly die a quick and sudden death.  They are fore the nfs server
: > only and there are practicle problems with their use.  The problems
: > aren't easily solved.  I'm not sure of all the details, but I thought
: > I'd let the NetBSD community know what some in the FreeBSD community
: > are thinknig.
: 
: Are we talking about the same "these calls"?  I don't know of any "nfs
: server" that uses fhopen() and I know of no practical problems with its
: use.  fhopen() is essentially a hack to allow user processes to bypass the
: namei cache, and it's a huge win for some applications (think of something
: that manages many, many individual files, accessed in patterns that seem
: random to the namei cache; say, an old-style Usenet news server; with
: open-by-filehandle, it can implement its _own_ namei cache and not thrash
: the system one).

I'm just repeating what I heard over there.  The fhopen stuff has been
replaced in FreeBSD with a inode file system that lops off name space
completely for news servers and similar applications.  I was given to
believe they are for things like amd and the like and were press
ganged later into the news applications when ufs fell over under the
weight of USENET.

: If you're talking about linux' setfsuid(), then yes, it's a nasty hack to
: support their nfs server and should die.  In particular, it's not really
: even possible to emulate it safely because it's defined to return 0 even
: if it fails, so you can leave the emulated process thinking it dropped
: root privs when actually it didn't.  Nice, huh?

No, not that one.

: So, what exactly is your notion of "these calls"?

The half open calls.

Warner