Subject: Linux-Development Digest #153
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:     Sun, 10 Oct 93 15:13:15 EDT

Linux-Development Digest #153, Volume #1         Sun, 10 Oct 93 15:13:15 EDT

Contents:
  Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?) (Daniel Quinlan)
  Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?) (Mark Swanson)
  Re: Xfree vs. BIOS (Matt McLeod)
  setitimer bug ? (Martin de Jong)
  Re: possible bug in virtual console switching (Kevin Brown)
  Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?) (Stefan Lukka)
  Re: setitimer bug ? (Casper H.S. Dik)
  Re: PLEASE HELP ME WITH MY SMAIL ROUTING.... (Andreas Klemm)
  NO QUESTIONS HERE PLEASE (Re: gcc on Linux acts wierdly compared to SUN) (Ian Jackson)
  Re: possible bug in virtual console switching (Joel M. Hoffman)
  Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?) (Daniel Quinlan)
  Re: GCC and structure field alignment (Johan Myreen)
  CMS Jumbo (QIC 40/80) Driver Status (Steve Traugott)

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

From: quinlan@aries.cs.bucknell.edu (Daniel Quinlan)
Subject: Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
Date: 10 Oct 1993 04:39:53 GMT
Reply-To: quinlan@spectrum.cs.bucknell.edu

>>>>> slukka@nyx.cs.du.edu (Stefan Lukka) said:

[in response to a post by Ian Jackson]

>>Please DO NOT POST QUESTIONS TO THIS GROUP and READ THE FAQ AND THE
>>HOWTOS BEFORE POSTING.

> How about you SHUT THE F*CK UP AND GET LOST? It isn't enough to put
> your moronic hourly "READ THIS" posts in my kill file, now I have to
> listen to more of your net.cop crap as well? GO GET A LIFE and stop
> harrasing people!

Is it so much to ask that people read the FAQs and HOWTO before
posting to the world?  What have you done for the Linux community
lately?  Ian maintains the FAQ and also tries to reduce the amount of
posting due to people who are too damn lazy to look for the answer
on their own - you just bitch.

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

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

From: ag010@Freenet.carleton.ca (Mark Swanson)
Subject: Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
Date: Sun, 10 Oct 1993 05:27:14 GMT


What Ian said was correct.  This IS the development channel as well... like Ian said.
Also, I found your rebuttle childish.  
-- 
Mark Swanson.    ag010@freenet.carleton.ca

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

Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: matt@krikkit1.apana.org.au (Matt McLeod)
Subject: Re: Xfree vs. BIOS
Date: Sat, 9 Oct 1993 23:39:27 GMT

Michael Griffith (grif@ucrengr.ucr.edu) wrote:
: In article <28uv1s$gos@cville-srv.wam.umd.edu>,
: Barzilai Spinak <barspi@wam.umd.edu> wrote:
: [citation deleted]
: >   I want to give a humble (and maybe a little naive) comment on that. 
: >If, as you say, all the needed video info can be gotten by BIOS calls, a few
: >lines of code could be added to the kernel before it goes into protected mode
: >to find out this info. Then, a little program can be written to install
: >XFree, which asks the kernel "What did you find out?", and then fill in the
: >information in that file that XFree uses when it starts (xcongif or something 
: >like that, I think). Now, this may have already been done; so, I may
: >be talking too much...
: [sig deleted]

: Perhaps you miss the point.  Although it might be easy enough for us
: to interrogate the BIOS in Linux, it will not be so easy to do that
: for the dozen or so other OS's that Xfree runs on.  The Xfree folks
: are not interested in solutions that only work on one out of many of
: the operating systems that they support.

Hm.  I was rather under the impression he was suggesting that this be a
part of the installation - no changes needed to XFree itself, just a
little program which can be run to make the necessary changes to xconfig.

It would be nice, but I'm not holding my breath...

Matt
-- 
                Matt McLeod     (matt@krikkit1.apana.org.au)
    Sysop, Krikkit One Public Access Unix, +61 49 423565 (11pm-7am AEST)
             "Hey Rocky!  Watch me pull a rabbit out of my hat!"

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

