Subject: Linux-Development Digest #159
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Tue, 12 Oct 93 03:13:22 EDT

Linux-Development Digest #159, Volume #1         Tue, 12 Oct 93 03:13:22 EDT

Contents:
  Re: Questions are permitted on c.o.l.d (Viktor Mraz)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (rich@mulvey.com)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (rich@mulvey.com)
  Re: Xfree vs. BIOS (Bernd Meyer)
  Re: g++ compile times and #pragma interface (Bernd Meyer)
  Re: Linux and PCI-Board (Michael Will)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (Theodore Y. Ts'o)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of grou (Pirate (Anthony Taylor))
  Re: Page fault (Peter Andersson)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development") (Remco Treffkorn)
  Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of grou (Yves LACHANCE)
  Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ? (Derek Fawcus)

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

From: vm@crashy.muc.de (Viktor Mraz)
Subject: Re: Questions are permitted on c.o.l.d
Date: Mon, 11 Oct 1993 21:44:00

Hiya All,

to make things clear, I'm a linux nobody, not even using it at the moment
but reading (/scanning) all *.linux*-news for a couple of weeks now.
I'll shut up as soon as I'm done with this threat since I've nothing
to tell you altruistic and kind developers of linux but THX!THX!THX!THX!-
THX!THX!THX!THX!THX!THX!THX!THX!THX!THX!THX! (that needed to be said ;-) !)

IMHO anybody thinking that somebodys post doesn't belong to some group
should send him a mail politely explaining things or something like
"READ THIS BEFORE POSTING" or "Guide to the comp.os.linux* hiearchy".

BTW, I'd like to BEG our kind linux-wizards to have patience and a working
"n"-key with/for newbie who can't see the difference between DEVELOPMENT
and HELP and people not able to mail a message instead of posting it.

Most personally I'd like to see Lars Wirzenius back on the net and
people like me, posting where they shouldn't altough they know that,
to stop making life for everybody and especially for our most-valuable
developers more difficult than it could be.

May the source be with all of you,
Viktor

PS:

I apologize to anyone feeling attacked or stepped upon by my post.
(Fell free to flame me if that helps although I have the policy of
 ignoring impolite mail/posts. [see discussion in news.newusers.questions])

Please notice that I'm not a native english speaker and that I
appreciate mails kindly correcting my errors very much.
THX for reading this Message to it's end!


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

Crossposted-To: news.groups
From: rich@mulvey.com
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: Mon, 11 Oct 1993 21:51:33 GMT

Byron A Jeff (byron@cc.gatech.edu) wrote:

: So here's my unofficial ;-) bottom line.

: 1) Development questions are welcome.
: 2) Non-development questions should be directed to c.o.l.help and
: 3) Non-development questions should not be answered here.

: I gurantee that if we don't answer the questions here people will stop posting
: them here.

   Far from it.  If you look at 95% of the questions posted to the linux
groups, it's obvious that people aren't bothering to RTFM *and* monitor
the group for a while before posting, as netiquette dictates.  Not answering
the questions won't work, because the people who post inappropriately won't
look at the group long enough to *see* what gets answered and what doesn't.

- Rich
-- 
Rich Mulvey                 Amateur Radio: N2VDS              Rochester, NY
rich@mulvey.com         "Ignorance should be painful."

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

Crossposted-To: news.groups
From: rich@mulvey.com
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: Mon, 11 Oct 1993 21:55:21 GMT

rich@mulvey.com wrote:
: Byron A Jeff (byron@cc.gatech.edu) wrote:

: : So here's my unofficial ;-) bottom line.

: : 1) Development questions are welcome.
: : 2) Non-development questions should be directed to c.o.l.help and
: : 3) Non-development questions should not be answered here.

: : I gurantee that if we don't answer the questions here people will stop posting
: : them here.

:    Far from it.  If you look at 95% of the questions posted to the linux
: groups, it's obvious that people aren't bothering to RTFM *and* monitor
: the group for a while before posting, as netiquette dictates.  Not answering
: the questions won't work, because the people who post inappropriately won't
: look at the group long enough to *see* what gets answered and what doesn't.


   As a follow-up to my followup:  I just threaded through the rest of the
articles in comp.os.linux.development.  Out of 11 new articles, 2 were
related to this discussion, and the remaining 9 were questions about
xview, suspected bugs, and requests for help with some application
software.

'Nuff said.

- Rich
-- 
Rich Mulvey                 Amateur Radio: N2VDS              Rochester, NY
rich@mulvey.com         "Ignorance should be painful."

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

Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: root@umibox.hanse.de (Bernd Meyer)
Subject: Re: Xfree vs. BIOS
Date: Sun, 10 Oct 1993 14:54:47 GMT

kem@prl.ufl.edu (Kelly Murray) writes:

>Hmm, maybe you should try using dosemu to run the DOS setmode program
>before starting up X?  A kludge, but if it works..

You are aware that dosemu is a wonderful tool for NOT using dos programs?
If you hack it a little, you can use it to list all IO-activities that have
gone on while running a certain program, and then can use this info to
implement the same functionality in a native linux program. 

Bernie

-- 
We both know that the earth is round         | Bernd Meyer, EE-student
So we can't see the way before us to its end | "Nobody is a failure who has
We walk on this way, hand in hand,           |  friends" (from: "It's a   
And I hope you are still with me behind the horizon| wonderful life")

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

From: root@umibox.hanse.de (Bernd Meyer)
Subject: Re: g++ compile times and #pragma interface
Date: Sun, 10 Oct 1993 19:57:10 GMT

imp@boulder.parcplace.com (Warner Losh) writes:


>I'm looking for ways to reduce the compile times of the OI library
>when using g++ on Linux.  I noticed the #pragma interface in the g++
>man page and was wondering if that would help.  Have people out there
>tried the #pragma interface/#pragma implementation stuff with g++ and
>Linux?  How much faster are compiles?  How much smaller are binaries?
>Is it generally worth the effort?  What sort of % decreases in size
>and speed of compile should I expect?

I have played around with linux, OI and gcc a little this evening. The
result is that I'm now able to compile the previewer app in less than 6
minutes on a 8MB 486/33. The following actions speed things up:

a) First of all - free all the memory you can. That is, don't run more
   shells than necessary, don't run top, don't run dosemu, and if you want
   really fasy compiles, don't even run X. I have found that it is OK to
   run programs that don't mind being swapped out completly (like gettys,
   most of the network demons, nn while not bein used....).

b) #pragma interface nearly doubles comilation speed. I used the following
   to create a nice set of include files:

     cd /usr/lib/X11
     mkdir OI_pragme
     cd OI
     for a in *; do (echo "#pragma interface"; cat $a) >../OI_pragma/$a; done
     cd ..
     mv OI OI_org
     ln -s OI_pragma OI

c) Optimization seems to reduce the size of the code held in memory. Using
   -O2 finally pushed me below the 2-minutes-per-file mark. It is NOT faster
   to have no Optimization, but a lot slower

d) There is a very slight speedup when specifying some includedirs - I used
    -I. -I/usr/lib/gcc-lib/i486-linux/2.4.5/include

e) You should really get gcc 2.4.5 if you still use something older. It 
   finishes in 2/3 of the time 2.4.3 needs for OI-code.

f) A general note - most of the compilation time seems to be spent to go
   through all the headers. So including only those needed (instead
   of oi.H) helps a lot. Another good move (performance-wise) is too have
   few large source files instead of many small - every object file takes 
   nearly two minutes just to include oi.H

When using all those tricks, OI and UIB are certainly usable even on a 8MB
machine. So let's go on and write some great apps!

Bernie
-- 
We both know that the earth is round         | Bernd Meyer, EE-student
So we can't see the way before us to its end | "Nobody is a failure who has
We walk on this way, hand in hand,           |  friends" (from: "It's a   
And I hope you are still with me behind the horizon| wonderful life")

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

From: michaelw@desaster.hanse.de (Michael Will)
Subject: Re: Linux and PCI-Board
Date: Mon, 11 Oct 1993 10:04:16 GMT
Reply-To: will@peanuts.informatik.uni-tuebingen.de

krupp@unix-ag.uni-kl.de (Heiko Krupp) writes:
>we had no problem with the ET4000 card. There's just the need of a SCSI driver
>for this NCR5381 chip and maybe the PCI-Graphicscard (we couldn't test).
>We'll have a look on a ATI-Mach32 card for PCI when it's available.
I rather think of the PCI-winner-1000-S3 of ELSA which is available...

>So give PCI a chance...my next board will be a PCI-Board :)
Mine too :-) only it has to be supported by my favourite OS, Linux...

Cheers, Michael Will
-- 
Michael Will <michaelw@desaster.hanse.de>     Linux - share and enjoy :-)
Life is not there if you can't share it... Hazel'O'Connor  Breaking Glass
Happily using Linux 0.99p12 with X11R5, \LaTeX, cnews/nn/uucp and:   PGP!
!!!  new mailadress:   will@peanuts.informatik.uni-tuebingen.de       !!!

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

