712 lines
26 KiB
Plaintext
712 lines
26 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: Sat, 24 Sep 94 12:13:05 EDT
|
||
Subject: Linux-Development Digest #220
|
||
|
||
Linux-Development Digest #220, Volume #2 Sat, 24 Sep 94 12:13:05 EDT
|
||
|
||
Contents:
|
||
Re: Status of Mac Linux & PPC Linux? (msouth on BIX)
|
||
Re: Linux on Pentium P90 PCI---which motherboard? (Gus P Ikonomopoulos)
|
||
Pascal for Linux?? (williams)
|
||
Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Josh Templin)
|
||
The ELF/PIC performance measurement. (H.J. Lu)
|
||
Re: A badly missed feature in gcc (Matt Day)
|
||
Re: Linux v1.0 SMAIL problem (Bill Wiest)
|
||
Re: File locking--gurus please read. :) (Matthias Urlichs)
|
||
Re: queue_glue: no memory for gluing queue in 1.1.50 (Matthias Urlichs)
|
||
Re: General Linux Development (Matthias Urlichs)
|
||
Re: memory leakage in 1.1.51 ? (FIX) (Richard L. Goerwitz)
|
||
Re: Alpha Linux (Andrew Bulhak)
|
||
Try this IPX bridging code ... (Vinod G Kulkarni)
|
||
Re: 1+ Gig SCSI Drives (Harald Milz)
|
||
Re: Alpha Linux (Andrew Bulhak)
|
||
Re: Alpha Linux (Andrew Bulhak)
|
||
Re: Alpha Linux (Andrew Bulhak)
|
||
Re: Alpha Linux (Andrew Bulhak)
|
||
|
||
----------------------------------------------------------------------------
|
||
|
||
From: msouth@BIX.com (msouth on BIX)
|
||
Crossposted-To: comp.os.linux.help
|
||
Subject: Re: Status of Mac Linux & PPC Linux?
|
||
Date: 20 Sep 94 05:23:42 GMT
|
||
|
||
|
||
(get info about mac hardware)
|
||
|
||
Two problems: 1) Apple documentation is intended for programmers
|
||
writing for the Mac OS, or manufacturers adding additional hardware.
|
||
2) There are a *lot* of variations. Unlike the PC world,
|
||
standardization is in OS software, not hardware.
|
||
|
||
Example: Hardware reference manual for IIsi says, in effect,
|
||
that 'the ADB ports are different from original Mac II, and
|
||
any software that talks to it directly probabally won't work.' Not
|
||
explained is _how_ it's different.
|
||
|
||
======================================================
|
||
Mike South
|
||
|
||
------------------------------
|
||
|
||
From: gpi41676@uxa.cso.uiuc.edu (Gus P Ikonomopoulos)
|
||
Crossposted-To: comp.os.linux.misc
|
||
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
|
||
Date: 24 Sep 1994 03:25:31 GMT
|
||
|
||
pratt@Sunburn.Stanford.EDU (Vaughan R. Pratt) writes:
|
||
|
||
>If Linux runs on your Pentium P90 PCI, or you know of a working such,
|
||
>I'd appreciate knowing what motherboard did the trick.
|
||
>--
|
||
>Vaughan Pratt http://boole.stanford.edu/boole.html
|
||
|
||
I have linux running on an AMI Atlas VIP motherboard with a 90MHz
|
||
Pentium. I also have an ATI Graphics Pro Turbo (Mach64), NE2000 (Novell-
|
||
Mycrodyne), and a Sound Blaster 16 ASP. It works great.
|
||
|
||
I also have an Adaptec 2940 (Fast SCSI-2) controller card with
|
||
a Fast SCSI-2 hard drive. Linux does NOT recognize it. I have borrowed
|
||
my friends IDE hard drive temporarily. I am hoping a driver will be out
|
||
soon.
|
||
|
||
Gus
|
||
gpi@uiuc.edu
|
||
|
||
|
||
------------------------------
|
||
|
||
From: zwilliam@ucssun1.sdsu.edu (williams)
|
||
Subject: Pascal for Linux??
|
||
Date: 20 Sep 1994 05:58:57 GMT
|
||
|
||
I was wondering if anyone knows of a Pascal compiler that is available
|
||
for Linux.. Please give me a pointer. Thanks!
|
||
--Zach
|
||
|
||
------------------------------
|
||
|
||
From: jtemplin@ub.d.umn.edu (Josh Templin)
|
||
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
|
||
Date: 23 Sep 1994 21:32:22 GMT
|
||
|
||
Vassili Leonov (vassili@cs.sunysb.edu) wrote:
|
||
: : portion of the spectrum utilised. I shudder to ask your opinion of
|
||
: : CW.
|
||
: Well - at least I managed to pass 13 wpm test - ulike you...
|
||
|
||
That is a VERY low blow. Everyone worked hard for their license,
|
||
and I would NEVER criticize someone on the level of their ticket. A
|
||
ticket is an honor..at any level and NO ONE deserves to be put down!
|
||
|
||
: : Not to mention that I've never seen a project run by any government
|
||
: : that could be managed more efficiently and cost-effectively than
|
||
: : one in a competitive private sector!
|
||
: What about GNU and Linux for that matter? I would not say it's run by
|
||
: the Government - but not by the private sector either.
|
||
|
||
Then who is it run by? (Some guy named Earl? -- j/k)
|
||
Linus still holds the copyleft...he's in the private sector, right?
|
||
|
||
: : WRONG! A lot of traffic that you enjoy goes through commercial
|
||
: : providers at some point or another. Face it, were it not for
|
||
: And if it would go by free channels - it would be cheaper. That's it.
|
||
|
||
But who's going to buy the equipment? Who's going to run it?
|
||
Take care of it? It's difficult for me to justify working all day keeping
|
||
up a network for free...I couldn't pay my bills that way! And that why I
|
||
believe our local network changes so often..if something breaks down,
|
||
it's too bad until the person can spare enough cash to get it fixed!
|
||
(One of our local backbone forwarders [KB9AMY.#NOWI.WI.USA.NA] went down
|
||
to lightning a few months ago. Things still aren't right with that
|
||
section of the network...) You would not see this problem in commercial
|
||
systems...they have to be stable, or no one would use them.
|
||
|
||
: : a) your can figure out how to do it for no cost.
|
||
: If allowed I would pay my share. A few $K would be OK. But then
|
||
: I'm FREE. And nobody can STEP ON me one day. Makes a BIG difference.
|
||
|
||
What are you going to do when you have to upgrade? You can't
|
||
really expect a lifetime of usage from a few $k...nothing lasts forever!
|
||
|
||
: : b) you don't steal bandwidth from Amateur Radio... we
|
||
: : already lost 11 meters to "public use" and look what
|
||
: : that got us! There are already enough well-funded
|
||
: Amazing GREED! Tune to 10 meters - in regular days - how many
|
||
: channels are used there (2MHz of spectrum)?. You're lucky if 2-3 of them.
|
||
: Then tune CB (11m - 0.65MHZ spectrum).
|
||
|
||
Oh please! You can't make that comparison! There are so many
|
||
other factors...(not in any order)
|
||
|
||
#1: Cost of equipment
|
||
11m stuff can be bought for 50 bucks! Where are you
|
||
going to find a new commercial ham radio for $50?
|
||
|
||
#2: Band condx
|
||
11m is designed for LOCAL use...and that's pretty constant.
|
||
But when we hams want to communmunicate around the world
|
||
on 10m we have to deal with band conditions, sun spots,
|
||
and a myrid of other factors!
|
||
|
||
#3: Liscensing requirement of AR
|
||
The need for a ticket does not allow someone to walk into
|
||
a radio store, buy equipment, and get on the air.
|
||
|
||
: Most channels are used. So - that WAS very fare. Use it or
|
||
LOSE IT!
|
||
|
||
True, but be reasonable!
|
||
|
||
: : What's your call sign, Vassili???
|
||
: You can find it in the callbook...
|
||
I don't have one...otherwise I'd try looking it up...
|
||
|
||
Josh
|
||
|
||
--
|
||
= jtemplin is Josh Templin (KB9ENE) jtemplin@ub.d.umn.edu =
|
||
= "Microsoft is not a role model. They're not even human. Some of the =
|
||
= things they do would cause a person to get hurt, expelled, arrested, or =
|
||
= possibly deported. To put it another way: don't try DOS at home." -JT =
|
||
|
||
------------------------------
|
||
|
||
From: hjl@nynexst.com (H.J. Lu)
|
||
Subject: The ELF/PIC performance measurement.
|
||
Date: 22 Sep 1994 21:52:27 GMT
|
||
|
||
I did an ELF/PIC performance measurement with gcc on a 486DX2/66 with
|
||
16MB RAM and no external cache.
|
||
|
||
1. Compiler A is gcc 2.6.0-940917 configured as i486-linuxelf and
|
||
linked with the ELF/PIC version of the Linux C 4.6.10. The assembler
|
||
is linked with the ELF/PIC version of the Linux C 4.6.10 as well as
|
||
the ELF/PIC version of libbfd.
|
||
|
||
2. Compiler B is gcc 2.6.0-940917 configured as i486-linux and linked
|
||
with the a.out/DLL version of the Linux C 4.6.10. The assembler
|
||
is linked with the a.out/DLL version of the Linux C 4.6.10 only.
|
||
|
||
Compiler A and Compiler B use the same linker which is linked with the
|
||
ELF/PIC version of the Linux C 4.6.10 as well as the ELF/PIC version
|
||
of libbfd.
|
||
|
||
While compiling c-torture 1.29.1 which contains 634 testing cases,
|
||
simultaneously, the timing for compiler A is:
|
||
|
||
4631.12user 5497.17system 5:33:35elapsed 50%CPU(0avgtext+0avgdata0maxresident)k
|
||
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
||
|
||
The timing for compiler B is:
|
||
|
||
4740.34user 4963.42system 5:28:24elapsed 49%CPU(0avgtext+0avgdata0maxresident)k
|
||
0inputs+0outputs (0major+0minor)pagefaults 0swaps
|
||
|
||
Compiler A is less than 5% slower than compiler B. If that can hold for
|
||
other cases, which may well be true, I think we are in very good shape
|
||
with ELF/PIC.
|
||
|
||
H.J.
|
||
09/22/94
|
||
|
||
|
||
------------------------------
|
||
|
||
From: mday@park.uvsc.edu (Matt Day)
|
||
Subject: Re: A badly missed feature in gcc
|
||
Date: Sat, 24 Sep 1994 13:17:08 GMT
|
||
|
||
In article <hpa.20930000.I.use.Linux@ahab.eecs.nwu.edu> hpa@nwu.edu (H. Peter Anvin) writes:
|
||
>Followup to: <hpa.1c0f0000.I.use.Linux@ahab.eecs.nwu.edu>
|
||
>By author: hpa@nwu.edu (H. Peter Anvin)
|
||
>In newsgroup: comp.os.linux.development
|
||
>>
|
||
>> Append to the line immediately following it:
|
||
>>
|
||
>> %{!ansi:-lang-c++ %{c:-U__cplusplus}}
|
||
> ^^^^^^^^^^^^^^^^^^
|
||
>
|
||
>Actually this turns out to be both redundant and incorrect. The best,
|
||
>thus, I have managed to come up with is:
|
||
>
|
||
>%{!ansi:-lang-c++}
|
||
>
|
||
>This should work as long as there are no files in the C++ include
|
||
>directories that conflict with any in the C include directories. I
|
||
>haven't still figured out how to get it to properly pass the
|
||
>-nostdinc++ flag if you are not compiling a C++ program. Nothing I
|
||
>have tried has worked properly, so it is probably best to leave it
|
||
>out.
|
||
|
||
If it's just // style comments you want, use the -lang-c-c++-comments
|
||
option to cpp, specified in the specs file like above. That turns on
|
||
// handling only.
|
||
|
||
A while ago, I mentioned to the gcc2 list about the need for an
|
||
all-purpose way to pass arguments to the various compiler pass programs
|
||
from the gcc command line, but I don't believe such a feature can be
|
||
expected in 2.6. :-( So for now, we have to edit the specs file.
|
||
|
||
Matt Day <mday@park.uvsc.edu>
|
||
|
||
------------------------------
|
||
|
||
From: bwiest@suspects.com (Bill Wiest)
|
||
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.p
|
||
Subject: Re: Linux v1.0 SMAIL problem
|
||
Date: Tue, 20 Sep 94 01:16:01 EDT
|
||
Reply-To: bwiest@suspects.com (Bill Wiest)
|
||
|
||
root@marinbbs.simenv.com (root) writes:
|
||
|
||
> Phil Homewood (phil@rivendell.apana.org.au) wrote:
|
||
> : Mihail S. Iotov (iotov@cco.caltech.edu) wrote:
|
||
>
|
||
> : : The easiest way out is to install uucp, then smail will call uuname to
|
||
> : : find out that the mail is not going to one of your uucp_neighbours and
|
||
>
|
||
>
|
||
> : An even better solution still os go and get sendmail 8.6.
|
||
> : Why have everything forward off through a smart host when it can get
|
||
> : to its destination directly anyway? (OK, I know smail can be
|
||
> : configured... but it's a pain to get it to send out un-munged headers
|
||
> : and such anyway...)
|
||
>
|
||
> Any anyone direct me to sendmail 8.6 ?
|
||
>
|
||
> Thanks.
|
||
>
|
||
>
|
||
I believe you can find at ftp.cs.berkeley.edu:/ucb/sendmail
|
||
|
||
--Bill Wiest
|
||
|
||
+-----------------------------------+-----------------------------------+
|
||
| Internet : bwiest@suspects.com | "You don't understand a thing |
|
||
| CompuServe : 70662,3311 | until you know its causes." |
|
||
| | -- Aristotle |
|
||
+-----------------------------------+-----------------------------------+
|
||
|
||
------------------------------
|
||
|
||
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
||
Subject: Re: File locking--gurus please read. :)
|
||
Date: 20 Sep 1994 05:37:44 +0200
|
||
|
||
In comp.os.linux.development, article <34vgav$8ud@panix3.panix.com>,
|
||
wboyce@panix.com (Willis Boyce) writes:
|
||
>
|
||
> Unfortunately, the Linux 1.1.8 that I am running apparently doesn't
|
||
> support deadlock detection. Indeed, there is even a comment in flock.c
|
||
> to that effect. Anybody who has ever used a heavily-loaded DBMS
|
||
> knows that deadlock detection is not something that can be done without;
|
||
> therefore, I would like to add it.
|
||
>
|
||
So upgrade to 1.1.51; it's in there.
|
||
|
||
--
|
||
You will meet your perfect mate today. Congratulations! It's yourself.
|
||
--
|
||
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
|
||
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
||
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
||
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
|
||
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
||
|
||
------------------------------
|
||
|
||
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
||
Subject: Re: queue_glue: no memory for gluing queue in 1.1.50
|
||
Date: 20 Sep 1994 05:51:27 +0200
|
||
|
||
In comp.os.linux.development, article <Cw4DIy.KD7@info.swan.ac.uk>,
|
||
iialan@iifeak.swan.ac.uk (Alan Cox) writes:
|
||
> In article <Cw0py0.CC@setanta.demon.co.uk> at@setanta.demon.co.uk (Amrik Thethi) writes:
|
||
> >One thing you could try is to mount the NFS directories with an 'rsize'
|
||
> >of 1024 or 4096 ( anything less than a mem page ). This may make life
|
||
> >easier for the IP fragment assembly code, and thereby prevent the
|
||
> >problem. No guarentees tho'
|
||
>
|
||
> That is by far the best way of doing it - but has a speed cost thanks to the
|
||
> SunOS I/O & VM subsystems.
|
||
|
||
That's a problem when writing. On the other hand, the big-packet problem
|
||
shows up only when reading, so rsize=2048 and wsize=8192 should get us the
|
||
best of both worlds. Sort of.
|
||
|
||
--
|
||
Isn't this my STOP?!
|
||
-- Zippy the Pinhead
|
||
--
|
||
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
|
||
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
||
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
||
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
|
||
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
||
|
||
------------------------------
|
||
|
||
From: urlichs@smurf.noris.de (Matthias Urlichs)
|
||
Subject: Re: General Linux Development
|
||
Date: 20 Sep 1994 06:13:32 +0200
|
||
|
||
In comp.os.linux.development, article <35dujt$e68@senator-bedfellow.mit.edu>,
|
||
brat@htilbom.ernet.in writes:
|
||
>
|
||
> Any other specific improvements you had in mind, while we are at it...
|
||
>
|
||
Don't forget to replace the SIGALRM handling. (Right now the kernel
|
||
decrements the counters when it walks the process queue every timer tick.)
|
||
|
||
I already have (somewhat ugly) patches which do this (part of porting the
|
||
BSD scheduler to Linux). The run queues are done with standard queues; I
|
||
just wrote another routine which adds a new element at the end instead of
|
||
at the beginning so that the scheduler will do round-robin within a
|
||
priority class. New priorities are calculated every two seconds or so.
|
||
|
||
Email if interested -- no need to invent the wheel twice...
|
||
|
||
--
|
||
One trouble with being efficient is that it makes everybody hate you so.
|
||
-- Bob Edwards
|
||
--
|
||
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
|
||
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
|
||
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
|
||
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
|
||
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
||
|
||
------------------------------
|
||
|
||
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
|
||
Subject: Re: memory leakage in 1.1.51 ? (FIX)
|
||
Reply-To: goer@midway.uchicago.edu
|
||
Date: Fri, 23 Sep 1994 17:29:52 GMT
|
||
|
||
Guenther Thomsen writes, re the apparent memory leak, and its basis
|
||
in a new swapping strategy:
|
||
>
|
||
>Ok, not a bug, but for an 'old' linuxer somewhat strange.
|
||
>
|
||
>PS: It may be a FAQ, or it will be. I have to say, that I didn't read
|
||
>the recent ones ;-)
|
||
|
||
My question is whether pages swapped out, but left resident in the
|
||
swap space, are marked as such, so that they can be cleaned out if
|
||
more virtual memory is needed. What I'm talking about is a kind of
|
||
compromise between the old and new systems....
|
||
|
||
--
|
||
|
||
-Richard L. Goerwitz goer%midway@uchicago.bitnet
|
||
goer@midway.uchicago.edu rutgers!oddjob!ellis!goer
|
||
|
||
------------------------------
|
||
|
||
From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
|
||
Subject: Re: Alpha Linux
|
||
Date: 20 Sep 1994 06:50:07 GMT
|
||
|
||
Anton Ertl (anton@mips.complang.tuwien.ac.at) wrote:
|
||
: In article <AMBRISKO.94Aug26104834@tasha.kpc.com>, ambrisko@kpc.com (Douglas Ambrisko) writes:
|
||
: |> The biggest task with the
|
||
: |> Alpha is making everything 64 bit clean and this will apply to the EISA
|
||
: |> drivers.
|
||
|
||
: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
|
||
: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
||
|
||
ints should be 32-bit, longs 64-bit and shorts 16-bit.
|
||
|
||
If both ints and longs were made 64-bit, one would have no access to
|
||
32-bit or 16-bit objects (depending on the size of a short). That would
|
||
break a lot of applications and cause headaches when dealing with file
|
||
formats.
|
||
|
||
I think that the OSF/1 solution (64-bit longs, 32-bit ints and 16-bit
|
||
shorts) is the best one; it seems to be intuitively logical (longs
|
||
should be long and may be longer than ints) and doesn't break much
|
||
(programs which depend on ints being 32-bit will still run).
|
||
|
||
--
|
||
Andrew Bulhak <acb@yoyo.cc.monash.edu.au> Celebrate PRODOS 1.1.1 DAY 18-Sep-94
|
||
|
||
------------------------------
|
||
|
||
From: vinod@cse.iitb.ernet.in (Vinod G Kulkarni)
|
||
Subject: Try this IPX bridging code ...
|
||
Date: Fri, 23 Sep 1994 04:32:40 GMT
|
||
|
||
I have uploaded IPX bridging code to sunsite (Incoming). This is
|
||
pre-pre-alpha, but is precursor for fulfledged development of IPX
|
||
bridging/routing on linux. At this stage, it *may* work for you.
|
||
And it is not all that efficient as of now. We mainly want feedbacks and
|
||
design ideas for efficiency.
|
||
|
||
Here is the README:
|
||
================================
|
||
This is first attempt to get IPX bridging and routing working
|
||
for linux.
|
||
|
||
This is pre-pre-alpha. This implementation is just to trigger off
|
||
the full fledged development.
|
||
|
||
ASSUMPTIONS:
|
||
1. Bridges between only two interfaces : eth0 and eth1. (Hardcoded)
|
||
2. The MTUs of both interfaces should remain equal.
|
||
|
||
TODO:
|
||
|
||
IPX bridging:
|
||
|
||
1. Intelligent bridging
|
||
2. Get most functionality into the kernel to minimise overheads
|
||
(in the style of routing)
|
||
|
||
IPX routing:
|
||
|
||
We are trying to port Mark Bush's <Mark.Bush@comlab.ox.ac.uk>
|
||
IPXrouted.tar.gz to linux. This package is IPX routed implementation
|
||
for SUNs. It is available in ftp.comlab.ox.ac.uk archives.
|
||
|
||
It handles IPX packets all by itself, without requiring any kernel support
|
||
from the sun system (i.e. it reads all packets from /dev/nit interface).
|
||
Hence, this package cannot make use of IPX sockets which are currently
|
||
in the kernel. We will try to eventually adapt this package to make
|
||
use of IPX sockets which are currently in the kernel.
|
||
|
||
|
||
Note
|
||
=====
|
||
We are still learning... All kinds of suggestions are welcome.
|
||
Are we doing some silly mistakes in network programming?
|
||
And allow us to take our own time!
|
||
|
||
And anyone there who is interested?
|
||
|
||
======================
|
||
Amitay Isaac, project engr., Dept. of Aero Engg. , IIT Bombay INDIA.
|
||
amitay@aero.iitb.ernet.in
|
||
|
||
Vinod G Kulkarni, research scholar, Dept of CSE, IIT Bombay, INDIA.
|
||
vinod@cse.iitb.ernet.in
|
||
|
||
--
|
||
--Vinod.G.Kulkarni. ,---------------------------------------
|
||
Research scholar, |"People often find it easier to be result
|
||
Dept. of CSE, IIT Bombay, | of the past than the cause of the -
|
||
INDIA. (vinod@cse.iitb.ernet.in)|___________________________- future.___
|
||
|
||
------------------------------
|
||
|
||
From: hm@ix.de (Harald Milz)
|
||
Subject: Re: 1+ Gig SCSI Drives
|
||
Reply-To: hm@ix.de
|
||
Date: Fri, 23 Sep 1994 17:11:56 GMT
|
||
|
||
In comp.os.linux.development, Marc Singer (elf@netcom.com) wrote:
|
||
|
||
> I, too, have been wondering about this. I believe that there are at
|
||
> least two problems with >1G support. First, the standard IBM
|
||
> partition scheme limits the number of heads to 255 and the number of
|
||
> cylinders to 1024. The math comes out such that drives larger than 1G
|
||
> cannot be supported without hardware/firmware assist, e.g. Adaptec's
|
||
> 255 head mapping trick. Since Linux uses the IBM style partition
|
||
> tables, there is nothing simple that can be done.
|
||
|
||
I don't really know which problems you folks have. I have been
|
||
operating a DEC DSP3160S (1.6 G) with a Adaptec 1542B since 0.99.9
|
||
and never had any problems. No Extended Translation, nothing. Remember:
|
||
All DOS-specific extensions as Extended Translation have to be switched OFF.
|
||
|
||
The one and only problem you may encounter is that you cannot boot a
|
||
file which resides above the 1 G limit because this is handled by the
|
||
BIOS which cannot access > 1023 cyls. Just keep your /vmlinuz'es below
|
||
and you should have no problems.
|
||
|
||
> I once read a rumor about a new filesystem standard. I believe that
|
||
> ALL unices are limited to 2G partition sizes due to the 32 bit file
|
||
> pointer accepted by the standard OS entry points. Perhaps there is a
|
||
> movement afoot to go to 64 bit pointers as did Microsoft with Windows
|
||
> NT.
|
||
|
||
Linus introduced 64 bit pointers recently.
|
||
|
||
--
|
||
Never be led astray onto the path of virtue.
|
||
--
|
||
Harald Milz (hm@ix.de) WWW: http://www.ix.de/editors/hm.html
|
||
iX Multiuser Multitasking Magazine phone +49 (511) 53 52-377
|
||
Helstorfer Str. 7, D-30625 Hannover fax +49 (511) 53 52-378
|
||
Opinions stated herein are my own, not necessarily my employer's.
|
||
|
||
------------------------------
|
||
|
||
From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
|
||
Subject: Re: Alpha Linux
|
||
Date: 20 Sep 1994 06:54:41 GMT
|
||
|
||
Andrew Ukrainec (ukrainec@soma.crl.mcmaster.ca) wrote:
|
||
: In article <ADC.94Sep6123815@bach.coe.neu.edu>,
|
||
: Albert D. Cahalan <adc@bach.coe.neu.edu> wrote:
|
||
: > >|> Alpha is making everything 64 bit clean and this will apply to the EISA
|
||
: > >|> drivers.
|
||
: >
|
||
: > >Only if Linux on the Alpha will be a 64-bit-OS.
|
||
: >
|
||
: > I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|
||
: >
|
||
: > >If it will be, I hope
|
||
: > >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
||
: >
|
||
: > Then you have to drop either the 16 bit or the 32 bit int type. Both
|
||
: > options may make some people unhappy. The 32 bit int is a reasonable
|
||
: > compromise. It also breaks all those programs which assume that a
|
||
: > pointer and an int are just the same thing, which is a good thing IMHO.
|
||
: >
|
||
: >Why drop one?
|
||
: >16 bits = short int
|
||
: >32 bits = int
|
||
: >64 bits = long
|
||
|
||
: Another observation: at least according to the K&R C specification, short
|
||
: int, int, and long int are not defined to be any specific bit length, and
|
||
: can all be equal to same bit length, as a matter of fact. The programmer
|
||
: who writes expecting short int = 16 bits should know that the code will not
|
||
: necessarily be portable.
|
||
|
||
: Therefore, there shouldn't be a problem defining
|
||
|
||
: short int = 32 bits
|
||
: int = 64 bits
|
||
: long int = 64 bits
|
||
|
||
: or all of them = 64 bits. This makes more sense to me than int = 32 bits.
|
||
|
||
Obviously you do not need to read files in binary formats much, or at
|
||
least not binary formats designed for older platforms. 16-bit quantities
|
||
are invaluable when dealing with file formats designed for MS-DOS
|
||
applications.
|
||
|
||
--
|
||
Andrew Bulhak acb@yoyo.cc.monash.edu.au
|
||
Remember the good old days, when "spam" on the Net referred to processed meat?
|
||
|
||
------------------------------
|
||
|
||
From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
|
||
Subject: Re: Alpha Linux
|
||
Date: 20 Sep 1994 07:03:20 GMT
|
||
|
||
David Holland (dholland@husc7.harvard.edu) wrote:
|
||
: adc@bach.coe.neu.edu's message of 06 Sep 1994 16:38:15 GMT said:
|
||
|
||
: > Why drop one?
|
||
: > 16 bits = short int
|
||
: > 32 bits = int
|
||
: > 64 bits = long
|
||
|
||
: Over in the next thread people were talking about Unicode; why not
|
||
|
||
: 16 bits = char
|
||
: 32 bits = short
|
||
: 64 bits = int, long
|
||
|
||
8 bits = char
|
||
16 bits = wchar_t, short
|
||
32 bits = int
|
||
64 bits = long
|
||
|
||
: Of course that would break a lot of things, but such is the price of
|
||
: progress :-)
|
||
|
||
Why break that which is not broken, especially for such a trivial
|
||
reason? Unicode and other 16-bit encodings already have wchar_t, and
|
||
they are not going to replace ASCII in the near future.
|
||
|
||
--
|
||
Andrew Bulhak acb@yoyo.cc.monash.edu.au
|
||
BRAKE WHATEVER IS NOT BROKEN AND CHANGE IT !
|
||
|
||
------------------------------
|
||
|
||
From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
|
||
Subject: Re: Alpha Linux
|
||
Date: 20 Sep 1994 07:08:52 GMT
|
||
|
||
Bill Hay (wish@dumain.demon.co.uk) wrote:
|
||
: Albert D. Cahalan (adc@bach.coe.neu.edu) wrote:
|
||
|
||
: > Why drop one?
|
||
: > 16 bits = short int
|
||
: > 32 bits = int
|
||
: > 64 bits = long
|
||
|
||
: Because an int should be the natural wordsize of the processor and should
|
||
: therefore be 64 bits.
|
||
|
||
What is "natural"? An Alpha can handle 32-bit quantities just as
|
||
"naturally" as 64-bit quantities, so it all comes down to convenience.
|
||
And dropping one size, thus making it unavailable to programmers, is
|
||
very inconvenient.
|
||
|
||
Let's not fool ourselves. Some people say that that is a Good Thing as
|
||
it breaks poorly written applications and teaches Good Programming. This
|
||
is tantamount to asserting that self-flagellation is character-building.
|
||
In other words, it has more to do with masochism than with making a
|
||
usable system. Programming environments should not be about obstacles
|
||
for the sake of obstacles.
|
||
|
||
Just my $0.02;
|
||
|
||
--
|
||
Andrew Bulhak acb@yoyo.cc.monash.edu.au
|
||
Remember the good old days, when "spam" on the Net referred to processed meat?
|
||
|
||
------------------------------
|
||
|
||
From: acbul1@penfold.cc.monash.edu.au (Andrew Bulhak)
|
||
Subject: Re: Alpha Linux
|
||
Date: 20 Sep 1994 07:12:39 GMT
|
||
|
||
Anton Ertl (anton@mips.complang.tuwien.ac.at) wrote:
|
||
|
||
: I have debugged enough programs (one:-) that worked perfectly well on
|
||
: decent OSs on an Atari ST to know why I dislike
|
||
: sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
|
||
: least 5 hours of debugging time of two people (one of them an
|
||
: experienced Atari user).
|
||
|
||
Since the converse ( "sizeof(int)==sizeof(void *)" ) is not specified in
|
||
the C specification, it should not be assumed. It is a pretty safe
|
||
assumption, however, that a long can hold both a pointer and an int.
|
||
|
||
--
|
||
Andrew Bulhak acb@yoyo.cc.monash.edu.au
|
||
Remember the good old days, when "spam" on the Net referred to processed meat?
|
||
|
||
------------------------------
|
||
|
||
|
||
** 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
|
||
******************************
|