Linux-Development-Sys Digest #570, Volume #6      Fri, 2 Apr 99 18:14:05 EST

Contents:
  Re: Kernel 2.3 when? ("G. Sumner Hayes")
  Re: How about /dev/web? (Joseph H Allen)
  Re: Neal Stephenson does the car metaphor (Alexander Viro)
  kernel 2.2.5, SMP and "unexpected IRQ vector 7" (Noah Romer)
  Re: cc compiler (Chris Leahy)
  Re: Proposal: "Linux 2000 Platform" (geezerex)
  NFS - HPUX Client mounts disappear - Linux 2.2 (Kane)

----------------------------------------------------------------------------

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.3 when?
Date: Thu, 01 Apr 1999 21:09:05 -0500

[EMAIL PROTECTED] wrote:
> 
> Subject says all. When is 2.3 going to be out?
> 

As soon as the developers don't spend all their time bug-hunting in
2.2.x.  It's still not completely stabilized yet (though I'm pleased
at how much smoother the 2.2 series has been than the 2.0 series was).

I expect Linus will get bored with 2.2.x soon enough and things will
progress onward.  It may be a couple more months, but probably not
more than that.

Remember, 2.0.x was up to about 2.0.20 before 2.1.0 forked off -- we're
not even to 2.2.10 yet!

> I keep hearing that there are supposed to be a lot of new and some old
> 3rd party things to enter the kernel: hardware monitoring (from
> lm_sensors2), 32 bit devices, uids, and gids, Pentium 3 support, raw
> devices, and ext2fs undeletion and ACLs. And much more!

Most of these ought to make it, but ext2fs undeletion is doubtful.
ACLs are questionable but much more likely.  (ext2fs undeletion will
probably never exist; the bits were reserved, but in retrospect it's
a problem better dealt with in userspace and Ted T'so has said as much
on linux-kernel).

Capabilities, stable RAID, and journalling are the killer features for 
2.3.x, IMO.

--Sumner

------------------------------

Crossposted-To: gnu.misc.discuss
From: [EMAIL PROTECTED] (Joseph H Allen)
Subject: Re: How about /dev/web?
Date: Fri, 2 Apr 1999 22:29:03 GMT

In article <7e3da9$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>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.

Yes, this is what is in the string returned by read() above.  It's a unique
token for each accepted connection.  It specifies the machine of the
connect().(and the actual port number to be used for the connection).  The
token could have this information literally, or it could just be a token and
the information is hidden inside the inet driver.  Whichever gets the read
first gets the connection.

>With AF_UNIX... How are you going to distinguish between the connect() and
>listen()?

Use open("name/connect") and open("name/listen").

>With SOCK_DGRAM you need packet boundaries *and* connectionless
>stuff. E.g. sendto(), even if your socket isn't connected.

This is easy.  As with the tape device driver, Write() and read() give the
packet boundary.  Open() gives the destination.  Open() in this case does
not actually specify a connection, just the address for the write or read. 
Alternatively, write() takes a packet containing both the address and the
data (you just open("/dev/dgram")).  The second method is faster, but the
first is probably more useful for shell scripts.

>You also need OOB stuff.

The OOB stuff is a real annoyance (incidentally, what uses it?).  Here I
would stoop to using an ioctl().

>       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()).

