Linux-Development-Sys Digest #569, Volume #6 Fri, 2 Apr 99 17:14:30 EST
Contents:
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Nix)
telnetd source? ("Jonas Anden")
FAT/VFAT FS-types not case sensitive? (Chris J/#6)
PATCH: mulaw with soundblaster under 2.2.x [was Re: how are contributions to the
linux development coordinated] (Michael Hirsch)
Re: Proposal: "Linux 2000 Platform" (Jeremy Crabtree)
Re: Proposal: "Linux 2000 Platform" (Emile van bergen)
Re: Kernel 2.3 when? ("G. Sumner Hayes")
Re: How about /dev/web? (Alexander Viro)
Re: How about /dev/web? (Alexander Viro)
Re: How about /dev/web? (Rajappa Iyer)
Re: How about /dev/web? (Matan Ziv-Av)
Re: How about /dev/web? (Joseph H Allen)
Re: How about /dev/web? ("G. Sumner Hayes")
----------------------------------------------------------------------------
From: Nix <$}xin{[email protected]>
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 01 Apr 1999 23:28:14 +0100
"Paul F. Dietz" <[EMAIL PROTECTED]> writes:
> Nix wrote:
>
> > Plus, instead of learning Yet Another One-Off Macro Language, you learn
> > lisp, which is about as not-one-off as you can get, in addition to being
> > wonderfully elegant.
>
> You learn a bastardized form of lisp. Emacs lisp is
> very nonstandard.
True; but it's still a Lisp. The fundamentals remain the same across
Common Lisp, elisp, MacLisp and Scheme, do they not? (Pedantically this
is not true, especially in Scheme - proper tail-recursion - but you know
what I mean.)
And one of the nice things about lisps is that you cna translate other
things into them easily in realtime. (Guess what's happening with elisp?
;) )
> I want emacs on top of Common Lisp. I suppose
> I'll have to settle for emacs on scheme, when
> that's available.
Fairly soon, if you believe http://www.gnu.org/. I'm looking forward to
that, too.
(It's a pity I won't be able to use, er, eCLOS though ;) I wonder if the
CLOS can be faked in Scheme?...)
--
`The purpose of a windowing system is to put some amusing
fluff around your one almighty emacs window.' -- Mark on gnu.emacs.help
------------------------------
From: "Jonas Anden" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: telnetd source?
Date: Fri, 2 Apr 1999 23:16:39 +0200
Anyone got a pointer to a telnetd source that will easily compile under
RedHat 5.2? I'm looking to create a chroot()ed version of the telnet server.
so that I can easily limit the software that may be used when telnetting in
to my servers.
// Judge
------------------------------
From: [EMAIL PROTECTED] (Chris J/#6)
Subject: FAT/VFAT FS-types not case sensitive?
Date: 2 Apr 1999 21:39:36 +0100
Reply-To: [EMAIL PROTECTED]
Hiya,
Found what could be a possible bug in Linux's support for FAT/VFAT
filesystems. If someone knows where the problem lies, or if I'm doing
something wrong, please get in touch. Linux kernel version 2.0.35.
I mount my Win95 c:\ drive as type vfat from fstab with the following
line:
/dev/hda1 /c vfat
defaults,nodev,nosuid,auto,uid=0,gid=500,umask=007,check=relaxed 0 0
According to mount(1), the file systems should be case insensitive. However,
when using Wine, a couple of programs failed to work...I checked the
file locations and existance, and they did exist. The only difference
was in the case of the filenames.
Example:
[220%][infinitum][chartist] >pwd
/c/progra~1/chartist
[221%][infinitum][chartist] >mount
/dev/hda2 on / type ext2 (rw,usrquota)
none on /proc type proc (rw)
/dev/hdb5 on /usr/local type ext2 (rw)
/dev/hdb6 on /var type ext2 (rw)
/dev/hda1 on /c type vfat (rw,nosuid,nodev,uid=0,gid=500,
umask=007,check=relaxed)
[222%][infinitum][chartist] >cat chartist.ini
[chartist]
shapefile=c:\progra~1\chartist\shapes.shp
snap=1
[223%][infinitum][chartist] >cat CHARTIST.INI
cat: CHARTIST.INI: No such file or directory
[224%][infinitum][chartist] >
Now, if the filesystems were case sensitive, I'd imagine that 'cat' should
be able to display the file chartist.ini in whatever case. But it can't.
Therefore, there is either:
a) A bug in the kernel for open() or similar
b) Something is wrong with my libc (I have version 5.4.33)
Yes, I know ther versions are old (before someone points that one out),
however it would be appreciated if I could have confirmation of a bug
*or* a need to upgrade.
TIA,
Chris...
--
O--------------------------------------------------O--- Chris Johnson ---O
\ And the devil in a black dress watches over \ \
\ My guardian angel walks away \ [EMAIL PROTECTED] \
\ -- Temple of Love, The Sisters of Mercy \ \
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: PATCH: mulaw with soundblaster under 2.2.x [was Re: how are contributions to
the linux development coordinated]
Date: 02 Apr 1999 16:17:55 -0500
[EMAIL PROTECTED] writes:
> I find the idea behind linux' success is very appealing: everyone
> who'd like to contribute to the development of linux can. But thinking
> of that, I ask myself: how is this coordinated. Say, for example, I'd
> like to change a line in a kernel's source file, because I think this
> would be more efficient. How would I do that? Do I have to register
> with some organisation, or with Linus?
You just do it. Like this:
I found a problem with the reorganized OSS audio code in 2.2.x. With
the original 2.0.xx code the soundblaster did mulaw encoding without
problem. With 2.2.x if you try, it says it does not support mulaw.
In fact, it does (by default, even!) but it does so silently.
I finally figured out the problem and I have a small kernel patch
which basically puts in a few lines that got deleted from the old OSS
code. Please try it and see if it makes any difference to your audio
experience. It shouldn't. I seem to have the only application in the
world that actually checks for mulaw support. (For the curious,
ccfaudio, a multiuser, mixing, internet phone.
http://ccf.mathcs.emory.edu)
It turns out that when a soundcard doesn't do mulaw in hardware, the
OSS sound driver does it in software. So there is some confusion as
to whether mulaw should show up in the format mask of the soundcard.
As far as the user is concerned, a sb has mulaw, but at the lower
level it doesn't.
The original OSS driver was careful to keep track of whether mulaw
should be included in the mask or not. In reworking the code for 2.2
this was lost. The main result is that if you ask what formats are
supported you won't get mulaw for the soundblaster, even though it
really is supported.
Here is a patch that works against 2.2.3, 2.2.4 and 2.2.5 (probably
any 2.2.x source tree). With this patch all soundcards that use the
OSS drivers will say they support mulaw encoding once again.
Please test it and get back to me before I submit it to kernel.org.
Thanks,
--Michael
--- linux/drivers/sound/audio.c.orig Wed Dec 16 15:52:01 1998
+++ linux/drivers/sound/audio.c Fri Mar 26 14:02:58 1999
@@ -60,7 +60,10 @@
else
return audio_devs[dev]->local_format;
- return audio_devs[dev]->local_format;
+ if (audio_devs[dev]->local_conversion)
+ return audio_devs[dev]->local_conversion;
+ else
+ return audio_devs[dev]->local_format;
}
int audio_open(int dev, struct file *file)
@@ -387,7 +390,7 @@
return 0;
case SNDCTL_DSP_GETFMTS:
- val = audio_devs[dev]->format_mask;
+ val = audio_devs[dev]->format_mask | AFMT_MU_LAW;
break;
case SNDCTL_DSP_SETFMT:
------------------------------
From: [EMAIL PROTECTED] (Jeremy Crabtree)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: 2 Apr 1999 21:18:54 GMT
Reply-To: [EMAIL PROTECTED]
Jim Ross allegedly wrote:
>
>Jeremy Crabtree wrote in message ...
>>Kendall Bennett allegedly wrote:
>>>Hi All,
>>>
>>>Since the announcement of MetroWerks CodeWarrior for the "Red Hat Linux"
>>>platform, a couple of threads have brought up the subject of difference
>>>between Linux distributions. As a developer of commercial products for
>>>the Linux platform, we are all too familiar with the subtle differences
>>>between Linux distributions that cause headaches for vendors wishing to
>>>develop and *support* products for the Linux platform. Hence
>>>software vendors end up developing for and supporting their products on
>>>the most popular Linux distribution, which is currently Red Hat.
>>
>>huh? Unless you do something that is obscenely distribution-specific,
>>it doesn't matter.
>
>...or very careless.
>All these Windows verdors that don't understand Linux/Unix may
>only develop on and test on say Redhat and accidently lock in to that
>vendor.
Like, say, VMWare? They didn't seem to think anyone would be using something
other than RedHat, so thats exactly how they wrote the installer. I had to
point the stupid thing at /tmp when it wanted to install the init scripts,
because they were only for RH. >:(
>Also people are starting to made to believe distros are very different and
>it seems believable.
Sounds like we, as a community, need to dispell this myth, and quick.
>>>I know there is already the Linux LSB project underway to hopefully solve
>>>some of these problems.
>>
>>Then why start yet another project?
>
>Linux LSB has very to be fully accepted by Redhat, the most widely used
>distro now.
>Also LSB isn't yet defined to my knowledge. This needs to be fleshed out.
That is sort of what I was saying...If there is already a project to do this,
why not just help that project instead of starting a new one?
[Minor SNIP]
>>1) PC '99 is evil, 2) Who gets to decide what is 'standard'?
>
>It scared my when Wintel does this alone.
Sacres me too...have you seen some of the things in the PC '99
spec?
[Minore snip]
>>Well...other than the bare minimum, just about everything should be
>optional.
>
>Absolutely. Maybe do this in layers.
>Base minimum - bootable.
I kind of like the base provided by Slackware, it's just enough to
do simple tasks. Which is to say, it's beyond the 'just bootable'
point, but not by a whole lot.
>More CLI tools.
>X.
>Some X apps.
>KDE/Gnome/etc
>KDE/Gnome/etc apps and other big programs (SO 5.0, WP8, etc).
>And of course a desktop, server, or package install.
Don't forget compilers and such. Some of us just couldn't 'do'
Linux without 'em.
>>>The important thing here is that then software vendors can say that they
>>>support the 'Linux 2000 Platform' as opposed to a particular Linux
>>>distribution. People writing books about Linux can target the 'Linux 2000
>>>Platform' as well, so people wanting to learn about Linux can simply get
>>>any distribution that is Linux 2000 compliant. As long as the
>>>distribution guidelines are set in and the distribution vendors correctly
>>>follow the guidelines, the Linux world will be a better place.
>
>Yes. And one RPM should install on all Linux 2000 systems.
>Not like 5 differenet RPM packages for one thing.
I dunno...I still get caught up at 'RPM'. Sure, it works, but
there are better alternatives.
>>Sounds like a marketing tool.
>
>It is. Also a tech issue.
>Even tech people would benefit.
>Like one RPM on all Linux 2000 distros.
>The benefits outway the limits.
>Maybe Linux 2000 install could be optional.
I dunno, again the 'RPM' part bugs me.
>
>>
>>>Perhaps we need a new mailing list dedicated to defining and regulating
>>>these issues?
>
>NO!
How about a special newsgroup?
>>
>>You would also need the participation and support of several MAJOR
>>players in the Linux community.
>
>Yes. This is to say basic Linux stuff should be the same.
>Like cdrom players, compatibility is most important.
Hardware compatibility is already the same.
>Differentiate on higher level stuff.
>I should never hear "Oracle for Redhat" and
>"Oracle may port to Debian soon"
Even if you do, you can just get the 'RedHat version' and run it,
quite happily, on Debian.
(Even if it's an RPM, there are conversion tools.)
>>>The following are my first two (very bare) suggestions to begin with:
>>>
>>>Linux 2000 Workstation
>>>----------------------
>>>
>>>Base components:
>>> . Standard locations for all configuration files!
>
>Should be in layers due to dependencies. See above.
Sort of...the files that exist would relate to the layers,
but the locations wouldn't really change.
[SNIPlet]
>>> . Glibc based
>>> . RPM for package manager
>
>Not close enough unfortunately.
>There should not need to be multiple RPM versions of KDE.
>This extra packaging in wasted energy.
I'm not sure I understand what you mean here...
[SNIP]
>>
>>Summary: It sounds like you want
>>RedHat == Linux 2000
>
>It seems if code is truely free than lets prove it and take the best pieces
>from each distro and put them together to make this standard base for Linux 2000.
In that case, no RPM ;P I agree, but for the most part he was describing
RedHat.
>There should not be vastly different ability and toolset to set up your
>sound card.
True, but there IS a standard way to do it already. If, say, sndconfig
became the standard way that might help. However, in it's current
incarnation sndconfig sucks. They need to make it configure ALL SUPPORTED
CARDS, not just SoundBlasters. I can't begin to tell you how much it bugs
me to hear 'I have an SB-compatible card, but it doesn't work' when the
card they have has NAITIVE-MODE support.
[SNIP]
Still sounds like the goal is RedHat == Linux2000
(That, and I didn't want to dig through the rest of that junk.)
--
"Being myself a remarkably stupid fellow, I have had to unteach myself
the difficulties, and now beg to present to my fellow fools the parts
that are not hard" --Silvanus P. Thompson, from "Calculus Made Easy."
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: Fri, 2 Apr 1999 02:24:03 +0200
Hmm... following up on myself, but this may be worthwile nonetheless.
On Fri, 2 Apr 1999, I wrote:
[SNIP]
>I _don't_ want the installation procedure of product X
>fiddling with my configuration files. The only thing I expect it to do
>is put all files into the right places, and tell a desktop manager like
>KDE or Gnome _nicely_ using a _clean and documented protocol_ that it
>would like the desktop manager to show an icon X in place Y.
And:
>To end: I really think config tweaking by apps a very bad idea. Many
>configuration files are some kind of language, look for example at
>Apache's configuration. There are no sensible defaults for everyone. If
>one would like this tool (webserver) to work for him/her, one _will_, in
>any case, need to learn how to make it do the desired thing. It's sad,
>but there is _no_ way around that.
I now understand the (instinctive, at first) problem I have with it a
bit better.
You see, Application/Server/'OS' "A"'s configuration files are "A"'s
'property'. They belong to "A". "A" knows how they are layed out, and as
"A" is updated, the syntax and/or semantics of its configuration files
may change.
This is all about Application/module "B" changing "A"'s property. Most
of the time like an elephant in a porcelain cupboard, like the Dutch
say. It's not the way to go.
So let's look again at exacly _what_ we're trying to accomplish here.
Let's say we have some entity "A" installed, and we'd like to install
entity "B" and "register" it with or make it known to entity "A". So
it's about two different entities actually that actually need to
_communicate_. Well, what's needed then? Simple, as for all
communications between _different_ partners: a _protocol_.
Now, one could think of many different ways to accomplish such a thing.
1. You could go for a registering scheme, in that component "A" knows
that it may expect registrations from other parties. It should be
possible then for a component X/Y/Z to call "A"'s registration
interface with some parameters (this is the actual protocol) telling "A"
about that particular component. "A" then saves everything "A" needs to
know about component X/Y/Z _itself_, in its _own_ configuration files,
in its own very special way.
Or, if "A"'s knowledge base on components that may interface with "A"
is simple and the layout for the file this knowledge is in is so simple
and standardizeable that it can be carved in stone for years to come,
along with the algorithms to add records to it, you _may_ actually allow
a situation in which the component may alter this file all by itself. In
that case, the protocol is the file layout along with the algorithms
mentioned.
I guess it all comes down to something very simple.
If one creates an application that can be extended, i.e. a desktop
environment that can be "extended" to show another icon for another
installed application, it really should also support a well documented
protocol that enables the "extension", i.e. the application to request
for doing that.
Now, if you continue along this line, if all desktop environments and
application installers could implement (a subset of) this protocol,
you'd be in business, still allowing for all kinds of different and new
destkop environments.
It's simple computer theory. There are two situations possible if one
tries to interface A, B and/or C with X, Y and/or Z.
The first is that each of A, B, and C knows all about X, Y _and_ Z. This
leads to 3 * 3 = 9 interfaces, and a lot of burden into each of A, B and
C (the applications from the previous example, which would need to know
every peculiarity of every desktop).
The second is that each of A, B, and C knows all about P, and X, Y and Z
also know all about P (a protocol). This only leads to 3 _plus_ 3 = 6
interfaces. The only drawback is the common P which must be agreed upon.
It is that area which holds the real challenge.
I hope that this adds something of value to the discussion.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.3 when?
Date: Fri, 02 Apr 1999 12:23:22 -0500
"Christopher B. Browne" wrote:
> It seems likely to me that there is more likely to be an "ext3fs" than
> there is an "augmented ext2fs."
Yes, sct's patches begin with "cp -a ext2/ ext3" (basically)
> I think we're going to see more than just one new filesystem; reiserfs
> is now tracking kernel revisions, and seems to install pretty stably
> (I've got my news "spool" running on it) on 2.2.x versions.
Yep. I want journalled, LVM'd RAID of reiserfs with capabilities.
> The other "killer feature" that I hope for is for EGCS to stabilize
> (e.g. - to become the new GCC), and for C9X functionality to thereupon
> provide us "portable" 64 bit values.
gcc supports long long, and the kernel already requires gcc to build.
(among other things, inline asm is kind of useful in a kernel ;)
I expect we'll have 64-bit values before egcs is the standard compiler
for the kernel. I use egcs to build the kernel, but my system is
pretty bleeding-edge anyway -- a Red Hat 2.x system with basically
everything updated (a.out->ELF, libc5->glibc) by hand to K001 new
versions.
--Sumner
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 2 Apr 1999 16:37:13 -0500
In article <[EMAIL PROTECTED]>,
Joseph H Allen <[EMAIL PROTECTED]> wrote:
>>>fd=open("/inet/tcp/123.456.789.10/50",0)Listen for connections on port 50
>>>read(fd,buf,100) Accept token for next connection
>>>fd1=open(buf,2) Accept the connection (buf would
>>> contain /inet/tcp/123.456.789.10/something)
>> Races. Besides, it's good for AF_INET, but for AF_UNIX it will be
>>royal PITA. Ditto for anything other than SOCK_STREAM.
>
>How does it race? Read blocks until there is a connection. The token hangs
>around until fd closes or the acknowledging open(). AF_UNIX is even easier-
>they look like named pipes. It all works fine with select().
accept() has an interesting parameter - *which* connections do we want.
Several processes may share a listening socket and accept connections from
different sources. That's for races. With AF_UNIX... How are you going to
distinguish between the connect() and listen()? With SOCK_DGRAM you need packet
boundaries *and* connectionless stuff. E.g. sendto(), even if your socket isn't
connected. You also need OOB stuff.
[snip]
>> Sigh... Servers in simple perl scripts are available right now.
>>As for ftp translator - WTF will you do without lseek() and mmap()?
>
>Yes but perl has to have a ton of socket code in it. If sockets were in the
>fs, _lots_ of programs become smaller, simpler and more general purpose.
>Even the C library would be smaller.
Ton? Ahem...
>As for mmap and lseek (and locking), most programs don't use them (use nfs
>if these are necessary). Nobody's going to run their database server over
>an ftp file system, so don't worry. Mmap and lseek could be done (with
>caching and lots of other work- at the very least rewind() could be done),
>but they are not necessary for providing the same functionality provided by
>ftp. Think emacs- there would be no need for the 'ftp:' thing to be
>implemented in emacs with user space ftp. Anything that makes emacs smaller
>(and cat more powerful) is a good thing (plus you get the same functionality
>in vi for free).
Try strace -elseek vi foo 2>/tmp/bar. And watch the show. *More*
than sure that the same holds for EMACS (sorry, I don't have it on any
of my boxen; on SunOS boxen in Uni it *definitely* uses lseek()).
--
"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: 2 Apr 1999 12:06:04 -0500
In article <[EMAIL PROTECTED]>,
Michael T. Babcock <[EMAIL PROTECTED]> wrote:
>
>Whether CD is or is not user-space is almost irrelevant. Have you ever used
>Midnight Commander? I'm not a big fan (too bulky), but it uses a good concept
>that I would like to have you think about ...
>
>... why not implement hierarchial Internet protocols as mountable filesystems
>handled by a daemon process? A background daemon could be loaded that would
>(using FTP as the example here) read /etc/ftpmount.conf and then
>~/.ftpmountconf and get username/password/other parameters and log into the
>site in question ...
Damnit, have you ever *looked* how does mc work? Ever noticed that
it doesn't allow execution of programs on pseudo-fs?
[snip]
>Now, are you going to keep arguing against this because you don't get it,
>because you didn't like it initially and now have something to prove, or
>are you going to start working toward a potentially useful feature?
WHAT? Excuse me, sir, but
(a) I have extremely low respect to self-appointed PHBs
(b) If you don't see problems with the approach in question - fine, go and
try to implement it
(c) I *am* working on useful things, thank you very much. If you are ready to
finish the integration of FAT cleanup with UMSDOS, real support for immutable/
append-only/unlink on the VFS level, cleanup of NFS silly_rename() stuff,
lookup atomicity and layered fs support - you are quite welcome to join.
I'm talking about the unfinished code that already exists (in decreasing order
by completeness).
If you want something done - go and do it. Talk is cheap. Show your
code. That's how the things are done. Sorry, normally I wouldn't say it, but
this "are you going" stuff is really over the top. Who the hell you are to
demand anybody to drop the work they are doing and start working on the thing
you want? Especially since *you* are the one who doesn't see the problems
with implementation of said thing.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Rajappa Iyer <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 02 Apr 1999 16:39:40 -0500
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Joseph H Allen) writes:
> In article <[EMAIL PROTECTED]>,
> Rajappa Iyer <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Joseph H Allen) writes:
> >
> >> Plan9 namespaces are nice, but they don't go anywhere near far enough:
> >>
> >> It would be nice if there were a way to mount a device driver (loadable
> >> module) as the server for a pseudo-directory.
> >
> >Check out Inferno.
>
> >www.lucent-inferno.com
>
> I will. The main problem with both this and plan9 is that they are not
> free. Actually never mind inferno, even my old Atari-800 could do this.
Well, Inferno is free in the sense that you don't have to pay anything
to Lucent to download and run the binary. You don't get the source
for the system, but InfernoSpaces (which implements the namespace
management in Inferno) will be open source in 4Q99.
Regards,
Rajappa
--
Rajappa Iyer <[EMAIL PROTECTED]> #include <std_disclaimer.h>
We're too busy mopping the floor to turn off the faucet.
------------------------------
From: Matan Ziv-Av <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: Sat, 3 Apr 1999 00:25:12 +0300
On 2 Apr 1999, Alexander Viro wrote:
> Damnit, have you ever *looked* how does mc work? Ever noticed that
> it doesn't allow execution of programs on pseudo-fs?
For that, you might want to check avfs by Miklos Szeredi. It does not yet
support ftp/http, but that is in the planning, and it seems like a good
approach.
The library replaces the file related libc functions (read, open, etc.)
with its own version, allowing virtual files. Currently it supportrs tar,
zip, gz and some more, but it also supports external modules, so it might
be easy (I did not try) to support http/ftp. Check it at
http://www.inf.bme.hu/~mszeredi/avfs/
--
Matan Ziv-Av [EMAIL PROTECTED]
------------------------------
Crossposted-To: gnu.misc.discuss
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: How about /dev/web?
Date: Fri, 2 Apr 1999 21:45:17 GMT
In article <[EMAIL PROTECTED]>,
Joseph H Allen <[EMAIL PROTECTED]> wrote:
>In article <7e38iq$[EMAIL PROTECTED]>,
>Alexander Viro <[EMAIL PROTECTED]> wrote:
>> Races. Besides, it's good for AF_INET, but for AF_UNIX it will be
>>royal PITA. Ditto for anything other than SOCK_STREAM.
>How does it race? Read blocks until there is a connection. The token hangs
>around until fd closes or the acknowledging open(). AF_UNIX is even easier-
>they look like named pipes. It all works fine with select().
To elaborate on this a little: mknod should create not have a device number-
instead it should have a path to file containing the device driver module
which should be used to implement the device. When the special file is
opened, the device driver is automatically loaded if it's not already (thus
there is no need for insmod and all that). Perhaps mknod and mount could be
somewhat merged this way.
Anyway, AF_UNIX sockets could work like this.
--
/* [EMAIL PROTECTED] (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: Fri, 02 Apr 1999 12:27:05 -0500
Robert Krawitz wrote:
> "Michael T. Babcock" <[EMAIL PROTECTED]> writes:
>
> > ... why not implement hierarchial Internet protocols as mountable
> > filesystems handled by a daemon process? A background daemon could
> > be loaded that would (using FTP as the example here) read
> > /etc/ftpmount.conf and then ~/.ftpmountconf and get
> > username/password/other parameters and log into the site in question
> > ...
> >
> > mount -tFTP ftp.mit.edu /mnt/mit-ftp/
> >
> > ... username and password are checked for in /etc/ftpmount.conf and
> > found to not exist, so the default anonymous and guest@(localhost)
> > are used and the root of the ftp site is mounted at /mnt/mit-ftp/
>
> At a high level, this isn't too different from an automounter. Many
> automounters are nifty little beasts that are very simple (and
> limited) NFS servers at their core.
podfuk is an nfs-server solution. There's talk about CODA-based
solutions on the kernel mailing list -- saner semantics and better
performance.
The old userfs has been disavowed even by its author.
--Sumner
------------------------------
** 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
******************************
