From owner-fam@oss.sgi.com Mon May 1 05:22:35 2000 Received: by oss.sgi.com id ; Mon, 1 May 2000 05:22:14 -0700 Received: from rodney.elit.se ([195.100.9.194]:6415 "EHLO rodney.elit.se") by oss.sgi.com with ESMTP id ; Mon, 1 May 2000 05:21:49 -0700 Received: by rodney.elit.se; id OAA15398; Mon, 1 May 2000 14:35:43 +0200 (CEST) Received: from unknown(10.10.10.2) by rodney.elit.se via smap (V5.0) id xma015391; Mon, 1 May 00 14:34:44 +0200 Received: from avenir.se ([10.10.12.254]) by mta.avenir.se (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id 412568D2.0042BF5D; Mon, 1 May 2000 13:09:03 +0100 Message-ID: <390EE150.83C544EF@avenir.se> Date: Tue, 02 May 2000 14:08:16 +0000 From: Ingvaldur Sigurjonsson X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] Patch for Linux 2.2.14 and gcc 2.95.2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi, I wanted to see the new efm so I decided to install the imon-patch to my linux 2.2.14 which was successful. But trying to compile the fam-oss-2.6.2 gave me some problems. I found rasters patch and applied it, but I still had some problems, so I fixed them (I believe ;) so enclosed you'll find the patch. The patch is done from the orignal fam-oss-2.6.2 to fam-oss-2.6.2.ingi which contains rasters patch and then fixes done by me. Hope it helps anyone. Oh and by the way, I've built the kernel with imon both as module and into the kernel, but when I launch fam I get the following error: fam[3811]: can't open /dev/imon: No such file or directory And it's correct that there's no /dev/imon and I cant figure out what major/minor number I should use to create it with mknod. Hints are welcome. regards - Ingi diff -c -r fam-oss-2.6.2/fam/Client.c++ fam-oss-2.6.2.ingi/fam/Client.c++ *** fam-oss-2.6.2/fam/Client.c++ Thu Mar 2 00:51:17 2000 --- fam-oss-2.6.2.ingi/fam/Client.c++ Mon May 1 15:06:21 2000 *************** *** 26,32 **** #include #include ! const in_addr Client::LOCALHOST = { htonl(INADDR_LOOPBACK) }; Client::Client(const char *name, in_addr host) : myname(name ? strcpy(new char[strlen(name) + 1], name) : NULL), --- 26,32 ---- #include #include ! const in_addr Client::LOCALHOST() { htonl(INADDR_LOOPBACK); }; Client::Client(const char *name, in_addr host) : myname(name ? strcpy(new char[strlen(name) + 1], name) : NULL), diff -c -r fam-oss-2.6.2/fam/Client.h fam-oss-2.6.2.ingi/fam/Client.h *** fam-oss-2.6.2/fam/Client.h Thu Mar 2 00:51:21 2000 --- fam-oss-2.6.2.ingi/fam/Client.h Mon May 1 15:07:09 2000 *************** *** 49,55 **** public: ! static const in_addr LOCALHOST; Client(const char *name, in_addr host); virtual ~Client(); --- 49,55 ---- public: ! static const in_addr LOCALHOST(); Client(const char *name, in_addr host); virtual ~Client(); diff -c -r fam-oss-2.6.2/fam/IMonIrix.c++ fam-oss-2.6.2.ingi/fam/IMonIrix.c++ *** fam-oss-2.6.2/fam/IMonIrix.c++ Thu Mar 2 00:51:18 2000 --- fam-oss-2.6.2.ingi/fam/IMonIrix.c++ Mon May 1 15:09:57 2000 *************** *** 35,41 **** #include "IMon.h" const intmask_t INTEREST_MASK = (IMON_CONTENT | IMON_ATTRIBUTE | IMON_DELETE | ! IMON_EXEC | IMON_EXIT | IMON_RENAME); int IMon::imon_open() { --- 35,45 ---- #include "IMon.h" const intmask_t INTEREST_MASK = (IMON_CONTENT | IMON_ATTRIBUTE | IMON_DELETE | ! IMON_EXEC | IMON_EXIT ! #ifdef IMON_RENAME ! | IMON_RENAME ! #endif ! ); int IMon::imon_open() { *************** *** 48,54 **** IMon::Status IMon::imon_express(const char *name, struct stat *status) { ! struct interest interest = { (char *) name, status, INTEREST_MASK }; int rc = ioctl(imonfd, IMONIOC_EXPRESS, &interest); if (rc < 0) { --- 52,63 ---- IMon::Status IMon::imon_express(const char *name, struct stat *status) { ! // The (famstat_t*)status cast should be ok as long as st_dev and ! // st_ino are the first members of struct stat ! // Ingi 2000-04-30 ! struct interest interest = { (char *) name, ! reinterpret_cast(status), ! INTEREST_MASK }; int rc = ioctl(imonfd, IMONIOC_EXPRESS, &interest); if (rc < 0) { *************** *** 84,91 **** if (can_revokdi) { ! struct revokdi revokdi = { dev, ino, INTEREST_MASK }; ! int rc = ioctl(imonfd, IMONIOC_REVOKDI, &revokdi); if (rc < 0) { Log::perror("IMONIOC_REVOKDI on \"%s\" failed", name); revokdi_failed = true; --- 93,107 ---- if (can_revokdi) { ! // There's no struct revokdi defined in imon.h, but there's ! // an 'struct revoke', and along with a IMONIOC define, it should ! // be safe to use that instead (How should I know anyhow, I just ! // want this to compile to see the new efm!!!) ! // Ingi 2000-04-30 ! // struct revokdi revokdi = { dev, ino, INTEREST_MASK }; ! // int rc = ioctl(imonfd, IMONIOC_REVOKDI, &revokdi); ! struct revoke revokdi = { dev, ino, INTEREST_MASK }; ! int rc = ioctl(imonfd, IMONIOC_REVOKE, &revokdi); if (rc < 0) { Log::perror("IMONIOC_REVOKDI on \"%s\" failed", name); revokdi_failed = true; diff -c -r fam-oss-2.6.2/fam/InternalClient.c++ fam-oss-2.6.2.ingi/fam/InternalClient.c++ *** fam-oss-2.6.2/fam/InternalClient.c++ Thu Mar 2 00:51:19 2000 --- fam-oss-2.6.2.ingi/fam/InternalClient.c++ Mon May 1 15:07:20 2000 *************** *** 31,37 **** InternalClient::InternalClient(const char *filename, EventHandler h, void *closr) ! : Client("myself", LOCALHOST), handler(h), closure(closr) { assert(filename); assert(h); --- 31,37 ---- InternalClient::InternalClient(const char *filename, EventHandler h, void *closr) ! : Client("myself", LOCALHOST()), handler(h), closure(closr) { assert(filename); assert(h); diff -c -r fam-oss-2.6.2/fam/Listener.c++ fam-oss-2.6.2.ingi/fam/Listener.c++ *** fam-oss-2.6.2/fam/Listener.c++ Thu Mar 2 00:51:19 2000 --- fam-oss-2.6.2.ingi/fam/Listener.c++ Mon May 1 15:08:37 2000 *************** *** 153,159 **** // Get the new socket. struct sockaddr_in addr; ! int addrlen = sizeof addr; int client_fd = accept(rendezvous_fd, (struct sockaddr *) &addr, &addrlen); if (client_fd < 0) { --- 153,159 ---- // Get the new socket. struct sockaddr_in addr; ! socklen_t addrlen = sizeof addr; int client_fd = accept(rendezvous_fd, (struct sockaddr *) &addr, &addrlen); if (client_fd < 0) { *************** *** 272,278 **** // Get the new socket. struct sockaddr_un sun = { AF_UNIX, "" }; ! int sunlen = sizeof(sun); int client_fd = accept(ofd, (struct sockaddr *) &sun, &sunlen); if (client_fd < 0) { --- 272,278 ---- // Get the new socket. struct sockaddr_un sun = { AF_UNIX, "" }; ! socklen_t sunlen = sizeof(sun); int client_fd = accept(ofd, (struct sockaddr *) &sun, &sunlen); if (client_fd < 0) { *************** *** 400,406 **** // Accept a new ugly connection. struct sockaddr_un sun; ! int sunlen = sizeof sun; int sock = accept(ugly, (struct sockaddr *)(&sun), &sunlen); if (sock < 0) { Log::perror("accept"); --- 400,406 ---- // Accept a new ugly connection. struct sockaddr_un sun; ! socklen_t sunlen = sizeof sun; int sock = accept(ugly, (struct sockaddr *)(&sun), &sunlen); if (sock < 0) { Log::perror("accept"); diff -c -r fam-oss-2.6.2/fam/LocalClient.c++ fam-oss-2.6.2.ingi/fam/LocalClient.c++ *** fam-oss-2.6.2/fam/LocalClient.c++ Thu Mar 2 00:51:19 2000 --- fam-oss-2.6.2.ingi/fam/LocalClient.c++ Mon May 1 15:07:26 2000 *************** *** 29,35 **** #include "Cred.h" LocalClient::LocalClient(int fd, const struct sockaddr_un *addr, Cred &cred) ! : TCP_Client(LOCALHOST, fd, cred) { assert(cred.is_valid()); sun.sun_family = AF_UNIX; --- 29,35 ---- #include "Cred.h" LocalClient::LocalClient(int fd, const struct sockaddr_un *addr, Cred &cred) ! : TCP_Client(LOCALHOST(), fd, cred) { assert(cred.is_valid()); sun.sun_family = AF_UNIX; diff -c -r fam-oss-2.6.2/fam/NFSFileSystem.c++ fam-oss-2.6.2.ingi/fam/NFSFileSystem.c++ *** fam-oss-2.6.2/fam/NFSFileSystem.c++ Thu Mar 2 00:51:19 2000 --- fam-oss-2.6.2.ingi/fam/NFSFileSystem.c++ Mon May 1 15:09:12 2000 *************** *** 26,31 **** --- 26,32 ---- #include #include #include + #include /* for sscanf(...) */ #include #include "Log.h" diff -c -r fam-oss-2.6.2/fam/Scheduler.c++ fam-oss-2.6.2.ingi/fam/Scheduler.c++ *** fam-oss-2.6.2/fam/Scheduler.c++ Thu Mar 2 00:51:20 2000 --- fam-oss-2.6.2.ingi/fam/Scheduler.c++ Mon May 1 15:02:29 2000 *************** *** 232,238 **** Scheduler::trim_fdinfo() { for (FDInfo *fp = &fdinfo[nfds - 1]; nfds > 0; --nfds, --fp) ! if (fp->read.handler || fp->write.handler) break; if (!nfds) --- 232,238 ---- Scheduler::trim_fdinfo() { for (FDInfo *fp = &fdinfo[nfds - 1]; nfds > 0; --nfds, --fp) ! if (fp->read.iohandler || fp->write.iohandler) break; if (!nfds) *************** *** 249,256 **** assert(fd >= 0); assert(handler); FDInfo *fp = fd_to_info(fd); ! IOHandler old_handler = (fp->*(iotype->iotype)).handler; ! (fp->*(iotype->iotype)).handler = handler; (fp->*(iotype->iotype)).closure = closure; assert(!old_handler || FD_ISSET(fd, &iotype->fds)); if (!FD_ISSET(fd, &iotype->fds)) --- 249,256 ---- assert(fd >= 0); assert(handler); FDInfo *fp = fd_to_info(fd); ! IOHandler old_handler = (fp->*(iotype->iotype)).iohandler; ! (fp->*(iotype->iotype)).iohandler = handler; (fp->*(iotype->iotype)).closure = closure; assert(!old_handler || FD_ISSET(fd, &iotype->fds)); if (!FD_ISSET(fd, &iotype->fds)) *************** *** 266,273 **** { assert(fd >= 0 && fd < nfds); FDInfo *fp = fd_to_info(fd); ! IOHandler old_handler = (fp->*(iotype->iotype)).handler; ! (fp->*(iotype->iotype)).handler = NULL; (fp->*(iotype->iotype)).closure = NULL; trim_fdinfo(); assert(old_handler); --- 266,273 ---- { assert(fd >= 0 && fd < nfds); FDInfo *fp = fd_to_info(fd); ! IOHandler old_handler = (fp->*(iotype->iotype)).iohandler; ! (fp->*(iotype->iotype)).iohandler = NULL; (fp->*(iotype->iotype)).closure = NULL; trim_fdinfo(); assert(old_handler); *************** *** 311,317 **** if (FD_ISSET(fd, fds)) { FDInfo *fp = &fdinfo[fd]; assert(iotype == &FDInfo::read || iotype == &FDInfo::write); ! (fp->*iotype).handler(fd, (fp->*iotype).closure); // Remember, handler may move fdinfo array. } } --- 311,317 ---- if (FD_ISSET(fd, fds)) { FDInfo *fp = &fdinfo[fd]; assert(iotype == &FDInfo::read || iotype == &FDInfo::write); ! (fp->*iotype).iohandler(fd, (fp->*iotype).closure); // Remember, handler may move fdinfo array. } } diff -c -r fam-oss-2.6.2/fam/Scheduler.h fam-oss-2.6.2.ingi/fam/Scheduler.h *** fam-oss-2.6.2/fam/Scheduler.h Thu Mar 2 00:51:24 2000 --- fam-oss-2.6.2.ingi/fam/Scheduler.h Mon May 1 15:03:37 2000 *************** *** 91,100 **** // Per-filedescriptor info is the set of three handlers and their // closures. - struct FDInfo { struct handler { ! IOHandler handler; void *closure; } read, write; }; --- 91,99 ---- // Per-filedescriptor info is the set of three handlers and their // closures. struct FDInfo { struct handler { ! IOHandler iohandler; void *closure; } read, write; }; -- --------------------------------------------------------- Ingvaldur Ŝ. Sigurjónsson Avenir AB ingi@avenir.se -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 1 13:34:59 2000 Received: by oss.sgi.com id ; Mon, 1 May 2000 13:34:49 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62591 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 1 May 2000 13:34:31 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA27566 for ; Mon, 1 May 2000 13:29:43 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id NAA47304; Mon, 1 May 2000 13:32:25 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005011332.ZM153149@rlyeh.engr.sgi.com> Date: Mon, 1 May 2000 13:32:24 -0700 In-Reply-To: Ingvaldur Sigurjonsson "[fam] Patch for Linux 2.2.14 and gcc 2.95.2" (May 2, 2:08pm) References: <390EE150.83C544EF@avenir.se> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: ingi@avenir.se Subject: Re: [fam] Patch for Linux 2.2.14 and gcc 2.95.2 Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Oh and by the way, I've built the kernel with imon both as module and > into the kernel, but when I launch fam I get the following error: > > fam[3811]: can't open /dev/imon: No such file or directory > > And it's correct that there's no /dev/imon and I cant figure out what > major/minor number I should use to create it with mknod. Does it work OK when you configure imon as a module? I'd be surprised if it works when it's *not* a module, as I'm not sure the initialization code is right. (On the other hand, if it does work once you have /dev/imon created, that would be good to know.) The other reason I'm not sure about imon built into the kernel is that when fam starts up, it looks for the major number in /proc/devices, and attempts to load the imon module if it's not there. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 2 06:53:41 2000 Received: by oss.sgi.com id ; Tue, 2 May 2000 06:53:31 -0700 Received: from tikki.ColoradoCollege.edu ([205.170.0.3]:50960 "EHLO tikki.ColoradoCollege.edu") by oss.sgi.com with ESMTP id ; Tue, 2 May 2000 06:53:05 -0700 Received: from conversion.ColoradoCollege.edu by ColoradoCollege.edu (PMDF V5.2-31 #41781) id <01JOX0YBRB4W98HZO9@ColoradoCollege.edu> for fam@oss.sgi.com; Tue, 2 May 2000 07:52:55 MST Received: from exchange2.ColoradoCollege.edu (exchange2web.ColoradoCollege.edu [205.170.0.14]) by ColoradoCollege.edu (PMDF V5.2-31 #41781) with ESMTP id <01JOX0XYD9NU98HTK8@ColoradoCollege.edu> for fam@oss.sgi.com; Tue, 02 May 2000 07:52:28 -0700 (MST) Received: from ngoodnight (ngoodnight.student.ColoradoCollege.edu [205.170.10.10]) by exchange2.ColoradoCollege.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id H1BNK1QJ; Tue, 02 May 2000 07:52:27 -0600 Date: Tue, 02 May 2000 07:54:36 -0600 (MDT) From: Nolan Goodnight Subject: [fam] issue compiling fam - errors To: fam@oss.sgi.com Reply-to: Nolan Goodnight Message-id: <01JOX0XYEMN098HTK8@ColoradoCollege.edu> MIME-version: 1.0 X-Mailer: CSCMail v1.6 pre1 Content-type: text/plain Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing I get this error when I try to compile fam-2.6.0 - I assume it might be a problem with my compiler but I would like to hear some feedback, Thanks. Scheduler.h:97: ANSI C++ forbids data member `handler' with same name as enclosing class make[2]: *** [Activity.o] Error 1 Nolan Goodnight -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 2 10:50:02 2000 Received: by oss.sgi.com id ; Tue, 2 May 2000 10:49:52 -0700 Received: from behemoth.vergenet.net ([198.186.202.43]:55561 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 2 May 2000 10:49:30 -0700 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id KAA11464; Tue, 2 May 2000 10:52:26 -0700 Message-Id: <200005021752.KAA11464@behemoth.su.varesearch.com> Date: Tue, 2 May 2000 10:52:26 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] issue compiling fam - errors To: n_goodnight@ColoradoCollege.edu cc: fam@oss.sgi.com In-Reply-To: <01JOX0XYEMN098HTK8@ColoradoCollege.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 2 May, Nolan Goodnight scribbled: -> I get this error when I try to compile fam-2.6.0 - I assume it might be a -> problem with my compiler but I would like to hear some feedback, Thanks. -> -> Scheduler.h:97: ANSI C++ forbids data member `handler' with same name as -> enclosing class -> make[2]: *** [Activity.o] Error 1 make CXXFLAGS="" :) -> Nolan Goodnight -> -> -- -> Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ -> To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 3 00:56:29 2000 Received: by oss.sgi.com id ; Wed, 3 May 2000 00:56:19 -0700 Received: from SMTP-OUT001.ONEMAIN.COM ([63.208.208.71]:32928 "HELO mail006.mail.onemain.com") by oss.sgi.com with SMTP id ; Wed, 3 May 2000 00:56:00 -0700 Received: (qmail 20407 invoked from network); 3 May 2000 07:55:48 -0000 Received: from unknown (HELO jps.net) ([208.237.196.134]) (envelope-sender ) by mail006.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 3 May 2000 07:55:48 -0000 Message-ID: <390FDAFC.6CD1D1A1@jps.net> Date: Wed, 03 May 2000 00:53:33 -0700 From: Megas of Vecanti Organization: Creative Truth Services X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] fam-oss 2.6.2 compile error(No, not CXXFLAGS) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Under g++ (egcs-2.91.66) in Linux, without an Imon kernel patch and with CXXFLAGS set to null prior to configure, fam-oss 2.6.2's build cuts off with this compile error: IMonNone.c++: In function `static int IMon::imon_open()': IMonNone.c++:27: `Log' undeclared (first use this function) IMonNone.c++:27: (Each undeclared identifier is reported only once IMonNone.c++:27: for each function it appears in.) IMonNone.c++:27: parse error before `::' make[2]: *** [IMonNone.o] Error 1 (etc.) Thanks, I eagerly await the next build... - D. Caswell / Megas of Vecanti - emegas@jps.net - ICQ 19943038 - Ring Leader, Creative Truth Services: "You Figure It Out" (Since 1996) "This calls for a very special blend of psychology and extreme violence." -Vyvyan, "The Young Ones" -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 3 01:02:59 2000 Received: by oss.sgi.com id ; Wed, 3 May 2000 01:02:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16918 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 3 May 2000 01:02:41 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id BAA09087 for ; Wed, 3 May 2000 01:06:56 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id BAA63853; Wed, 3 May 2000 01:00:36 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005030100.ZM161925@rlyeh.engr.sgi.com> Date: Wed, 3 May 2000 01:00:35 -0700 In-Reply-To: Megas of Vecanti "[fam] fam-oss 2.6.2 compile error(No, not CXXFLAGS)" (May 3, 12:53am) References: <390FDAFC.6CD1D1A1@jps.net> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Megas of Vecanti Subject: Re: [fam] fam-oss 2.6.2 compile error(No, not CXXFLAGS) Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Under g++ (egcs-2.91.66) in Linux, without an Imon kernel patch and with > CXXFLAGS set to null prior to configure, fam-oss 2.6.2's build cuts off > with this compile error: Yeah, I stupidly broke that in the last version. You can add #include "Log.h" to fam/IMonNone.c++, or wait a few minutes for 2.6.3. (No no, I really mean it this time.) (Are you suuure you don't want imon?) --Rusty P.S. OK, "a few minutes" might have been a bit optimistic. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 3 02:37:10 2000 Received: by oss.sgi.com id ; Wed, 3 May 2000 02:36:50 -0700 Received: from SMTP-OUT001.ONEMAIN.COM ([63.208.208.71]:47520 "HELO mail003.mail.onemain.com") by oss.sgi.com with SMTP id ; Wed, 3 May 2000 02:36:22 -0700 Received: (qmail 12048 invoked from network); 3 May 2000 09:36:05 -0000 Received: from unknown (HELO jps.net) ([208.237.196.134]) (envelope-sender ) by mail003.mail.onemain.com (qmail-ldap-1.03) with SMTP for ; 3 May 2000 09:36:05 -0000 Message-ID: <390FF27E.BB4A7522@jps.net> Date: Wed, 03 May 2000 02:33:50 -0700 From: Megas of Vecanti Organization: Creative Truth Services X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: rusty@sgi.com CC: fam@oss.sgi.com Subject: Re: [fam] fam-oss 2.6.2 compile error(No, not CXXFLAGS) References: <390FDAFC.6CD1D1A1@jps.net> <10005030100.ZM161925@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Yeah, I stupidly broke that in the last version. You can add #include > "Log.h" to fam/IMonNone.c++, or wait a few minutes for 2.6.3. (No no, I > really mean it this time.) Nice, easier fix than I thought...It builds now, no visible problems. Thanks. > (Are you suuure you don't want imon?) Heheheh...Not quite yet. Don't worry, I've seen what imon can do on IRIX(The 3D school I go to runs Maya mostly off O2s and Origins). There's little chance I won't at least try the patch. =) > P.S. OK, "a few minutes" might have been a bit optimistic. Maybe you can get fam CVS hosting? That way everytime you have an almost-but-not-quite release you could point to the commits on the latest tree. (It works for the GIMP team. =) j/k) - D. Caswell / Megas of Vecanti - emegas@jps.net - ICQ 19943038 - Ring Leader, Creative Truth Services: "You Figure It Out" (Since 1996) "This calls for a very special blend of psychology and extreme violence." -Vyvyan, "The Young Ones" -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 3 06:28:05 2000 Received: by oss.sgi.com id ; Wed, 3 May 2000 06:27:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26642 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 3 May 2000 06:27:24 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA03026 for ; Wed, 3 May 2000 06:22:36 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id GAA18184 for ; Wed, 3 May 2000 06:25:38 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id GAA81886 for fam@oss.sgi.com; Wed, 3 May 2000 06:22:48 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005030622.ZM176787@rlyeh.engr.sgi.com> Date: Wed, 3 May 2000 06:22:47 -0700 X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fam@oss.sgi.com Subject: [fam] fam-oss-2.6.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.110005030622.ZM176787.engr.sgi.com" Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing --PART-BOUNDARY=.110005030622.ZM176787.engr.sgi.com Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u Yes, only thr^H^H^Hfour weeks after I said I would do it, fam-oss-2.6.3 i= s out. (http://oss.sgi.com/projects/fam/) This incorporates the patches that everyone's been sending for the last f= ew weeks, but see the caveats below. (Also, I don't actually have gcc-2.95.= 2 working on my machine yet, and it's quite possible that I goofed up mergi= ng some of the patches, so let me know if you have any problems. I did cons= ider pasting the source into http://www.codesourcery.com/gcc-compile.html...) Also, I added a rpm target, so you can go "./configure && make rpm", and = it will put RPM packages in build/rpm. If you have other package formats yo= u like, let me know, and I will be happy to add them. (I believe I have a = moral obligation to add SGI IRIX inst format next.) RPM gave me a lot of grief= , but I'm pretty happy that it's working now, & that you don't have to be root = to build an RPM. (oh yeah, so there are RPMs in the download area too.) What I didn't add: - Sumit Bose included snprintf for platforms which don't have it, but the= qpopper licensing terms made me nervous. I thought it would be easier = to paste snprintf etc. from glibc than to get permission from Qualcomm to include theirs, and it may still turn out to be easy, but I haven't don= e it yet. ("If at first you don't succeed... hey, are you guys going to dinner?") There were a couple of other things in Sumit's patch which I= haven't incorporated yet, which means it still won't build on IRIX 5.3 unless you grab parts of Sumit's patch again. (Sorry about that...) - Ingvaldur Sigurj=F3nsson's patch had some changes to IMonIrix.c++, but instead I made the configure script smarter about not building that on Linux. :) Let me know if it fails in any way to surpass your wildest expectations. --Rusty --PART-BOUNDARY=.110005030622.ZM176787.engr.sgi.com-- -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sat May 6 23:02:41 2000 Received: by oss.sgi.com id ; Sat, 6 May 2000 23:02:32 -0700 Received: from svn.net ([167.160.200.10]:44297 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Sat, 6 May 2000 23:02:13 -0700 Received: from wantelbos (bastian@pm3-152.svn.net [167.160.201.152]) by svn.net (8.10.0/8.10.0) with SMTP id e4764PN29684; Sat, 6 May 2000 23:04:25 -0700 From: Waldo Bastian To: rusty@sgi.com Subject: Re: [fam] fam-oss-2.6.3 Date: Sat, 6 May 2000 23:03:56 -0700 Content-Type: text/plain References: <10005030622.ZM176787@rlyeh.engr.sgi.com> In-Reply-To: <10005030622.ZM176787@rlyeh.engr.sgi.com> Cc: fam@oss.sgi.com MIME-Version: 1.0 Message-Id: <00050623035601.01557@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Wed, 03 May 2000, you wrote: > > Yes, only thr^H^H^Hfour weeks after I said I would do it, fam-oss-2.6.3 is > out. (http://oss.sgi.com/projects/fam/) Hiya, Just wanted to let you know that I have imon & fam-oss-2.6.3 succesfully running on a Linux 2.2.14 kernel compiled with gcc 2.95.2. I compiled it directly into the kernel (not as a module). Current development versions of KDE use FAM automagically when available. Advice to others: It was a bit of a pain to get imon in my linux kernel. Make sure you turn it on with "make config" or "make menuconfig". You also want to run "make depend" after applying the patch because otherwise make will fail to rebuild some files after changing the configuration. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 11 00:54:42 2000 Received: by oss.sgi.com id ; Thu, 11 May 2000 07:54:32 +0000 Received: from concorde.inria.fr ([192.93.2.39]:48343 "EHLO concorde.inria.fr") by oss.sgi.com with ESMTP id ; Thu, 11 May 2000 07:54:23 +0000 Received: from margaux.inria.fr (margaux.inria.fr [128.93.8.2]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA23166 for ; Thu, 11 May 2000 09:53:19 +0200 (MET DST) Received: from alan-schm1p (alan-schm1p.inria.fr [128.93.20.79]) by margaux.inria.fr (8.7.6/8.7.3) with SMTP id JAA00152 for ; Thu, 11 May 2000 09:53:19 +0200 (MET DST) Received: by alan-schm1p (sSMTP sendmail emulation); Thu, 11 May 2000 07:52:10 +0200 From: Alan Schmitt Date: Thu, 11 May 2000 07:52:10 +0200 To: fam@oss.sgi.com Subject: [fam] Log::fatal missing when compiling fam without imon support Message-ID: <20000511075210.A11074@r112m239.cybercable.tm.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Organization: INRIA Rocquencourt Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi, In the file "fam/IMon.c++", if there is no support for imon, then compilation fails because Log::fatal is not defined. I changed it to Log::critical, but I would like to know if this is the correct fix. Thanks a lot, Alan Schmitt -- The hacker: someone who figured things out and made something cool happen. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 11 11:01:00 2000 Received: by oss.sgi.com id ; Thu, 11 May 2000 18:00:50 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43018 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 11 May 2000 18:00:31 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09647 for ; Thu, 11 May 2000 11:04:56 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id KAA31430; Thu, 11 May 2000 10:58:24 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005111058.ZM32154@rlyeh.engr.sgi.com> Date: Thu, 11 May 2000 10:58:24 -0700 In-Reply-To: Alan Schmitt "[fam] Log::fatal missing when compiling fam without imon support" (May 11, 7:52am) References: <20000511075210.A11074@r112m239.cybercable.tm.fr> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: alan.schmitt@inria.fr Subject: Re: [fam] Log::fatal missing when compiling fam without imon support Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > In the file "fam/IMon.c++", if there is no support for imon, then > compilation fails because Log::fatal is not defined. > I changed it to Log::critical, but I would like to know if this is the > correct fix. Yes, that's correct. In every release, I try to include at least one totally boneheaded change that doesn't compile on someone's machine. So far I've been pretty successful. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 11 12:14:42 2000 Received: by oss.sgi.com id ; Thu, 11 May 2000 19:14:32 +0000 Received: from svn.net ([216.174.228.10]:18705 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Thu, 11 May 2000 19:14:17 +0000 Received: from wantelbos (pm3-113.svn.net [167.160.201.113]) by svn.net (8.10.0/8.10.0) with SMTP id e4BILQG03768 for ; Thu, 11 May 2000 11:21:31 -0700 From: Waldo Bastian To: fam@oss.sgi.com Subject: [fam] Class names Date: Thu, 11 May 2000 11:20:20 -0700 Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00051111202002.21991@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hiya, I encountered some problems when linking KDE programs with FAM. The problem is caused by libfam containing "Client" as class. This collides with programs which define such a class as well. (For completely different purposes). I suggest to wrap everything up in a "FAM" namespace or to at least to prefix the classname with FAM. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 11 17:31:04 2000 Received: by oss.sgi.com id ; Fri, 12 May 2000 00:30:54 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37936 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 12 May 2000 00:30:40 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09992 for ; Thu, 11 May 2000 17:35:05 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id RAA35084; Thu, 11 May 2000 17:28:38 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005111728.ZM35420@rlyeh.engr.sgi.com> Date: Thu, 11 May 2000 17:28:37 -0700 In-Reply-To: Waldo Bastian "[fam] Class names" (May 11, 11:20am) References: <00051111202002.21991@wantelbos> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: bastian@suse.com Subject: Re: [fam] Class names Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I encountered some problems when linking KDE programs with FAM. The problem > is caused by libfam containing "Client" as class. This collides with > programs which define such a class as well. I just tried a little test program containing its own Client class (including some of the same methods as the Client class in libfam), and was able to link it with libfam; then I tried moving the client class into a separate shared library and linking with that, so the program was linking with two different libraries containing classes called Client, and it all linked & ran OK on both Linux & IRIX. (On IRIX I got warnings about the multiple definitions, though.) I can send you the little test if you want to see whether it works on your machine, but you're right that it should be fixed. libfam should export only the symbols listed in fam.h. I know how to do this with SGI compilers; does anyone know how to do it with g++/GNU ld? --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 11 21:46:19 2000 Received: by oss.sgi.com id ; Fri, 12 May 2000 04:46:10 +0000 Received: from f312.law8.hotmail.com ([216.33.240.187]:4625 "HELO hotmail.com") by oss.sgi.com with SMTP id ; Fri, 12 May 2000 04:45:41 +0000 Received: (qmail 74415 invoked by uid 0); 12 May 2000 04:45:36 -0000 Message-ID: <20000512044536.74414.qmail@hotmail.com> Received: from 137.189.4.8 by www.hotmail.com with HTTP; Thu, 11 May 2000 21:45:36 PDT X-Originating-IP: [137.189.4.8] From: "chi li" To: fam@oss.sgi.com Subject: [fam] please help Date: Fri, 12 May 2000 12:45:36 CST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing hello i don't know how to patch my kernel with the imon-1.2.2.13, i always can't not patch all files you wrote in imon.txt. how come? what should i type for patch? and need to recompile my kernel? thank you for your kind attention! alanli ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 12 00:42:10 2000 Received: by oss.sgi.com id ; Fri, 12 May 2000 07:41:50 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39749 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 12 May 2000 07:41:28 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA05822 for ; Fri, 12 May 2000 00:45:53 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id AAA36114; Fri, 12 May 2000 00:39:26 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005120039.ZM36010@rlyeh.engr.sgi.com> Date: Fri, 12 May 2000 00:39:26 -0700 In-Reply-To: "chi li" "[fam] please help" (May 12, 12:45pm) References: <20000512044536.74414.qmail@hotmail.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: alanli888@hotmail.com Subject: Re: [fam] please help Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > i don't know how to patch my kernel with the imon-1.2.2.13, i always > can't not patch all files you wrote in imon.txt. how come? what should i > type for patch? and need to recompile my kernel? 1) Make sure you're applying the right patch for your kernel version. imon-0.0.1-2.2.13 should work on a 2.2.13 or 2.2.14 kernel. If you don't have kernel source, start at http://www.kernel.org/mirrors/ 2) To apply the patch, follow the instructions at the top of the patch :) If you've saved the patch as ~/imon-0.0.1-2.2.13, then cd to the root of your kernel source tree, and type "patch -p 1 < ~/imon-0.0.1-2.2.13" You should see output like the following: patching file `Documentation/Configure.help' patching file `Documentation/imon.txt' patching file `fs/Config.in' patching file `fs/Makefile' patching file `fs/attr.c' patching file `fs/exec.c' ... 3) To recompile your kernel, see the instructions in the README file included with the kernel source. Also the linux kernel HOWTO is available from many sites listed at http://www.linuxdoc.org/mirrors.html If you haven't compiled a working kernel, you might work on that first, before applying the imon patch, just to make sure you've got it going OK without imon. Once you're building kernels that you can boot from, then try applying the patch, reconfigure with imon enabled, recompile, etc. --Rusty P.S. I forgot step 0: find a friend who's done this before, buy them the beverage of their choice, and watch them do steps 1-3. Lower risk of repetitive stress injury that way. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 12 02:05:00 2000 Received: by oss.sgi.com id ; Fri, 12 May 2000 09:04:51 +0000 Received: from 68.ppp1-20.worldonline.dk ([212.54.79.196]:37359 "EHLO mage.dk") by oss.sgi.com with ESMTP id ; Fri, 12 May 2000 09:04:28 +0000 Received: (from loststar@localhost) by LAA00493mage.dk (8.9.3/8.9.3) id LAA00493; Fri, 12 May 2000 11:04:17 +0200 Date: Fri, 12 May 2000 11:04:17 +0200 From: Morten Brix Pedersen To: rusty@sgi.com Cc: fam@oss.sgi.com Subject: Re: [fam] please help Message-ID: <20000512110417.A30724@kolon.worldonline.dk> References: <20000512044536.74414.qmail@hotmail.com> <10005120039.ZM36010@rlyeh.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <10005120039.ZM36010@rlyeh.engr.sgi.com>; from rusty@rlyeh.engr.sgi.com on Fri, May 12, 2000 at 12:39:26 -0700 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Fri, May 12, 2000 at 12:39:26 -0700, Rusty Ballinger wrote: > > i don't know how to patch my kernel with the imon-1.2.2.13, i always > > can't not patch all files you wrote in imon.txt. how come? what should i > > type for patch? and need to recompile my kernel? > > 1) Make sure you're applying the right patch for your kernel version. > imon-0.0.1-2.2.13 should work on a 2.2.13 or 2.2.14 kernel. If you > don't have kernel source, start at http://www.kernel.org/mirrors/ Just a quick note, it works on 2.2.15 as well. Morten. -- http://loststar.wiktor.dk/ "The nice thing about Windows is - It does not just crash, it displays a dialog box and lets you press 'OK' first." - Arno Schaefer -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 12 17:06:26 2000 Received: by oss.sgi.com id ; Sat, 13 May 2000 00:06:16 +0000 Received: from svn.net ([167.160.200.10]:20998 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Sat, 13 May 2000 00:05:52 +0000 Received: from wantelbos (pm3-120.svn.net [167.160.201.120]) by svn.net (8.10.0/8.10.0) with SMTP id e4D05pG19300; Fri, 12 May 2000 17:05:52 -0700 From: Waldo Bastian To: rusty@sgi.com Subject: Re: [fam] Class names Date: Fri, 12 May 2000 17:08:02 -0700 Content-Type: text/plain References: <00051111202002.21991@wantelbos> <10005111728.ZM35420@rlyeh.engr.sgi.com> In-Reply-To: <10005111728.ZM35420@rlyeh.engr.sgi.com> Cc: fam@oss.sgi.com MIME-Version: 1.0 Message-Id: <0005121708020C.17904@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Thu, 11 May 2000, you wrote: > > I encountered some problems when linking KDE programs with FAM. The > > problem is caused by libfam containing "Client" as class. This collides > > with programs which define such a class as well. > > I just tried a little test program containing its own Client class > (including some of the same methods as the Client class in libfam), and > was able to link it with libfam; then I tried moving the client class into > a separate shared library and linking with that, so the program was linking > with two different libraries containing classes called Client, and it all > linked & ran OK on both Linux & IRIX. (On IRIX I got warnings about the > multiple definitions, though.) I encountered problems in a KDE application which dlopened a library which used Client as well. The problem was that the wrong destructor got called. A very nasty error since it took me some time to realize what was going on. It was remarkable that if I didn't dlopen the library but linked it directly into the application, the problem didn't occur. > I can send you the little test if you want > to see whether it works on your machine, but you're right that it should be > fixed. > > libfam should export only the symbols listed in fam.h. I know how to do > this with SGI compilers; does anyone know how to do it with g++/GNU ld? I suggest you use libtool's -export-symbols option. It should take care of any platform-dependencies. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 14 12:11:59 2000 Received: by oss.sgi.com id ; Sun, 14 May 2000 19:11:49 +0000 Received: from pat.genie.syncordia.net ([193.113.200.222]:57785 "HELO pat.genie.syncordia.net") by oss.sgi.com with SMTP id ; Sun, 14 May 2000 19:11:43 +0000 Received: from u.genie.co.uk (193.113.116.219) by pat.genie.syncordia.net; 14 May 2000 20:11:35 +0100 Message-ID: <391EE790.CEAA0019@u.genie.co.uk> Date: Sun, 14 May 2000 18:51:12 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.15 i586) X-Accept-Language: en MIME-Version: 1.0 To: fam Subject: [fam] No /dev/imon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing I have just compiled and installed imon-0.0.1-2.2.13, fam-oss-2.6.3 on version 2.2.15 of the Linux kernel. The compilations all worked fine with no errors. When I boot with the new kernel, I get a message saying 'imon (inode monitor) $Revision: $' which all looks fine but once the system is up and running, /dev/imon doesn't seem to exist. It does on my IRIX 5.3 system so I guess it should be visible. Do I need to do something to create it or has something gone wrong? I'd be grateful for any pointers on how to work out why it isn't there. My tests indicate that fam is working but of course it may be polling. Would it make sense to use fam in programs which are just interested in monitoring single files such as a text editor monitoring the file it has open or are the overheads such that it is only worth using if a whole directory structure is going to be monitored? Oliver Kiddle -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 14 12:23:30 2000 Received: by oss.sgi.com id ; Sun, 14 May 2000 19:23:20 +0000 Received: from behemoth.vergenet.net ([198.186.202.43]:40972 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Sun, 14 May 2000 19:23:16 +0000 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id MAA22913 for fam@oss.sgi.com; Sun, 14 May 2000 12:27:38 -0700 Message-Id: <200005141927.MAA22913@behemoth.su.varesearch.com> Date: Sun, 14 May 2000 12:27:38 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: [fam] monitoring for executing....... how about........ To: fam@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing ok - fam can tell me when somehting starts executing.. great.. :) BUT somehting i think that's missing thats almost essential - monitoring for read/write the problem: I'm writign a file manager (efm) - when files get "changed" i need to re-evaluate them - that means if the mime type is image/* re-generate a thumbnail... and that means openig file, read, generate thumb, write, display. the problem is the change event comes in whilste the file is still being written it isnt finished yet - and theres no way to know if someone is activel ywritign to the file- yes - i suppose i could use fuser and check if tis opened - but it may beopened for read onyl- or the writes maye be finsihed but the file nto close (maybe a log file of some sort) so beig able tohave events like: file written at byte 16384 size 4096 file read at byte 300 size 256 etc. woudl be greta - then at ;eats i could pause the thumbnail generation until writes have stopped (ie no more write events for that file come in, and then wait a small amoutn of time after each event comign in before spawinging the thumbnail generator) the problem si some files take a while to writ e- for example saving a 1024x768 png in gimp actually takes like 3 or 4 seconds.... and some formats save instantly... so it'd be great to have a way of telling this.. :) and sicne fam can alreayd tell when when things execute, i'm sure it probabyl coudl tell me when they read/write :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 13:36:02 2000 Received: by oss.sgi.com id ; Mon, 15 May 2000 20:35:52 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41765 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 15 May 2000 20:35:38 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA02683 for ; Mon, 15 May 2000 13:40:08 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id NAA44193; Mon, 15 May 2000 13:33:36 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005151333.ZM44299@rlyeh.engr.sgi.com> Date: Mon, 15 May 2000 13:33:34 -0700 In-Reply-To: Waldo Bastian "Re: [fam] Class names" (May 12, 5:08pm) References: <00051111202002.21991@wantelbos> <10005111728.ZM35420@rlyeh.engr.sgi.com> <0005121708020C.17904@wantelbos> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: bastian@kde.org Subject: Re: [fam] Class names Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > > libfam should export only the symbols listed in fam.h. I know how to do > > this with SGI compilers; does anyone know how to do it with g++/GNU ld? > > I suggest you use libtool's -export-symbols option. It should take care of > any platform-dependencies. Yes, that's exactly what I want. Thanks! Except... I tried adding a "fam.sym" file containing the symbols which should be exported, and "-export-symbols fam.sym" to libfam_la_LDFLAGS in libfam/Makefile.am, and I can see that automake is passing the -export-symbols flag to libtool with --mode=link, but libtool doesn't appear to pass the right argument on to the linker (this is using SGI compilers on IRIX--it should pass "-exports_file fam.sym"). Does this sound like a problem with libtool, a misconfiguration, or luser error? It looks like it might be doing the right thing on Linux, but I didn't get any linker warnings there before; you want to try this and see if it fixes your problem? The contents of fam.sym should be: FAMCancelMonitor FAMClose FAMDebugLevel FamErrlist FAMErrno FAMMonitorCollection FAMMonitorDirectory FAMMonitorDirectory2 FAMMonitorFile FAMMonitorFile2 FAMNextEvent FAMOpen FAMOpen2 FAMPending FAMResumeMonitor FAMSuspendMonitor --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 14:45:23 2000 Received: by oss.sgi.com id ; Mon, 15 May 2000 21:45:13 +0000 Received: from svn.net ([167.160.200.10]:30479 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Mon, 15 May 2000 21:45:01 +0000 Received: from wantelbos (pm3-148.svn.net [167.160.201.148]) by svn.net (8.10.0/8.10.0) with SMTP id e4FLjYl17106; Mon, 15 May 2000 14:45:34 -0700 From: Waldo Bastian To: rusty@sgi.com Subject: Re: [fam] Class names Date: Mon, 15 May 2000 14:47:07 -0700 Content-Type: text/plain References: <00051111202002.21991@wantelbos> <0005121708020C.17904@wantelbos> <10005151333.ZM44299@rlyeh.engr.sgi.com> In-Reply-To: <10005151333.ZM44299@rlyeh.engr.sgi.com> Cc: fam@oss.sgi.com MIME-Version: 1.0 Message-Id: <0005151447070H.24198@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, 15 May 2000, you wrote: > > > libfam should export only the symbols listed in fam.h. I know how to > > > do this with SGI compilers; does anyone know how to do it with g++/GNU > > > ld? > > > > I suggest you use libtool's -export-symbols option. It should take care > > of any platform-dependencies. > > Yes, that's exactly what I want. Thanks! > > Except... I tried adding a "fam.sym" file containing the symbols which > should be exported, and "-export-symbols fam.sym" to libfam_la_LDFLAGS in > libfam/Makefile.am, and I can see that automake is passing the > -export-symbols flag to libtool with --mode=link, but libtool doesn't > appear to pass the right argument on to the linker (this is using SGI > compilers on IRIX--it should pass "-exports_file fam.sym"). Does this > sound like a problem with libtool, a misconfiguration, or luser error? Looks like a libtool error. You can send a bug-report to bug-libtool@gnu.org. > It looks like it might be doing the right thing on Linux, but I didn't get > any linker warnings there before; you want to try this and see if it fixes > your problem? Well, it seems that the not-used symbols are being filtered out of the "normal symbol table" but not out of the "dynamic symbol table" and that as such it doesn't solve the problem. I'm trying to convince the linux linker guys that this is a bug somewhere. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 18:40:46 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 01:40:35 +0000 Received: from deliverator.sgi.com ([204.94.214.10]:46892 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 01:40:08 +0000 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA01063 for ; Mon, 15 May 2000 18:35:16 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA30077 for ; Mon, 15 May 2000 18:39:35 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id SAA32474; Mon, 15 May 2000 18:36:11 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005151836.ZM44854@rlyeh.engr.sgi.com> Date: Mon, 15 May 2000 18:36:10 -0700 In-Reply-To: Oliver Kiddle "[fam] No /dev/imon" (May 14, 6:51pm) References: <391EE790.CEAA0019@u.genie.co.uk> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: opk@u.genie.co.uk Subject: Re: [fam] No /dev/imon Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I have just compiled and installed imon-0.0.1-2.2.13, fam-oss-2.6.3 on > version 2.2.15 of the Linux kernel. The compilations all worked fine > with no errors. When I boot with the new kernel, I get a message saying > 'imon (inode monitor) $Revision: $' which all looks fine but once the > system is up and running, /dev/imon doesn't seem to exist. It does on my > IRIX 5.3 system so I guess it should be visible. Do I need to do > something to create it or has something gone wrong? No, it's OK; on Linux, when fam starts up, it creates /dev/imon with the major number it reads from /proc/devices. (Then it promptly deletes the device; the person who wrote that part felt there was no need for /dev/imon to hang around.) That bothers enough people that I will add it to the FAQ, and possibly remove the bit in fam which removes /dev/imon. If you want to make sure fam is using imon instead of polling, there are a couple of things you could do: one is to add the -d flag (for debugging) to the line in /etc/inetd.conf which starts fam, and killall -HUP inetd, and make sure your syslog configuration will dump debug messages somewhere where you can find them. When fam starts up, it should say whether it was able to open /dev/imon. (It should probably do that even when it's not in debug mode, since that's a pretty interesting piece of information!) Another thing you can do (easier, actually) is cat /proc/fs/imon-meter or /proc/fs/imon-hash (unless you turned off DEBUG_INTO_PROC in your linux/fs/imon/imon.c). If imon is monitoring any files, the "base" line in /proc/fs/imon-hash will have an address other than 0, and there will be a list of hash table entries. If imon *has* monitored any files (even if none are being monitored now), the "adds" line in /proc/fs/imon-meter will be non-zero. > Would it make sense to use fam in programs which are just interested in > monitoring single files such as a text editor monitoring the file it has > open or are the overheads such that it is only worth using if a whole > directory structure is going to be monitored? We're talking about NEdit, right? (I love nedit!) I don't know. NEdit stats the file you're editing when the window gets focus, right? That seems pretty simple, and because it's based on user action rather than polling periodically, it means it really isn't doing anything when it's minimized or stowed or whatever. On the other hand, you *are* polling when you don't need to, and on the other other hand it seems like you could get into cases where the user has been typing into the same window for five minutes without knowing that the file changed underneath them four minutes ago. Whether that justifies the overhead of fam (and how much overhead there really is) I don't know. Once you're running, I think there's basically no overhead (just one more fd in the select), but when you connect to fam, FAMOpen() has to get a port number from the portmapper, and open a couple of sockets, so there's a bit of overhead there. If fam isn't already running, then someone has to pay for inetd forking & starting it up, but only the first client has to do that. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 19:31:16 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 02:30:55 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1857 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 02:30:33 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA02070 for ; Mon, 15 May 2000 19:35:03 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id TAA44979; Mon, 15 May 2000 19:28:32 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005151928.ZM38149@rlyeh.engr.sgi.com> Date: Mon, 15 May 2000 19:28:31 -0700 In-Reply-To: raster@rasterman.com "[fam] monitoring for executing....... how about........" (May 14, 12:27pm) References: <200005141927.MAA22913@behemoth.su.varesearch.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: raster@rasterman.com Subject: Re: [fam] monitoring for executing....... how about........ Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I'm writign a file manager (efm) - when files get "changed" i need to > re-evaluate them - that means if the mime type is image/* re-generate a > thumbnail... and that means openig file, read, generate thumb, write, > display. > > the problem is the change event comes in whilste the file is still > being written it isnt finished yet - and theres no way to know if > someone is activel ywritign to the file- yes - i suppose i could use > fuser and check if tis opened - but it may beopened for read onyl- or > the writes maye be finsihed but the file nto close (maybe a log file of > some sort) > > so beig able tohave events like: > file written at byte 16384 size 4096 > file read at byte 300 size 256 > etc. > woudl be greta - then at ;eats i could pause the thumbnail generation > until writes have stopped (ie no more write events for that file come > in, and then wait a small amoutn of time after each event comign in > before spawinging the thumbnail generator) > > the problem si some files take a while to writ e- for example saving a > 1024x768 png in gimp actually takes like 3 or 4 seconds.... and some > formats save instantly... so it'd be great to have a way of telling > this.. :) and sicne fam can alreayd tell when when things execute, i'm > sure it probabyl coudl tell me when they read/write :) It sounds like what you want to know is not when & where someone writes, but when someone *stops* writing. (So instead of spawning the thumbnail generator on a Changed event, you do it on a "DoneBeingChanged" event.) I don't know of a good way to do this. A not-so-good way for fam to do it would be if imon reported when a file was opened & closed; fam could then pass that on to clients. (That would take changes to imon, the interface between imon and fam, and the fam API. The reason it's not so good is that you still have the problem of knowing whether the process that just closed the file is the same one that was writing to it, whether or not the writing process is done, etc.) Failing that, a not-so-good way for the client application to do it would be to always wait a certain amount of time between the last Changed event on a file and starting the thumbnail generator on the file, but that's so bad, forget I even suggested it. Maybe the right way for this to work is, you spawn the thumbnail generator whenever you get a Changed event, and the first thing the t.g. does is fcntl(fd, F_SETLKW, {F_RDLCK, ...}) the file, and hope that whoever's writing the file was polite enough to lock it while they're writing. That way the t.g. sleeps until the writing process explicitly says "OK, I'm done writing." I like that, but I have no idea how many image-writing processes are that polite. (I wouldn't be surprised if the answer is "none.") --Rusty P.S. The problem with imon passing the offset & length of writes to fam is that, in the current implementation, imon doesn't actually know the offset & length. If its hooks into the fs code were rewritten, it would be able to do this, but you'd still have to change the interface between imon & fam, and the fam API, and I think that information still wouldn't tell you when someone was done changing the file. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 22:32:09 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 05:31:51 +0000 Received: from svn.net ([167.160.200.10]:57092 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 05:31:45 +0000 Received: from wantelbos (pm3-155.svn.net [167.160.201.155]) by svn.net (8.10.0/8.10.0) with SMTP id e4G5WNl08756 for ; Mon, 15 May 2000 22:32:23 -0700 From: Waldo Bastian To: fam@oss.sgi.com Subject: Re: [fam] monitoring for executing....... how about........ Date: Mon, 15 May 2000 22:33:58 -0700 Content-Type: text/plain References: <200005141927.MAA22913@behemoth.su.varesearch.com> In-Reply-To: <200005141927.MAA22913@behemoth.su.varesearch.com> MIME-Version: 1.0 Message-Id: <0005152233580V.24198@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Sun, 14 May 2000, you wrote: > the problem is the change event comes in whilste the file is still > being written it isnt finished yet - and theres no way to know if > someone is activel ywritign to the file- yes - i suppose i could use We encountered the same problem within KDE, where we were reading desktop files before "make install" had written anything into them :-] Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 22:41:39 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 05:41:20 +0000 Received: from svn.net ([167.160.200.10]:14341 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 05:41:11 +0000 Received: from wantelbos (pm3-155.svn.net [167.160.201.155]) by svn.net (8.10.0/8.10.0) with SMTP id e4G5fnl09254 for ; Mon, 15 May 2000 22:41:49 -0700 From: Waldo Bastian To: fam@oss.sgi.com Subject: Re: [fam] monitoring for executing....... how about........ Date: Mon, 15 May 2000 22:43:24 -0700 Content-Type: text/plain References: <200005141927.MAA22913@behemoth.su.varesearch.com> <10005151928.ZM38149@rlyeh.engr.sgi.com> In-Reply-To: <10005151928.ZM38149@rlyeh.engr.sgi.com> MIME-Version: 1.0 Message-Id: <0005152243240W.24198@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, 15 May 2000, you wrote: > I don't know of a good way to do this. A not-so-good way for fam to do it > would be if imon reported when a file was opened & closed; fam could then > pass that on to clients. (That would take changes to imon, the interface > between imon and fam, and the fam API. The reason it's not so good is that > you still have the problem of knowing whether the process that just closed > the file is the same one that was writing to it, whether or not the writing > process is done, etc.) Well, if the file just got created, it is unlikely to be opened by more than one process. If the file happens to be used as log-file, it can take quite a while before you get the close-event. Never the less, as a user of fam you have some more possibilities to do what is right for your particular situation. > Failing that, a not-so-good way for the client > application to do it would be to always wait a certain amount of time > between the last Changed event on a file and starting the thumbnail > generator on the file, but that's so bad, forget I even suggested it. That's what we currently do :-) > [Snap] I like that, but I have no idea how many image-writing processes > are that polite. (I wouldn't be surprised if the answer is "none.") In our case, I'm not aware of /usr/bin/install doing that. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 23:17:20 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 06:17:09 +0000 Received: from behemoth.vergenet.net ([198.186.202.43]:57355 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 06:17:02 +0000 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id XAA14467; Mon, 15 May 2000 23:21:40 -0700 Message-Id: <200005160621.XAA14467@behemoth.su.varesearch.com> Date: Mon, 15 May 2000 23:21:40 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] monitoring for executing....... how about........ To: bastian@kde.org cc: fam@oss.sgi.com In-Reply-To: <0005152243240W.24198@wantelbos> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 15 May, Waldo Bastian scribbled: -> On Mon, 15 May 2000, you wrote: -> > I don't know of a good way to do this. A not-so-good way for fam to do it -> > would be if imon reported when a file was opened & closed; fam could then -> > pass that on to clients. (That would take changes to imon, the interface -> > between imon and fam, and the fam API. The reason it's not so good is that -> > you still have the problem of knowing whether the process that just closed -> > the file is the same one that was writing to it, whether or not the writing -> > process is done, etc.) -> -> Well, if the file just got created, it is unlikely to be opened by more than -> one process. If the file happens to be used as log-file, it can take quite a -> while before you get the close-event. Never the less, as a user of fam you -> have some more possibilities to do what is right for your particular -> situation. thats why i was thinkign that fam has kernel hooks - they are exported by imon - and the kernel knwos when a process does read(0 write() open() and close() - i suppose the imon patch your attach some parasite data to any fd a porcess gets fomr am open/close and whenever close()'d write(0en or read() from it can look at the struct - if imon at the time has that inode/file in its list to be monitored imon could generate the event form fam to propagate to clients... i can see that being possible - the problem is haviung the parasite struct data attached - that'd be a reasonable bit of work - but still possibl e- it's somehting the kernel does definitely know and hides fomr user-space, so making it available would be handy :) -> > Failing that, a not-so-good way for the client -> > application to do it would be to always wait a certain amount of time -> > between the last Changed event on a file and starting the thumbnail -> > generator on the file, but that's so bad, forget I even suggested it. -> -> That's what we currently do :-) hmm - that was my only solution i thought of - but it wasnt that clean - a bit hackish.. hmmmmmm oh well - looks like its time to give my timout system a workout again.. :) -> > [Snap] I like that, but I have no idea how many image-writing processes -> > are that polite. (I wouldn't be surprised if the answer is "none.") -> -> In our case, I'm not aware of /usr/bin/install doing that. not much does - a lot of libs and programs dont expect multiple processes to be reading the file they are writing at that tim e- mail programs do (mail spools) but others dont - its just not what programmers expected.. :( -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 23:17:20 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 06:17:10 +0000 Received: from behemoth.vergenet.net ([198.186.202.43]:57099 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 06:17:02 +0000 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id XAA14459; Mon, 15 May 2000 23:21:40 -0700 Message-Id: <200005160621.XAA14459@behemoth.su.varesearch.com> Date: Mon, 15 May 2000 23:21:40 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] monitoring for executing....... how about........ To: bastian@kde.org cc: fam@oss.sgi.com In-Reply-To: <0005152233580V.24198@wantelbos> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 15 May, Waldo Bastian scribbled: -> On Sun, 14 May 2000, you wrote: -> > the problem is the change event comes in whilste the file is still -> > being written it isnt finished yet - and theres no way to know if -> > someone is activel ywritign to the file- yes - i suppose i could use -> -> We encountered the same problem within KDE, where we were reading desktop -> files before "make install" had written anything into them :-] what was your solution? -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 15 23:32:41 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 06:32:30 +0000 Received: from behemoth.vergenet.net ([198.186.202.43]:11276 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 06:32:19 +0000 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id XAA25660; Mon, 15 May 2000 23:37:01 -0700 Message-Id: <200005160637.XAA25660@behemoth.su.varesearch.com> Date: Mon, 15 May 2000 23:37:01 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] monitoring for executing....... how about........ To: rusty@sgi.com cc: rusty@rlyeh.engr.sgi.com, fam@oss.sgi.com In-Reply-To: <10005151928.ZM38149@rlyeh.engr.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 15 May, Rusty Ballinger scribbled: -> > I'm writign a file manager (efm) - when files get "changed" i need to -> > re-evaluate them - that means if the mime type is image/* re-generate a -> > thumbnail... and that means openig file, read, generate thumb, write, -> > display. -> > -> > the problem is the change event comes in whilste the file is still -> > being written it isnt finished yet - and theres no way to know if -> > someone is activel ywritign to the file- yes - i suppose i could use -> > fuser and check if tis opened - but it may beopened for read onyl- or -> > the writes maye be finsihed but the file nto close (maybe a log file of -> > some sort) -> > -> > so beig able tohave events like: -> > file written at byte 16384 size 4096 -> > file read at byte 300 size 256 -> > etc. -> > woudl be greta - then at ;eats i could pause the thumbnail generation -> > until writes have stopped (ie no more write events for that file come -> > in, and then wait a small amoutn of time after each event comign in -> > before spawinging the thumbnail generator) -> > -> > the problem si some files take a while to writ e- for example saving a -> > 1024x768 png in gimp actually takes like 3 or 4 seconds.... and some -> > formats save instantly... so it'd be great to have a way of telling -> > this.. :) and sicne fam can alreayd tell when when things execute, i'm -> > sure it probabyl coudl tell me when they read/write :) -> -> It sounds like what you want to know is not when & where someone writes, -> but when someone *stops* writing. (So instead of spawning the thumbnail -> generator on a Changed event, you do it on a "DoneBeingChanged" event.) -> -> I don't know of a good way to do this. A not-so-good way for fam to do it -> would be if imon reported when a file was opened & closed; fam could then -> pass that on to clients. (That would take changes to imon, the interface -> between imon and fam, and the fam API. The reason it's not so good is that -> you still have the problem of knowing whether the process that just closed -> the file is the same one that was writing to it, whether or not the writing -> process is done, etc.) Failing that, a not-so-good way for the client -> application to do it would be to always wait a certain amount of time -> between the last Changed event on a file and starting the thumbnail -> generator on the file, but that's so bad, forget I even suggested it. -> -> Maybe the right way for this to work is, you spawn the thumbnail generator -> whenever you get a Changed event, and the first thing the t.g. does is -> fcntl(fd, F_SETLKW, {F_RDLCK, ...}) the file, and hope that whoever's -> writing the file was polite enough to lock it while they're writing. That -> way the t.g. sleeps until the writing process explicitly says "OK, I'm done -> writing." I like that, but I have no idea how many image-writing processes -> are that polite. (I wouldn't be surprised if the answer is "none.") hmm - problem is almost no-one to a tea - except mail clients and mta's lock files much (or it a suite of apps that use files to share data) so in general it doesnt tend to work :( -> --Rusty -> -> P.S. The problem with imon passing the offset & length of writes to fam is -> that, in the current implementation, imon doesn't actually know the offset -> & length. If its hooks into the fs code were rewritten, it would be able to -> do this, but you'd still have to change the interface between imon & fam, -> and the fam API, and I think that information still wouldn't tell you when -> someone was done changing the file. hmmm ok - well it was just an idea - i do know the kernel knows.. it's just a matter of perculating the information back into user space - offset and size isnt really important - thought it coudl see in a general way that it would be useful to know if you are monitoring a file - if that part of the file you were looking at changed... maybe this coudl be put onto a "some daty later" feature list :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 16 10:42:44 2000 Received: by oss.sgi.com id ; Tue, 16 May 2000 17:42:35 +0000 Received: from svn.net ([167.160.200.10]:51719 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Tue, 16 May 2000 17:42:23 +0000 Received: from wantelbos (pm3-145.svn.net [167.160.201.145]) by svn.net (8.10.0/8.10.0) with SMTP id e4GHh1l24704; Tue, 16 May 2000 10:43:01 -0700 From: Waldo Bastian To: raster@rasterman.com Subject: Re: [fam] monitoring for executing....... how about........ Date: Tue, 16 May 2000 00:03:34 -0700 Content-Type: text/plain Cc: fam@oss.sgi.com References: <200005160621.XAA14459@behemoth.su.varesearch.com> In-Reply-To: <200005160621.XAA14459@behemoth.su.varesearch.com> MIME-Version: 1.0 Message-Id: <00051600033412.24198@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, 15 May 2000, raster@rasterman.com wrote: > On 15 May, Waldo Bastian scribbled: > -> On Sun, 14 May 2000, you wrote: > -> > the problem is the change event comes in whilste the file is still > -> > being written it isnt finished yet - and theres no way to know if > -> > someone is activel ywritign to the file- yes - i suppose i could use > -> > -> We encountered the same problem within KDE, where we were reading > desktop -> files before "make install" had written anything into them :-] > > what was your solution? Wait a little and hope for the best :-) Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 17 17:26:14 2000 Received: by oss.sgi.com id ; Thu, 18 May 2000 00:26:05 +0000 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:28688 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 May 2000 00:25:41 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04855 for ; Wed, 17 May 2000 17:30:13 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id RAA48821 for fam@oss.sgi.com; Wed, 17 May 2000 17:24:06 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005171724.ZM50294@rlyeh.engr.sgi.com> Date: Wed, 17 May 2000 17:24:05 -0700 X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fam@oss.sgi.com Subject: [fam] Qt/GTK+ tutorial Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hey, rather than putting out a new version of fam with actual bug fixes, or rewriting imon's hooks into the filesystem code, the last few days I've been writing a tutorial on how to use fam with Qt and GTK+. It's quite possible that I'm advising people to do something stupid; if you're a Qt or GTK+ fiend, you want to review it for technical bogosity? http://oss.sgi.com/projects/fam/qt_gtk.html (I also added a link to it from the documentation page.) --Rusty P.S. OK, I oughtta put the sample code against a different-colored background. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 17 21:06:06 2000 Received: by oss.sgi.com id ; Thu, 18 May 2000 04:05:55 +0000 Received: from svn.net ([167.160.200.10]:28677 "EHLO svn.net") by oss.sgi.com with ESMTP id ; Thu, 18 May 2000 04:05:36 +0000 Received: from wantelbos (bastian@pm5-251.svn.net [167.160.201.251]) by svn.net (8.10.0/8.10.0) with SMTP id e4I45pl09980; Wed, 17 May 2000 21:05:51 -0700 From: Waldo Bastian To: rusty@sgi.com Subject: Re: [fam] Qt/GTK+ tutorial Date: Wed, 17 May 2000 21:51:16 -0700 Content-Type: text/plain References: <10005171724.ZM50294@rlyeh.engr.sgi.com> In-Reply-To: <10005171724.ZM50294@rlyeh.engr.sgi.com> Cc: fam@oss.sgi.com MIME-Version: 1.0 Message-Id: <00051721511600.00375@wantelbos> Content-Transfer-Encoding: 8bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Wed, 17 May 2000, you wrote: > Hey, rather than putting out a new version of fam with actual bug fixes, > or rewriting imon's hooks into the filesystem code, the last few days I've > been writing a tutorial on how to use fam with Qt and GTK+. It's quite > possible that I'm advising people to do something stupid; if you're a Qt or > GTK+ fiend, you want to review it for technical bogosity? About the Qt example. Is it required to make the filedescriptor non-blocking? It isn't necassery for QSocketNotifier and I think it hurts for Client::readEvent() in the case when their is only a half event available. In theory you can end up busy-waiting in the while-loop, which is bad for your load. In practice these events are probably delivered as a whole anyway, so I don't think it's critical, but better safe than sorry. Cheers, Waldo -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 18 03:16:40 2000 Received: by oss.sgi.com id ; Thu, 18 May 2000 10:16:21 +0000 Received: from cav.logica.co.uk ([158.234.10.66]:63253 "EHLO cav.logica.co.uk") by oss.sgi.com with ESMTP id ; Thu, 18 May 2000 10:15:50 +0000 Received: from u.genie.co.uk ([158.234.39.229]) by cav.logica.co.uk (8.9.1/8.9.1) with ESMTP id LAA12570; Thu, 18 May 2000 11:15:39 +0100 Message-ID: <3923C2C8.52B96094@u.genie.co.uk> Date: Thu, 18 May 2000 11:15:36 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: rusty@sgi.com CC: fam@oss.sgi.com Subject: [fam] NEdit (was Re: No /dev/imon) References: <391EE790.CEAA0019@u.genie.co.uk> <10005151836.ZM44854@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > > No, it's OK; on Linux, when fam starts up, it creates /dev/imon with the Thanks. I've checked /proc/devices and /proc/fs/imon-* and it is all working fine. > We're talking about NEdit, right? (I love nedit!) I don't know. NEdit Yes, that was exactly what I what I was talking about. > stats the file you're editing when the window gets focus, right? That seems It isn't just when NEdit gets focus that it checks for modifications to the file: as far as I can tell, the checking is done at various points. There is a procedure which does the actual check (CheckForChangesToFile) which first compares a timestamp so that the check is not done more often than once every 3 seconds (MOD_CHECK_INTERVAL). This procedure is called from three places which as far as I can tell are when the window gets focus, the cursor is moved or when the edit buffer is modified by, for example the user typing. This means that the polling will be done for every user keypress which is fairly regularly. It also seems that it doesn't just do a stat, it checks whether the file can be written to so I'm not sure how that could be done with fam. Also, do you know if motif offers a way that the select approach could be used with fam? > Once you're running, I think there's basically no overhead (just one > more fd in the select), but when you connect to fam, FAMOpen() has to get a > port number from the portmapper, and open a couple of sockets, so there's a > bit of overhead there. If fam isn't already running, then someone has to pay > for inetd forking & starting it up, but only the first client has to do that. I'd have thought that given time, there will be a good few programs using fam, especially with it being used in KDE's standard library so that the initial inetd start would become less relevant. Do many of the IRIX programs use fam? Anyway, if you think it would be useful addition to NEdit, I'll have a go at adding it. Oliver Kiddle -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 18 15:22:15 2000 Received: by oss.sgi.com id ; Thu, 18 May 2000 22:22:05 +0000 Received: from deliverator.sgi.com ([204.94.214.10]:8988 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 May 2000 22:21:55 +0000 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01361 for ; Thu, 18 May 2000 15:16:59 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA24334 for ; Thu, 18 May 2000 15:20:04 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id PAA03030; Thu, 18 May 2000 15:16:40 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005181516.ZM2975@rlyeh.engr.sgi.com> Date: Thu, 18 May 2000 15:16:40 -0700 In-Reply-To: Waldo Bastian "Re: [fam] Qt/GTK+ tutorial" (May 17, 9:51pm) References: <10005171724.ZM50294@rlyeh.engr.sgi.com> <00051721511600.00375@wantelbos> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: bastian@kde.org Subject: Re: [fam] Qt/GTK+ tutorial Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > About the Qt example. Is it required to make the filedescriptor > non-blocking? It isn't necassery for QSocketNotifier and I think it hurts > for Client::readEvent() in the case when their is only a half event > available. In theory you can end up busy-waiting in the while-loop Well, both the Qt 1.44 and 2.0.2 QSocketNotifier class reference say in both the text and the sample code that your socket should be non-blocking. (I'm not sure why, as I can't imagine that Qt would ever do anything but select on the socket.) But you're right about that being bad for Client::readEvent(). I didn't think of that. It seems like the right thing to do is in the read loop in Client::readEvent(), if the fd is non-blocking, and readEvent() is supposed to block, do a select before subsequent reads, so that it still blocks, but not busily. Thanks a lot for catching that. (I guess that's separate from the question of whether the tutorial should say to make the socket non-blocking... if you're sure it's not necessary, I'll remove it.) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 18 15:23:36 2000 Received: by oss.sgi.com id ; Thu, 18 May 2000 22:23:15 +0000 Received: from deliverator.sgi.com ([204.94.214.10]:29468 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 18 May 2000 22:23:08 +0000 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01506 for ; Thu, 18 May 2000 15:18:16 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA27621 for ; Thu, 18 May 2000 15:21:19 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id PAA03013; Thu, 18 May 2000 15:18:01 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005181518.ZM47227@rlyeh.engr.sgi.com> Date: Thu, 18 May 2000 15:18:00 -0700 In-Reply-To: Oliver Kiddle "[fam] NEdit (was Re: No /dev/imon)" (May 18, 11:15am) References: <391EE790.CEAA0019@u.genie.co.uk> <10005151836.ZM44854@rlyeh.engr.sgi.com> <3923C2C8.52B96094@u.genie.co.uk> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: opk@u.genie.co.uk Subject: Re: [fam] NEdit (was Re: No /dev/imon) Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > This means that the polling will be done for every user keypress which > is fairly regularly. It also seems that it doesn't just do a stat, it > checks whether the file can be written to so I'm not sure how that > could be done with fam. When you get a Changed event from fam (which will also happen if the file's mode changes, which is good), you'll basically call CheckForChangesToFile. (Except that the bit which ignores the event if the last check was less than MOD_CHECK_INTERVAL should probably be moved down to where the warning is popped up--if the file is changed, and CheckForChangesToFile is called, and a moment later the file's mode is changed to read-only, for example, you probably still want to call UpdateWindowTitle and UpdateWindowReadOnly!) Also, you'll get a Deleted event from fam if the file is deleted, which can either be ignored (as CheckForChangesToFile does now by bailing when the stat fails) or it might be nice to pop up a dialog saying so. > Also, do you know if motif offers a way that the select approach could > be used with fam? I think XtAppAddInput? I don't know anything about it, but it's used by nedit/source/shell.c, which might provide a good example. > I'd have thought that given time, there will be a good few programs > using fam, especially with it being used in KDE's standard library so > that the initial inetd start would become less relevant. Do many of the > IRIX programs use fam? Yes: mailbox, zmail/mediamail, mediad (removable media daemon), fm (file manager), ov (desks overview), iconcatalog (shows installed software), and other desktop & system administration stuff. > Anyway, if you think it would be useful addition to NEdit, I'll have a > go at adding it. That would be neat. You'll have to wrap it in #ifdef USE_FAM or something, and add -DUSE_FAM to Makefile.sgi, and a comment in the Linux section of the README saying "to use fam, add -DUSE_FAM to CFLAGS in makefiles/Makefile.linux". I'll be happy to test it on my machines! --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Thu May 18 21:08:20 2000 Received: by oss.sgi.com id ; Fri, 19 May 2000 04:08:11 +0000 Received: from deliverator.sgi.com ([204.94.214.10]:44644 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 19 May 2000 04:08:00 +0000 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA08455 for ; Thu, 18 May 2000 21:02:56 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id VAA53406; Thu, 18 May 2000 21:05:25 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005182105.ZM53154@rlyeh.engr.sgi.com> Date: Thu, 18 May 2000 21:05:25 -0700 In-Reply-To: "Rusty Ballinger" "Re: [fam] Qt/GTK+ tutorial" (May 18, 3:16pm) References: <10005171724.ZM50294@rlyeh.engr.sgi.com> <00051721511600.00375@wantelbos> <10005181516.ZM2975@rlyeh.engr.sgi.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: bastian@kde.org Subject: Re: [fam] Qt/GTK+ tutorial Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > > About the Qt example. Is it required to make the filedescriptor > > non-blocking? It isn't necassery for QSocketNotifier and I think it hurts > > for Client::readEvent() in the case when their is only a half event > > available. In theory you can end up busy-waiting in the while-loop ... > It seems like the right thing to do is in the read loop in > Client::readEvent(), if the fd is non-blocking, and readEvent() is > supposed to block, do a select before subsequent reads, so that it still > blocks, but not busily. Thanks a lot for catching that. Actually, after looking at it, I think it's OK the way it is. FAMNextEvent won't busy-wait on a non-blocking socket, because when the read in Client::readEvent() fails (with errno == EAGAIN/EWOULDBLOCK), readEvent bails, and FAMNextEvent will return an error (leaving errno == EAGAIN), which seems reasonable. (If the caller doesn't want the error, they shouldn't call FAMNextEvent on a non-blocking socket until FAMPending says an event is ready.) Does that make sense? I'll fix the man page to encourage the use of FAMPending. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 19 18:31:13 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4K1VDj05072 for fam-outgoing; Fri, 19 May 2000 18:31:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from gin.ext.thepuffingroup.com ([216.208.98.3]) by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4K1VCU05069 for ; Fri, 19 May 2000 18:31:12 -0700 Received: (from willy@localhost) by gin.ext.thepuffingroup.com (8.9.3/8.9.3) id WAA05544; Fri, 19 May 2000 22:30:52 -0400 Date: Fri, 19 May 2000 22:30:52 -0400 From: willy@thepuffingroup.com To: linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com Cc: fam@oss.sgi.com Subject: [fam] [prepatch] Directory Notification Message-ID: <20000519223052.M28590@thepuffingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-fam@oss.sgi.com Precedence: bulk Hi. I've implemented directory change notification for linux 2.3.99pre8. I've done some light testing, but more eyes are always welcome. I'm not sure that doing the notifications from within vfs_* is the right thing to do; could the filesystem stacking guys take a look? This includes some of the work from Manfred on making kill_fasync SMP-safe. It's unrelated to the imon work done by SGI but serves the same purpose, hence their inclusion. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 19 18:50:49 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4K1ong05269 for fam-outgoing; Fri, 19 May 2000 18:50:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from gin.ext.thepuffingroup.com ([216.208.98.3]) by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4K1omU05266 for ; Fri, 19 May 2000 18:50:48 -0700 Received: (from willy@localhost) by gin.ext.thepuffingroup.com (8.9.3/8.9.3) id WAA05607; Fri, 19 May 2000 22:50:41 -0400 Date: Fri, 19 May 2000 22:50:41 -0400 From: willy@thepuffingroup.com To: linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com Cc: fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification Message-ID: <20000519225041.P28590@thepuffingroup.com> References: <20000519223052.M28590@thepuffingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <20000519223052.M28590@thepuffingroup.com>; from willy@thepuffingroup.com on Fri, May 19, 2000 at 10:30:52PM -0400 Sender: owner-fam@oss.sgi.com Precedence: bulk On Fri, May 19, 2000 at 10:30:52PM -0400, willy@thepuffingroup.com wrote: [and forgot to include the patch URL] ftp://ftp.uk.linux.org/pub/linux/people/willy/ lock-2.3.99pre8.diff is the kernel patch and dirnot.c is an example program using the interface. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sat May 20 08:42:01 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4KFg1510524 for fam-outgoing; Sat, 20 May 2000 08:42:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from localhost (mail@localhost) by oss.sgi.com (8.10.1/8.10.1) with SMTP id e4KFeNb10469; Sat, 20 May 2000 08:40:23 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.12); Sat, 20 May 2000 08:40:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4KFeNI10463 for oss-projects-outgoing; Sat, 20 May 2000 08:40:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-oss-projects@oss.sgi.com using -f Received: (from cattelan@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4KFeNB10461 for oss-projects@oss.sgi.com; Sat, 20 May 2000 08:40:23 -0700 Date: Sat, 20 May 2000 08:40:23 -0700 From: Russell Cattelan Message-Id: <200005201540.e4KFeNB10461@oss.sgi.com> To: oss-projects@oss.sgi.com Sender: owner-fam@oss.sgi.com Precedence: bulk test please ignore -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sat May 20 12:31:37 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4KJVb112171 for fam-outgoing; Sat, 20 May 2000 12:31:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4KJVbn12168 for ; Sat, 20 May 2000 12:31:37 -0700 Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03909; Sat, 20 May 2000 15:31:34 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id PAA07400; Sat, 20 May 2000 15:31:29 -0400 (EDT) Date: Sat, 20 May 2000 15:31:29 -0400 (EDT) Message-Id: <200005201931.PAA07400@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: willy@thepuffingroup.com Cc: linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification In-reply-to: Your message of "Fri, 19 May 2000 22:50:41 EDT." <20000519225041.P28590@thepuffingroup.com> Sender: owner-fam@oss.sgi.com Precedence: bulk In message <20000519225041.P28590@thepuffingroup.com>, willy@thepuffingroup.com writes: > On Fri, May 19, 2000 at 10:30:52PM -0400, willy@thepuffingroup.com wrote: > [and forgot to include the patch URL] > > ftp://ftp.uk.linux.org/pub/linux/people/willy/ > > lock-2.3.99pre8.diff is the kernel patch and dirnot.c is an example program > using the interface. I looked briefly at the patch, and I'm afraid I don't understand some basic things. Perhaps you can let us (-fsdevel) all know the following (which you should probably put in a README on your Web page along w/ the patches): - what is directory notification - (is it related at all to notify_change or the old check_media_change?) - what is it good for - why it cannot be done using other mechanisms - an overview of how it can be used (I couldn't understand it from your test program) - an overview of what your patch does. (Your patch seems rather long. You should explain on this list why it is that long, what it does, etc.) - what impact, if any, does your patch have on the rest of the kernel and other file systems. Whenever I write and submit patches, I accompany them with a README that gives people (and esp. kernel maintainers) an overview of what the patch does. The kernel maintainers are very busy and get many patch submissions all the time; my feeling is that a well thought and well documented patch stands a much better chance of getting accepted. Thanks, Erez. (stacking guy :-) -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 21 08:19:10 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4LFJAh18644 for fam-outgoing; Sun, 21 May 2000 08:19:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from gin.ext.thepuffingroup.com ([216.208.98.3]) by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4LFJ9n18641 for ; Sun, 21 May 2000 08:19:09 -0700 Received: (from willy@localhost) by gin.ext.thepuffingroup.com (8.9.3/8.9.3) id MAA22486; Sun, 21 May 2000 12:18:30 -0400 Date: Sun, 21 May 2000 12:18:30 -0400 From: willy@thepuffingroup.com To: Erez Zadok Cc: linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification Message-ID: <20000521121830.X28590@thepuffingroup.com> References: <20000519225041.P28590@thepuffingroup.com> <200005201931.PAA07400@shekel.mcl.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200005201931.PAA07400@shekel.mcl.cs.columbia.edu>; from Erez Zadok on Sat, May 20, 2000 at 03:31:29PM -0400 Sender: owner-fam@oss.sgi.com Precedence: bulk On Sat, May 20, 2000 at 03:31:29PM -0400, Erez Zadok wrote: > I looked briefly at the patch, and I'm afraid I don't understand some basic > things. Perhaps you can let us (-fsdevel) all know the following (which you > should probably put in a README on your Web page along w/ the patches): > - what is directory notification > - what is it good for Directory notification is a mechanism for informing interested tasks when the contents of a directory change. This has immediate applications for file managers and ps. Samba benefits from this, and there are some non-obvious applications such as a persistent make which perpetually keeps a tree up-to-date by noticing modifications to files. > - (is it related at all to notify_change or the old check_media_change?) > - why it cannot be done using other mechanisms notify_change() is not called in all the situations where we need to be notified. > - an overview of how it can be used (I couldn't understand it from your test > program) It delivers a realtime signal to tasks which have requested it. The task can then call fstat to find out what changed. > - an overview of what your patch does. (Your patch seems rather long. You > should explain on this list why it is that long, what it does, etc.) There are really 4 conflated patches here: * A rewrite of the fs/locks.c code. * Making kill_fasync() SMP-safe. * Directory notification. * Addition of file leases. I should split them up. > - what impact, if any, does your patch have on the rest of the kernel and > other file systems. It delivers a lot more signals when someone's using the feature. The impact on other filesystems was what I want to ask you about. I'm currently doing the notify from within the vfs_* functions which seem the best way to ensure that we don't miss an event. However, it may be that some of the more unusual filesystems (umsdos? stacking?) call those functions, leading to a dual-notification. That's not necessarily a bad thing, but it's suboptimal. I'm not really keen on the idea of adding these extra test-and-call patches to each time we call a vfs function. What I'd like to do would be to stack a notification layer on top of a directory, which would actually just entail replacing its ->i_op with a shim which notified and then passed the call on. That would involve remembering the original ->i_op though,and I can't see anywhere convenient to store it. I'll make a split set of patches available RSN. Thanks. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 21 12:08:30 2000 Received: (from majordomo@localhost) by oss.sgi.com (8.10.1/8.10.1) id e4LJ8UE20195 for fam-outgoing; Sun, 21 May 2000 12:08:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-fam@oss.sgi.com using -f Received: from gin.ext.thepuffingroup.com ([216.208.98.3]) by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4LJ8Tn20192 for ; Sun, 21 May 2000 12:08:29 -0700 Received: (from willy@localhost) by gin.ext.thepuffingroup.com (8.9.3/8.9.3) id QAA22732; Sun, 21 May 2000 16:07:51 -0400 Date: Sun, 21 May 2000 16:07:51 -0400 From: willy@thepuffingroup.com To: Erez Zadok Cc: linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification Message-ID: <20000521160751.B28590@thepuffingroup.com> References: <20000519225041.P28590@thepuffingroup.com> <200005201931.PAA07400@shekel.mcl.cs.columbia.edu> <20000521121830.X28590@thepuffingroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <20000521121830.X28590@thepuffingroup.com>; from willy@thepuffingroup.com on Sun, May 21, 2000 at 12:18:30PM -0400 Sender: owner-fam@oss.sgi.com Precedence: bulk On Sun, May 21, 2000 at 12:18:30PM -0400, willy@thepuffingroup.com wrote: > There are really 4 conflated patches here: > > * A rewrite of the fs/locks.c code. > * Making kill_fasync() SMP-safe. > * Directory notification. > * Addition of file leases. > > I should split them up. ftp://ftp.uk.linux.org/pub/linux/people/willy/2.3.99pre8/ dirnot.diff requires killfasync.diff to be applied first, but it's not relevant to understanding the patches. I just split the patches up by hand, there may well be duplicated pieces or poor line numbering. As I suspect the lock-rewrite patch is by far the biggest chunk; it includes the leases. Trond, I haven't fixed any of the problems you noticed yet, you needn't bother looking. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From majordomo@oss.sgi.com Sun May 21 19:06:59 2000 Received: (from localhost user: 'majordomo', uid#102) by oss.sgi.com id ; Sun, 21 May 2000 19:06:39 -0700 Received: from behemoth.vergenet.net ([198.186.202.43]:63751 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Sun, 21 May 2000 19:06:26 -0700 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id TAA26098 for fam@oss.sgi.com; Sun, 21 May 2000 19:09:14 -0700 Message-Id: <200005220209.TAA26098@behemoth.su.varesearch.com> Date: Sun, 21 May 2000 19:09:14 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: [fam] bug in fam/imon? To: fam@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: Majordomo List Manager Fake-Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing i just noted theres a bug in fam/imon.. if you monitor a mountpoint thats unmounted - then it gets moutned fam doesn send back exists/add events - it does nothing.. :( -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 21 19:57:16 2000 Received: by oss.sgi.com id ; Sun, 21 May 2000 19:56:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23642 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 21 May 2000 19:56:42 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA01573 for ; Sun, 21 May 2000 19:51:51 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id TAA55036; Sun, 21 May 2000 19:54:39 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005211954.ZM71226@rlyeh.engr.sgi.com> Date: Sun, 21 May 2000 19:54:38 -0700 In-Reply-To: raster@rasterman.com "[fam] bug in fam/imon?" (May 21, 7:09pm) References: <200005220209.TAA26098@behemoth.su.varesearch.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: raster@rasterman.com Subject: Re: [fam] bug in fam/imon? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > i just noted theres a bug in fam/imon.. if you monitor a mountpoint > thats unmounted - then it gets moutned fam doesn send back exists/add > events - it does nothing.. :( Hey, I just tried that, and it worked for me. The nfs client (where the monitoring is being done) is running a 2.2.13 kernel with imon configured as a module. Monitoring the mount point, and then mounting a filesystem from an irix box with fam, I got a bunch of create events; unmounting it, I got a bunch of delete events; then mounting a filesystem from a linux box without fam on the same mount point, I got a bunch of create events, and then unmounting it, I got the delete events. Is fam failing to monitor /etc/mtab or something? Do you see anything interesting if you run fam in debug mode? (Either by adding "-d" to the line that starts it in inetd.conf, and making sure syslogd is sending debug messages somewhere, or by starting fam yourself & seeing what it prints out. Remember that if you start fam yourself, it registers itself with the portmapper, and inetd/portmap will be confused later. I will add "how do I run fam in debug mode" to the FAQ.) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Sun May 21 22:08:36 2000 Received: by oss.sgi.com id ; Sun, 21 May 2000 22:08:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:12141 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 21 May 2000 22:07:48 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA10210 for ; Sun, 21 May 2000 22:02:56 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id WAA72043; Sun, 21 May 2000 22:04:40 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005212204.ZM71494@rlyeh.engr.sgi.com> Date: Sun, 21 May 2000 22:04:39 -0700 In-Reply-To: willy@thepuffingroup.com "[fam] Re: [prepatch] Directory Notification" (May 21, 12:18pm) References: <20000519225041.P28590@thepuffingroup.com> <200005201931.PAA07400@shekel.mcl.cs.columbia.edu> <20000521121830.X28590@thepuffingroup.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: willy@thepuffingroup.com, ezk@cs.columbia.edu Subject: [fam] Re: [prepatch] Directory Notification Cc: fam@oss.sgi.com, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I'm not really keen on the idea of adding these extra test-and-call > patches to each time we call a vfs function. What I'd like to do would > be to stack a notification layer on top of a directory, which would > actually just entail replacing its ->i_op with a shim which notified and > then passed the call on. That would involve remembering the original > ->i_op though,and I can't see anywhere convenient to store it. I'd like to see the same thing (for files as well as directories). The existing imon patches (http://oss.sgi.com/projects/fam/imon.txt) also work by adding notification in sys_write etc., but that seemed too lame to post on lkml because it means operations on any file have to pay the price for a service which is used on relatively few files. If modules could easily replace ->i_op (preferably without stomping each other), you could load modules which did whatever they wanted in response to various operations on specific inodes (logging? encrypting data? preventing/redirecting operations?), and performance would only be affected for those inodes who were deliberately being fiddled with. Not only that, but the rest of the filesystem code wouldn't have to know about it, and wouldn't get cluttered up with "now send SIGIO... now notify imon..." etc. after every operation. You could do a lot of neat stuff with that. (Is there already a way to do this?) --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 00:41:56 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 00:41:36 -0700 Received: from behemoth.vergenet.net ([198.186.202.43]:20740 "EHLO behemoth.su.varesearch.com") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 00:41:12 -0700 Received: (from raster@localhost) by behemoth.su.varesearch.com (8.9.3/8.9.3) id AAA01503; Mon, 22 May 2000 00:44:05 -0700 Message-Id: <200005220744.AAA01503@behemoth.su.varesearch.com> Date: Mon, 22 May 2000 00:44:05 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] bug in fam/imon? To: rusty@sgi.com cc: rusty@rlyeh.engr.sgi.com, fam@oss.sgi.com In-Reply-To: <10005211954.ZM71226@rlyeh.engr.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 21 May, Rusty Ballinger scribbled: -> > i just noted theres a bug in fam/imon.. if you monitor a mountpoint -> > thats unmounted - then it gets moutned fam doesn send back exists/add -> > events - it does nothing.. :( -> -> Hey, I just tried that, and it worked for me. The nfs client (where the -> monitoring is being done) is running a 2.2.13 kernel with imon configured -> as a module. Monitoring the mount point, and then mounting a filesystem -> from an irix box with fam, I got a bunch of create events; unmounting it, -> I got a bunch of delete events; then mounting a filesystem from a linux box -> without fam on the same mount point, I got a bunch of create events, and -> then unmounting it, I got the delete events. Is fam failing to monitor -> /etc/mtab or something? Do you see anything interesting if you run fam in -> debug mode? (Either by adding "-d" to the line that starts it in hm good point.. i do run it as a daemon.. um... this isnt nfs tho - it's /mnt/cdrom :) so it shoudl be all nice and local.. -> inetd.conf, and making sure syslogd is sending debug messages somewhere, or -> by starting fam yourself & seeing what it prints out. Remember that if you -> start fam yourself, it registers itself with the portmapper, and -> inetd/portmap will be confused later. I will add "how do I run fam in -> debug mode" to the FAQ.) well i run it from rc.local with -T 0 so it always hangs about.. :) lets see.... fam[1277]: client 6 said: request 4 monitor dir "/mnt/cdrom" fam[1277]: Setting euid to 500 fam[1277]: told imon to monitor "/mnt/cdrom" = dev 8/5, ino 36865 fam[1277]: sent event to client 6: request 4 "/mnt/cdrom" Exists fam[1277]: +chdir to "/mnt/cdrom" fam[1277]: -chdir to "/" fam[1277]: sent event to client 6: request 4 "/mnt/cdrom" EndExist fam[1277]: imon said dev 8/21, ino 36865 changed CONTENT but then i get no "exists" or "add" events... if i go mounting and unmounting it kind of works - but its flakey at best (firts tim i unmounted it sent deletes for the files in /mnt/cdrom - when i remounted they appeard - i got adds but wh i unmoutned again their didnt go away...) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 05:25:37 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 05:25:26 -0700 Received: from TSX-PRIME.MIT.EDU ([18.86.0.76]:22675 "HELO tsx-prime.MIT.EDU") by oss.sgi.com with SMTP id ; Mon, 22 May 2000 05:25:16 -0700 Received: by tsx-prime.MIT.EDU with sendmail-SMI-8.6/1.2, id IAA05370; Mon, 22 May 2000 08:25:05 -0400 Date: Mon, 22 May 2000 08:25:05 -0400 Message-Id: <200005221225.IAA05370@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: willy@thepuffingroup.com CC: Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com In-reply-to: willy@thepuffingroup.com's message of Sun, 21 May 2000 12:18:30 -0400, <20000521121830.X28590@thepuffingroup.com> Subject: [fam] Re: [prepatch] Directory Notification Phone: (781) 391-3464 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Date: Sun, 21 May 2000 12:18:30 -0400 From: willy@thepuffingroup.com Directory notification is a mechanism for informing interested tasks when the contents of a directory change. This has immediate applications for file managers and ps. Samba benefits from this, and there are some non-obvious applications such as a persistent make which perpetually keeps a tree up-to-date by noticing modifications to files. This was discussed on IRC, but for those who weren't there ---- it should be clear that the current implementation uses dentries, so if you have a file which is hard-linked to appear in two different directories, only the parent directory which was used as an access path when the file was changed would get notified. That is, if /usr/foo/changed_file and /usr/bar/changed_file are hard links, and a user-program modifies /usr/foo/changed_file via that pathname, a server who had asked for directory notification on /usr/bar would not get notified that /usr/bar/changed_file had changed. This is a pretty fundamental limitation, and can't really be fixed without using inode numbers as the notification path; but that requires a very different architecture, and that design wouldn't work for those filesystems that don't use inode numbers. Life is full of tradeoffs. A much more obvious place where directory notification won't work is for any kind of shared filesystem --- i.e., GFS, or any other networked filesystem (NFS, smbfs, etc.). But that's for pretty obvious reasons.... This is not to say that willy's work is bad, but people should understand where it works and where (and why) it won't work. - Ted -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 11:26:52 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 11:26:41 -0700 Received: from galaga.cae.wisc.edu ([144.92.240.30]:12794 "EHLO cae.wisc.edu") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 11:26:34 -0700 Received: from mlg-12-1.cae.wisc.edu (mlg-12-1.cae.wisc.edu [144.92.12.138]) by cae.wisc.edu (8.9.1/8.9.0) with ESMTP id NAA25099; Mon, 22 May 2000 13:26:32 -0500 (CDT) Received: (from gerdts@localhost) by mlg-12-1.cae.wisc.edu (8.9.3+Sun/8.9.3) id NAA24712; Mon, 22 May 2000 13:26:32 -0500 (CDT) Date: Mon, 22 May 2000 13:26:32 -0500 From: Michael Gerdts To: "Theodore Y. Ts'o" Cc: willy@thepuffingroup.com, Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification Message-ID: <20000522132631.A24380@cae.wisc.edu> References: <20000521121830.X28590@thepuffingroup.com> <200005221225.IAA05370@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200005221225.IAA05370@tsx-prime.MIT.EDU>; from tytso@MIT.EDU on Mon, May 22, 2000 at 08:25:05AM -0400 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, May 22, 2000 at 08:25:05AM -0400, Theodore Y. Ts'o wrote: > A much more obvious place where directory notification won't work is for > any kind of shared filesystem --- i.e., GFS, or any other networked > filesystem (NFS, smbfs, etc.). But that's for pretty obvious > reasons.... My first thought was along these lines as well. Sun faced a similar situation with POSIX ACL's over NFS. The solution was to make it so that their nfsd added an nfs_acl service, which made commands like getfacl() and setfacl() work properly over NFS. It seems to me that directory notifications could be handled in a similar manner without a whole lot of difficulty. Applications (like always) would just need to be aware that not all file systems will support this feature. Additionall, the NFS client code would need to be aware that the server may not support directory notifications. Come to think of it, this could make it so that when both the NFS client and the NFS server support directory notifications, the NFS client could use this method to enhance the functionality of attribute caching. Then again, I have worked on all of about 3 lines of the NFS code. Mike -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 13:22:53 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 13:22:43 -0700 Received: from charged.uio.no ([129.240.86.49]:47111 "EHLO charged.uio.no") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 13:22:26 -0700 Received: (from trondmy@localhost) by charged.uio.no (8.9.3/8.9.3) id WAA20738; Mon, 22 May 2000 22:22:12 +0200 To: Michael Gerdts Cc: "Theodore Y. Ts'o" , willy@thepuffingroup.com, Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification References: <20000521121830.X28590@thepuffingroup.com> <200005221225.IAA05370@tsx-prime.MIT.EDU> <20000522132631.A24380@cae.wisc.edu> From: Trond Myklebust Date: 22 May 2000 22:22:11 +0200 In-Reply-To: Michael Gerdts's message of "Mon, 22 May 2000 13:26:32 -0500" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Acadia" Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing >>>>> " " == Michael Gerdts writes: > My first thought was along these lines as well. Sun faced a > similar situation with POSIX ACL's over NFS. The solution was > to make it so that their nfsd added an nfs_acl service, which > made commands like getfacl() and setfacl() work properly over > NFS. > It seems to me that directory notifications could be handled in > a similar manner without a whole lot of difficulty. > Applications (like always) would just need to be aware that not > all file systems will support this feature. Additionall, the > NFS client code would need to be aware that the server may not > support directory notifications. This would require some sort of stateful protocol. Anything like this would need very careful planning and design of a protocol in order not to impose too much of a burden on the server. It was easier with ACLs because they don't require anything beyond the usual stateless model. Cheers, Trond -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 14:12:53 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 14:12:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46622 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 14:12:36 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA06438 for ; Mon, 22 May 2000 14:17:13 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id OAA73099; Mon, 22 May 2000 14:10:35 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005221410.ZM66853@rlyeh.engr.sgi.com> Date: Mon, 22 May 2000 14:10:34 -0700 In-Reply-To: raster@rasterman.com "Re: [fam] bug in fam/imon?" (May 22, 12:44am) References: <200005220744.AAA01503@behemoth.su.varesearch.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: raster@rasterman.com Subject: Re: [fam] bug in fam/imon? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > hm good point.. i do run it as a daemon.. um... this isnt nfs tho - > it's /mnt/cdrom :) so it shoudl be all nice and local.. ... > but then i get no "exists" or "add" events... > if i go mounting and unmounting it kind of works - but its flakey at > best (firts tim i unmounted it sent deletes for the files in /mnt/cdrom > - when i remounted they appeard - i got adds but wh i unmoutned again > their didnt go away...) Hey, you're right, with /dev/cdrom, it happens to me too. It looks like there's something weird going on with /etc/mtab. (fam monitors that itself, and when it changes, fam rebuilds its table of mounted filesystems and sends notification for monitored stuff which was just mounted or unmounted.) Anyway, the weird thing about /etc/mtab is its inode number is changing after some operations (so it's being replaced by a new file), and fam isn't noticing subsequent mounts/unmounts. It looks like part of the problem is that FileSystemTable::mtab_event_handler ignores everything except Changed events on /etc/mtab, and part of the problem is that you don't seem to get changed events when you're monitoring a file (not a directory) and someone renames a file over the one you're monitoring. That looks like a problem in imon (as it works on irix running the same fam). --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 15:07:04 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 15:06:43 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:15673 "EHLO rasterman.com") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 15:06:29 -0700 Received: (from raster@localhost) by rasterman.com (8.9.3/8.8.7) id PAA31369; Mon, 22 May 2000 15:07:10 -0700 Message-Id: <200005222207.PAA31369@rasterman.com> Date: Mon, 22 May 2000 15:07:10 -0700 (PDT) From: raster@rasterman.com Reply-To: raster@rasterman.com Subject: Re: [fam] bug in fam/imon? To: rusty@sgi.com cc: rusty@rlyeh.engr.sgi.com, fam@oss.sgi.com In-Reply-To: <10005221410.ZM66853@rlyeh.engr.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On 22 May, Rusty Ballinger scribbled: -> > hm good point.. i do run it as a daemon.. um... this isnt nfs tho - -> > it's /mnt/cdrom :) so it shoudl be all nice and local.. -> ... -> > but then i get no "exists" or "add" events... -> > if i go mounting and unmounting it kind of works - but its flakey at -> > best (firts tim i unmounted it sent deletes for the files in /mnt/cdrom -> > - when i remounted they appeard - i got adds but wh i unmoutned again -> > their didnt go away...) -> -> Hey, you're right, with /dev/cdrom, it happens to me too. It looks like -> there's something weird going on with /etc/mtab. (fam monitors that itself, -> and when it changes, fam rebuilds its table of mounted filesystems and -> sends notification for monitored stuff which was just mounted or unmounted.) -> -> Anyway, the weird thing about /etc/mtab is its inode number is changing -> after some operations (so it's being replaced by a new file), and fam isn't -> noticing subsequent mounts/unmounts. It looks like part of the problem is -> that FileSystemTable::mtab_event_handler ignores everything except Changed -> events on /etc/mtab, and part of the problem is that you don't seem to get -> changed events when you're monitoring a file (not a directory) and someone -> renames a file over the one you're monitoring. That looks like a problem -> in imon (as it works on irix running the same fam). aha! I knew somehting was fishy :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 17:37:34 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 17:37:24 -0700 Received: from cs.columbia.edu ([128.59.16.20]:56819 "EHLO cs.columbia.edu") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 17:37:04 -0700 Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA08531; Mon, 22 May 2000 20:37:01 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id UAA04907; Mon, 22 May 2000 20:37:00 -0400 (EDT) Date: Mon, 22 May 2000 20:37:00 -0400 (EDT) Message-Id: <200005230037.UAA04907@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: willy@thepuffingroup.com Cc: Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification In-reply-to: Your message of "Sun, 21 May 2000 12:18:30 EDT." <20000521121830.X28590@thepuffingroup.com> Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing In message <20000521121830.X28590@thepuffingroup.com>, willy@thepuffingroup.com writes: > On Sat, May 20, 2000 at 03:31:29PM -0400, Erez Zadok wrote: > > I looked briefly at the patch, and I'm afraid I don't understand some basic > > things. Perhaps you can let us (-fsdevel) all know the following (which you > > should probably put in a README on your Web page along w/ the patches): > > > - what is directory notification > > - what is it good for > > Directory notification is a mechanism for informing interested tasks > when the contents of a directory change. This has immediate applications > for file managers and ps. Samba benefits from this, and there are some > non-obvious applications such as a persistent make which perpetually > keeps a tree up-to-date by noticing modifications to files. Do you get notified on any change to the directory, files within, even recursively? Do you get notified if a file's data had changed but the file's [cm]time etc. didn't change? Is an atime update considered a change? I think a mechanism for notification can be very useful, but first you have to decide on what can and/or should be notified. Then on the notification mechanism: should be a pull, push, or register-and-wait-for-event system? There advantages and disadvantages to each mechanism. Your signal method appears OK as a first try. Can you use a better method with a more direct connection b/t a user process and the kernel (a unix pipe, something ala kernel-user netlink, shm, maybe out of kernel RPCs, etc.) I also think you should consider using my stackable templates as a possible starting point. You'd have the advantage of not having to touch the VFS proper, and having this mechanism work on top of all f/s, not just ext2. Erez. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 17:45:14 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 17:45:04 -0700 Received: from cs.columbia.edu ([128.59.16.20]:40695 "EHLO cs.columbia.edu") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 17:45:02 -0700 Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA08983; Mon, 22 May 2000 20:44:59 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id UAA05045; Mon, 22 May 2000 20:44:58 -0400 (EDT) Date: Mon, 22 May 2000 20:44:58 -0400 (EDT) Message-Id: <200005230044.UAA05045@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: willy@thepuffingroup.com Cc: Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification In-reply-to: Your message of "Sun, 21 May 2000 12:18:30 EDT." <20000521121830.X28590@thepuffingroup.com> Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing In message <20000521121830.X28590@thepuffingroup.com>, willy@thepuffingroup.com writes: > On Sat, May 20, 2000 at 03:31:29PM -0400, Erez Zadok wrote: [...] > > - what impact, if any, does your patch have on the rest of the kernel and > > other file systems. > > It delivers a lot more signals when someone's using the feature. > The impact on other filesystems was what I want to ask you about. > I'm currently doing the notify from within the vfs_* functions which > seem the best way to ensure that we don't miss an event. However, it > may be that some of the more unusual filesystems (umsdos? stacking?) call > those functions, leading to a dual-notification. That's not necessarily > a bad thing, but it's suboptimal. My stacking code, as well as other F/S, calls the vfs_* functions. In a stacking environment, you may cause duplicate signals sent for the same event. It might be better for you to do this work in a stackable f/s, from which you can control the lower layer somewhat, and avoid the duplicate signals that way. BTW, this recursive behavior is a problem currently with ->permission, which I hope will be fixed with a proper vfs_permission() function. > I'm not really keen on the idea of adding these extra test-and-call > patches to each time we call a vfs function. What I'd like to do would > be to stack a notification layer on top of a directory, which would > actually just entail replacing its ->i_op with a shim which notified and > then passed the call on. That would involve remembering the original > ->i_op though,and I can't see anywhere convenient to store it. Replacing an existing ->i_op is ugly, and can lead to all kinds of problems, but it's doable. My stacking code doesn't replace existing ->i_op vectors, but rather create a new one for operations that know how to go from one layer to another. (We store lower objects, such as inodes, in the private field of the struct inode.) Erez. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 17:47:34 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 17:47:24 -0700 Received: from cs.columbia.edu ([128.59.16.20]:19192 "EHLO cs.columbia.edu") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 17:47:08 -0700 Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA09091; Mon, 22 May 2000 20:47:06 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id UAA05083; Mon, 22 May 2000 20:47:06 -0400 (EDT) Date: Mon, 22 May 2000 20:47:06 -0400 (EDT) Message-Id: <200005230047.UAA05083@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: rusty@sgi.com Cc: willy@thepuffingroup.com, ezk@cs.columbia.edu, fam@oss.sgi.com, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers.edu Subject: [fam] Re: [prepatch] Directory Notification In-reply-to: Your message of "Sun, 21 May 2000 22:04:39 PDT." <10005212204.ZM71494@rlyeh.engr.sgi.com> Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing In message <10005212204.ZM71494@rlyeh.engr.sgi.com>, "Rusty Ballinger" writes: > > I'm not really keen on the idea of adding these extra test-and-call > > patches to each time we call a vfs function. What I'd like to do would > > be to stack a notification layer on top of a directory, which would > > actually just entail replacing its ->i_op with a shim which notified and > > then passed the call on. That would involve remembering the original > > ->i_op though,and I can't see anywhere convenient to store it. > > I'd like to see the same thing (for files as well as directories). The > existing imon patches (http://oss.sgi.com/projects/fam/imon.txt) also work > by adding notification in sys_write etc., but that seemed too lame to post > on lkml because it means operations on any file have to pay the price for > a service which is used on relatively few files. > > If modules could easily replace ->i_op (preferably without stomping each > other), you could load modules which did whatever they wanted in response > to various operations on specific inodes (logging? encrypting data? > preventing/redirecting operations?), and performance would only be affected > for those inodes who were deliberately being fiddled with. Not only that, > but the rest of the filesystem code wouldn't have to know about it, and > wouldn't get cluttered up with "now send SIGIO... now notify imon..." etc. > after every operation. > > You could do a lot of neat stuff with that. (Is there already a way to do > this?) > > --Rusty What you're describing is called stackable file systems, which I've created under Linux. I have an encryption f/s, compression f/s, and several other samples---all built on top of "generic" stacking templates. See http://www.cs.columbia.edu/~ezk/research/fist/ Erez. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Mon May 22 22:57:56 2000 Received: by oss.sgi.com id ; Mon, 22 May 2000 22:57:46 -0700 Received: from [216.208.98.3] ([216.208.98.3]:55817 "EHLO gin.ext.thepuffingroup.com") by oss.sgi.com with ESMTP id ; Mon, 22 May 2000 22:57:20 -0700 Received: (from willy@localhost) by gin.ext.thepuffingroup.com (8.9.3/8.9.3) id CAA32366; Tue, 23 May 2000 02:56:36 -0400 Date: Tue, 23 May 2000 02:56:36 -0400 From: willy@thepuffingroup.com To: "Theodore Y. Ts'o" Cc: Erez Zadok , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, tridge@linuxcare.com, fam@oss.sgi.com Subject: [fam] Re: [prepatch] Directory Notification Message-ID: <20000523025636.E24370@thepuffingroup.com> References: <20000521121830.X28590@thepuffingroup.com> <200005221225.IAA05370@tsx-prime.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <200005221225.IAA05370@tsx-prime.MIT.EDU>; from Theodore Y. Ts'o on Mon, May 22, 2000 at 08:25:05AM -0400 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing On Mon, May 22, 2000 at 08:25:05AM -0400, Theodore Y. Ts'o wrote: > This was discussed on IRC, but for those who weren't there ---- it > should be clear that the current implementation uses dentries, so if you > have a file which is hard-linked to appear in two different directories, > only the parent directory which was used as an access path when the file > was changed would get notified. *nod*. I don't see this as too big a problem. Hard links are relatively uncommon; particularly in the context where we immediately plan to use this. > A much more obvious place where directory notification won't work is for > any kind of shared filesystem --- i.e., GFS, or any other networked > filesystem (NFS, smbfs, etc.). But that's for pretty obvious > reasons.... Not necessarily. SMB has the NT_TRANSACT_NOTIFY_CHANGE call which SMB could implement. I haven't done this as part of my patch; but the i_op->fasync entry is per-filesystem, and SMB could have its own special one to invoke this call. I thought about this carefully and decided to put the default one in the network filesystems anyway as they can still receive notifications whenever something changes locally. > This is not to say that willy's work is bad, but people should > understand where it works and where (and why) it won't work. one of the things which concerns me most is that we throw away much of the information about what changed because there isn't enough defined space in the signal structure. There's plenty of space available (there's something like 116 bytes unused). It'd be nice to say _which_ event caused the notification. I suspect there would be some resistance to defining a new field in the SIGPOLL arm of the union at this point though. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 23 21:31:59 2000 Received: by oss.sgi.com id ; Tue, 23 May 2000 21:31:50 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17708 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 23 May 2000 21:31:39 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA10510 for ; Tue, 23 May 2000 21:26:47 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id VAA23207; Tue, 23 May 2000 21:28:35 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005232128.ZM122979@rlyeh.engr.sgi.com> Date: Tue, 23 May 2000 21:28:34 -0700 In-Reply-To: Erez Zadok "Re: [prepatch] Directory Notification" (May 22, 8:47pm) References: <200005230047.UAA05083@shekel.mcl.cs.columbia.edu> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: ezk@cs.columbia.edu Subject: [fam] Re: [prepatch] Directory Notification Cc: fam@oss.sgi.com, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers.edu, willy@thepuffingroup.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing ezk: > rusty: > > willy: > > > What I'd like to do would be to stack a notification layer on top of > > > a directory, which would actually just entail replacing its ->i_op > > > with a shim which notified and then passed the call on. ... > > If modules could easily replace ->i_op (preferably without stomping each > > other), you could load modules which did whatever they wanted in response > > to various operations on specific inodes ... > What you're describing is called stackable file systems, which I've created > under Linux. I have an encryption f/s, compression f/s, and several other > samples---all built on top of "generic" stacking templates. See > > http://www.cs.columbia.edu/~ezk/research/fist/ Is there a way to wrap operations on a single file or directory without affecting operations on other files in or below that directory? If I understand correctly, you'd have to overlay mount your wrapfs-fs on the file's directory, and on every subsequent operation on files under that mount point, determine whether or not the operation was on the inode(s) you were interested in. That's an improvement over the way imon works now, and I will try it out, but I'd prefer it to work as willy described. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 24 04:11:42 2000 Received: by oss.sgi.com id ; Wed, 24 May 2000 04:11:32 -0700 Received: from f196.law8.hotmail.com ([216.33.241.196]:18952 "HELO hotmail.com") by oss.sgi.com with SMTP id ; Wed, 24 May 2000 04:11:17 -0700 Received: (qmail 55332 invoked by uid 0); 24 May 2000 11:11:01 -0000 Message-ID: <20000524111101.55331.qmail@hotmail.com> Received: from 203.198.124.96 by www.hotmail.com with HTTP; Wed, 24 May 2000 04:11:01 PDT X-Originating-IP: [203.198.124.96] From: "chi li" To: fam@oss.sgi.com Subject: [fam] how fam should work? Date: Wed, 24 May 2000 19:11:01 CST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing hello i patched the 2.2.14 kernel with imon sucessfully, when i exec. fam , it tells me the "cannot register service: RPC: Unable to receive; errno= connection refused fam[914]: can't register with portmapper" so what can i do? how can i test my imon is working or not? please tell me about the method of lauching imon and fam~~ thank you for your help! alanli ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 24 09:48:55 2000 Received: by oss.sgi.com id ; Wed, 24 May 2000 09:48:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:30020 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 24 May 2000 09:48:28 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA18529 for ; Wed, 24 May 2000 09:43:35 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA53903 for ; Wed, 24 May 2000 09:47:57 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id JAA18062; Wed, 24 May 2000 09:44:40 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005240944.ZM123430@rlyeh.engr.sgi.com> Date: Wed, 24 May 2000 09:44:39 -0700 In-Reply-To: "chi li" "[fam] how fam should work?" (May 24, 7:11pm) References: <20000524111101.55331.qmail@hotmail.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: alanli888@hotmail.com Subject: Re: [fam] how fam should work? Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > i patched the 2.2.14 kernel with imon sucessfully, when i exec. fam , > it tells me the > "cannot register service: RPC: Unable to receive; errno= connection refused > fam[914]: can't register with portmapper" Is the portmapper running? You can test this by going "rpcinfo -p", and that should give you a list of services which have registered with the portmapper. If it's not, in your /etc/init.d/ or /etc/rc.d/init.d/, there should be a script, probably either "portmap" or "network", which will start the portmapper. ("fgrep portmap *" in /etc/init.d or rc.d/init.d/ to find out which init script to use.) If you need more detailed instructions, or if that doesn't help, send mail to me (rusty@sgi.com) instead of the fam list & we'll see if we can figure out the problem. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Wed May 24 19:59:28 2000 Received: by oss.sgi.com id ; Wed, 24 May 2000 19:59:18 -0700 Received: from cs.columbia.edu ([128.59.16.20]:10913 "EHLO cs.columbia.edu") by oss.sgi.com with ESMTP id ; Wed, 24 May 2000 19:59:08 -0700 Received: from shekel.mcl.cs.columbia.edu (shekel.mcl.cs.columbia.edu [128.59.18.15]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA23809; Wed, 24 May 2000 23:59:06 -0400 (EDT) Received: (from ezk@localhost) by shekel.mcl.cs.columbia.edu (8.9.3/8.9.3) id XAA28739; Wed, 24 May 2000 23:59:06 -0400 (EDT) Date: Wed, 24 May 2000 23:59:06 -0400 (EDT) Message-Id: <200005250359.XAA28739@shekel.mcl.cs.columbia.edu> From: Erez Zadok To: rusty@sgi.com Cc: ezk@cs.columbia.edu, fam@oss.sgi.com, linux-fsdevel@vger.rutgers.edu, linux-kernel@vger.rutgers.edu, willy@thepuffingroup.com Subject: [fam] Re: [prepatch] Directory Notification In-reply-to: Your message of "Tue, 23 May 2000 21:28:34 PDT." <10005232128.ZM122979@rlyeh.engr.sgi.com> Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing In message <10005232128.ZM122979@rlyeh.engr.sgi.com>, "Rusty Ballinger" writes: > ezk: > > rusty: > > > willy: > > > > What I'd like to do would be to stack a notification layer on top of > > > > a directory, which would actually just entail replacing its ->i_op > > > > with a shim which notified and then passed the call on. > ... > > > If modules could easily replace ->i_op (preferably without stomping each > > > other), you could load modules which did whatever they wanted in response > > > to various operations on specific inodes > ... > > What you're describing is called stackable file systems, which I've created > > under Linux. I have an encryption f/s, compression f/s, and several other > > samples---all built on top of "generic" stacking templates. See > > > > http://www.cs.columbia.edu/~ezk/research/fist/ > > Is there a way to wrap operations on a single file or directory without > affecting operations on other files in or below that directory? If I > understand correctly, you'd have to overlay mount your wrapfs-fs on the > file's directory, and on every subsequent operation on files under that > mount point, determine whether or not the operation was on the inode(s) > you were interested in. That's an improvement over the way imon works > now, and I will try it out, but I'd prefer it to work as willy described. > > --Rusty It's possible to do what you want, but it complicates stacking considerably. Consider how you'd have to carefully handle the ".." chdir case from a non-stacked directory up to one which is (partially) stacked. You can't do it without somehow maintaining some state in the node (inode, dentry, whatever) of where you came from (or who is the real or desired parent). It is easier and cleaner to stack on every file or directory, as it gives you the opportunity to modify the behavior, data, etc. of these objects. In addition, the performance overhead of null-layer stacking can be really small (I measured it to be 1-2%). If you want different behavior for certain files or directories, that can be done. You can start w/ the default null-layer stackable f/s (nullfs, lofs, wrapfs, whatever the name happens to be that week :-) and you apply your changed behavior for given files or directories based on their name. You can store different operations vectors (->i_op, ->f_op, ->d_op, etc.) for the files you want to change, and default to the pass-through null-layer ops for all others. Ion and I used such a technique in usenetfs, a stackable f/s that breaks large flat USENET directories into a deeper hierarchy of directories based on a hash of the article file name. So for example, the article control/cancel/123456 was transparently moved to control/cancel/345/123456; this was of course to improve access to these large flat directories w/o changing the format of the low-level f/s. But we didn't want to do it for all article directories, only for those which were really large on our news server (such as control/cancel, misc/jobs, etc.) So we devised usenetfs to be a regular pass-through null-layer f/s, and only turn on the special nested directory structure code for directories that were flagged that way; we co-opted the (seldom-used) setuid bit on directories as our trigger. Erez. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 09:57:56 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 09:57:29 -0700 Received: from citycenter.citilink.com ([209.98.8.5]:56199 "EHLO citycenter.citilink.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 09:02:59 -0700 Received: from relay.citilink.com (root@as5300-1-100.mpls.citilink.com [209.98.9.131]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id LAA02648 for ; Fri, 26 May 2000 11:58:17 -0500 (CDT) Posted-Date: Fri, 26 May 2000 11:58:17 -0500 (CDT) Received: (from chris@localhost) by relay.citilink.com (8.9.3/8.9.3) id LAA03209 for fam@oss.sgi.com; Fri, 26 May 2000 11:53:43 -0500 Date: Fri, 26 May 2000 11:53:43 -0500 From: Chris Siegler To: fam@oss.sgi.com Subject: [fam] ftp down Message-ID: <20000526115343.A3195@relay.citilink.com> Mail-Followup-To: Chris Siegler , fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Is there a mirror of the imon tarball somewhere? The ftp site has been down for two days now. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 10:56:27 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 10:56:16 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:1974 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 10:56:07 -0700 Received: from atsystem1.informatik.tu-muenchen.de ([131.159.8.165] HELO atsystem1.informatik.tu-muenchen.de ident: postfix [port 38130]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <111335-19363>; Fri, 26 May 2000 14:34:05 +0000 Received: from in.tum.de (kreibich.modem.informatik.tu-muenchen.de [172.16.1.68]) by atsystem1.informatik.tu-muenchen.de (Postfix) with ESMTP id 2A8E084A9 for ; Fri, 26 May 2000 14:33:49 +0200 (MET DST) Message-ID: <392AA439.C1112C47@in.tum.de> From: Christian Kreibich Organization: Technische Universitaet Muenchen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] FAM port to Solaris. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 May 2000 14:33:54 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi, I've ported fam 2.6.3 to Solaris. Unfortunately I cannot test it right now, since I don't have root access to Solaris machines. This is an updated version of the port though, and the feedback on the 2.6.2 port was positive (on the Enlightenment mailing list). The port compiles on Solaris 2.6 and 2.7 as well as Linux. I couldn't test on sgi's though. It's up on http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.tar.gz The equivalent patch is at http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.patch I'll be glad to hear any feedback. I won't be able to test it myself before next week. Best regards, -- Christian. _______________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 11:13:06 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 11:12:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:25162 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 11:12:36 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA16953 for ; Fri, 26 May 2000 12:07:42 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA08779 for ; Fri, 26 May 2000 12:10:49 -0700 (PDT) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id MAA67866; Fri, 26 May 2000 12:07:35 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005261207.ZM259401@rlyeh.engr.sgi.com> Date: Fri, 26 May 2000 12:07:34 -0700 In-Reply-To: Chris Siegler "[fam] ftp down" (May 26, 11:53am) References: <20000526115343.A3195@relay.citilink.com> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: siegler@citilink.com Subject: Re: [fam] ftp down Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Is there a mirror of the imon tarball somewhere? The ftp site has been down > for two days now. Hey, I just tried it from home through my ISP about 20 minutes ago, and it was fine; is it still not working for you? --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 11:23:06 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 11:22:56 -0700 Received: from citycenter.citilink.com ([209.98.8.5]:65172 "EHLO citycenter.citilink.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 11:22:34 -0700 Received: from relay.citilink.com (root@as5300-1-173.mpls.citilink.com [209.98.9.204]) by citycenter.citilink.com (8.8.8/8.7.5) with ESMTP id OAA27082 for ; Fri, 26 May 2000 14:18:08 -0500 (CDT) Posted-Date: Fri, 26 May 2000 14:18:08 -0500 (CDT) Received: (from chris@localhost) by relay.citilink.com (8.9.3/8.9.3) id OAA03731 for fam@oss.sgi.com; Fri, 26 May 2000 14:11:53 -0500 Date: Fri, 26 May 2000 14:11:53 -0500 From: Chris Siegler To: fam@oss.sgi.com Subject: Re: [fam] ftp down Message-ID: <20000526141153.A3708@relay.citilink.com> Mail-Followup-To: Chris Siegler , fam@oss.sgi.com References: <20000526115343.A3195@relay.citilink.com> <10005261207.ZM259401@rlyeh.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <10005261207.ZM259401@rlyeh.engr.sgi.com>; from rusty@rlyeh.engr.sgi.com on Fri, May 26, 2000 at 12:07:34PM -0700 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Rusty Ballinger wrote: > Hey, I just tried it from home through my ISP about 20 minutes ago, and it > was fine; is it still not working for you? > It works now. -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 11:43:07 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 11:42:57 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:22712 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 11:42:46 -0700 Received: from atsystem1.informatik.tu-muenchen.de ([131.159.8.165] HELO atsystem1.informatik.tu-muenchen.de ident: postfix [port 39006]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <110963-19360>; Fri, 26 May 2000 21:42:44 +0000 Received: from in.tum.de (kreibich.modem.informatik.tu-muenchen.de [172.16.1.68]) by atsystem1.informatik.tu-muenchen.de (Postfix) with ESMTP id CE85984D8 for ; Fri, 26 May 2000 21:42:37 +0200 (MET DST) Message-ID: <392ED433.66046E39@in.tum.de> From: Christian Kreibich Organization: Technische Universitaet Muenchen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: [fam] Re: FAM port to Solaris. References: <392AA439.C1112C47@in.tum.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 May 2000 21:42:40 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Oh damn, I forgot -- thanks to Michael Lea (michael@widgetworks.com) for helping me debugging ... sorry Michael. Regards, -- Christian. _______________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich Christian Kreibich wrote: > > Hi, > > I've ported fam 2.6.3 to Solaris. Unfortunately I cannot test it right > now, since I don't have root access to Solaris machines. This is an > updated version of the port though, and the feedback on the 2.6.2 port > was positive (on the Enlightenment mailing list). > > The port compiles on Solaris 2.6 and 2.7 as well as Linux. I couldn't > test on sgi's though. It's up on > > http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.tar.gz > > The equivalent patch is at > > http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.patch > > I'll be glad to hear any feedback. I won't be able to test it myself > before next week. > > Best regards, > -- Christian. > _______________________________________________________________________ > mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 12:37:07 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 12:36:57 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54533 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 12:36:44 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05651 for ; Fri, 26 May 2000 13:41:26 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id NAA71288; Fri, 26 May 2000 13:34:40 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005261334.ZM267864@rlyeh.engr.sgi.com> Date: Fri, 26 May 2000 13:34:39 -0700 In-Reply-To: Christian Kreibich "[fam] FAM port to Solaris." (May 26, 2:33pm) References: <392AA439.C1112C47@in.tum.de> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: kreibich@informatik.tu-muenchen.de Subject: Re: [fam] FAM port to Solaris. Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > I've ported fam 2.6.3 to Solaris. Unfortunately I cannot test it right > now, since I don't have root access to Solaris machines. This is an > updated version of the port though, and the feedback on the 2.6.2 port > was positive (on the Enlightenment mailing list). > > The port compiles on Solaris 2.6 and 2.7 as well as Linux. I couldn't > test on sgi's though. It's up on > > http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.tar.gz > > The equivalent patch is at > > http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.3.patch > > I'll be glad to hear any feedback. I won't be able to test it myself > before next week. Your changes do build OK on IRIX. I have a version 2.6.4 (done last week, actually; I just never got around to moving it out) which I might be able to put out today or this weekend; next week if you're happy with your testing on Solaris I'll include your changes in 2.6.5. (I will probably mess with the #defines a bit; to conditionally #include sys/mntent.h vs. mntent.h, I'd rather use a symbol like HAVE_SYS_MNTENT_H than HAVE_SUN. If I do that, will it be OK if I mail you patches to make sure they still compile on your box?) --Rusty P.S. Just out of curiosity, what was the matter with having variables named "sun"? -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 13:40:39 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 13:40:30 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:38844 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 13:40:09 -0700 Received: from atsystem1.informatik.tu-muenchen.de ([131.159.8.165] HELO atsystem1.informatik.tu-muenchen.de ident: postfix [port 39124]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <111288-19360>; Fri, 26 May 2000 23:39:51 +0000 Received: from in.tum.de (kreibich.modem.informatik.tu-muenchen.de [172.16.1.68]) by atsystem1.informatik.tu-muenchen.de (Postfix) with ESMTP id 3C8AA84DD for ; Fri, 26 May 2000 23:39:38 +0200 (MET DST) Message-ID: <392EEF9F.CDF58C17@in.tum.de> From: Christian Kreibich Organization: Technische Universitaet Muenchen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: Re: [fam] FAM port to Solaris. References: <392AA439.C1112C47@in.tum.de> <10005261334.ZM267864@rlyeh.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 26 May 2000 23:39:41 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi Rusty Rusty Ballinger wrote: > > Your changes do build OK on IRIX. Hey, great :) > I have a version 2.6.4 (done last week, > actually; I just never got around to moving it out) which I might be able > to put out today or this weekend; next week if you're happy with your > testing on Solaris I'll include your changes in 2.6.5. (I will probably > mess with the #defines a bit; to conditionally #include sys/mntent.h vs. > mntent.h, I'd rather use a symbol like HAVE_SYS_MNTENT_H than HAVE_SUN. Yeah, whatever you want. I was just basically looking for a way to have an #ifdef condition that's true whenever I'm on a Sun. > If I do that, will it be OK if I mail you patches to make sure they still > compile on your box?) Of course, no problem. Is there any way that I'll not have to do the port again? (I mean, from 2.6.4 to a possible 2.6.5? I guess my patch won't work on 2.6.4 ...) > P.S. Just out of curiosity, what was the matter with having variables > named "sun"? Somehow (you know it's not like I'm a Solaris expert) "sun" was #defined to be 1. I got tons of errors whenever "sun" was used as a variable -- just changing the name stopped that. Best regards, -- Christian. _______________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 13:48:29 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 13:48:19 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50955 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 13:48:16 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA05761 for ; Fri, 26 May 2000 14:52:58 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id OAA74101; Fri, 26 May 2000 14:46:12 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005261446.ZM273959@rlyeh.engr.sgi.com> Date: Fri, 26 May 2000 14:46:11 -0700 In-Reply-To: Christian Kreibich "Re: [fam] FAM port to Solaris." (May 26, 11:39pm) References: <392AA439.C1112C47@in.tum.de> <10005261334.ZM267864@rlyeh.engr.sgi.com> <392EEF9F.CDF58C17@in.tum.de> X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: kreibich@informatik.tu-muenchen.de Subject: Re: [fam] FAM port to Solaris. Cc: fam@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing > Is there any way that I'll not have to do the port again? (I mean, from > 2.6.4 to a possible 2.6.5? I guess my patch won't work on 2.6.4 ...) No, I bet it will work; if it doesn't, it should be easy to straighten out, so you won't have to do it again. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Fri May 26 20:31:11 2000 Received: by oss.sgi.com id ; Fri, 26 May 2000 20:31:01 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:65050 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 26 May 2000 20:30:46 -0700 Received: from rlyeh.engr.sgi.com (rlyeh.engr.sgi.com [163.154.5.94]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA02683 for ; Fri, 26 May 2000 21:35:26 -0700 (PDT) mail_from (rusty@rlyeh.engr.sgi.com) Received: (from rusty@localhost) by rlyeh.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id VAA60752 for fam@oss.sgi.com; Fri, 26 May 2000 21:29:10 -0700 (PDT) From: "Rusty Ballinger" Message-Id: <10005262129.ZM273808@rlyeh.engr.sgi.com> Date: Fri, 26 May 2000 21:29:09 -0700 X-Face: #)4}U4e`O6YEe%oBzE}>ycmT!Xt?Myiqo~|p3Wh'UuQ[N7)&4\4?8:1n)bmPX]b@#k94%!VojpODdmk:sCr1b\-aXD&P:wjBqupMB:ag6}BwVseJZM@K{$E|0J9}&,Rpdg{&N4/Y8&PTm6>|r[,gI2T*qN!`AZhl>Bdy7JR`dDvP(/pz.}?Q@dg':mlV`RX51Z_ZG?Gta|Q!iA[MaOh Reply-To: rusty@sgi.com X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: fam@oss.sgi.com Subject: [fam] fam-oss-2.6.4 available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Aside from a barely-perceptible API change, the big deal about this version is that it adds & removes itself in /etc/inetd.conf, /etc/rpc, and /etc/ld.so.conf as needed when installed & uninstalled. The script which does this isn't specific to fam; feel free to use it in other open-source projects that need to add or remove configuration file lines. If you try it out and come up with improvements (or if you know of a better replacement), please let me know. Also definitely let me know if it does anything stupid. I actually put this version together last week, so it doesn't include Christian Kreibich's changes for building on Solaris. (That will probably be next week, or the week after as I'll be taking a bit of vacation.) Once again, a plug for a neat thing introduced in the last version (well I think it's cool): ./configure make rpm rpm -i build/rpm/fam-2.6.4-1.i386.rpm Here's the change log. fam-oss-2.6.4 Stupid, gratuitous breakage of the FAM API introduced by Rusty in 2.6.0, and only partially fixed in 2.6.1, is fixed "again." The difference is that FAMPending now returns 1 instead of -1 on error/EOF. Both "make install" and the RPM packages generated by "make rpm" now add fam to /etc/rpc and /etc/inetd.conf, and /usr/local/lib (or wherever libfam.so is installed) to /etc/ld.so.conf if it's not already there. libfam includes a list of exported symbols (only the symbols in fam.h), even though there seem to be some issues with libtool handling them correctly. Thanks to Waldo Bastian for pointing me at the right libtool option. The last version contained another gross failure to build without imon support on Linux, introduced by Rusty, fixed in this version by Wesley Smith. The fam(3X) man page is more clear about how to use FAMPending and FAMNextEvent. --Rusty -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 30 10:09:28 2000 Received: by oss.sgi.com id ; Tue, 30 May 2000 10:09:08 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:24473 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Tue, 30 May 2000 09:03:59 -0700 Received: from atsystem1.informatik.tu-muenchen.de ([131.159.8.165] HELO atsystem1.informatik.tu-muenchen.de ident: postfix [port 48306]) by tuminfo2.informatik.tu-muenchen.de with SMTP id <111624-12988>; Tue, 30 May 2000 19:03:17 +0000 Received: from in.tum.de (lxjessen1.informatik.tu-muenchen.de [131.159.20.25]) by atsystem1.informatik.tu-muenchen.de (Postfix) with ESMTP id 9924C85BF for ; Tue, 30 May 2000 19:03:08 +0200 (MET DST) Message-ID: <3933496F.CE13B9B1@in.tum.de> From: Christian Kreibich Organization: Technische Universitaet Muenchen X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: fam@oss.sgi.com Subject: Re: [fam] Update of Solaris port to 2.6.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 30 May 2000 19:03:10 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi again, uhm ... well actually it was supposed to be an update of the port of 2.6.4 to Solaris *grin*. I've tested it for some time now and I think it works fine. Mark Bowyer noticed that the build was in fact broken on Solaris 2.6 because of the word "sinclude" at the end of fam/Makefile and support/Makefile and suggested to add a ":" to the end, which I did -- An include with a nonexistent file would abort anyway, so it's probably supposed to be a target? Solaris 2.7 ignored the line and moved on. Best regards, -- Christian. _______________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com From owner-fam@oss.sgi.com Tue May 30 10:09:38 2000 Received: by oss.sgi.com id ; Tue, 30 May 2000 10:09:09 -0700 Received: from tuminfo2.informatik.tu-muenchen.de ([131.159.0.81]:52876 "EHLO tuminfo2.informatik.tu-muenchen.de") by oss.sgi.com with ESMTP id ; Tue, 30 May 2000 06:54:40 -0700 Received: from sunhalle4.informatik.tu-muenchen.de ([131.159.4.148] EHLO sunhalle4.informatik.tu-muenchen.de ident: kreibich [port 60941]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <110768-12989>; Tue, 30 May 2000 16:53:57 +0000 From: Christian Kreibich To: fam@oss.sgi.com Subject: [fam] Update of Solaris port to 2.6.4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 30 May 2000 16:53:53 +0000 Sender: owner-fam@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;fam-outgoing Hi all, I've updated the port to the 2.6.4 release. Rusty, you were absolutely right, the old patch applied almost immediately. It's untested, but I'll hopefully be able to do some testing over the next couple of hours. If anyone wants to check it out please definitely do so and provide feedback. http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.4.patch http://www.in.tum.de/~kreibich/downloads/fam-oss-2.6.4.tar.gz Best regards, -- Christian. ________________________________________________________________________ mailto:kreibich@in.tum.de http://www.in.tum.de/~kreibich -- Source code, list archive, and docs: http://oss.sgi.com/projects/fam/ To unsubscribe: echo unsubscribe fam | mail majordomo@oss.sgi.com