Does it use it on 'foo' or the temporary swap file?  (On SGI no lseeks are
used at all in the above test).  I've looked at the code for emacs, and know
that it is not true (it just reads the whole file into memory in one fell
swoop).  Actually I just tried it on emacs, and it uses lseek on some
startup file only.
-- 
/*  [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: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.sys.next.advocacy
Subject: Re: Neal Stephenson does the car metaphor
Date: 1 Apr 1999 21:21:26 -0500

In article <6hVM2.5240$[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>The initial point of it is to build a FS using balanced trees, which
>should provide improved performance for small files and for various
>sorts of directory accesses.
>
>Proposals came over the wire to build something into it like unto the
>upcoming NT "multiple resource forks in a file" thing.  (*Manifestly*
>not an NT innovation; somewhat more like the OS/2 Extended Attributes.)
>
>Controversy immediately arose for much the reasons suggested; the most
>useful *concrete* comment was that people often mount filesystems using
>NFS, which means that any functionality that can't be expressed "over
>NFS" will get lost/ignored. 

... and not the first time. BTW, you've messed the history part - Genera
had equivalents of forks/files-as-objects *waaaay* before OS/2.
As for the only concrete argument - I'ld beg to differ. There is tar, for
example. There is a lot of other applications that will be very unhappy
over that.
[snip]

>Arguments that UNIX "ought" to offer additional functionality relating
>to filesystems pretty forcibly requires that there be some way of doing
>this across networks, which means that changing APIs to the point to
>which NFS isn't enough until something demonstrably better is
>*deployable* (e.g. - CODA or AFS-like schemes) is just not going to
>happen. 

Not to mention the fact that neither CODA nor AFS support the thing...

[snip]
>>> In part, quite true.  It's also why Unix has never taken over the world: it
        Since when did we go insane and decided to "take over the world"?
>>> spends its time fragmented between 50 different versions, all almost, but
>>> not quite, compatible.  It's happening to Linux as we speak: I suspect it
>>> won't be long before we see distro-specific programs.
        Lusers are everywhere. Wait until hordes of "I've read VB for dummies
and now I'm a programmer" wankers will "port" their turdl^Wproducts. The
you'll definitely see it.

[snip]
>The only place where persistent fragmentation *may* *ARGUABLY* be
>happening is with the "system administration" tools, where Red Hat is
>sponsoring one project (Linuxconf), and Caldera another (COAS). 

... and in the area of *real* package management (real == behind the UI;
place completely ignored by most of wank^advocates).

[snip]
>There's not One True Linux Distribution, which means that if an asteroid
>strikes North Carolina, thus destroying Red Hat Software, or Microsoft
>decides to vaporize Provo, Utah so as to eliminate Novell *and* Caldera
>in one fell swoop, or if Godzilla eats the city in Japan where
>TurboLinux development takes place, none of these events forcibly
>demolish Linux development. 

        Erm... I suspect that the first variant would have much more
interesting consequences ;-/

[big snip]
>>This wasn't supposed to be a discussion of security, but rather a
>>discussion of priorities and values. I'm not really a security expert...
>
>Security is starting to become more of an issue as it becomes easier and
>easier to establish connections between computers.
>
>The unfortunate problem is that building secure systems presently
                                                        ^^^^^^^^^^^
                                                        intrinsically
>requires system administrators that *understand security.* That leaves
>the naive home user of Windows 98 completely out in the cold.
>Unfortunately, a "default install" of Red Hat Linux done by a user that
>has no comprehension of security will only be moderately more secure,
>and that really only because the kernel/user space separation prevents
>*some* exploits.
        Which prevention fails if said user runs everything as root,
installs whatever he sees, answers "yes" to all questions of installer,
no matter what setup he has, ignores *all* warnings, never does RTFM,
never looks into configs and has an attention span of severely retarded
groundhog in everything that has any relation to computers (i.e.
manpage longer that 7 lines is doomed - 3-4 random lines will be read,
anything else ignored; any representation of config (and that includes
text file, buttons, whatever) containing more than 6 options is doomed
too, etc.). We are talking about psychical disorder here, and if
somebody would demonstrate the same level of, erm, attention deficite
in situation *not* related to computers he would be considered imbecil.
You are *not* going to give a car to somebody unless he's able to pay
*some* attention to signs, color of the lights and distinction between
the pedals. Yet for some reasons equivalent mental strain is considered
too hard when it comes to computers. Sigh...

-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

------------------------------

From: [EMAIL PROTECTED] (Noah Romer)
Subject: kernel 2.2.5, SMP and "unexpected IRQ vector 7"
Date: 2 Apr 1999 22:12:11 GMT

Ok, here's the deal: one of the machines I work on at work (of all places)
is a Dual PPro system (we use it to run Bugzilla and as backup internal
web server for our group). It's been running stock 2.0.36 (w/ SMP turned
on) for the past couple of months w/o any trouble. A few days ago, I
decided to give 2.2.x a whirl. After compiling and installing, I rebooted
and everything looked fine until I ran dmesg which printed out:

vector 7 on CPU#0!
unexpected IRQ vector 7 on CPU#0!
(ad infentum)

When I went to look at the system (it's not in my cube), the console was a
continuous stream of "unexpected IRQ vector 7 on CPU#0!". However, this
error message is the only indication that there's some sort of problem;
everything appears to run just fine (the response time for Bugzilla has
even gone down a little bit) and 2.2.5 takes about 2/3 the time of 2.0.36
to boot.

Does anyone have any suggestions on what might be causing this? I'm kind
of tossing around the idea that it's just some sort of error in the error
detection of 2.2.x, but meanwhile, I'm back to running 2.0.36 just to be
on the safe side.

Much thanks,
Noah Romer
-- 
Noah Romer              | "I hold a firm belief in the stupidity and 
[EMAIL PROTECTED]       | foolishness of humanity, especially myself."
PGP key available       | - me
by finger or email      |

------------------------------

From: Chris Leahy <[EMAIL PROTECTED]>
Subject: Re: cc compiler
Date: Fri, 02 Apr 1999 14:25:06 -0800

Dominic Leelodharry wrote:

> Help!
> I have Redhat Linux
> And I can not  seem to get the cc compiler to work.
> I think I am missing the header files such as <stdio.h> etc, does any
> one know where I can
> down load them from, If they are included as a RPM could you tell what
> that is called
> thanks.

Upgrade your system using the boot disk. Select the "Upgrade" option. Pop
your install CD into the drive and make sure you select all the
development libraries.
They are included in the distribution. You need to install them in order
to compile anything.


------------------------------

From: geezerex <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.linux.misc
Subject: Re: Proposal: "Linux 2000 Platform"
Date: Fri, 02 Apr 1999 22:28:29 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Kendall Bennett) 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.
>
> I know there is already the Linux LSB project underway to hopefully solve
> some of these problems. However I think we need something more
> definitative than this. What we need to do is put together something
> similar to the the Microsoft PC '99 guidelines, but for Linux
> distributions. I am proposing that we start a new project to define the
> 'Linux 2000 Platform'.
>
> Since there will be differences between the different uses for Linux, we
> should define multiple variations of the Linux 2000 platform. The
> contents of what make up the variations Linux 2000 platform should be
> debated and eventually voted on to come up with the final guidelines.
> Some people may not agree with the final vote, but the important thing is
> that compromises need to be made for this to be successful. We may also
> want to define what are 'base components' that must be installed on every
> system, and components that are optional and may or may not be installed
> by the user.
>
> 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.
>
> Perhaps we need a new mailing list dedicated to defining and regulating
> these issues?
>
> The following are my first two (very bare) suggestions to begin with:
>
> Linux 2000 Workstation
> ----------------------
>
> Base components:
>  . Standard locations for all configuration files!
>  . Glibc based
>  . RPM for package manager
>  . GNU make, C/C++ compiler and development libraries
>  . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
>
> Optional components:
>  . Web browser (Netscape or Mozilla variation?)
>  . Need more suggestions here!
>
> Linux 2000 Server
> -----------------
>
> Base components:
>  . Standard locations for all configuration files!
>  . Glibc based
>  . RPM for package manager
>  . GNU make, C/C++ compiler and development libraries
>  . XFree86 installed to /usr/X11R6/lib (or /usr/X11)
>  . Ftp, telnet servers
>  . Apache web server
>  . Web browser (Netscape or Mozilla variation?)
>
> Optional components:
>  . Need more suggestions here!
>
> --
>
> +----------------------------------------------------------------------+
> |      SciTech Software - Building Truly Plug'n'Play Software!         |
> +----------------------------------------------------------------------+
> | Kendall Bennett          | To reply via email, remove nospam from    |
> | Director of Engineering  | the reply to email address. Do NOT send   |
> | SciTech Software, Inc.   | unsolicited commercial email!             |
> | 505 Wall Street          | ftp  : ftp.scitechsoft.com                |
> | Chico, CA 95928, USA     | www  : http://www.scitechsoft.com         |
> +----------------------------------------------------------------------+
>

In the web browser area, due to some personal concerns with aol's handling of
netscape, consider Sun's Hotjava browser as well.....

The Many Headed Hydra of Usenet, the Vigilante Doppleganger
Mr Happy Himself, come visit at:
http://members.tripod.com/~betty_3/site.html

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: Kane <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: NFS - HPUX Client mounts disappear - Linux 2.2
Date: Fri, 02 Apr 1999 21:28:16 +0000

Hello. 

I have been working on a problem for the last week that has me very
perplexed. I work in a mixed enviroment using Solaris, Irix, HPUX, and
Linux. Linux is used for all our new servers. We just loaded a server
with Redhat 5.2 and upgraded it to the 2.2.5-ac1 kernel (after trying
2.2.3). 

Here is the problem we have started experiencing after moving to the
2.2.x kernels:

The linux box mounts NFS exports from various unix machines including
the HPUX 10.20 machines. We are using nfs-server-2.2beta40 and
am-utils-6.0. When I "cd" into /net/bob it mounts the server named bob
and if I do and "ls" I see "bob" and "bob2" are being exported. I can
"cd" into "bob" and then type "ls" and it seems to work, I "cd" down
another directory and type "ls", still no problem. However, If I type a
few more commands and then type "ls" again, "ls" returns nothing, not
even an error. All the files seem to have disappeared. Strange, so I
"cd" up an directory (/net/bob/bob)and type "ls" and still nothing. I
then try to edit a file I know is there called .xinitrc. That works
fine. I can edit the file and "pwd" works fine, but "ls" doesn't show a
thing. 

If I then cd into /net/bob/bob2 I can work in there all day and never
have a problem. This behavior is very repeatable and occurs on every HP
we have. After making sure I had all the correct nfs/am versions on my
linux box, and setting it up to use nfs-server and not knfsd (which I
also tried, but didn't seem to help), I started looking at the HPs. HP
gave me some patches to try (no help). A friend read that trying to set
rsize=8192, wsize=8192 in the HP exports might fix it, that is one of
the only things I have't tried yet.

>From the behvior of the problem, I though that maybe it was the first
mount in the exports file that was experiencing problems, but I killed
that theory by adding /tmp as the first line in exports and the problem
still occured. The other thought is that maybe the first mount
alphabetically is being affected. That is another thing I may try, but
other then these two options, I am out of ideas, and I'm not sure if the
problem is really an HP or Linux issue. It certainly cropped up with the
new linux 2.2.x kernels and I know that there are some new Linux NFS
server issues in the new kernel code, but this is a client thing.

This problem does not occur when mounting non-HPUX machines.

If anyone has any ideas, or knows what is causing this, I would love to
hear from you. 

Thanks a lot, 
Sean
============
Sean P. Kane
Senior Systems Administrator
Metron, Inc. - Simulation Sciences Division
Solana Beach, CA, USA

[EMAIL PROTECTED]

------------------------------


** 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
******************************

Reply via email to