Crossposted-To: comp.unix.programmer
From: mdejong@dutiws.twi.tudelft.nl (Martin de Jong)
Subject: setitimer bug ?
Date: Sun, 10 Oct 1993 15:23:05 GMT

I'm writing a program that needs a timer.. I'm using the setitimer function
for this. It seems that there is a difference in handling a timer in linux
and in SunOS. In SunOS, if i set a timer, it will call a function that handles
SIGALRM every second for example.

In linux on the other hand, it will only call the function that handles
SIGALRM once. After that first time SIGALRM will be handled in the default
way, which is killing the proces.

Example code :

sighandler()
{
        /* Do something here... */
}

main()
{
        signal(SIGALRM,sighandler);
        setitimer(ITIMER_REAL,&value,&ovalue);
}

Currently i made a workaround by putting the following code in the handler :

#ifdef __linux__
        signal(SIGALRM,sighandler);
#endif

No everything works ok, but it doesn't look nice...
Am i doing something wrong, or is this a difference between the two OS's ?

I don't have the manual pages for setitimer and signal for linux, only the
ones from Sun. And the Sun behaves like it should.

-- 
/------------------------------------------------------------------\
| Martin de Jong  | E-Mail : mdejong@dutiws.twi.tudelft.nl         |
|                 |          martin@kgs.twi.tudelft.nl             |
|                 |          martin@void.tdcnet.nl                 |
\------------------------------------------------------------------/

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: possible bug in virtual console switching
Date: Sun, 10 Oct 1993 08:54:35 GMT

In article <931009562@caution.cistron.nl.mugnet.org> danny@caution.cistron.nl.mugnet.org (Danny ter Haar) writes:
>In article <CEL9BB.HDq@sunsrvr6.cci.com> rxg@cci.com (Rob Getter) writes:
>>every other keypress, and others beep. If I switch to another text VC and
>>back, it is back to normal. I don't know whether this is in .99p12 since I
>>jumped from .99p11 to .99p13.
>>
>It's not only solved by switching VC's, try pushing the cntrl-alt-shit keys
>on the left and the right and al is done. Somehow the kernel thinks one of
>those keys is stuck and by pressing and releasing them the kernel also 
>notices them as released.... dont know hy ...

Interestingly enough, this causes a really bizarre thing to happen.  I'm
running bash, which by default comes up in emacs mode, but if I do the
VC switch from an X session to a regular VC and hit return immediately
after the switch, oftentimes I'll get the behavior as described above and,
even stranger, bash will be in vi mode!  doing a "set -o emacs" will
restore things (after doing the ctrl-alt-shift thing) back to normal.  I
find this behavior very peculiar.  Fortunately, it's not a show-stopper.


-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?

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

From: slukka@nyx.cs.du.edu (Stefan Lukka)
Subject: Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
Reply-To: /dev/null@nyx.cs.du.edu
Date: 10 Oct 93 16:44:58 GMT

In article <CEo1tE.K3t@freenet.carleton.ca> ag010@Freenet.carleton.ca (Mark Swanson) writes:
>
>What Ian said was correct.  This IS the development channel as well... like Ian said.
>Also, I found your rebuttle childish.

More childish than calling someone who simply raised a
development-related issue "Idiot who knows no netiquette"? Read
Jackason's post carefully. Such an unprovoked attack is simply
unacceptable, and should not be condoned.

Stefan J Lukka /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\


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

From: casper@fwi.uva.nl (Casper H.S. Dik)
Crossposted-To: comp.unix.programmer
Subject: Re: setitimer bug ?
Date: 10 Oct 1993 16:57:54 GMT

mdejong@dutiws.twi.tudelft.nl (Martin de Jong) writes:

>In linux on the other hand, it will only call the function that handles
>SIGALRM once. After that first time SIGALRM will be handled in the default
>way, which is killing the proces.

>I don't have the manual pages for setitimer and signal for linux, only the
>ones from Sun. And the Sun behaves like it should.

My Sun doesn't behave this way at all :-).
Short answer: look at the sigaction manual page and use that.
(Disclaimer: I don't know Linux, and I'm not sure whether it's
Posixy enough. But it should have either sigset() or sigaction().)

