lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest134
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

801 lines
30 KiB
Plaintext
Raw Blame History

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: Wed, 7 Sep 94 08:13:05 EDT
Subject: Linux-Development Digest #134
Linux-Development Digest #134, Volume #2 Wed, 7 Sep 94 08:13:05 EDT
Contents:
Re: DOSEMU 0.53 notes
Re: Future of linux -- the sequel (Jens Krauss (Steinfath))
Re: Homemade Terminal Server cheap (William)
Multiprocessing Pentium Systems ("David Williams")
Bug in c-lib (ftell) ? (root)
Re: DOSEMU 0.53 notes (ddelsig@uoft02.utoledo.edu)
[Q] on Linux/MIPS port (tiv@ludens.elte.hu)
Re: lynx dying when calling malloc (Rafal Maszkowski)
A thought to improve security (J.A.vanderMost)
Re: Unicode & Linux's future (was Re: Acid) (Andries Brouwer)
DOSEMU 0.53p17 & mouse (Francesco Defilippo)
Re: Multiprocessing Pentium Systems (Tim Morley)
Re: What on earth is happening to the stability of the Linux Kernel? (Alan Cox)
Re: Mosaic and other TCP/IP problems (Alan Cox)
Re: Netware Client (Alan Cox)
Re: help SCSI aha1542 broken since 1.1.36 now in 1.1.49 (Steven A Marien)
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Mitchum DSouza)
Re: Bug: in beta gcc & libc's? (4.6.x + gcc 2.6.x) (Mitchum DSouza)
Re: Bug in c-lib (ftell) ? (Robert Mayer - Student)
----------------------------------------------------------------------------
From: fnrjh@dev103.elmer.alaska.edu ()
Subject: Re: DOSEMU 0.53 notes
Date: Wed, 7 Sep 1994 01:52:33 GMT
Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <34djse$cds@sunb.ocs.mq.edu.au> mkrisch@avalanche.mpce.mq.edu.au (Mark Krischer) writes:
: what patchlevel?
I am using 1.1.42 dosemu0.53pre17
: I don't think so. Only ET4000, S3, trident for now.
I to wish they supported ATI. I have one (weird card) and DOSEMu stops
when I try to use the graphics mode. Do I need to make a copy of the
BIOS for the video card? Any strange thing to get graphics mode. Character
mode works great. The old DOSEMu 52 worked with the ATI. Cursor looked
funny but it worked.
Robert J. Hale III
fnrjh@dev103.elmer.alaska.edu
roberth@muskox.alaska.edu
------------------------------
From: krauss@charlie.igd.fhg.de (Jens Krauss (Steinfath))
Subject: Re: Future of linux -- the sequel
Date: 7 Sep 1994 08:25:12 GMT
Reply-To: igd.fhg.de
In article <3456g5$1ekr@yuma.ACNS.ColoState.EDU>, pyeatt@CS.ColoState.EDU (Larry Pyeatt) writes:
>
> In article <CvGnDw.I0C@world.std.com>, entropy@world.std.com (Lawrence Foard) writes:
> |>
> |> Why should I pay 5 times more for a non PC system which gives me the same
> |> performance as a 486 100?
>
> What? I was unaware that any company was still making such slow
> machines. You can get a VL bus motherboard with MIPS R4600 processor
> that makes Pentium look like a 4.77 8086. Why waste money on such
> a junky architecture as Intel when there are good processors available.
>
> |> When there are enough non PC users to port
> |> Linux to other platforms it will get ported. Why do you expect
> |> PC users to spend $10K for a workstation so they can spend time porting
> |> Linux to it? Its up to the people who own those systems to put in the
> |> effort, don't expect someone to do it for you. (If you have all that
> |> extra money to throw around why not pay somone to port it?)
>
> Compare the price/performance of processors and Intel comes out to
> make the worst processors in existence. PowerPC chips provide twice
> the performance of Pentium at half the cost. That means they are
> 4 times as good. PowerPC is considered slow compared to some other
> processors on the market. For myself, I am just trying to decide
> which non-Intel motherboard to get. They do not cost anywhere near
> $10K.
> --
> Larry D. Pyeatt All standard disclaimers apply.
> pyeatt@cs.colostate.edu Void where prohibited.
You are right!!!!!
But one can buy PC-Hardware on each Shop, department store, and so on....
The "Shit" is available everywhere. If you go to a computer show (e.g. CeBIT,
or ComDex...) you here the question "Can this HardWare running Windows???"!
The masses ask for Intel, not For POWER, MIPS, Sparc or ARM....!!!
I to think Motorola, and all the others have built better Procs., but not the
best wins the Price. The most aggressive does it!! And MS-Intel is aggressive!
Linux is I think the best choice making your PC like a Workstation. But if no
one wants to buy the other Hardware, Intel will win the race. One motor for
this is the OS market. On an R4600, PCI board the only choice is NT. Do you want
NT????
I Hope IBM will have their Linux Port ready, when they bring up their PC killing
POWER PREP system (I heard about this project!!)!!!! But perhaps they bring
a light wight (working, bug free) AIX for this system. Without any choice against NT, .......
Cioa Jens
PS: I'm currently developing software for MIPS, Sparcs, Linux, and...
I'm developing an VxD Device Driver for Windows 3.1.! And I can say Windows
best place is the Waste Basket!!!
------------------------------
From: billw@glare.cisco.com (William )
Crossposted-To: comp.dcom.servers
Subject: Re: Homemade Terminal Server cheap
Date: 7 Sep 94 01:49:29
Cyclade has released a 16-port 115k serial card (risc based) with
drivers for Linux. Up to 2 cards can be put in one machine. 32 port
cost $400 (!!). Plus the cost of a PC and ethernet card you have a 32
port SLIP,CSLIP,PPP terminal server for $1500.
Well, cisco has on and off again played with the idea of using a PC platform
to achieve a low cost comm server, so I sent off to cyclade for some info.
There are some gotchas...
1) MSRP for the 16 port card is over $700 apiece - I don't know where
the original poster got $400 for 16 ports. (MSRP of 8 port cards
was over $400.) Cyclade also sells a full "terminal server", 16 ports
for (barely) under $2000...
2) "RISC based" means that the cards are based on Cirrus logic's CD1400
quadARTs. The Cirrus parts are amoung the nicest uarts one can buy
(IMHO,) and are implemented via an internal RISC core processor, but
they aren't reprogrammable in any sense. Implementing a 32 port
comm server based on this technology still means doing byte-at-a-time
I/O to FIFOs on the chip, which is rather difficult to do at 32x115kbps.
The CD1400 are quite a bit smarter than 16550's, especially for unix
(they'll do \n -> crlf on-chip, for example) but they aren't the sort
of order-of-magnitude speed improvement one needs to be a true 115kbps
server. (16 lines @ 115kbps is approximately equivilent to 1 T1 line.
No one in their right mind does programmed IO for T1 data rates. Of
course, it's easy to argue that true 115k support is not required.)
IMO, claiming a card is risc-based when it isn't reprogrammable at all
is sneaky and misleading...
BillW
cisco
------------------------------
From: "David Williams" <dwwillia@mango.ucs.indiana.edu>
Subject: Multiprocessing Pentium Systems
Date: Tue, 6 Sep 1994 21:10:20 -0500
I've just seen some new dual processor pentium systems in Computer
Shopper. They look swell for the money, but there isn't a single OS
that can take advantage of them. Anybody have any thoughts about how
hard it might be to make Linux one of the first OS's to take advantage
of these systems?
David Williams Member of League for Programming Freedom
dwwillia@iucf.indiana.edu Linux, PGP, the Web: I love this NET!
http://www.iucf.indiana.edu Indiana University Cyclotron Facility
------------------------------
From: root@kirk.in-berlin.de (root)
Subject: Bug in c-lib (ftell) ?
Date: 6 Sep 1994 20:37:15 +0200
Hi,
I recently upgraded my system from libc 4.5.21 to libc 4.5.24. Some of my
programs which are running without any problem with 4.5.21 and on a lot
of other machines (Unix and aah Dos) don't run any more.
I tracked it down to a call of ftell. After running in that problem I upgraded
to libc 4.5.26 in the hope of, well ya know.
But the same. I attached an example program where I isolated the interesting
parts.
I compiled it on our Ultrix, Sun and messy dos and on every system I got the
same results for first size and second size as I assumed. Only on my linux
box I got different sizes. It turned out that ftell seems to reset the
filepointer of the filehandle to zero. And so beneath the wrong fileposition,
the formerly written data gets overwritten.
Any clues?
Achim
====================== snip ==============================================
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>
#define STRING "This is something that got written out in a loop! Count: %d\n"
#define BINARY "ftellbug.tst"
/*
* I know the b will be ignored for Linux but messy dos needs it
*/
#define MODE "wb"
void main()
{
FILE* fp;
int fh;
long fpos = 0L;
long firstsize = 0L;
long secsize = 0L;
int i;
int len = strlen( STRING );
int result;
struct stat fb;
if( (fp = fopen( BINARY, MODE )) == (FILE*)0 )
fprintf( stderr, "Failed to open file %s for writing\n", BINARY );
fh = fileno( fp );
for( i=0; i < 20; i++ )
{
if( (result=write( fh, STRING, len )) != len )
{
fprintf( stderr, "Something happened while writing tried to write\n\
%d, but get only %d written\n", len, result );
}
}
fstat( fh, &fb );
firstsize = fb.st_size;
fclose( fp );
/*
* Second run with ftell
*/
if( (fp = fopen( BINARY, MODE )) == (FILE*)0 )
fprintf( stderr, "Failed to open file %s for writing\n", BINARY );
fh = fileno( fp );
for( i=0; i < 20; i++ )
{
if( (result=write( fh, STRING, len )) != len )
{
fprintf( stderr, "Something happened while writing tried to write\n\
%d, but get only %d written\n", len, result );
}
if( (fpos = ftell( fp )) == -1 )
fprintf( stderr, "There is an error at ftell\n");
else
printf( "Filelength: %ld\n", fpos );
}
fstat( fh, &fb );
secsize = fb.st_size;
fclose( fp );
printf( "First Size without ftell %ld\nSecond Size with ftell %ld\n",
firstsize, secsize );
}
========================= result =================================
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
Filelength: 0
First Size without ftell 1200
Second Size with ftell 60
=============================== snip ===================================
------------------------------
From: ddelsig@uoft02.utoledo.edu
Subject: Re: DOSEMU 0.53 notes
Date: Tue, 6 Sep 1994 17:05:21 GMT
>The only other problem I have noticed is that mem does not show any EMS memory
>even though I ask for it. Am I the only one for which EMS doesn't show up?
>
>Harry
In config.sys, load the driver `ems.sys' that came in dosemu.
Dave
ddelsig@uoft02.utoledo.edu
------------------------------
From: tiv@ludens.elte.hu
Subject: [Q] on Linux/MIPS port
Date: 2 Sep 94 10:37:48 +0200
Hello,
I've read the annonuncement and FAQ on the MIPS/linux port, and there are
still things I'd like to know...
Does this port work only for that specific board ?
What about other architectures based on MIPS processors ?
Once this project is done, how difficult would be to port _that_
to a MIPS based DECstation for example ? I'm curious because we have a bunch
of DECstation 3100's (Running MIPS R3000 as I know and Ultrix). Currently
we can only use them for X terminals (lack of memory and hd) but maybe with
the efficient memory management of linux ( e.g. shared libs and dynamic buffer
cache - things that Ultrix never heard about ) we could use them as regular
workstations...
Is such a porting project planned anywhere ? I'd contribute, but I have not
enough time, resources and experience to start it alone.
Generally, I think it'd make sense to port linux (as a free, modern and usable
unix clone) to architectures which are the latest ones (like ALPHA and PowerPC)
but they're reliable, incorporate standards (like SCSI) and widely used.
tivadar
------------------------------
From: rzm@dain.oso.chalmers.se (Rafal Maszkowski)
Subject: Re: lynx dying when calling malloc
Date: Wed, 7 Sep 1994 09:30:08 GMT
H.J. Lu (hjl@nynexst.com) wrote:
> In article <BP0RBZTG@math.fu-berlin.de>, rzm@dain.oso.chalmers.se (Rafal Maszkowski) writes:
> |> I have problems with lynx. It dies when trying to access link like
> |> file://localhost/~/ which is special lynx hack to access and manage
> |> home directory. It seems that malloc library function is causing
> |> segmetation violation. Lynx killed our Convex here some time ago (new
> The first thing I would check is if Lynx somehow frees a malloced pointer
> more than once. That can happen in many ways, like call fclose () twice on
> an fp.
You were right. I installed Checker-0.5 (wonderful tool!) and found
it almost immediately:
--- LYGetFile.c.bak Tue Sep 6 02:51:25 1994
+++ LYGetFile.c Tue Sep 6 02:51:25 1994
@@ -53,7 +53,7 @@
if (strlen(++cp))
strcat(address_buffer,cp);
if (strcmp(href,address_buffer)) {
- free(href);
+/* free(href);*/
StrAllocCopy(href,address_buffer);
}
}
(StrAllocCopy is calling free() on href too)
R.
--
Rafal Maszkowski rzm@oso.chalmers.se http://www.mat.uni.torun.pl/~rzm
Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec
------------------------------
From: jvdmost@hupnos.wi.leidenuniv.nl (J.A.vanderMost)
Subject: A thought to improve security
Date: 7 Sep 1994 09:08:01 GMT
Just a thought :
Some programs in a Unix system have to be SUID root to do the things they do.
Like /bin/passwd /bin/login /usr/bin/lp /user/bin/at etc.. are all SUID root.
But being root is MUCH to powerful for these programs, they don't need all
the abilities of root, only a very small portion of it. And that's exactly
my point, if we give such a program not more than it needs than a security-
bug is not so harmful as it is now.
Let's say lpr has a security bug in it, it allows a normal user that knows
witch options, etc. to use, to modify a file that this user couldn't normally
modify. This is a very harmful bug, because this user can easily become root!
If we give lpr just enough permissions to do his job, the user can NOT become
root so easily.
Now my suggestion :
Let's modify the kernel a bit, and redefine the meaning of the UIDs below 256:
UID 0 is root ( like it always was, many programs depend on this )
UID >256 are normal users, without a special meaning.
UID 1-255 are not what they used to be, they have a special meaning :
1 1 1 1 1 1 1 1
| | | | | | | |
| | | | | | | - Processes running with this UID-bit set can read ANY file,
| | | | | | | EXCEPT when owned by root.
| | | | | | --- Processes running with this UID-bit set can write ANY file,
| | | | | | EXCEPT when owned by root.
| | | | | ----- Processes running with this UID-bit set can chmod/chown ANY
| | | | | file, EXCEPT ... ( guess what :-)
| | | | ------- Processes running with this UID-bit set can attach to ports
| | | | < 1024
| | | --------- Processes running with this UID-bit set can change their UID
| | | (but NOT to 0, and only to give away permissions, not to gain)
| | ----------- etc..
| -------------
===============
!!!! ^- THIS IS JUST AN EXAMPLE, NOT THE FINAL WORD !!!!
All processes that need to access things owned by root will still have to run
SUID root, if not, the user can, somehow, get any-file-write permissions and
alter files owned by root, and so becoming root. By excluding files owned by
root we can prevent this.
Note that UID 255 has not the same rights as UID 0.
If we somehow have a security hole in some program running SUID 1-255 and
the user can become UID 1-255 by using the security hole, the effect is not
as harmful as it would have been when the program run as SUID 0 !
If these changes get implemented in the kernel, someone will have to write a
program/shellscript to shift the UIDs 1-255 to some other value. Although a
file without the SUID bit has no special rights, it is nicer to use 1-255 only
for SUID progs.
All comments are appreciated, especially from kernel-hackers.
I will log all follow-ups and email messages and send a summary to Linus, if
the net thinks it's a good idea, then Linus will be our final judge :-)
Jeroen van der Most
--
* JvdMost@wi.leidenuniv.nl * America may be unique in being a country *
* Most@stpc.wi.leidenuniv.nl * which has leapt from barbarism to *
* * decadence without touching civilization *
* * -- John O'Hara *
------------------------------
From: aeb@cwi.nl (Andries Brouwer)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Date: Wed, 7 Sep 1994 09:38:39 GMT
djohnson@arnold.ucsd.edu (Darin Johnson) writes:
>> >is input methods: Do the keyboard drivers work with the operating system
>> >in such a way that one can, on the fly, change one's keymap? Does it sup-
>> Yes.
>But it's overkill. You don't need special support from the keyboard
>drivers to support input methods. All you need is for the input
>consumer to map internally. Most input methods work by running as
>a separate process rather than being embedded into the OS.
I agree entirely. And for Chinese, Japanese etc that is the only way to go.
But if what you need is ASCII plus not more than a few dozen additional symbols,
then an input method is too heavy a solution, and it is easiest to have
a keymap in the kernel.
>> >Finally, do the display drivers
>> >and GUIs support multiple wordwrap directions?
>Again, this is best solved in the application, not the GUI (and
>especially not the display driver).
>Of course, this begs the issue of getting 'ls' to display with a
>mixture of left-to-right and right-to-left scripts - but running
>'ls' (or more likely, an 'nls') inside a multilingual window
>solves this. I think it's better to start there and make progress
>than to ponder how to fit all that code into the console device...
I did it once, and found that only a few changes were required
(like: x++ becomes x += dx), and it was not very difficult to make ls
go top-to-bottom or right-to-left. (The most difficult part was getting
the screen to scroll horizontally.) But not many people seem to be
interested in such features.
------------------------------
From: clint@hal9000.unipv.it (Francesco Defilippo )
Subject: DOSEMU 0.53p17 & mouse
Date: 7 Sep 1994 09:23:17 GMT
Hi, when i exit from dosemu selection doesn't work,
I'v linux 1.1.49 & dosemu 053p17
--
With Best Regards:
:sw=4,ts=4.
+--------------------------------+
| Francesco Defilippo |
| clint@hal9000.unipv.it |
| public-key: finger(1) e-mail |
+--------------------------------+ +---[Network]
^ ^ /
0 0 /
=--------------oOO-(_)-OOo--------------------=[beware someone is watching u]
-- A black Hole is what happens when God divides by 0 --
------------------------------
From: tim@morgoth.derwent.co.uk. (Tim Morley)
Subject: Re: Multiprocessing Pentium Systems
Date: 7 Sep 1994 11:25:01 +0100
In article <1994Sep6.211029.11082@news.cs.indiana.edu>,
David Williams <dwwillia@mango.ucs.indiana.edu> wrote:
>
>I've just seen some new dual processor pentium systems in Computer
>Shopper. They look swell for the money, but there isn't a single OS
>that can take advantage of them. Anybody have any thoughts about how
>hard it might be to make Linux one of the first OS's to take advantage
>of these systems?
Well it would be hard to do so, as OS/2 SMP already exists and is
avaliable for dual processor machines...
We could be the first _FREE_ OS to support it though 8-)
Tim M
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: What on earth is happening to the stability of the Linux Kernel?
Date: Wed, 7 Sep 1994 10:25:51 GMT
In article <hpa.3cf80000.Swedes.have.more.fun@ahab.eecs.nwu.edu> hpa@nwu.edu (H. Peter Anvin) writes:
>Since the kernel developers are gearing up for a new production
>release (1.2.0) the stability of recent 1.1.x kernels have been
>rapidly improving, since the developers have gotten much more
>conservative with adding new features. Expect 1.2.0 to be very
>stable, but the first 1.3.x kernels (new development thread) will
>probably be a bit wobbly due to many suddenly added untested features.
Well the 1.3.x networking code will probably start out fairly interesting
with all the additional IP multicasting, protocol layering and other toys.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Mosaic and other TCP/IP problems
Date: Wed, 7 Sep 1994 10:35:43 GMT
In article <345a7h$1s1@exile.oec.com> stewart@oec.com (Stewart Allen) writes:
> show up. My network cohorts claim that 5632 bytes = 1 machine page +
> minimum TCP packet + TCP header and that there may be a problem with the
> VJ conjestion control algorithms. Is this true or is the algorithm not
> even implemented?
The algorithm is implemented and 5632 almost certainly has no relation to
anything in the kernel code. However it certainly shouldn't be happening.
1 machine page + min tcp packet + tcp header is about 4200 bytes for those
who can add. What are you talking to at the remote end ?
> One other beef... the close() socket protocol is not implemented correctly.
> Instead of negotiating the close of a socket, Linux just waits 60 secs.
> and then closes the socket (/usr/src/linux/net/inet/tcp.h). For RPC servers
> that spawn when called, this is ok; the residual process just hangs
> around for an extra 60 seconds before going away. This can be seen on an
The Linux TCP code follows the RFC state diagram. You cannot close and yield
up a network connection instantly because the TCP TIME_WAIT state is
required. The actual close() from a process will be immediate unless the
process chooses to set SO_LINGER. Most RPC servers are udp anyway. In no
case does your comment apply. The earlier 1.0 kernels have a problem that
caused reuse of the same port (eg rsh) to occasionally have a 20 second
lag but this was fixed a long time ago and isn't directly related.
> httpd server that is under heavy load. Every access to the httpd server
> leaves a residual process for 60 secs. after completing the request. For
> RPC servers that are necessarily single-threaded, however, Linux's hack is
> not acceptable. The server must wait 1 minute before completing each
> request and accepting the next. Is there a fix for this in the works?
No because it's a bug that doesn't exist. Read the .c files too
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Netware Client
Date: Wed, 7 Sep 1994 10:37:45 GMT
In article <090294103907Rnf0.79b5@ankh-morpork.hacktic.nl> sander@ankh-morpork.hacktic.nl (Sander Plomp) writes:
>NetWare isn't really DOS based. The OS that runs on the servers is a
>completely different OS. It has a weird history, because it dates back
>to the days of DOS 1, and has many hacks to support DOS oddities. But deep
>down it is more like UNIX than like DOS.
>
>But NetWare clients for many OS-es exists, and it should be possible to
>make one for linux just as well.
Yes you buy the documentation from Novell for $15000 + royalties sign a
non disclosure agreement and write a user mode file system using no GPL or
LGL code.
Alternatively you wait for Undocumented Netware to come out and work from
that.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
------------------------------
Crossposted-To: comp.os.linux.help
From: smarien@maroon.tc.umn.edu (Steven A Marien)
Subject: Re: help SCSI aha1542 broken since 1.1.36 now in 1.1.49
Date: Wed, 7 Sep 1994 02:45:11 GMT
In article <94249.131208BTITMARS@esoc.bitnet>,
BARRY TITMARSH <BTITMARS@ESOC.BITNET> wrote:
>So please. Who is working on scsi aha1542B/C code now..
>I have a broken aha1542 since 1.1.36 and still no fix.
>please mail me if you have info on who is the current maintainer of
>scsi for aha1542
>thnaks.
>see my other postings about scsi bug in 1.1.37--->>--1.1.49
>thnaks.
My Adaptec 1542B has worked with every kernel I've installed.
This includes 1.1.49 and many other previous patch levels.
Maybe you have some other device which is conflicting with
the autoprobing?
------------------------------
From: Mitchum.DSouza@mrc-apu.cam.ac.uk (Mitchum DSouza)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 7 Sep 1994 11:09:40 GMT
In article <34gq1u$ba@bosnia.pop.psu.edu>, barr@pop.psu.edu (David Barr) writes:
|> In article <346t0b$m2n@lyra.csx.cam.ac.uk>,
|> Mitchum DSouza <Mitchum.DSouza@mrc-apu.cam.ac.uk> wrote:
|> >In article <3453ud$i9v@bosnia.pop.psu.edu>, barr@pop.psu.edu (David Barr)
|> writes:
|> >|> Okay, I'll spell it out. In Solaris, the filename of the shared
|> >|> libraries to load are stored at compile-time. There's also
|> >|> run-time directory search list which is built from ld's -R flag and
|> >|> LD_LIBRARY_PATH, if set.
|> >
|> >I had patches to ld/ld.so to implement this for linux, but it is not really
|> >worth the extra binary bloat by recording paths at compile-time. Having a
|> >sensible cache in place is usually enough to satisfy the linking procedure.
|>
|> Huh? A cache is only good for speed-up purposes. A cache does you no
|> good if you have two incompatible libraries around of the same name
Yes our cache can keep around libraries of the same name, but of different
version numbers quite happily. In fact I have 3 libc's in my cache presently.
|> that you need simultaneous access to. (Oh, like say X11R5 libX11.so and
|> X11R6 libX11.so) In fact a cache needlessly randomizes and obscures
Why don't you just use LD_LIBRARY_PATH to point to the different library
location. Just as simple and doesn't require path recording. Anyway this
topic is moot, as I previoulsy stated, ELF binaries will have this option.
|> the process. Having compile-time library paths (and filenames) is in
|> no way "binary bloat".
The people in the GCC channel decided that this was a form of unwanted binary
bloat, especially since we just removed the __load.o from all binaries to
ld.so.
|> It's funny that you're hung up on the "Slowaris" moniker here, since
|> Solaris's shared library loader is significantly faster than SunOS 4.x's.
|> (and all else being equal, as fast or faster than Linux's)
I am not easily drawn into "my OS is better than your" kind of arguments but
I will answer this one.
When I mentioned Slowaris I did not concentrate specifically on the dynamic
linker at all. You may be correct about the dynamic linker but I was referring
generally to Slowaris. A similar machine (say a SS10/41 with equivalent
hardware) running SunOS is much snappier and seems quicker in my opinion.
Clearly Slowaris running a version with fewer bugs than 2.2 on a multiprocessor
machine will be a different kettle of fish totally.
Secondly it is unfair to compare Linux's and Slowaris's ld.so as they are
inherently different. We do not perform dynamic linking as we have fixed
addressing. To counteract the fact that SunOS ld.so was slow and bound
all symbols at runtime, Slowaris now has the concept of lazy-binding - hence
the apparent speed. You need to set LD_BIND_NOW if you want to see the speed
decrement in true dynamic linking.
All in all you cannot compare apples with oranges (IMHO).
Mitch
------------------------------
From: Mitchum.DSouza@mrc-apu.cam.ac.uk (Mitchum DSouza)
Subject: Re: Bug: in beta gcc & libc's? (4.6.x + gcc 2.6.x)
Date: 7 Sep 1994 11:13:37 GMT
In article <34idbc$gaf@vixen.cso.uiuc.edu>, bf11620@ehsn20.cen.uiuc.edu (Byron
Thomas Faber) writes:
|> Hello
|>
|> I'm posting this here because I can't seem to post to the GCC
|> listserver. I'll figure it out sometime, but in the meantime I seem
|> to have found a problem. Maybe its me.
|>
|> I installed gcc 2.6.x (the latest from tsx-11 private dir) and I also
|> have gcc 2.5.8. This bug exists with either compiler.
|>
|> Anyway, when compiling svgalib (the newest version), I get a sig 11
|> consistently on the file mem.S. It does not compile.
|>
|> I suspect this has something to do with the new 'as' that I installed
|> (the one detailed in the release.libc 4.6.x that replaces binutils-1.0)
|>
|> If somebody out that could look at this, it might do us/me some good.
Your message did get thru to the GCC channel. H.J. also found a lot of bugs
when compiling the recent libc-4.6.x with the gcc snap-shots. He has posted
to the the gnu.gcc.bugs and RMS he said.
Keep using 2.5.8 for the moment.
Mitch.
------------------------------
From: robert@par.univie.ac.at (Robert Mayer - Student)
Subject: Re: Bug in c-lib (ftell) ?
Date: 7 Sep 1994 11:52:27 GMT
As far as I know you are not allowed to use FILE*-functions *and*
handle-functions on the same file (at least not without calling fflush()
in between).
If you use fwrite() instead of write(), then your program will probably
work on all systems, including linux. The fact that your program works on
the other systems doesn't prove that it is correct ;-)
Regards,
Robert.
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink