On Thu, Mar 21, 2002 at 07:39:19PM -0700, Jon Arney wrote: > Actually, I didn't even know it existed. If you point me at the source, > I'll look at it and see if it's useful to me.
Might be at Neal's web site (ftp.walfield.org), or just try google. James has a collection on his site, I read here ;) > After writing it, I also realize that the data obtained through /proc > comes from a multitude of sources under the Hurd because of the > division of responsibilities in the system. That's one of the problems. The complementary problem is that it can't even gather the data from all relevant sources, because there is no repository that tells it where those sources are (eg there could be more than one proc server). Not that we would want it to gather the data from all sources, this would break the encapsulation (you use a second proc server exactly to hide your processes from the main system ;) > My reasons for doing it were to a) learn the Hurd architecture, get > warmed up for a more "substantive" project. and b) to get a little > "feeling of home" as you put it. Wonderful reasons to do it, as I said. No question about that. I just hope that other people choose different traslators, so that we don't end up with 20 procfs implementations over the years ;-) OTOH, we have 40 editors and 30 window managers, so why not likewise for /proc... > When I tell Linux users about the Hurd, the first question out of their > mouths is 'what does /proc' look like. That is usually a wonderful time to explain to them why /proc doesn't cut it on the Hurd ;) Mmmh. Do you think the curiosity for bogo mips /proc/cpuinfo might be a substitute for lack of other interesting concepts in Linux... probably not... <evil plan> We should write up some funny /proc/cpuinfo et all and include them as ascii files in the distribution. </> > I agree with this point and as I was hacking, it occured to me that some > of the Hurd translators should/could provide more information about what > they're doing. I was writing my mail without need, your thoughts already wander all in the right directions. Just keep going! (Although I don't think we have all made our mind up how to do complex configuration and reporting in the individual cases. A filesystem is always tempting, sometimes extra RPCs might be better, don't rule them out when pondering it). > Another good idea. Forgive my simple-minded-ness, but a simple > approach to the problem might be for filesystems to voluntarily > register themselves by simply writing to /etc/mtab as a real > file. Is this a job that really needs a translator to do? > Writing an RPC to a translator is similar to simply opening /etc/mtab > (except of course, for the root which might require special > consideration). Ok, I will tell you my idea. What you said would work, except that it wouldn't ensure that filesystems are removed when they die. So the mtab server has to keep track of the server life span. This is done with death notification messages on mach ports. To make the implementation easy, I recommended toNick to just let the server open the /etc/mtab "file" active translator) with O_WRONLY, which means that the file gets special semantics: The server will write one line into it, which is the path name it claims it is attached to. The mtab server will use the path, and lookup the port. It will expect a translator there, and set it the fsys_get_options rpc to retrieve the argument line. This includes information about the filesystem type (strip leading /hurd/ and trailing "fs") and the file system options. From this information, it constructs the mtab entry (whic is of course returned as a list if you open with O_RDONLY). Now the trick is that the server will keep the file handle (port to mtab) open, it does not close it. If it wants to update the info (mv /local/mnt /mnt; fsysopts /mnt --mtab /mnt), it just writes another line. The mtab server will then update the info (only the last line written counts). When the file handle is closed, the mtab sevrer will remove the entry. This can be because the user requested that the filesystem does not register itself (fsysopts /mnt --no-mtab), or because the server died. The alternative to this is to have some real RPCs for this (exchanging ports etc). But I think this is unnecessary, as the above scheme fits the expectations quite nicely. Thanks Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