A long time ago, the semantics of signal() were like this: once
a signal was raised, the signal handler was reset to the default.
That was inconvenient, but nothing more. Worse though, there was no
way to block signals are make sure you'd catch all signals.
There's always a small gap between the moment the OS resets the signal
handler and the moment you get the chance the reinstate the signal
handler in the signal handler.

``Reliable signals'' were introduced in BSD to remedy this.
The semantics and (kernel) implementation of the BSD implementation
were fine. Alas, the programming interface they designed had a large
number of flaws:
        - silent change to the semantics of signal.
        - signal mask limited to number of bits in int.
        - no easy extensible interface.

It's the silent change the signal() that's giving me most problems
when porting to SysV environments.

Of course, other interface designs didn't do to well either.
(The sigset/sighold/sigrelse interface as found in SysV has
a fatal flaw that makes sighold()/sigrelse() pairs unusable).

Fortunately, POSIX did this right and made an interface that
looks very much like the BSD interface except:
        - no signal() or compatibl call
        - no sizeof(integral type) limit on number of signals
        - renamed all calls (when you change the interface/semantics,
                change the name)

                sigvec - sigaction
                sigblock/sigsetmask - sigprocmask
                sigpause - sigsuspend
        - new calls
                sigpending - what signals are pending
                sig*set, sigismember - manipulate signal sets.

I strongly advise the use of the POSIX calls.

I also believe that the semantics of signal() in SunOS x.y (x < 5) and BSD
Unix to be wrong: changing signal in this way has been a costly mistake
in the ongoing porting costs it gives today. Bugs caused by this change
are often very hard to find.
Either using BSD signal() the traditional way or using traditional
signal the BSD way or even more subtle interaction with SIGCH*LD
is one of the trickiest porting issues in my book.

Casper

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

From: andreas@knobel.knirsch.de (Andreas Klemm)
Crossposted-To: comp.os.linux.misc,comp.os.linux.help
Subject: Re: PLEASE HELP ME WITH MY SMAIL ROUTING....
Date: 10 Oct 1993 14:24:01 -0000

pogyk@unixg.ubc.ca (Pogy Kurniawan) writes:

>I have recently installed Slackware 1.04 (great package) get it. But I 
>am no smail expert. My machine name is holly.can.com (and holly.uucp).
>Yes my machine has to take email to others within my domain and forward
>it to my uucp neighbors. I have a smarthost defined at van-bc just a uucp
>call away. And I have two downstream feeds (ve7lad.can.com or ve7lad and
>provar.can.com or provar) If mail comes in to my machine it should be
>should put it into their /usr/spool/uucp/provar and /usr/spool/uucp/ve7lad.
>Which would make sense. (they would call me and pick up their mail)
>But it does not, it just gives it to my smarthost. This is very frustrating.
>Also if I type mail ve7lad!bj or provar!root  it still gives it to the smarthost
>If you have any suggestions please email. I am desperate for advice.

I think you have to make an entry into smail's paths file,
usually located in /usr/lib/smail

There should be entries for your machine, your smarthost and each
system, that should receive mail directly from you.

Something like this:

.can.com        van-bc!%s
holly   %s
holly.can.com   %s
provar  provar!%s
provar.can.com  provar!%s
van-bc  van-bc!%s
van-bc.can.com  van-bc!%s
ve7lad  ve7lad!%s
ve7lad.can.com  ve7lad!%s

Usually this file is sorted.
-- 
Andreas Klemm                 /\/\____ Wiechers & Partner Datentechnik GmbH 
andreas@knobel.knirsch.de ___/\/\/     andreas@sunny.wup.de (Unix Support)

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

From: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: NO QUESTIONS HERE PLEASE (Re: gcc on Linux acts wierdly compared to SUN)
Date: Sun, 10 Oct 1993 11:15:58 GMT

