Linux-Development-Sys Digest #533, Volume #6 Fri, 26 Mar 99 03:14:14 EST
Contents:
Re: How about /dev/web? (Christopher B. Browne)
Re: How about /dev/web? (Alexander Viro)
Re: How about /dev/web? (Alexander Viro)
Re: Debugging terrible stack corruption problems - tips or tools? (Justin Vallon)
Re: How about /dev/web? (Craig Kelley)
Re: Stack dump from signal handler (Andi Kleen)
Re: bzImage won't boot ("John R. Owens")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.emacs,gnu.misc.discuss
Subject: Re: How about /dev/web?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 26 Mar 1999 05:00:16 GMT
On 25 Mar 1999 21:39:51 -0500, Alexander Viro <[EMAIL PROTECTED]> posted:
>In article <GLAK2.5802$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>>Note that the Hurd "filesystem translator" notion, for which a Linux
>>daemon *has* been created, does provide generally this sort of
>>functionality, essentially allowing you to try to access web information
>>as if it were a filesystem.
> URLs to papers?
That one may not actually have been implemented yet.
>>Hurd allows "mounting" FTP connections as if they were filesystems; the
>>password authentication takes place at the point at which the mount is
>>attempted.
> Could you give some details? On what level of stack it happens?
>What warranties does it provide?
See: <http://www.gnu.ai.mit.edu/software/hurd/hurd-paper.html>, which
describes this in greater detail than it makes sense to present here.
>[snip]
>>Note that the "mount" pushes *absolutely nothing* of this process into
>>the kernel, since mount is a user-space program, not a kernel-space
>>program. That's the insight that Ryan seems not to have seen, and it's
>>not something that is *blindingly* obvious when you consider that
>>"mount" is one of those programs that sits at the edge between
>>kernel-mode and user-mode.
> Yes. But cd isn't. Moreover, if you are into the HTTP stuff
>you don't have a persistent connection and every request may take
>separate validation. Mount on each and every page?
In the case of FTP, "Parts of [this] command could be left out and the
transparent FTP program would read them from a user's .netrc file."
For HTTP, there would evidently be a need for some mechanism to handle
validation for sites that require challenge/response. It would be sensible
to use something like the .netrc method to make this information persistent.
>>>>Seems like an ideal way to make all legacy applications internet ready.
>>>
>>>Wake me up when you will implement lseek() and mmap() over FTP. FTP is not
>>>a filesystem. HTTP is not a filesystem. BTW, could you tell me how to
>>>implement locks over these protocols?
>>
>>This *doesn't* establish that it's a dumb idea to try to treat FTP as a
>>sort of filesystem, merely that the semantics will differ from ext2,
>>much as the semantics of ext2 already differ assortedly from NFS, CODA,
>>UMSDOS, procfs, reiserfs, et al.
>
> Semantics of NFS is *very* unpleasant to deal with, especially
>without working lockd. CODA is much more graceful (and closer to ext2 and
>reiserfs). procfs is in bad need of cleanup and I'm not happy about the
>pseudo-symlinks in /proc/<pid>/fd/ - they are not. Running anything on
>/proc is not too good idea. It's definitely not an fs for general-purpose
>data, whatever it means. UMSDOS... <censored><censored><censored> I don't
>know how Matija manages to keep sanity working on it. It's full of races
>and that's not exactly UMSDOS fault - underlying stuff in msdosfs and FAT
>is race-ridden too. I've more or less finished with MSDOS/VFAT/FAT cleanup
>(constant inumbers and got rid of tens of bad races). I'm less than happy
>about the next step ;-/ Especially with the way hardlinks are represented.
>UMSDOS *tries* to reproduce sane semantics. The problem being, it's very
>hard to do (a) atop of the racey fs driver, (b) outside of VFS (UMSDOS tries
>to implement layered filesystem a-la 4.4BSD ones), (c) atop of very sick
>and twisted data structures (FAT-derived fs layout).
> As for ftpfs I don't think that it can be done in the kernel without
>the layered fs support. In the userspace you can try to implement NFS-to-FTP
>proxy. Not too pleasant. More-or-less clear solution might go along the
>lines of mirror-on-demand, but that requires (a) portalfs or equivalent and
>(b) infrastructure for layering. Otherwise you'll get yet another partial
>copy of said infrastructure, with its own set of bugs and races, lurking in
>fs/*/*. We already got 3 - the most clean is in CODA, but it almost doesn't
>touch namespace stuff; weird one in HFS (ad-hoc needed to deal with forks)
>and one in UMSDOS (see above). All 3 are mutually incompatible - merging them
>is harder than writing from scratch.
There's no promises that this is all easy...
>>Probably a sign of having vaguely gathered the notion of Name Spaces,
>>thinking it might be useful on the Internet, and then not being aware of
>>relevant seminal works such as
>><http://plan9.bell-labs.com/plan9/doc/names.html>, "The Use of Name
>>Spaces in Plan 9." (And that paper may have further references that may
>>be considered previous to it...)
>
> I wish we could do it on Linux VFS. Not yet and will not
>be there for quite a while - it's *not* likely to be doable in 2.3 (OK,
>unless 2.3 will take the same time as 2.1...).
There's enough relevant traffic on the reiserfs mailing list between Hans
Reiser and Steven Tweedie to indicate that effort is definitely going into
VFS, which is somewhat encouraging.
The other alternative for many of these sorts of things is to stick an NFS
server in the way. That's the approach taken by "Podfuk" (which "wants to
replace userfs").
My suspicion is that the most fruitful approach would probably be for
someone to write an NFS server that's "easy to hack."
The *ideal* solution would probably be to try to build a redesigned
replacement for NFS that doesn't have its cruft. CODA seems to be the
nearest thing; I don't see any other alternatives coming any time soon.
>>I've got Tom Lord's papers on this at
>><http://www.hex.net/~cbbrowne/bbdb.txt>. He cites Emacs as an
>>illustration of the principle of having a virtual, extensible file
>>system interface. See GNUS for a *really* good example of this; GNUS is
>>able to join together news "feeds" from upwards of a dozen different
>>kinds of news sources.
> Rrrrr.... If EMACS is cited as an example of design... Oh, well.
>Thanks for URL, I'll look it through. BTW, since when did EMACS become
>multitaksing?
I didn't say it was :-).
People that use GNUS seem often to spawn *TWO* Emacs instances; one to do
news, and one to do "other stuff," because when GNUS goes off to do its
thing, that blocks everything else.
My theory of how Emacs ought to be rearchitected were it to be rebuilt now
would involve a Hurd-like architecture where multiple "Scheme engines" could
be spawned to support their respective buffers, but that's more
Pie-in-the-Sky than anyone wants to have anything to do with...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: How about /dev/web?
Date: 25 Mar 1999 16:58:25 -0500
In article <7de4or$l2a$[EMAIL PROTECTED]>,
Ryan S Warner <[EMAIL PROTECTED]> wrote:
>: Wake me up when you will implement lseek() and mmap() over FTP. FTP is not
>: a filesystem. HTTP is not a filesystem. BTW, could you tell me how to
>: implement locks over these protocols? And what on the Earth "internet ready"
>: is supposed to mean?
>
>I guess I'm not looking for full fledged filesystem access. Just
>something that feels like it in a limited way. Example: A KDE image
>viewer can open an image not on the local file system by using a
>URL for the path. With this approach one could then do the same with xv.
>I don't see why a phony file system isn't realistic. Have you ever heard
>of /proc?
Yes. And most of the programs beyond the plain filters will die
on it. If you need plain filters - there is a wget. You can imitate a
namespace, all you need for that is to dig out userfs and port it to 2.2.
Anything beyond that will require much more clever protocols. You are
losing lseek(), you are losing mmap(), you are losing random access
(i.e. read/write are for the whole files only), you are losing flock()/fcntl(),
you are losing readdir() (for HTTP; for FTP it is possible but requires
parsing the ls -l output). For namespace you are going to have a nice time
with security issues (and privacy, BTW - especially if the thing is sticky).
Again, most of the programs (especially ones you are likely to peruse from
filemanager) will choke and die without lseek().
>Oh, and. Ooooh, oooh, somebody has an idea I don't like. Ouch! Ouch!
>What's that? My undies bunching up? I better go flame someone before
>circulation is cutoff to my groin. <tap tap tap (typing flame)> Ahhh! boy
>I showed that moron for trying to innovate. I'm so smart.
Yawn... Flame? *That* was flame? Cool. As for 'innovate' - second yawn.
Look on DejaNews. And where is your code, BTW? "Wouldn't it be nice if" doesn't
count.
Moreover, I have some idea of the cost it will have. Right now VFS
is *not* ready for such exercises. Probably the best approximation you can
do without doubling the size of fs/* is to write a userland phony NFS server
that would speak NFS with the kernel and FTP/HTTP with the outer network.
That may be done without too much blood, but it's not a pleasant exercise.
Feel free to do it, anyway. Maybe somebody already did it - use search
engines since *some* code may be already available.
Recommending you to cool down is obviously useless - it's USENET.
Sigh... Just in case, *it* *i* *not* *a* *flame*. If you feel a need to
be martir, flamed by evil conservative innovation-stifflers - take it
to email and spare the group from that kind of fun, OK?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.emacs,gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 26 Mar 1999 00:45:07 -0500
In article <[EMAIL PROTECTED]>,
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>On 25 Mar 1999 21:39:51 -0500, Alexander Viro <[EMAIL PROTECTED]> posted:
>>lines of mirror-on-demand, but that requires (a) portalfs or equivalent and
>>(b) infrastructure for layering. Otherwise you'll get yet another partial
>>copy of said infrastructure, with its own set of bugs and races, lurking in
>>fs/*/*. We already got 3 - the most clean is in CODA, but it almost doesn't
>>touch namespace stuff; weird one in HFS (ad-hoc needed to deal with forks)
>>and one in UMSDOS (see above). All 3 are mutually incompatible - merging them
>>is harder than writing from scratch.
>
>There's no promises that this is all easy...
Thanks ;-)
[snip]
>> I wish we could do it on Linux VFS. Not yet and will not
>>be there for quite a while - it's *not* likely to be doable in 2.3 (OK,
>>unless 2.3 will take the same time as 2.1...).
>
>There's enough relevant traffic on the reiserfs mailing list between Hans
>Reiser and Steven Tweedie to indicate that effort is definitely going into
>VFS, which is somewhat encouraging.
You see, there is one problem (and that's why I don't believe in
2.3 timeframe for Plan-9ish namespaces) - seriously touching namei.c before
filesystems (and in needed places - VFS/fs interface) will be cleaned up
will just leave us with a pile of bloated, bug ridden code on hands and no
chances to maintain it. Right now the worst offenders are UMSDOS, HFS and
AFFS (each by its own reasons). It will take several flagdays and that's
2.3 stuff. I hope that 2.3 will see layered filesystems, namespace unrolls
(i.e. real handling of namespace-related races) and softupdates. The last one
is separate issue, but first two are closely related and will need some time
to settle down. Besides, we'll most likely need separation of fs-specific
parts of struct inode, and it means changes over all filesystems. Not too
significant changes, but it will take time for settling down.
>The *ideal* solution would probably be to try to build a redesigned
>replacement for NFS that doesn't have its cruft. CODA seems to be the
>nearest thing; I don't see any other alternatives coming any time soon.
NQNFS. CMU stack. ARLA.
>>>I've got Tom Lord's papers on this at
>>><http://www.hex.net/~cbbrowne/bbdb.txt>. He cites Emacs as an
>>>illustration of the principle of having a virtual, extensible file
>>>system interface. See GNUS for a *really* good example of this; GNUS is
>>>able to join together news "feeds" from upwards of a dozen different
>>>kinds of news sources.
>> Rrrrr.... If EMACS is cited as an example of design... Oh, well.
>>Thanks for URL, I'll look it through. BTW, since when did EMACS become
>>multitaksing?
>
>I didn't say it was :-).
I.e. "races do not matter". Goodie. Moreover, EMACS is, erm, well-known for
interesting things it does with free memory. In case of kernel things are
slightly trickier. AFAIK GNUS also doesn't have to deal with serious cache
coherency problems. See Heidemann's paper for discussion of that stuff (not
that I was happy with his approach to this problem and especially with his
assumption that filesystems are relatively clever wrt race prevention, but
it's definitely worth reading). It's on
<http://nii.isi.edu/people/johnh/PAPERS/Heidemann95e.html>
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: Debugging terrible stack corruption problems - tips or tools?
Date: 26 Mar 1999 00:49:26 -0500
"David Mellor" <[EMAIL PROTECTED]> writes:
> Does any one have any tips or tools for resolving those terrible stack
> corruption problems please?
>
> I have a problem where function parameters become inaccessible part way
> through a function, as a result of stack corruption - caused by something
> the function has done. I get a segmentation fault when I access them.
>
> Unfortunately I can not reproduce the problem under Windows, or I would use
> Purify to try to find the source of the problem.
Some tips:
1) Use counted breakpoints: Set a breakpoint somewhere, ignore
1000000, and run. When you get the seg fault, you should be able to
see how many times the breakpoint was crossed, and then set a real
breakpoint ignoring N-1 (ie: stop the last time the breakpoint is seen
before the corruption). Try setting the counted breakpoint at the top
of the function that is crashing.
In gdb, maybe: break SomeFunction
ignore 1000000
run
info break
# passed 3948 times
kill
ignore 3947
run
# Should be in last frame
2) If your app is deterministic (always the same sequence, maybe not
for GUIs or comm stuff), you can theoretically find the crash by
executing a sequence of the following statements:
next <some-number>
step
next <some-number>
step
...
next <some-number>
# crash!
The sun debugger has a "replay" command that can remove some number of
the last commands from the history, and rerun, so you could say:
run
next
next
next
# Crash!
# Last next failed, so "undo"
replay -1
# debugger replays: run, next, next
step
# One frame closer
next
next
...
next
# Crash!
replay -1
step
And so on. It might take a while, but it's pretty mindless. Try
saving the commands in a script. Your final playback script might
look something like:
next 3
step
next 40
step
next 39
step
# etc
--
-Justin
[EMAIL PROTECTED]
------------------------------
Subject: Re: How about /dev/web?
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 25 Mar 1999 23:20:12 -0700
[EMAIL PROTECTED] (Ryan S Warner) writes:
> How about implementing /dev/web? then an act like:
> mount /dev/web /mnt/web -t web
> could put http and ftp in the filesystem. I'm not up on the technical
> aspects of how to do this, but is seems reasonable. Take the following
> fictional example for how it would work:
The Linux userfs provides this kind of functionality.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Stack dump from signal handler
Date: 26 Mar 1999 07:08:38 +0100
[EMAIL PROTECTED] (David Nilsen) writes:
> This should be relatively trivial on an x86 system, but I'm having
> trouble figuring out to do a stack dump from a signal handler
> (i.e. print out faulting PC, and where it was called from).
>
> It appears that the standard signal handler does not have the magic
> "extra" argument that gives me a context where the fault occurred.
>
> I know the faulting PC is on the stack somewhere. Does anyone know
> how to get it? (Now if I knew what the interrupt frame looked like...)
/usr/include/asm/sigcontext.h, struct sigcontext
In 2.2 you can get a more standard siginfo structure (Unix95 compliant)
by setting SA_SIGINFO in sigaction.
-A.
--
This is like TV. I don't like TV.
------------------------------
From: "John R. Owens" <[EMAIL PROTECTED]>
Subject: Re: bzImage won't boot
Date: Fri, 26 Mar 1999 07:52:41 +0000
Might sound obvious, but....
If you selected modules, did you do "make modules" and "make modules_install"?
Also the appropriate depmod, if your init scripts don't do it. Might not get
very far without those... especially when they're so handy for keeping that
aforementioned larger kernel trim & lean.
Since you brought it up, though: What is the usefulness of that System.map? I
ran 2.2.x kernel for a while on a System.map-2.0.36, so I have trouble believing
it's really critical... at least from the user end....
Drew Tennenbaum wrote:
>
> Here are the steps I use to compile a new kernel.
>
> make bzImage
> make... make .., etc
> cp bzImage /boot/vmlinuz-2.2.4
> cp System.map /boot/System.map-2.2.4
> mkinitrd /boot/initrd-2.2.4.img 2.2.4
> lilo
>
> When I follow these steps, mine allows works.
>
> -Drew
>
> "Preston F. Crow" wrote:
>
> > In upgrading to 2.2, I found that my kernel was much larger, so I had
> > to build a bzImage. Unfortuantely, every time I tried to boot it,
> > LILO would say that it was booting Linux, and then the system would
> > reset. I upgraded to LILO version 21 (confirmed with `lilo -V`).
> > Same thing.
> >
> > (Yes, I got it working by making sound into a module, so it shouldn't
> > be a matter of my selecting the wrong options. I just want to
> > understand why it failed. Oh, and it's 2.2.3-ac3, if that matters.)
> >
> > I've read that some hardware is incompatible with bzImage files. I
> > have a 90MHz Pentium with a Biostar motherboard which uses an Intel
> > Triton chipset. I really wouldn't expect to find it to be
> > incompatible.
> >
> > The relevant details from /etc/lilo.conf:
> >
> > boot = /dev/hda
> > vga = normal
> > ramdisk = 0
> > image = /vmlinuz-2.2
> > root = /dev/hda3
> > label = linux22
> > read-only
> >
> > I install the kernel by doing:
> > cp -p /usr/src/linux/arch/i386/boot/bzImage /vmlinuz-2.2
> > lilo
> > and LILO reports the installation of my images.
> >
> > Am I doing something stupid here?
> >
> > --PC
> >
> > --
> > "Everything is permissible"--but not everything is beneficial.
> > "Everything is permissible"--but not everything is constructive.
> > --I Corinthians 10:23
-- John R. Owens aka KarMann http://www.execpc.com/~jowens/
**********************************************************
Men rarely (if ever) manage to dream up a god superior to themselves. Most
gods have the manners and morals of a spoiled child. --- Lazarus Long
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
