Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest282
2024-02-19 00:24:15 -05:00

627 lines
23 KiB
Plaintext

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, 9 Oct 94 02:13:07 EDT
Subject: Linux-Development Digest #282
Linux-Development Digest #282, Volume #2 Sun, 9 Oct 94 02:13:07 EDT
Contents:
Device driver for serial line/SCSI device (Jan Willamowius)
Re: 1280x1024, Term, and System Lockup! (Olaf Titz)
Re: Shared library - HOW? (John S. Kallal)
Re: Linux For Mac (Tony Jones)
Re: Telnet & ftp freeze! - AND possible FIX (Thomas E Zerucha)
Re: Beautifying Linux/Xfree (Tom Wilson)
Re: 1280x1024, Term, and System Lockup! (Yasuo Ohgaki)
Re: Orchid Soundwave32 (Michael Hipp)
Re: Flame on the attitude of Linux towards GCC development (Jeff Kesselman)
Re: Shared Libs: working toward a permanent solution? (H. Peter Anvin)
Re: LINUX & VESA vs ISA (H. Peter Anvin)
Re: Flame on the attitude of Linux towards GCC development (Henry Ware)
Re: Flame on the attitude of Linux towards GCC development (Stormy Henderson)
Re: Improving SLIP latency under Linux (Al Longyear)
----------------------------------------------------------------------------
From: jan@janhh.sh.sub.de (Jan Willamowius)
Subject: Device driver for serial line/SCSI device
Date: Thu, 6 Oct 1994 12:43:05 GMT
I'd like to write a device driver for a scanner that's connected
to the serial line or the SCSI port.
It should be in the kernel (or a loadable module), so it can register
a character device and can be accessed bei applications using ioctl.
But I'd like to use "high level" communication with the serial/SCSI
port that is unavailable to a kernel driver.
What would be the best way to implement such a driver ?
- Jan
--
Jan Willamowius, Nienredder 6, 22527 Hamburg, Germany
E-Mail: jan@janhh.sh.sub.de
(if E-Mail fails, please try: willamow@informatik.uni-hamburg.de)
------------------------------
From: uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz)
Crossposted-To: comp.os.linux.help
Subject: Re: 1280x1024, Term, and System Lockup!
Date: 6 Oct 1994 13:24:04 GMT
Joseph Bennett - PCD ~ <jbennett@frx146.intel.com> wrote:
> I am running Linux on my 486 DX/2 66 PCI system. I have been running
How much RAM?
> Now, however, I am greedy, and have attempted to alter my Xconfig to run
> X at 1280x1024 resolution.
>...
> This one program, however, causes the whole system to LOCK UP! It draws
Does this program use extraordinarliy much memory? If yes, perhaps
increased RAM usage of the X server and/or the program in question
(does it make the window bigger?) in higher resolution might cause a
memory hog.
Olaf
--
___ olaf@bigred.ka.sub.org - uknf@rz.uni-karlsruhe.de
__ o <a href="http://rzstud1.rz.uni-karlsruhe.de/~uknf/">click</a>
__/<_ also: s_titz@ira.uka.de - uknf@dkauni2.bitnet - praetorius@irc
_)>(_)_________ "now i find that most of the time love's not enough in itself"
------------------------------
From: kallal@stimpy.eecis.udel.edu (John S. Kallal)
Subject: Re: Shared library - HOW?
Date: 9 Oct 1994 00:33:06 GMT
In article <jwshin.781607962@nitride.EECS.Berkeley.EDU> jwshin@nitride.EECS.Berkeley.EDU (Jinwoo Shin) writes:
>Can someone tell me the details of Linux shared library stuffs? Like how to
>create a shared library with gcc? If there is a faq for this, I couldn't find
>one.
You need to get the file
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.16.tar.gz
Then make and print out the file 'README.ps' for instructions on how to make
a DLL shared library. I think that you need to talk to Eric Youngdale about
address assignments for your shared library. The procedure look a bit complex
for a brand new library.
However if you can wait a few months, REAL SOON NOW a elf shared
library toolset is due out. The elf format shared library fixed some of the
problems with the current DLL shared library system.
John Kallal (kallal@udel.edu)
------------------------------
From: tony@odin.sunquest.com (Tony Jones)
Subject: Re: Linux For Mac
Date: 8 Oct 1994 10:33:08 -0700
Aaron 'Raz' Wrasman (wrasman@duncan.cs.utk.edu) wrote:
: Actually could I get some info on Linux for the Mac also? My friend
: has a Mac and was wondering the same thing, he doesn't keep up with
: these groups though.
It would be nice to have something about the status of the PowerMac port
posted every so often (other than the 3 lines which never change in the projects
FAQ).
From reading the group, it seems lots of people have tried e-mailing the
developers, and their mail was bit-bucketed. Clearly it's annoying for those
doing the port to be constantly bonbarded with e-mail.
Maybe an official status posting every 2 months or so, would keep everyone
happy ????
From the total lack of info, I'm starting to wonder if the port isn't in
trouble ?
tony (still searching for hardware info on the PowerMAC)
--
Tony Jones (tony@sunquest.com)
UNIX Technical Resource Group
Sunquest Information Systems
------------------------------
From: zerucha@shell.portal.com (Thomas E Zerucha)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Telnet & ftp freeze! - AND possible FIX
Date: 8 Oct 1994 18:24:58 GMT
Please undo my previous patch.
I think the following code should fix the problem. It works on my system.
It corrects a locked socket buffer problem with ppp.c (the one with 2.1.2a).
(change is at the end of ppp_xmit). (compare 3c505.c).
---
zerucha@shell.portal.com - main email address
*** linhb/drivers/net/ppp.c Fri Sep 16 22:09:22 1994
--- linux/drivers/net/ppp.c Sat Oct 8 13:40:07 1994
***************
*** 1760,1767 ****
ppp_kick_tty(ppp);
done:
if (skb->free)
! kfree_skb(skb, FREE_WRITE);
return 0;
}
--- 1760,1769 ----
ppp_kick_tty(ppp);
done:
+ #if 0
if (skb->free)
! #endif
! dev_kfree_skb(skb, FREE_WRITE);
return 0;
}
------------------------------
From: ctwilson@mercury.interpath.net (Tom Wilson)
Crossposted-To: comp.os.linux.misc
Subject: Re: Beautifying Linux/Xfree
Date: 8 Oct 1994 22:28:57 -0400
Ummm, not trying to be picky or anything, but you're crediting me
with the original posters work. I was trying to say basically the
same thing you were, except that I was adding that to be VUE-like
you might need motif...myself, I've used fvwm and xfm to set up a
fairly handy desktop...
In article <BCR.94Oct8001740@k9.via.term.none>,
Bill C. Riemers <bcr@physics.purdue.edu> wrote:
:>>>>> "Tom" == Tom Wilson <ctwilson@mercury.interpath.net> writes:
:
: Tom> In article <372tg0$1ai@huron.eel.ufl.edu>, Alexandra Griffin
: Tom> <acg@kzin.cen.ufl.edu> wrote:
not mine.....
:
: Tom> :3) Another idea from HP-VUE... this environment
: Tom> features a "console :bar" area at the bottom of the screen,
: Tom> containing buttons to switch :virtual desktops, invocation
: Tom> icons for commonly-used apps, small icons
:
:
:It already exists. Its called "GoodStuff" and is part of fvwm. For
:example, I prefere to put stuff on the side. So I have a left
:"management" area that contains the following:
:
YUP!
{CHOMP}
:By using the side, istead of the bottom, I still have about 1024x910
:of my 1152x910 display left. Leaving me ruffly a square screen area
:to work with.
:
: Tom> I've been toying with somthing quite similar using fvwm and
: Tom> xfm...the functionality is quite similar if you don't mind
: Tom> using fvwm's virtual desktops.
:
:Whats wrong with them. I prefere virtual screens to virtual desktops,
NOTHING AT ALL. PLease, don't be so sensitive..I'm not talking
about your children. Personally, I think they're fine. My remarks
were aimed at the *ORIGINAL POSTER*.
:but normally I use a combination of both. i.e. Completely separate
:projects go on different desktops, the same project overflows to
:different virtual screens. Since it is a pain sticking windows
:switching to another desktop and then unsticking them (the only way
:I know to move windows between desktops) virtual screens tend to
:be easier.
Sounds fine to me.
: Tom> :for system functions (logging out...), and space for a
: Tom> clock, :calendar, Xload bargraph, & other stuff. The
: Tom> appearance of the bar is :very professional, with little
: Tom> beveled insets for each item. I'm
Once again, this is the *****original poster,****** *NOT* me.
:You can arrange your desktop however you want. I agree this should be
:much easier to configure. It took me quite awhile to come-up with
:something I think looks just as professional as as the HP-UX
:environment. Even longer to improve on it. "vuewm" is you can't
:load your own background, you have to stick to ugly patterns.
You can load whatever you please...you should see the variety of
wallpapers that my coworkers use.
:I much prefere being able to have 'xv" load a random picture from
:CD every 5 or so minuites, so I'm not constantly looking at the
:same thing.
Probably quite possible from VUE, but you have to remember, I
was the one that was speaking for what was already there,
not *for* VUE. The overhead is excessive, it's based on motif,
which, as we all know is *not free*. Nice, mind you, but I'm
quite satisfied with what I've put together with X, fvwm, and xfm.
:
:What is really needed is:
:
: 1. A Null box. i.e. Something that can be used to mark areas for
: xload, xbiff, and icons even when they aren't present, but as
: far as the window manager is conserned don't exist.
:
: 2. Auto-resume from last session. i.e. Each time I end-up opening
: several xterms in one screen, emacs somewhere else, Mosaic, ...
: if fvwm could remember what I had running when I quit and ask
: me to restart them again, it would be quite a timesaver.
This is the one thing that VUE has that I like, except that it doesn't
query, you. Does a nice job of remembering what had running if you
ask it to, though. Now, if its desktops were threaded :-).
--
/-----------------------------------------------------------------------\
| Tom Wilson | "I can't complain, but sometimes |
| ctwilson@rock.concert.net | I still do." |
| | -Joe Walsh |
------------------------------
Crossposted-To: comp.os.linux.help
From: yohgaki@mercury.cair.du.edu (Yasuo Ohgaki)
Subject: Re: 1280x1024, Term, and System Lockup!
Date: Tue, 4 Oct 1994 19:19:30 GMT
Joseph Bennett - PCD ~ (jbennett@frx146.intel.com) wrote:
: Hello.
: I am running Linux on my 486 DX/2 66 PCI system. I have been running
: Term over a 14.4kb modem to dial into work, and was running at 1024x768
: resolution.
: Everything has been working just honky-dory. No problems whatsoever.
: Now, however, I am greedy, and have attempted to alter my Xconfig to run
: X at 1280x1024 resolution.
: At first, everything was fine. I grabbed one of the examples from the
: Sample-Xconfig directory, and my monitor (Nanao F550i) and video card
: (ATI Mach32 PCI) were cool with it. I dialed into work with Term, no
: problems, and was able to run all but *1* of my X programs with absolutely
: no hitches.
: This one program, however, causes the whole system to LOCK UP! It draws
: the main window fine, and gets as far as bringing the second window up,
: but when it attempts to finish drawing it, the system goes dead. The
: modem stops sending packets, the disk drive stops, mouse and keyboard
: are dead. I have to push the computer's RESET button because I am
: completely dead in the water.
: The program is "Vantage Spread Sheet", our VHDL simulator.
: I tried a new kernel, same problem. I went back to my older 1024x768
: resolution, and it all worked fine. Which leads me to believe that
: I am not setting up the video correctly, and this is causing some
: really unpredictable behavior.
: Anyway, here is my video hardware setup:
: Nanao F550i 17" monitor
: ATI Mach 32 PCI video card (2 Meg RAM)
: Xconfig line for 1280x1024 resolution:
: "1280x1024" 110 1280 1328 1512 1712 1024 1025 1028 1054
: I had also tried this line, but my monitor apparently didn't like it (too
: high a refresh rate, I'm assuming):
: "1280x1024" 135 1280 1312 1456 1712 1024 1027 1030 1064
This is not what you asked but your monitor supports upto 110Mhz. If
you use higher than 110Mhz dot clock, it just shutdown automatically
to protect your monitor. So don't use higher than 110Mhz clock.
Read README files for X for more info. I think good monitors will
shutdown automatically if you try to run monitor over spec.
BTW, those who don't have what you are doing. You can damage your HW.
Read readme, howto, etc before play around with XFree.
: Any help would be appreciated. I thank everybody who already responded
: to a post of mine for more Xconfig samples, even though they didn't work.
: The only other piece of information I can give you is that this is
: program comes up with the message "unknown X server XFree86" or something
: like that when attempting to bring the program up.
: As an aside, I'm kind of surprised my whole system locked up. I really
: wouldn't have expected that. I just would have thought Term would die
: or something.
: Also, I'm still unclear on the concept of the three horizontal and vertical
: timing numbers that appear after the pixel value. Is there some mathematical
: thing which correlates this to numbers you find in the monitor's Owners Manual?
: I still can't figure it out.
There is a detailed documentation how to calc these numbers. You should
be able to find somewhere in tsx or sunsite. Not easy to find the best
value, though. Since it's involves some guess work.
--
Yasuo Ohgaki
e-mail: yohgaki@phoebe.cair.du.edu
------------------------------
From: zxmhp01@studserv.zdv.uni-tuebingen.de (Michael Hipp)
Subject: Re: Orchid Soundwave32
Date: 8 Oct 94 18:44:24 GMT
In <PJG.94Oct7155603@tesla.esl.com> pjg@tesla.esl.com (Paul Gyugyi) writes:
>In article <CxBDK2.G6n@cosy.sbg.ac.at> chris@cosy.sbg.ac.at (Christian Linhart) writes:
[...]
>I tried to get the SW32 recognized as a 16 bit MS Sound System compatible
>card by the new voxware drivers (to play doom). No luck. I can cat
>to /dev/audio, but doom's sndserver says I don't have the voxware
>drivers installed.
You can setup your card using the pss-stuff from the voxware driver.
The pss even can upload your .ld file to the card.
I have managed to run the MSS (ad1848 codec) _without_ installing
a soundblaster-driver. (btw: then doom works with 16bit sound)
Greetings,
Mike
--
// Michael Hipp ,Talstr. 1, 72072 Tuebingen , Germany // Netmaze, the best //
// Email: mhipp@student.uni-tuebingen.de // 3D/X11 action-game //
// x400: c=de;a=d400;p=uni-tuebingen;o=student;s=mhipp // ever written!! //
------------------------------
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: jeffpk@netcom.com (Jeff Kesselman)
Subject: Re: Flame on the attitude of Linux towards GCC development
Date: Sun, 9 Oct 1994 00:48:56 GMT
I'm not goping to flame you back, because I have some problems myself
with the 'version .0 always has bugs' view. (I really don't know enough
about GNU history to have a very intelligent view on this, just a feelign
that the only products I've ever seen where this was literraly true were
all made by Microsoft.)
On your subejct of 'come on and help us develop' though, i wanted to make
you aware of anothre side. Myself, I would love to do some Linux kernel
hacking, but i don't because I work 40+ hours a week programming for a
living, which only leaves a small amoutn of time (after the chunkc other
responsabilities take out) to work on my own projects. Given that, at
the moment, other projects interest me more. As fasr GCC goes, I'm happy
I have it, Ill be happy to report bugs, but i don't mhave the time to do
development on it as well. If that were really necessary, Ild go buy a
commercial compiler. Luckily, I haven't found that to be the case.
Just my nickle's worth,
(Used to be 2 cents, before Reganomics ;) )
Jeff Kesselman
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: Shared Libs: working toward a permanent solution?
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Fri, 7 Oct 1994 07:40:11 GMT
Followup to: <372jc2$edj@andante.aib.com>
By author: eric@aib.com (Eric Youngdale)
In newsgroup: comp.os.linux.development
>
> The performance penalty is not due to the library being relocated. It
> is because we lose one of the machine registers so that it can be used
> to point to the GOT table. The Intel architecture is painfully short of
> registers, so losing one gives a noticable performance impact.
>
[...]
>
> The only way to avoid the performance penalty is to modify the compiler
> to do something like half-pic. THis way the same pic operands are
> used so but
> are not referenced to the %ebx register - then you can free up the %ebx
> register...
>
Well, it seems to me there should be a way of handling this using a
segment register, instead of wasting a general-purpose register. Set
up a local descriptor table, then use the base of a currently unused
segment register (GS, for example), then do any references with
respect to GS. This doesn't solve the cases where a pointer needs to
be passed, of course, but I presume that is not the majority of cases,
and this would free up EBX.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
This article might have been generated by a buggy newsreader.
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: LINUX & VESA vs ISA
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Fri, 7 Oct 1994 07:44:10 GMT
Followup to: <36stip$nao@news.halcyon.com>
By author: darkwind@chinook.halcyon.com (C. Joseph Bridwell)
In newsgroup: comp.os.linux.development
>
> I'd like to know whether people installing LINUX have had more, the same,
> or less problems depending on whether the PC was VLB or ISA.
>
It should make no difference at all; possibly VLB might have sligtly
less problems if you have > 16 Mb.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
Microsoft: The Second Evil IBMpire!
------------------------------
From: hware@bronze.coil.com (Henry Ware)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Flame on the attitude of Linux towards GCC development
Date: 7 Oct 1994 03:56:54 -0400
Are you a moron? Postings belong in at most ***ONE*** linux group.
Flamebait should be directed to col.misc. You may/may not have valid
points, I'm supporting the boycott of any crossposted message.
With patience,
Henry
--
Will hack Linux for virtual beer.
------------------------------
From: Stormy@Purple.Madness (Stormy Henderson)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Flame on the attitude of Linux towards GCC development
Date: 7 Oct 1994 07:57:04 GMT
Reply-To: Stormy@Grand.Mother.Com
What was your point?
------------------------------
From: longyear@netcom.com (Al Longyear)
Subject: Re: Improving SLIP latency under Linux
Date: Sat, 8 Oct 1994 02:58:08 GMT
eric@pandora.Las-Vegas.NV.US (Eric J. Schwertfeger) replies to someone:
>: Actually, I guess there is one thing you could do. You could set
>: things up so that if an interactive packet gets queued while a bulk
>: packet is in the middle of transmission, you immediately interrupt
>: the bulk packet (by sending an end-of-frame character and relying
>: on the remote end to discard the incomplete frame) and start the
>: interactive one instead. Ugly, and I don't recommend it for SLIP
>: (which has no link error detection). It would improve latency
>: somewhat.
As you indicated, don't try it with SLIP. Putting X window protocol
over a SLIP link is very dangerous without sending the complete and
error-free frame.
The problem is not that the modems are busy sending the frames. The
problem seems to come from the fact that the modems themselves have a
buffer. Once you fill this buffer, the modem will refuse to accept
additional data until the buffer reaches the low water mark.
If you disable the modem buffer then you will probably find that your
performance will DECREASE since the buffer in the modem smoothes out
the transmission interrupt latency times. (Yes, it occurs on the
transmitter as well as the receiver.)
The PPP software has defined a "frame abort" sequence. (It is coded as
ESC-FLAG if you wish to dig up the appropriate RFC documents.) If the
receiver sees this sequence, the frame is to be considered aborted and
no further processing (including CRC calculations) is to be performed.
Then consider the fact that you may decide to abort the FTP data
transfer frame just short of its normal completion. This would waste
the time that you have already spent sending the data to this
point. (Modem buffers will get in the way in determining just how far
the modem is in progress for sending the frame.) You then put the
frame back on the transmit queue for later transmission and send the
SMTP frame. This gets almost through and then comes a telnet character
frame. So, on hold goes the SMTP frame and now the telnet goes
out. The telnet frame completes and you then restart to send the
SMTP. Oops, now another telnet frame. So back it goes on the queue.
This is not a very workable solution. I suppose that you could bump
the priority by one every time that it goes back on the pending queue
to avoid starving the frames. However, you need to consider the entire
system, not just the single message. You need to consider the amount
of time that you spent calculating the vj header compression, and the
ability to send all of the data.
I doubt that this is a workable solution. However, you are certainly
free to try . . . . :)
If you are the only person using the link and you don't want the
telnet session to be degraded by ftp, then don't start the ftp
transfer. (Simple, isn't it?) If you are not the only user then you
don't have this option. However, consider that the person doing the
ftp transfer wants the data transferred as fast as possible as
well. You must consider all of the users, not just one.
The best solution is to simply choose the priority when you do the
transmission and then send it in that order.
>How about setting the MTU based on the anticipated amount of interactive
>traffic, and adjusting it based on the actual amount? Or is the MTU set
>once for a session?
The maximum value is set once for the session. You could reduce it,
but increasing it is definitely not a good idea.
--
Al Longyear longyear@netcom.com
------------------------------
** 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
******************************