In article <1993Oct9.190902.28392@cdf.toronto.edu>,
Dhaliwal Bikram Singh <a228dhal@cdf.toronto.edu> wrote:
>I am doing a program that requires heavy use of linked lists.  We
>are running gcc on our SUN IPC's at school, I have had no problems
>compiling and getting expected results from this setup.  Except it is
>when I try to compile the same program at home that I get results that
>I can't figure out.
>
>[...]

1. You posted to the wrong group.  GCC questions go to gnu.gcc.help,
bug reports to gnu.gcc.bug; there's nothing really special about the
Linux port of GCC.  You should CERTAINLY not post ANY kind of question
to c.o.l.development.

>I am sorry that I am not that descriptive, I can't get cut and paste
>to work between my xterm and the program I am using to log onto the 
>schools computer (minicom in an xterm, another question).

2. There is nowhere near enough information here to figure out your
problem.  Saying `cut and paste didn't work' is no excuse - figure out
how to get it to work, or find another way to transfer the file.  If
you can't be bothered to do this you're saying very rude things about
how you value your time compared to that of the readers of
col.development.

>Should I upgrade my version of gcc?  It is the distribution that came
>with the 99pl10 release (I think).

3. You should have read the GCC Info documentation.  Then you know how
to get GCC to show you its version number, and then we would know what
version of GCC you're running.  You'd also know how to report a bug
in GCC and what information is required.

Please go and read Matt Welsh's "Introduction to the comp.os.linux
Hierarchy", the netiquette postings in news.announce.newusers, and the
GCC documentation.

In the meantime if you send your program to me I'll tell you what you
did wrong - I'm 98% certain that you haven't found a bug in GCC.

-- 
Ian Jackson, at home  <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
PGP2 public key available on server.  Urgent email: <iwj10@phx.cam.ac.uk>
2 Lexington Close, Cambridge, CB4 3LS, England;  phone: +44 223 64238

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

From: joel@rac3.wam.umd.edu (Joel M. Hoffman)
Subject: Re: possible bug in virtual console switching
Date: Sun, 10 Oct 1993 17:48:35 GMT

[who wrote what deleted]
>>>every other keypress, and others beep. If I switch to another text VC and
>>>back, it is back to normal. I don't know whether this is in .99p12 since I
>>>jumped from .99p11 to .99p13.
>>>
>>It's not only solved by switching VC's, try pushing the cntrl-alt-shit keys
>>on the left and the right and al is done. Somehow the kernel thinks one of
>>those keys is stuck and by pressing and releasing them the kernel also 
>>notices them as released.... dont know hy ...
>
>Interestingly enough, this causes a really bizarre thing to happen.  I'm
>running bash, which by default comes up in emacs mode, but if I do the
>VC switch from an X session to a regular VC and hit return immediately
>after the switch, oftentimes I'll get the behavior as described above and,
>even stranger, bash will be in vi mode!  doing a "set -o emacs" will
>restore things (after doing the ctrl-alt-shift thing) back to normal.  I
>find this behavior very peculiar.  Fortunately, it's not a show-stopper.

I find the same thing (with dosemu and other VC's).  So, there's
clearly something wrong.  And what's wrong is the VC switching, and in
particular, that part of it that both X and dosemu use.  Further,
whatever it is about the keyboard that bash uses to go into vi mode is
be changed, so that should provide a clue.  If I had the sources to
bash handy I might even try to track it down myself....

-Joel
(joel@wam.umd.edu)
-- 
=============================================================================
|_|~~ Germany, Europe. 1943.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded. 
 cnc  Bosnia, Europe. 1993.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the 
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
=============================================================================
     Tell Clinton to stop the genocide:  president@whitehouse.gov

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

From: quinlan@pleiades.cs.bucknell.edu (Daniel Quinlan)
Subject: Re: NO QUESTIONS HERE PLEASE / RTF FAQ (Re: -m486 doing nothing?)
Date: 10 Oct 1993 18:09:20 GMT
Reply-To: quinlan@spectrum.cs.bucknell.edu


ag010@Freenet.carleton.ca (Mark Swanson) writes:

>> What Ian said was correct.  This IS the development channel as
>> well... like Ian said.  Also, I found your rebuttle childish.

slukka@nyx.cs.du.edu (Stefan Lukka) adds:

> More childish than calling someone who simply raised a
> development-related issue "Idiot who knows no netiquette"? Read
> Jackason's post carefully. Such an unprovoked attack is simply
> unacceptable, and should not be condoned.

"development-related issue?"  Are you serious?  What was he developing
other than an enormous 11 line signature and an attitude where he
couldn't even bother to RTF FAQ?

As far as netiquette goes, you know none.  You should not criticize
anyone about netiquette when you have this crap this in your header:

Reply-To: /dev/null@nyx.cs.du.edu

Are you afraid of getting a reply to your posts?  Grow up.

// Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

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

From: jem@snakemail.hut.fi (Johan Myreen)
Subject: Re: GCC and structure field alignment
Date: 09 Oct 93 18:17:40 GMT

In article <1993Oct8.160006.4728@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:

>I suggest you read the standard before claiming that something is broken.
>Bitfield support is not guaranteed to be *anything*; most especially it is not
>guaranteed to be portable and it is not guaranteed to generate any particular
>alignment.  It never has been.  And it probably never will be, since C would
>become much harder to implement on many processors if a specific alignment
>were required.

>Anyone want to quote chapter and verse from K&R2 here?  My copy's at work; all
>I have here is K&R1.

K&R2 Appendix A, page 212-214 (in my copy):

8.3 Structure and Union Declarations


It includes the comment:

``The ANSI standard makes fields even more implementation-dependent
than the first edition. It is advisable to read the language rules for
storing bit-fields as "implementation-dependent" without
qualification. Structures may be used as a portable way of attempting
to reduce the storage required for a structure (with the probable cost
of increasing the instruction space, and time, needed to access the
fields), or as a non-portable way to describe a storage layout known
at the bit level. In the second case, it is necessary to understand
the rules of the local implementation.''

-- 
Johan Myreen
jem@cs.hut.fi
60 11'55" N, 24 53'30" E

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

From: stevegt@TerraLuna.Org (Steve Traugott)
Subject: CMS Jumbo (QIC 40/80) Driver Status
Date: Sun, 10 Oct 93 12:58:39 EDT

Does anyone know the current status of any QIC-40 or QIC-80 driver
for Linux?  (Such as for the Colorado Memory Systems Jumbo tape
drives.)

I emailed someone at CMS, and found out the following from their
perspective.  I'd be interested to see what comments people have,
particularly in the area of System V and installpkg compatibility.

(I am not a current Linux user, but would like to be - I do UNIX
SVR4.x internals work professionally, but am looking for something I
can hack the source for at home.  Linux fits that bill, but I can't
see getting rid of the popular tape drive I already own just so I can
upgrade.)

I haven't called the QIC Committee yet - has anyone here already
contacted them?

Steve
---                     .        .    `   *    
Steve Traugott             `    .  *           +       stevegt@TerraLuna.Org
 ...Organizational Evolution         +    ` .   .      stevegt@well.sf.ca.us
Unix/Internet Systems Engineer         .      UUs-L@UBVM.BITNET List Manager
Currently contracting in Summit, NJ  .                       stevegt@usl.com



Date: 30 Sep 93 19:22:57 EDT
From: CO_MEM_SYS <71621.3022@CompuServe.COM>
Subject: Jumbo Linux Driver

It is true that CMS does not have a driver for Linux.  But you are welcome
to call the QIC Committee at 805-963-3853 for the required specs to write
your own driver.
 
Our Unix driver SU-53J is System 5 compatible and Linux is not.  We use an
install package method of installation which is not offered in terms with
Linux.  We are cognizant of the ever growing need for backup under Linux and
this market may at sometime be explored.  We do have plans to create a Posix
compliant driver, but the release date is unknown; perhaps within a few
months depending solely on market need and feasibility of creating the
drivers.  We appreciate your input and hope to have something to suit your
needs soon.  Keep in touch.
 
    <Name Withheld - I didn't obtain specific permission to repost; I
    asked, but didn't get a yes or no answer.>

    Customer Support Engineer- Colorado Memory Systems

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


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