lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

465
mail-archive/linux-devel/Volume1/digest5XX/digest577 Normal file
View File

@@ -0,0 +1,465 @@
Subject: Linux-Development Digest #577
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: Fri, 25 Mar 94 09:13:05 EST
Linux-Development Digest #577, Volume #1 Fri, 25 Mar 94 09:13:05 EST
Contents:
Re: LINUX port to a transputer system (Baranski, A.S.)
Re: Specialix Driver Round 2 (From specialix) (David Wright)
Re: WORD status (Niels Skov Olsen)
Linux <--> DOS PLIP??? (Alexandra Griffin)
Re: 486DLC support anyone? (lcvanveen@et.tudelft.nl)
Re: Scsi host time outs -- help (Eric Youngdale)
PAS16 Mixer for XFree?
Re: Genoa Phantom ET4000/w32i + XFree86 anyone?
----------------------------------------------------------------------------
From: v922215@si.hhs.nl (Baranski, A.S.)
Subject: Re: LINUX port to a transputer system
Reply-To: v922215@si.hhs.nl
Date: Fri, 25 Mar 1994 07:40:27 GMT
In article 15762@leeds.ac.uk, een6njb@sun.leeds.ac.uk (N J Bailey) writes:
>In article 764502256@marie, wpp@marie.physik.tu-berlin.de (Kai Petzke) writes:
>> Antoni.Baranski@si.hhs.nl (Baranski, A.S.) writes:
>>
>> >Hi World,
>>
>> > I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland.
>> >During my summer holliday I am planning on making a port of LINUX onto a T800
>> >transputer subsystem which plugs into my PC.
>>
>> Well, I want to encourage you to do it. It will stop all these
>> people, who say: "But linux does not run on a multiprocessor", if
>> it runs on your plug in transputer :-)
>>
>I agree!
>
>> My idea was to do as minimal work as possible in the beginning. Is
>> it possible, that a process on the transputer sends a signal to the
>> Intel chip? Furthermore, is it possible to map transputer memory
>> into the Intel address space? In that case, all the system calls
>> could be processed by the standard Linux kernel, and all you had to
>> programme was a small transputer kernel, which transfers the system
>> calls to the Intel.
>
>Watch out here. Transputers do not have a memory manager, and their
>whole raison d'etre (as we say in England) is to support CSP-based
>programming as embodied in the Occam programming language. If you
>want to use the (very efficient) task scheduling hardware provided
>by a Transputer chip, you will have to use links for comms (not shared
>memory) or else get your hands very dirty indeed hacking around at the
>lowest level. Also since there is no memory management, stopping
>one process corrupting another is next to impossible. Unless you impose
>a one-prcessor, one-process limit.
>
>Transputers aren't really meant for this sort of thing -- they are
>good for embedded systems and highly parallel machines, but not really
>for complex OSs. Unless you have T9000s (rumoured to exist, years overdue,
>never seen one myself). You may be better off implementing the iserver
>in a more efficient way. Transputers are also very slow, compared with
>486s, 68040s etc. (again, excepting T9000s).
>
Here I must interupt because the T800-25MHz 8Mb RAM board I have burns
rubber where as my 486DX-50MHz 8Mb is not even near to the number
crunching powers of the transputer.
>But don't let me stop you being creative!
>
>Nick.
>---
>-------------------------------------------------------------------------------
>Nick Bailey Telephone: +44 532 332057
>Lecturer in Electronic Engineering Facsimile: +44 532 332032
>University of Leeds
>Woodhouse Lane
>Leeds LS2 9JT
>United Kingdom
>===============================================================================
>
SU L8R
================
Baranski, A. S. | Haagse HogeSchool
e-Mail: | Sector Informtica
Antoni.Baranski@si.hhs.nl | Student Software Engineering
>
------------------------------
From: dmw@prism1.prism1.com (David Wright)
Subject: Re: Specialix Driver Round 2 (From specialix)
Date: Wed, 23 Mar 1994 13:04:37 GMT
>>>>> "CMR" == Craig Milo Rogers <rogers@drax.isi.edu> writes:
CMR> In the following reply, I may appear a little condescending,
CMR> even sarcastic. I apologize in advance. I don't really wish to
CMR> offend, I simply wish to make my point obvious. Also, this is a
CMR> long post, and I apologize for that, too.
I won't take it personally...
CMR> 1) The intelligent board connects to the host system by the
CMR> system I/O bus, right?
This would seem obvious. :-)
CMR> 4) Since the intelligent board contain a running software program
CMR> of its own, the format of the registers, and their meanings, may
CMR> be time-varying in very complex, arbitrary, obscure, arcane,
CMR> and wonderful ways.
This is true, but irrelevant if the host (unix) side of the driver
provides a standard API for vendor-specific driver code to talk to. The person
writing such Unix "glue" code could release the API as a public standard,
and there would be no problem with vendors shipping binary-only versions of
their code that "knew" how to use this API. This is especially true in the
case of loadable "modules" under Unix.
CMR> Here we reach the nut of the problem. Each :intelligent
CMR> serial board" vendor may use a completely and arbitrarily *different*
CMR> allocation (spatial and temporal) of bits on the host side of the
CMR> interface, to do that vendor's various and wonderful things. There is
CMR> no common convention or standard (of which I'm aware) for the hardware
CMR> design, meaning of bits, temporal dependencies, etc. in these boards.
CMR> Nada. Zip.
I agree, but I feel this is irrelevant. It's not like there are
different standards out there for us to work with. If the driver that is
being worked on for the Specialix boards is released, the whole Unix-interface
side is likely to be under the GPL, and will be there to serve as an example
for other manufacturers. As the people from Specialix have said, they consider
the code that runs ON the board to be their "jewels", not the code to talk
to the board. Short of companies like Diamond or Matrox, I would expect this
to be the "norm".
CMR> Conclusion: the host-side interface is vendor-specific,
CMR> in-and-of itself.
No, only portions that relate to talking to the *host adapter* are
vendor specific. The portion that talks to Linux / Unix COULD be the same for
every board, technically. The vendor-specific portions of code could fairly
easily be hidden behind an API, or even as a loadable "module".
CMR> For competitive reasons, at least one "intelligent serial
CMR> board" vendor wishes to keep various aspects of their host-side
CMR> interface a trade secret.
This also happens in the video card & ethernet card markets. Big deal.
Buy someone elses board who isn't as anal. Personally, we only use Specialix
boards here anyway, after years of using DigiBoard products, and I would love
to have a DigiBoard driver for Linux.
CMR> There is no "generic" intelligent host adaptor "glue" code,
CMR> because there is no "generic intelligent host adaptor" (of which I am
CMR> aware). No standard has been established, not even a partial
CMR> standard, as is found in video adaptors, sound adaptors, SCSI disk
CMR> adaptors/drives, etc. Lacking adherence to a common standard, nothing
CMR> is generic. Lacking adherence to a common standard, functioning
CMR> (complete in itself) "generic" driver code for intelligent serial
CMR> boards is not possible.
Whether the hardware itself has a generic interface is irrelevant. I
was not suggesting that the same driver would work for all boards at all.
Only that a vendor could take large portions (and possibly all) of existing
driver "glue" code and save development time. I don't what would be stopping
someone from writing their own "intelligent serial interface" for Linux,
providing a standard API, that allowed vendors to write to this API instead of
directly to Linux. The code provided by the API could be supplied in the
standard kernel, and all the vendor would have to supply is the code that
talked via it in some form that could be linked with the kernel (or as a
loadable module). For instance, The API could provide a board "initialization"
hook that got called at boot time, so the board could do what it needed,
load it's local OS, whatever. The same call could provide in a standard,
agreed-upon structure, the desired IRQ, DMA channel, port address, and board
address. Cards that didn't make use of it (set by jumpers or whatever) could
just ignore it. The is no need for the rest of the Linux system to "know" what
the card does when it starts up, so I don't see how vendor-specific "features"
would be an issue here.
Similarly, the Linux "glue" code could supply board read/write
functions to Linux, so the OS talked to all boards via the same IOCTLS, etc.
The glue code would then make use of a "standard" function call to read or
write data from/to the board. You could also provide similar functionality
for things like checking for data to be read from the board, etc.
It would seem to make sense to me to have a structure returned by
the board init routine that would indicate what the vendor-supplied code
supported. IE: Should the Linux-code work in polled-mode, interupt-driven,
etc. In terms of just the API I can't see this would take someone more than a
few days to sketch out on paper, maybe a week (or part-time work) at most.
I would even do it myself, but I do not know enough about the Linux-side of
the interface to do the actual programming on my own.
CMR> The details for loading the on-board processor code is, quite
CMR> probably, one of the major functions that the vendor(s) wish to remain
CMR> a trade secret.
Why do they care about who knows how the code is *loaded*? What the
code that get's loaded DOES is the important part. Most of the embedded OS's
on the cards I have seen are quite small, and it would not suprise me to
learn they just load them into main memory and then DMA them onto the card,
but even stuffing it through an I/O buffer is reasonable since it only gets
done once per boot.
CMR> The OS-specific part of the driver could be considered the API
CMR> you described above, except that the API *wouldn't* know "how to
CMR> write to the intelligent card on the other side", as doing so is
CMR> specific to each vendor's device, in-and-of itself. Writing to the
CMR> intelligent card would be the responsibility of the non-GPLed,
CMR> object-only portion of the device driver.
That is my point. The API would NOT know about the specifics of the
card it was talking to. It would only know to call specific functions (supplied
by the vendor) which did the communication on their own.
CMR> On the OS-dependent side, you could establish a API, such as a
CMR> set of IOCTLs, to be used by user-level programs to reset the intelligent
CMR> serial board's on-board processor, load a new program into the board,
CMR> and other functions that are not present in a standard "dumb" serial
CMR> board, but which may be reasonably expected to be common to intelligent
CMR> serial boards. However, the implementation of resetting, loading, etc.,
CMR> the on-board processor would be part of the hardware-device-specific,
CMR> non-GPLed code in the two-part driver I refer to above.
Exactly what I have always been talking about doing.
Dave
--
____________________________________________________________________________
| /\ / | Prism Computer Applications | David Wright |
| -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM |
| /____\ | Lakewood, OH 44107 USA | 216-228-1400 |
--
____________________________________________________________________________
| /\ / | Prism Computer Applications | David Wright |
| -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM |
| /____\ | Lakewood, OH 44107 USA | 216-228-1400 |
------------------------------
From: dingbat@diku.dk (Niels Skov Olsen)
Subject: Re: WORD status
Date: Thu, 24 Mar 1994 22:57:00 GMT
seiferth@bandelier.cs.unm.edu (Justin Seiferth) writes:
>Whatever happened to the project dedicated to developing a word
>processor/ desktop publishing application? If this is under
>active development I'm interested in participating.
When Wine is finished and stable you'll have access to a whole
line of advanced word processors and dtp systems.
>I did subscribe to the WORD channel, but have not received any
>traffic from there.
Niels
--
"here is a man who *would* not take it any more -- here is a man who stood up"
-Travis Bickle
------------------------------
From: acg@kzin.cen.ufl.edu (Alexandra Griffin)
Subject: Linux <--> DOS PLIP???
Date: 24 Mar 1994 23:31:55 GMT
I've been trying to do this same thing. The only apparent change seems
to have been that a new "protocol byte" has been added to the packet; this
byte is either 0xFD or 0xFC depending on whether the packet is an original
"Type I" packet (the type the Crynwr plip.com driver uses), or a new Linux
Type II packet. The difference seems to be that a Type II packet has reduced
header information, and is generated if enough of the header matches up
between the two ends of the connection...
I attempted to modify my (kernel 1.0) copy of plip.c to dispense with
the protocol byte and always use/expect type I packets. In the
receive_packet() function I removed the get_byte() call to read in the
protocol byte, setting it to a constant 0xFD at this point. Similarly, I
remoed the corresponding send_byte() call from the send_packet() function and
fixed the header-similarity test to never generate a type-II packet.
Unfortunately, this still doesn't work-- there must be somet other protocol
incompatiblity (or perhaps I accidentally messed something up in the driver).
This has resulted in a bit of improvement-- the Linux machine doesn't
just lock up solid when it receives packets from the DOS system (from plip.com)
but instead just ignores them, hanging for a couple of seconds every time one
comes in.
Has anyone had better luck with this, either modifying Linux to
dispense with type-II packets and the extra byte, or modifying plip.com to
handle the new PLIP protocol? I could definitely benefit from having
DOS <--> Linux communications capablity under PLIP, so I'm kind of eager to
get this going.
Thanks in advance,
--
______
\ / //////////////////////////////////////////////
\ / / Alexandra Griffin /// acg@kzin.cen.ufl.edu /
\/ //////////////////////////////////////////////
------------------------------
From: lcvanveen@et.tudelft.nl
Subject: Re: 486DLC support anyone?
Date: 25 Mar 94 10:08:53 +0100
Stuff deleted
Applying the alt diff's does not allways do the job, when your
setup file gets bigger then 512 byte your running into trouble
and that's just what happend even after applying then alt diffs
to the kernel. That's why I had to rip some video stuff out.
Martijn
------------------------------
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Scsi host time outs -- help
Date: Thu, 24 Mar 1994 16:01:14 GMT
Sorry about the crosspost, but I need to reach a wide audience with this.
In article <2mmvem$74s@panix.com> dcv@panix.com (Dimitri Vlahakis) writes:
>
>I keep getting error messages while running linux on my system, if I leave it
>on for over an hour or so. Basically they come randomly, and the message is
>scsi host 0 time out, and I can no longer access my scsi hard drives, or
>the partitions they contain. The drives work fine until then. This problem
>has happened to me with both linux 99pl13 and with 1.0 as well.
I have a patch that one person is reporting success with. I am posting
it to see if it helps anyone else (this is the same patch that was posted to
the SCSI channel a day or two ago). This patch is only for the 1542 driver,
although the wd7000 driver is similar enough that the patch could be used there
as well - don't know about any of the others.
From what I can tell, this patch will help in cases where you have
multiple devices (or multiple drives) that are being used simultanously.
Usually the problem is most severe with machines that have more than one disk
drive since you tend to send a lot more commands to a disk than to a tape drive
or cdrom - expiring news on a 2-disk system can be a pretty good way of
triggering this. Anyway, there was a race condition in the code where we send
commands to the device that this patch corrects, and as I mentioned before,
there is someone with a 1542C that no longer gets timeouts with these patches
installed.
Although I do not expect any problems, I would like people to try this,
because I want to make sure that there are no bad side effects. This patch
will be incorporated into 1.0 if no one reports any problems.
-Eric
begin 644 aha1542.diff
M*BHJ(&%H83$U-#(N8RY^,7X)4W5N($UA<B`Q,R`Q.#HU,SHS,"`Q.3DT"BTM
M+2!A:&$Q-30R+F,)5'5E($UA<B`R,B`R,#HQ.#HT."`Q.3DT"BHJ*BHJ*BHJ
M*BHJ*BHJ*@HJ*BH@.3<L,3`Y("HJ*BH*+2TM(#DW+#$Q,B`M+2TM"B`@"B`@
M<W1A=&EC(&EN="!A:&$Q-30R7V]U="AU;G-I9VYE9"!I;G0@8F%S92P@=6YC
M:&%R("IC;61P+"!I;G0@;&5N*0H@('L**R`@("`@8VQI*"D["B`@("`@('=H
M:6QE("AL96XM+2D*("`@("`@("!["B`@"2`@5T%)5"A35$%455,H8F%S92DL
M($-$1BP@,"P@0T1&*3L*("`)("!O=71B*"IC;61P*RLL($1!5$$H8F%S92DI
M.PH@("`@("`@('T**R`@("`@<W1I*"D["B`@("`@(')E='5R;B`P.PH@("`@
M9F%I;#H**R`@("`@<W1I*"D["B`@("`@('!R:6YT:R@B86AA,34T,E]O=70@
M9F%I;&5D*"5D*3H@(BP@;&5N*S$I.R!A:&$Q-30R7W-T870H*3L*("`@("`@
M<F5T=7)N(#$["B`@?0HJ*BHJ*BHJ*BHJ*BHJ*BH**BHJ(#$Q,"PQ,C(@*BHJ
M*@HM+2T@,3$S+#$R."`M+2TM"B`@"B`@<W1A=&EC(&EN="!A:&$Q-30R7VEN
M*'5N<VEG;F5D(&EN="!B87-E+"!U;F-H87(@*F-M9'`L(&EN="!L96XI"B`@
M>PHK("`@("!C;&DH*3L*("`@("`@=VAI;&4@*&QE;BTM*0H@("`@("`@('L*
M("`)("!704E4*%-405154RAB87-E*2P@1$8L($1&+"`P*3L*("`)("`J8VUD
M<"LK(#T@:6YB*$1!5$$H8F%S92DI.PH@("`@("`@('T**R`@("`@<W1I*"D[
M"B`@("`@(')E='5R;B`P.PH@("`@9F%I;#H**R`@("`@<W1I*"D["B`@("`@
M('!R:6YT:R@B86AA,34T,E]I;B!F86EL960H)60I.B`B+"!L96XK,2D[(&%H
B83$U-#)?<W1A="@I.PH@("`@("!R971U<FX@,3L*("!]"B!L
`
end
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
------------------------------
From: itusul@dale.ucdavis.edu ()
Subject: PAS16 Mixer for XFree?
Date: Fri, 25 Mar 1994 00:49:32 GMT
Is there a X based mixer for the PAS16 out there somewhere? I know there
is x-mix for the SB16...
--
+---------------------------+---------------------------------+
| Lance Kinley | email: lkinley@ucdavis.edu |
| Consultant | login: itusul@dale.ucdavis.edu |
| Information Technology +---------------------------------|
| Campus Access Point |Linux 1.0: It's out & bug free :)|
|---------------------------+---------------------------------+
| 1400 Surge II, University of California, Davis 95616 |
+-------------------------------------------------------------+
------------------------------
From: itusul@dale.ucdavis.edu ()
Subject: Re: Genoa Phantom ET4000/w32i + XFree86 anyone?
Date: Fri, 25 Mar 1994 00:53:20 GMT
M{kinen Sami J. (sjm@isosotka.cs.tut.fi) wrote:
: Has anyone tried the Genoa Phantom ET4000/W32i VLB
: display card with XFree86 ? I have 2MB of display
: memory installed, and I can only occassionally start
: up the XF86_Mono server in 800x600 mode. The other
: servers (XF86_SVGA, XF86_VGA16) will either cause
: the screen go all white and hang the whole system,
: or reboot instantly :(
That's strange...I tried one out for a day and got it to work under XFree
without any problems...
You have to set Chipset to "ET4000" since W32 is not supported (yet).
--
+---------------------------+---------------------------------+
| Lance Kinley | email: lkinley@ucdavis.edu |
| Consultant | login: itusul@dale.ucdavis.edu |
| Information Technology +---------------------------------|
| Campus Access Point |Linux 1.0: It's out & bug free :)|
|---------------------------+---------------------------------+
| 1400 Surge II, University of California, Davis 95616 |
+-------------------------------------------------------------+
------------------------------
** 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
******************************