From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Crossposted-To: news.groups
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: 12 Oct 1993 00:57:27 GMT

In article <29a9g0$olg@samba.oit.unc.edu> mdw@sunSITE.unc.edu (Matt Welsh) writes:
>In article <1993Oct10.204642.6749@rzrbyte.fay.ar.us>,
>Tim Peoples <tep@rzrbyte.fay.ar.us> wrote:
>>
>>>This is an official Request for Discussion for the removal of
>>the group "comp.os.linux.development".  When and if this discussion
>>deems it necessary, a vote will be called on this matter.

>Idiot. People voted highly in favor of this group not 4 months ago.

For this reason alone, this can't be an official Request for Discussion.
According to the USENET rules for group creation/deletion, the process
for creating/deleting comp.os.linux.development can not start until
after six months after the last vote.  So Mr. People's RFD is out of
order for at least two more months.

The rest of his posting showed an equal ignorance of how USENET works,
including his assertion that USENET is only for "answering questions".
Nothing could be further from the truth.

Given these two observations, I urge people to just simply ignore him
and his postings.  If enough people put him into their kill files, maybe
he will go away.

                                                - Ted

P.S.  I hate to say "I told you so", but I did warn people (before the
split) that it was going to be impossible to get people (especially the
idiots) to respect group divisions....

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

Crossposted-To: news.groups
From: fnatt@elmer.alaska.edu (Pirate (Anthony Taylor))
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of grou
Date: Tue, 12 Oct 1993 01:34:14 GMT

In article <acP0ac21w165w@cybernet.cse.fau.edu> dnewcomb@cybernet.cse.fau.edu (Dan Newcombe) writes:

>byron@cc.gatech.edu (Byron A Jeff) writes:
>> So here's my unofficial ;-) bottom line.
>> 
>> 1) Development questions are welcome.
>> 2) Non-development questions should be directed to c.o.l.help and
>> 3) Non-development questions should not be answered here.
>> 
>> I gurantee that if we don't answer the questions here people will stop
>postin
>> them here.

>But you forget.  People will cross post them to c.o.l.a, c.o.l.d, c.o.l.m,
>c.o.l.h, and rec.arts.music :)   That is probably where the worst of our
>problems are.  Not form people posting/answering here, but people
>cross-posting and us having to see all the answers, despite the charter
>saying it is discouraged (Then again, we can't get half the people to read
>the FAQ, much less a charter.)

>        -Dan

A possible (though Not Very Nice) solution: every time a FAQ or non-
development question is posted, every single person on c.o.l.d should send a 
nice, gentle reminder to the person who posted the offending question.  
After a few times of being deluged by mail, I think the poster will figure 
out where to ask user questions.

It's guaranteed to give c.o.l.d a bad rep.  But remember, Keep It Nice.

Lurk mode {on}.

========================================================================
I only wish UAF held the same opinions I do.


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

From: pand@kullmar.se (Peter Andersson)
Subject: Re: Page fault
Date: Mon, 11 Oct 1993 23:45:43 GMT

urlichs@smurf.sub.org (Matthias Urlichs) writes:

>In comp.os.linux.development, article <1993Oct8.092506.20032@kullmar.se>,
>  pand@kullmar.se (Peter Andersson) writes:
>> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>> 
>> What I need is to let my program handle the causing
>> SIGSYSV as this:

>It's sigSEGv.
That's correct, I forgot to "proofread" my text. Sorry :-(

>> 1 - change the protection of the page to allow read & write
>> 2 - single step the instruction who caused the SIGSYSV
>> 3 - change the protection back
>> Got any idea how to handle this?
>> 
>Why do you want to do this in the first place? It seems that singlestepping 
>every instruction that refers to such a page would be hideously slow.
Because I need to emulate all memory references to certain I/O block.

Btw, does anybody know if siginfo() is going to be included to the Linux
kernel?

>> But how does gdb handle it? It is able to single step one instruction!
>> 
>No. It's able to tell the kernel to please set that flag for the process in 
>question, through the ptrace() system call. This is not something you'll want 
>to do in a normal program.
Of course not... but this isn't a "normal" program ;) Thanks for the info btw.

- Peter Andersson, pand@kullmar.se - Sweden (so don't ask me where to find
                                     ^^^^^^  cheap computer equipment! =)



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

Crossposted-To: news.groups
From: remco@hip-hop.suvl.ca.us (Remco Treffkorn)
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of group "comp.os.linux.development")
Date: Mon, 11 Oct 1993 08:20:19 GMT

