[33] in arla-drinkers
Re: fs does not work?
daemon@ATHENA.MIT.EDU (Love)
Tue Jun 23 22:02:17 1998
From arla-drinkers-request@sundance.stacken.kth.se Wed Jun 24 02:02:16 1998
Return-Path: <arla-drinkers-request@sundance.stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 27038 invoked from network); 24 Jun 1998 02:02:15 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 24 Jun 1998 02:02:15 -0000
Received: from elixir.e.kth.se (sendmail@elixir.e.kth.se [130.237.48.5])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id DAA23941;
Wed, 24 Jun 1998 03:57:30 +0200 (MET DST)
Received: from zafir.e.kth.se (zafir.e.kth.se [130.237.48.6])
by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id DAA27223;
Wed, 24 Jun 1998 03:57:30 +0200 (MET DST)
Received: (e96_lho@localhost) by zafir.e.kth.se (8.8.7/8.6.6) id DAA15540; Wed, 24 Jun 1998 03:57:28 +0200 (MET DST)
Sender: e96_lho@elixir.e.kth.se
From: Love <lha@stacken.kth.se>
To: Naomaru Itoi <itoi@eecs.umich.edu>
Cc: Love <lha@stacken.kth.se>, arla-drinkers@stacken.kth.se
Subject: Re: fs does not work?
References: <199806232336.TAA04027@soso.eecs.umich.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: 24 Jun 1998 03:57:28 +0200
In-Reply-To: Naomaru Itoi's message of Tue, 23 Jun 1998 19:36:19 -0400
Message-ID: <yxb2g1gvlfxz.fsf@zafir.e.kth.se>
Lines: 106
X-Mailer: Gnus v5.3/Emacs 19.34
Naomaru Itoi <itoi@eecs.umich.edu> writes:
> I think it is using syscall 210. This is a kernel message on loading
> xfs_mod.o:
>
> : syscall 210
> ^^^^^^^^^^^
Ok, great.
> : xfs_init
>
> But still ...
> % /usr/arla/bin/fs
> Error detecting AFS
Not that great.
But does the syscall ever reach xfs ? Flipp on
all debugging and see if it get there. And if
you can see that it does.
I added the patch and some documentation (that isn't run
thou the local spellchecking map yet)
Love
Index: xfs_deb.c
===================================================================
RCS file: /usr/local/cvsroot/arla/xfs/bsd/xfs_deb.c,v
retrieving revision 1.4
diff -u -w -r1.4 xfs_deb.c
--- xfs_deb.c 1998/03/20 21:01:24 1.4
+++ xfs_deb.c 1998/06/24 01:08:55
@@ -47,13 +47,13 @@
int xfsdeb = (0
|
- x(XDEBDEV) |
- x(XDEBMSG) |
- x(XDEBDNLC) |
- x(XDEBNODE) |
+ X(XDEBDEV) |
+ X(XDEBMSG) |
+ X(XDEBDNLC) |
+ X(XDEBNODE) |
X(XDEBVNOPS) |
- x(XDEBVFOPS) |
- x(XDEBLKM) |
- x(XDEBSYS) |
+ X(XDEBVFOPS) |
+ X(XDEBLKM) |
+ X(XDEBSYS) |
0
);
@node pioctl and kafs, ,The files in arlad/, Parts of Arla
@heading pioctl and kafs
pioctl is a ioctl but with a path instead of a filedescriptor.
When you probe if there is a live afsclient you first run
@code{k_hasafs()} that probe if there is a afsclient around.
It also setup some static variables in the library. So if you
start to do pioctl() w/o running k_hasafs(), you're up to
funny errors.
What k_hasafs() does is AFSCALL_PIOCTL with opcode VIOCSETTOK
and insize == 0, ie you try to set a token (ticket) that is
0 bytes long. This is cleary invalid and kafs expects to find a
EINVAL returned from syscall(2)
The pioctl is used more then just for AFSCALL_PIOCTL, other uses
are AFSCALL_SETPAG (setting pag). It has also been in use for
setting xfs debugginglevels.
When xfs discovers that a path is given in the pioctl()
it does a VOP_LOOKUP on the path and if the returned
a vnode that resides in afs then it extracts the xfs-handle
for that node (that just happens to be the VenusFid) and
passes that on to arlad.
The only ugly thing about the current implentation is that
the syscall code assumes that the arlad on "xfs-fd" is the
arlad that should get this syscall.
An example of pioctl()
@code
int
fs_getfilecellname(char *path, char *cell, size_t len)
{
struct ViceIoctl a_params;
a_params.in_size=0;
a_params.out_size=len;
a_params.in=NULL;
a_params.out=cell;
if (k_pioctl(path,VIOC_FILE_CELL_NAME,&a_params,1) == -1)
return errno;
return 0;
}
