Linux-Development-Sys Digest #567, Volume #6      Fri, 2 Apr 99 14:14:17 EST

Contents:
  tiny driver patch  (Re: 3c509B + 2.0.36 + 486/66 = badness) (Anthony Shipman)
  Re: Outlook? (John Burton)
  IDE Chipsets (Chris Leahy)
  Re: Kernel 2.3 when? (Aki M Laukkanen)
  Re: kernel-upgrade (Igor Zlatkovic)
  Re: "playing MPEGs" or "problems with SMP kernel" ("G. Sumner Hayes")
  Re: Took one guy 3 days, another 1 day, me 1 hour... (Adam P. Jenkins)
  Re: EGCS and Stack? (John Burton)
  Re: How about /dev/web? (Robert Krawitz)
  Re: How about /dev/web? (Joseph H Allen)

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

From: [EMAIL PROTECTED] (Anthony Shipman)
Crossposted-To: comp.os.linux.networking
Subject: tiny driver patch  (Re: 3c509B + 2.0.36 + 486/66 = badness)
Date: 2 Apr 1999 16:20:40 GMT

I solved my problem.  It's a bit too embarassing to go into
details :-(.

Anyway here is a tiny patch to the 3c509.c driver that I found useful
while debugging.

*** 3c509.c-orig        Mon Mar 15 00:46:51 1999
--- 3c509.c     Wed Mar 17 03:47:57 1999
***************
*** 675,680 ****
--- 675,684 ----
                if (rx_status & 0x4000) { /* Error, update stats. */
                        short error = rx_status & 0x3800;
  
+                       if (el3_debug > 5)
+                           printk("   Error: rx_packet(), rx_status %4.4x.\n",
+                               rx_status);
+ 
                        outw(RxDiscard, ioaddr + EL3_CMD);
                        lp->stats.rx_errors++;
                        switch (error) {

--
Anthony Shipman,                "You've got to be taught before it's too late,
AAII, Melbourne, Australia       Before you are six or seven or eight,
[EMAIL PROTECTED]                  To hate all the people your relatives hate,
+61 3 92477679                   You've got to be carefully taught."  R&H

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

From: John Burton <[EMAIL PROTECTED]>
Subject: Re: Outlook?
Date: Fri, 02 Apr 1999 14:24:04 +0100

Igor Zlatkovic wrote:
> 
> John Burton wrote:
> 
> > ...I'll have to read the manuals on how to get at the windows mail. Can I
> > just
> > use mapi to do
> > this?
> 
> No Manuals out there for MS Mail programming. You will have to get your hands
> on Microsoft Developer Network, which is a very good source of documentation
> for Windows programming. Check it at http://msdn.microsoft.com.

Yes I've got that. I'll have a browse though it.  I should be able to
set up 
a msmail postoffice on my windows PC at home and have a play about with
it
over easter. I'll post a mesage if I find anything. Thanks for the
suggestions.

I did find some documents (an rfc841) which I believe that actually
describes the
ms mail .MAI format files. The problem as you mentioned is that the
files are
compress and encrypted in some way. I don't think that the encryption is
very
good though. I tried sending myself a large message consisting mostly of
spaces and
the resulting file has a short repeating sequence which I wouldn't
expect with
any half decent encryption scheme.

> What everyone should do who wants to deal with MS software is subscribe to the
> MSDN. It costs about $ 1500 per year and you get gigabytes of documentation,
> all development products, all operating systems, all office and backoffice
> products, including Exchange, SQL, SMS and so on. If you buy the stuff
> directly, it costs much more.
> 
> What your admin should do is port the mailing system to Linux. This is a lot
> better solution than any MSDN can offer. All others would still be able to
> access their messages through IMAP4 or POP3, they would never see the
> difference. However, porting from MS Exchange Server to any kind of Linux-based
> mailing is possible. Porting from MS Mail is not.


Yes we use the MSDN extensivly in the development department where I
work, but
I don't believe that the license agreement permits us to use things like 
exchange server for general us within the company, only for development
purposes and
compatibility testing. Our network manager isn't going to run it at this
time
which is why I wanted to try to find another solution even if I had to
write it
myself in my own time.

I keep saying they should use a POP3/IMAP mail system but like I said,
the existing
mail system works fine for everyone else at the moment so they don't
want to
spend time and money upgrading it.

> You�re welcome. That is why I hang out here. To learn, to help where I can and
> possibly to get help when I need some.
> 
> > ...This has got a bit off topic. Is there a more relevent newsgroup for this
> > sort of thing?
> 
> We are talking about developing software that enables one to read messages
> delivered through MS Mail on his Linux workstation. This really is a topic that
> has to do with Linux development. It is not necessarily off topic because
> Microsoft is mentioned here. If you don�t get help here, you wont get it
> anywhere. Do you think that anyone in any microsoft related group would answer
> your post regarding Linux? No way. If you go to the MS IRC chat network and set
> the room topic to something that contains the word "Linux", a system bot comes
> and claims that the topic is inapropriate. This group and
> comp.os.linux.development.apps are the places where people exchange information
> regarding development under Linux and that�s exactly what we are talking about.

Yes, you're right now I think about it. I want to develop linux software
to read
microsoft mail so it is the right place.

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

From: Chris Leahy <[EMAIL PROTECTED]>
Subject: IDE Chipsets
Date: Fri, 02 Apr 1999 09:49:32 -0800

Hello all,

I'm a RedHat user but this question can be put to users of any linux
distribution.
I'm running RedHat 5.2 with an AMD K6-2 400 MHz on an ASUS P5A
Motherboard
The problem is this, (though its not an emergency)
Even the latest kernel (2.2.5 I believe) does not recognize the ALi 154x
chipset on the motherboard
The result is that it runs ok, but DMA is disabled at boot and can not
be enabled.
Earlier on I found a 3rd party patch for the 2.2.0 kernel that added
support for the ALi chipset
and this runs ok but I would like to be using the latest kernel and the
patch would only go on the 2.2.0 source
I'm wondering when support for this popular (and common) super 7 chipset
will appear in the
official release.

If the answer is unknown to any of you maybe someone could direct me to
a place where I might find the answer to this question.

Please CC replies to [EMAIL PROTECTED]

Thanks for your help

Chris


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

From: [EMAIL PROTECTED] (Aki M Laukkanen)
Subject: Re: Kernel 2.3 when?
Date: 2 Apr 1999 13:37:17 GMT

In article <[EMAIL PROTECTED]>, 
Christopher B. Browne wrote:
>>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!
>Hmmm.  What was the timing like?  Are we producing 2.2.x's faster than
>we did 2.0.x's?

Not really. If you take a look at Riley Williams' kernel history site at:
http://ps.cus.umist.ac.uk/~rhw/kernel.versions.html

You will find that the kernel releases prior to the forking of the 2.1
development branch were quite fast in pace. More so they introduced
very little new code (about 150 kB archive growth) over time of little
less than four months. This leads me thinking that they were mostly
bug fixing although I didn't follow ia32 kernel development at that
time. 

In contrast it has been a little over two months since the release of 2.2.0.
There have been just five releases after that which have introduced
around 400 kB of new code. Bulk of that code has been introduced because 
of the merging with the PPC and Sparc ports. My very subjective opinion is
that During its life time the 2.2.x series has stabilized quite nicely. So
I'd say after a couple more releases the time should be ripe for 2.3 forking
in May/June but what do I know (I was off by two months in my 2.2.0 release
guestimate).

>It seems likely to me that there is more likely to be an "ext3fs" than
>there is an "augmented ext2fs."

Yes, this seems to be what Linus wants. I think mr. Tweedie reported on
linux-kernel that he would have something to release in about one month.
Stay tuned to ftp://ftp.uk.linux.org/pub/linux/sct/ I believe?

>--> The ability to have "safe" partitions using the current "stable"
>    functionality, and "experimental" partitions with K001 New Stuff.

One of the reasons cited for ext3fs versus extending ext2fs was the name 
recognisition. Linus didn't want to start "breaking" the stable filesystem
and thus creating confusion within the now larger community. Also it seems 
that ext2fs code has decayed somewhat during the years and nowadays expresses 
some bad behavior in its presumptions about the kernel interface and their
characteristics. So it seems a good idea to make a more complete overhaul
of the internal workings and call it something else than to keep extending
the old base.

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

I took the adventorous route too and moved my home partition under
reiserfs. It has worked quite nicely although any performance improvements
are probably lost with my 1.4GB laptop hard drive.

>VFS, and then having several "X-File Systems" that shake out into some
>smaller number of *truly* improved FSes that may be attuned to
>different purposes.

This is a one thing I'd like to see clear up. It is my impression that  
these two projects are separate and both sort of aim to be the next 
generation general purpose filesystem. This could create some confusion 
so either they should merge or specialize to different purposes.

>- Bigger-than-2GB files ("ext64fs," maybehaps?)

See Large File Summit patches (currently extend ext2):
ftp://mea.tmt.tele.fi/linux/LFS/

For more 2.3.x musings, there is the linux-future mailing list at:
http://humbolt.nl.linux.org/lists/linux-future/

and the summary page:
http://users.ox.ac.uk/~mert0236/linux-future.html

-- 
D.

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

From: Igor Zlatkovic <[EMAIL PROTECTED]>
Subject: Re: kernel-upgrade
Date: Fri, 02 Apr 1999 14:17:46 +0000

Svein K Svendsen wrote:

> When  upgrading my rh5.2 with  a new kernel  I can't find a way to
> create a new
> module-info-new_kernel  file.  Everything seems to work as long as I
> remove
> the "preferred" pointer in /lib/modules/  , and don't make a new one .
> Can anybody please help me out.
> Svein S,

Hello.

The file /boot/module-info-x.x.x is not that important. This fil only
helps some part of Redhat control-panel work. The kernel does not need it
at all. you should just copy the original file and give it a new name,
according to the version of the new kernel. You can also create an empty
file.

What you are missing is a file called .rhkmvtag located in
/lib/modules/x.x.x. This is the file that /etc/rc.d/rc.sysinit script
will look for and this script will create a "preferred" link based on
this file. This script also creates the /boot/System.map link and
/boot/module-info link at boot time, all based on the info found in
/lib/modules/x.x.x/.rhkmvtag.

The misterious file, .rhkmvtag contains exactly one line, and that is the
same what you will find in /proc/version. You can create this file with
cat /proc/version > .rhkmvtag on the shell prompt. Do this once you boot
the new kernel, because the contents of .rhkmvtag must match the
/proc/version at boot time.

Cheers
Igor


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

From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.os.linux.setup,comp.os.linux.misc
Subject: Re: "playing MPEGs" or "problems with SMP kernel"
Date: Thu, 01 Apr 1999 15:07:01 -0500

Peter Kharchenko wrote:
> 
> Hi,
>  I've ran into a weird problem when I put a second processor into my
> system: When the kernel is running in SMP mode with two processors,
> video players don't seem to work. All of them (mpeg_play, MpegTV, 
> xanim) are showing the same exact problem: they spit out a bunch of 
> frames, then freeze, then spit out some more and so on.

It could be that the video player is getting bumped back and forth
between processors and is falling out of the cache in the process.
There's a compile-time constant that you can alter to increase
processor affinity under SMP, but I don't recall what it is off the
top of my head.  It was mentioned recently on linux-kernel.

Of course, I could be completely wrong.

--Sumner

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

Crossposted-To: comp.os.linux.advocacy
Subject: Re: Took one guy 3 days, another 1 day, me 1 hour...
From: [EMAIL PROTECTED] (Adam P. Jenkins)
Date: 02 Apr 1999 13:00:06 -0500

Charlie Ebert <[EMAIL PROTECTED]> writes:
> I also read in here something about having to re-boot linux one to
> install software.  What?  I've never had to re-boot linux to install
> software.  Not since I installed RedHat have I personally had to do
> that.
> 
> Applix required NO re-boot.
> Cad Cam program had no re-boot.
> None of my editors did.
> 
> There is no re-boot necessary with Linux on an install?
> What did you guys install which required a re-boot anyway?

I think you misread something.  They were talking about having to
reboot during the *Linux* installation process, not during installing
other software packages.  There are two places where the RedHat
install process asks you to reboot.  One is after you set up the hard
drive partitions.  In my experience this can be safely ignored, but it
does recommend rebooting after making changes to the partition table.
The second is of course when the installation process is complete, and
it reboots into your new Linux installation.

-- 
Adam P. Jenkins 
[EMAIL PROTECTED]

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

From: John Burton <[EMAIL PROTECTED]>
Subject: Re: EGCS and Stack?
Date: Wed, 31 Mar 1999 20:09:06 +0100

Andreas Jusek wrote:
> 
> Hallo all,
> 
> We have a problem with EGCS-1.1.2 and the size of the stack in a C++-program.
> Does anyone know, how egcs g++ handle the stacksize? Is it possible to
> manipulate the size of the stack - especially to increse it?

I don't think the size of the stack is determined by the compiler. I
seem to
be able to use many megabytes of stack space with little problem.

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

From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: How about /dev/web?
Date: 02 Apr 1999 09:25:27 -0500

"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.  They mount themselves at various
places on the filesystem, and in response to requests, mount other
filesystems and then return to the kernel something that looks like a
symlink.  Automounter technology has improved, but not all that much
(stuff like loopback filesystems).

Perhaps there are efficiencies or robustness to be gained by giving
the kernel more knowledge of what's going on.  Certainly the
automounter as it exists doesn't have the facilities needed to do
this, but there's nothing that I can see preventing someone from
writing an automounter that does all this (handles the ftp protocol on
its client side and NFS on its server side).

The main disadvantage of NFS as an interchange protocol that comes to
mind is its statelessness.  A protocol with state such as open/close
and perhaps the existence of a file pointer would make a lot of things
simpler.  Perhaps a design whereby the state information is made
available, but is not required for correct operation, would be a good
start.

-- 
Robert Krawitz <[EMAIL PROTECTED]>          http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

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

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

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.  For example, it would be cool
if you could open a serial port with:
open("/dev/serial/baud=9600,bits=8,parity=n,stop=1"), and have everything
after the serial/ part passed to the open handler.  fcntl() could be
modified to accept a string for changing parameters:
fcntl(fd,"baud=115200").  Many (all?) ioctls() could be eliminated-
hopefully special programs like 'stty' could be eliminated as well.

I wish the entire socket system worked this way as well (IMHO, those stoned
out hippies at berserkely really screwed up be not putting the socket system
in the filesystem to begin with).  It could work something like this:

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)

You could then make servers with simple shell scripts.  There could be a dns
translator mounted on another directory.  There could be authentication
translators mounted on yet other directories, http and ftp translators could
be added on top of that.  Of course not every device driver is necessarily
going to provide all of the functionality available in a real filesystem-
it very useful even without it.

Device drivers themselves should have well defined APIs and perhaps exist as
processes with their own memory map.  Preferably there is no difference
between a device driver and a normal process except for the resources it has
permission to access.  A single thread race-condition free model should be
used as a default (faster models could be enabled) so that simple device
drivers are not so difficult to write.  The kernel then becomes some sort of
manager for this (I don't want to say a message passing system, because
that's not quite right).  In general I think for many applications the
purpose of the computer is manager special purpose hardware, so it should be
easy to write drivers for this.

I don't necessarily that this is the direction Linux should be going in-
just the way I would attempt to write UNIX if I were to redo it from
scratch.  Its seems that hacks like special NFS and CODA servers are the
easiest way to add functionality similar to this Linux.  I have something
like this in mind for sticking a custom database in the filesystem
(actually, I don't want to deal with the NFS or CODA protocols at all,
instead I'm figuring out how to use sockets from within a device driver). 
Anyway, each table will appear as a file and queries in ralational algerbra
can be made even if there is no such file.  The idea is to eliminate the
need for an SQL shell, as in sybase.  Also I hope to be able to reexport the
database filesystem with samba so that it has interoperability with Windows-
for example you should be able to make a database query in the file name
prompt for file-open in Excel.  Applications which need transaction
processing still would have to go to the actual database server.
-- 
/*  [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]]);}

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


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