Matt Welsh (mdw@sunSITE.unc.edu) wrote:
: In article <29aedp$pj7@soc2.pop.psu.edu>, David Barr <barr@pop.psu.edu> wrote:
: >In article <29a9g0$olg@samba.oit.unc.edu>,
... deleted some discussion if Mr. Peoples is an idiot or not...
: mdw
: -- 
: Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu

Matt, David and all the others:

I think we are all idiots, because we swallowed the flame bait.
I think I would be as justified to officially call for Mr. Peoples removal
from the net and would probably get more support for this request than he
will get for his. What saddens me is how defensive many people got. As if
anybody would owe him an explanation for anything. Nobody does!

Worse then anything else, you can't even call him a liar for the "official"
bit. Lots of things on the internet are "official" just because there are
no written rules that would state otherwise. He just made a wrong impression.
He very eloquently abuses the english language to mislead people, that he
probably thinks are inferior to him. 

I am not going to explain the merits of this group. I do not even think of
it as 'going through a bad phase'. It is well and alive and does what it is
supposed to do. It could be better, but what couldn't?

I am willing to explain my opinion about this, or any other group, using email.
What certainly does not belong here are postings like Mr. Peoples or my follow
up (or Matts or Davids or Lars's).

If we could only ignore demagoges like Mr. People COL* would be much more
productive.

Beeing german I have seen at least one too many great manipulator of the
masses. Just ask yourself what Mr. Peoles motivation could be to propose
the killing of a newsgroup that did HIM no harm and is used by many
people in a productive manner. I am sick and tired of the selfproclaimed
defenders of the week with their selfserving agendas and no real compassion
for those 'week' that they feel are too week-minded to defend themselves.

I do not want to be defended by Mr. Peoples. I can very well do that myself
if the need *should* arise. It has not happend yet, it has not happend here!

I FEEL DEEPLY OFFENDED BY MR. PEOPLES POST AND DEMAND AN APOLOGY FROM HIM.

Remco.


-- 

Remco Treffkorn, DC2XT
remco@hip-hop.suvl.ca.us   <<-- REAL reply address !!
(408) 685-1201

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

From: yveslach@binkley.cs.mcgill.ca (Yves LACHANCE)
Crossposted-To: news.groups
Subject: Re: Questions are permitted on c.o.l.d (was Re: RFD: Removal of grou
Date: 12 Oct 1993 04:46:56 GMT

Pirate (Anthony Taylor) (fnatt@elmer.alaska.edu) wrote:

>A possible (though Not Very Nice) solution: every time a FAQ or non-
>development question is posted, every single person on c.o.l.d should send a 
>nice, gentle reminder to the person who posted the offending question.  
>After a few times of being deluged by mail, I think the poster will figure 
>out where to ask user questions.

>It's guaranteed to give c.o.l.d a bad rep.  But remember, Keep It Nice.

Something that might actually get someone in line fairly quickly would be
that every reader of something not in its place send a copy of the FAQ about
c.o.l.*.  Sooner or later the guy will read the FAQ and choose more
carefully the newsgroup in which he posts.  (Note: That's a hell of a
"deluge" in one's mailbox if you receive 50 FAQs overnight...)

PS: I know FAQ isn't the right word for it, but I can't think of the
document's name; in any case, it's the one that describe each newsgroup and
its use.

--
Yves Lachance    | THE GAMEMASTER * (514) 858-7777 * UUCP News/Mail * MajorNet
Montreal, Canada | Teleconference * Board/War/Role Playing Games * On MajorBBS

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

From: df@eyrie.demon.co.uk (Derek Fawcus)
Subject: Re: [Q]Anyone working on Cyrix 486DLC cache coherency probs ?
Date: Mon, 11 Oct 1993 22:46:00 +0000

In article <1993Oct8.044610.1783@falcon.DIALix.oz.au>
  root@falcon.DIALix.oz.au (Darren Gilchrist) writes:

I've seen these questions about the Cyrix chip raised a number of times,
so here's the bumph:

There exist a set of configuration registers CCR0, CCR1, NCR1, NCR2, 
NCR3 and NCR4 that control how the on-chip cache works.  These registers
are accessed through two I/O ports (0x22 and 0x23), the first port 0x22
is an address index register and 0x23 is a data register.

The cache control registers are at addresses in the range 0xc0 to 0xcf,
to use them write the index into 0x22 and read/write the value from/to
0x23.

Register Name                   Index                   Size (bytes)
=============                   =====                   ============

CCR0                            0xc0                    1
Configuration Control 0

CCR1                            0xc1                    1
Configuration Control 1

NCR1                            0xc4 - 0xc6             3
Non-Cachable Region 1

NCR2                            0xc7 - 0xc9             3
Non-Cachable Region 2

NCR3                            0xca - 0xcc             3
Non-Cachable Region 3

NCR4                            0xcd - 0xcf             3
Non-Cachable Region 4

The non-cachable regions are specified by a block size and a starting
address.  The sizes range from 4kbytes to 4Gbytes, the starting address
must be on a multiple of the the block size.  A size of 0 disables that
non-cachable region, and a size of 4G marks all of memory as non-cachable.

Taking NCR1 as an example, the break down is as follows:

        ADDR    BITS
        0xc4    7 - 0           Address bits 31-24 of starting address
        0xc5    7 - 0                        23-16
        0xc6    7 - 4                        15-12
                3 - 0           Block size, call this value sz

Registers NCR2 - NCR4 are as above but with different starting regions.

Block sizes are given by size = 2048bytes * (2 ^ sz) except for values
of sz of 0 and 15 which are disable region and 4G non-cachable respectivly.

CCR0 is a set of bits as follows:

        BIT     NAME

        0       NC0     If 1 sets the first 64k of each 1M boundary as
                        non-cachable.

        1       NC1     If 1 sets 640k to 1M as non-cachable

        2       A20M    If 1 enables A20M# input (ala '486) - don't alter.

        3       KEN     If 1 enables KEN# input - don't alter.

        4       FLUSH   If 1 enables FLUSH# input - don't alter.

        5       BARB    If 1 enables flushing of the internal cache when hold
                        state is entered.

        6       CO      Selects cache organisation. 0 = 2 way set associative
                                                    1 = direct-mapped

        7       SUSPEND If 1 enables SUSP# input and SUSPA# output - dont alter.


CCR1 is not really of interest as it controls the use of the RPLSET and
RPLVAL# output lines, these require extra hardware and on a board designed
for the Cyrix chip should probably not be touched.  If bit 0 is set then
these lines are enabled.

On power up all bits are 0 except 0xc6 which is set to 0x0f thereby
disabling all caching.


Now to the specifics in you article:

> The second problem is the lack of cache coherency (if it were enabled
> :-)) Because the 386 had no internal cache, there are no cache coherency
> lines such as FLUSH# etc which would be normally become activated after
> (for example) a DMA transfer on a true 486 (Oh no I hear you all say...)

I would suggest that you enable the BARB option listed above, as this may
flush the cache whenever DMA occurs (assuming that DMA causes the uP to
enter the hold state).  You could also set NC1 if and try both values in
CO to see which is best.

> If I shove the 486DLC detection code (Developed for SysV r4+ by Ti Kan -
> most likely req modification) into boot.S and enable caching (minus
> 640-1M limit?) and patch the enable_dma() code in include/asm/dma.h to
> disable caching during dma transfer will it work :-) Or more to the
> point, is that where it should go ?

Certainly you'd need to use some detection code, but I'd add it to the
kernel proper (part of boot/head.S) so that if you need to use software
cache flushing you can test a variable.

Then set some values in the registers ie, adjust the bits I mentioned
above, and change 0xC6 such that memory is cachable.  You may wish to
set a non-cahable region if you have a linearly mapped video card.

If using BARB doesn't sort out your cache coherency issues then you could
mark the floppy (and QIC-40/80) transfer regions as non-cachable.  At
worst you could flush the cache after a DMA trasfer.

> The other problem is the scsi device WD7000 code enables dma transfer at
> init time if the channel is available and leaves it in this state...

> Any ideas on how to determine whether DMA transfer has completed, with
> minimal modification to the blk_drv code ?

Any slave DMA could be handled by flushing the cache after a transfer,
(expensive but it may be all you can do).  Bus-Master DMA would have to
be handled in a similar manner - ie flush the cache after you receive
the notification that the transfer has completed.  NB the manual cache
flushes are assuming that using BARB does not work.

Last bit of info, to flush the cahce load 3 into TR5 (you may have to
also load 7 - i'm not sure from the manual).

Good Luck with the mod's Darren, from the above you should be able to get
started.

PS: If Cyrix come out with a 80MHz DRu2 (to replace my 40MHz 386) at a
    reasonable price then I may buy one and actually use the above.

DF
-- 
Derek Fawcus (G7FVS)                                df@eyrie.demon.co.uk

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
