From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 29 Mar 94 19:13:14 EST Subject: Linux-Development Digest #588 Linux-Development Digest #588, Volume #1 Tue, 29 Mar 94 19:13:14 EST Contents: Re: PC as C64 file server (Garner Keith Thomas) Re: Problem trying to directt IP address back to loopback interface (Alan Cox) Re: TCP/IP-Bug in 1.0 Kernel? (Michael Will) LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Baranski@si.hhs.nl () writes: (Baranski, A.S.) InterViews shared libs (Michael N. Lipp) Re: Async I/O (Nick Maclaren) Re: LINUX port to a TRANSPUTER (N J Bailey) Re: LINUX port to a transputer system (David Arnold) Re: program to watch IRQs (Joe George) Re: A truely non-debugging Kernel? (Kevin Brown) Re: TCP/IP-Bug in 1.0 Kernel? (Rob Janssen) ---------------------------------------------------------------------------- From: k-garner@ux4.cso.uiuc.edu (Garner Keith Thomas) Crossposted-To: comp.sys.cbm Subject: Re: PC as C64 file server Date: 29 Mar 1994 06:52:37 GMT acbul1@lindblat.cc.monash.edu.au (Andrew Bulhak) writes: >Sven Goldt (goldt@math.tu-berlin.de) wrote: >: paul (paul@dino.eng.monash.edu.au) wrote: >: : Ok, >: : It seems quite clear that there is a need for a device that allows >: : a standard ibm pc to be used as a file server for our humble ol' Commodore >: : 64's. Is anyone working on such a device? What do people think about the idea? >: : Is it possible ?? >: Well,it IS possible.If i find the time i will write such >: a client/server package.The HD could be accessed just like a >: normal floppy.I think the c64 part could act like a >: fastloader and the PC (server) part as a device driver or tsr program,but >: i prefer to use a server under unix. >I was thinking of a Linux daemon which polls a device on /dev/lp0 or >somewhere and acts as a virtual 1541. That way, this would place a very >light load on the machine, allowing it to be used for other tasks as >well. >Another Linux/1541 project, the reciprocal of this, would be a 1541 file >system which uses the X1541 cable. >-- >Andrew Bulhak acb@yoyo.cc.monash.edu.au >Slackware: The Linux of the SubGenius. I was thinking of something like the 1541 file system myself....Maybe get linus to add it to the kernel :) --Keith. ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: Problem trying to directt IP address back to loopback interface Date: Mon, 28 Mar 1994 12:56:54 GMT In article <1994Mar27.002418.6060@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes: >down and I do this: > >route add -host 125.5.5.5 dev lo > >Packets set to 125.5.5.5 are dropped! This is BAD, since apps like >talk to a local user will fail if it uses the 125.5.5.5 IP address. This is correct. Your machine will keep forwarding the packet around until it gets fed up. You don't have an interface of that address. If you want you can set up another dip script that doesn't bother dialing but sets the ip address and no routes. Then you can talk to yourself over that ip address with no problems. (Just not anyone else) Alan ------------------------------ From: zxmgv07@studserv.zdv.uni-tuebingen.de (Michael Will) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: 29 Mar 94 09:58:53 GMT In hedrick@farside.rutgers.edu (Charles Hedrick) writes: >zxmgv07@studserv.zdv.uni-tuebingen.de (Michael Will) writes: >>I have noticed that SLIP does work with 1.0 but has problems running >>ftp and the like with anything beyond that. I tried 1.0p2 and 1.0p4 but >>had to go back to 1.0 to work with SLIP. >This note doesn't have enough information to diagnose the problem. Tell me what to find out to help and I will do all I can. I have no idea where to begin here - I just saw what happened, and it happenes to happen to more people than just me :-) >Unfortunately this message doesn't contain enough information to do >any diagnosis. If you could give me a hint what to find out - I will be happy :-) > I will say that systems like this are complex enough >that it's easy to draw incorrect conclusions. Yes, you are right there. > I thought Linux had >broken TCP in going from pre-1 to 1.0. However further investigation >made it clear that for some reason my terminal server had started >dropping characters more often. That seemed to be a one-time thing: >further experience with 1.0 and 1.0.x has been pretty much the same as >late 0.99pl15. Well I can boot 1.0p2 or p4 and it does not work. I reboot with 1.0 and it works. More I do not know at the moment, what could I look for? >I do think there's a possible problem in dealing with some PC TCP >implementations. I do not use PC-TCP. I will take a closer look what our terminalserver is and mail you the information... > However so far no one has sent me any packet traces, >so there's nothing I can do about it. How can I do one? I am fairly new at this, but always eager to learn. Cheers, Michael Will ------------------------------ From: v922215@si.hhs.nl (Baranski, A.S.) Subject: LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Baranski@si.hhs.nl () writes: Reply-To: v922215@si.hhs.nl Date: Tue, 29 Mar 1994 07:40:26 GMT FIRST OF ALL SORRY FOR THE TOOOO LONNNNG LINEESSSSSSS. Hi world, So far I have received many reactions from GREAT to shut this guy up in a lunny bin. But I think that most people didn't really understand my first message. I said I wanted to have the 486 do all the I/O work and thus working as a server with the transputer as client. Well I've been searching high and low in articels concering transputer hardware. And found some advertisments about SCSI 1/2 controllers as a T-RAM module. So the need for ans AFS (Alien file server) might not be so great, or maybe it would because I would need a way to boot the transputer (it would be possible to boot from a EPROM).. And now let me try to explain the idea again, so simple as possible: The idea was that it would be possible to open a window under LINUX with X11 and have the Transputer running in there. Doing some number crunching in parallel with the 486. And there for a part of the LINUX code would be needed to run on the Transputer. The port wouldn't be written in OCCAM 2 because that would give me a HUGE pain in the BUM!!!! Because of the way how OCCAM 2 is written. But in C and compiled with a 3L-C Compiler. Which I am planning on buying soon. If I can get it for a nice price. And not for 600 pounds which is around 1800 Guilders and that's a bit much, for a student that has to live of something around 300 guilders a month. So I'll be looking at 3L if they don't have a studente version or a student price, for their compiler. Or if someone out there in internet land would like to part with his 3L compiler, I am interested.!!! I hope this makes life easyer for you folks out there. SU ================ Baranski, A. S. | Haagse HogeSchool e-Mail: | Sector Informtica Antoni.Baranski@si.hhs.nl | Student Software Engineering P.S. Sorry to all of you who couldn't read the first posting ........ Keywords: ------------------------------ From: mnl@dtro.e-technik.th-darmstadt.de (Michael N. Lipp) Subject: InterViews shared libs Date: 29 Mar 1994 10:00:28 GMT Hello, does anybody know anything about source for InterViews shared libraries for Linux? I tried to contact pmacdona@ra.uvic.ca (mentioned in the DLL doc as "official" owner of the DLL address space for InterViews), but he does not respond to my mail. I`m currently building my own version of shared libIV.a and libUnidraw.a (nonshared work fine already), if there are no official jump.* files and if there is any interest, I`ll make source and binaries available. Michael -- =================,==============================,============================== Michael N. Lipp ! Institut fuer Datentechnik ! Phone: 49-6151-163776 ! Merckstr. 25 ,----------' Fax: 49-6151-164976 ! D-6100 Darmstadt ! E-Mail: ! (Germany) ! mnl@dtro.e-technik.th-darmstadt.de ================='==================='========================================= ------------------------------ From: nmm@cl.cam.ac.uk (Nick Maclaren) Subject: Re: Async I/O Date: 29 Mar 1994 09:22:31 GMT In article <2n75g3$ibh@valhalla.ee.rochester.edu>, dave@valhalla.ee.rochester.edu (David F. Carlson) writes: |> May I suggest rather than using MVS as a model for your async I/O support, |> get a recent draft of the IEEE POSIX1003.4 (nee' 1b) standard. This was |> recently ratified by the IEEE real-time POSIX committee and although not |> perfect contains much insight into the problems you discuss. The hassle |> is that the IEEE has decided to make money on their standards so the documents |> are not ftp'able. |> |> Since Linux is already 1003.1 compliant, getting the pieces to 1003.4 in place |> seems like the "Portable" thing to do. Yes, indeed, and I wouldn't propose using MVS's interface for a second. While it is probably at least as good (technically) as POSIX, it is philosophically incompatible with UNIX. Most of POSIX is more-or-less compatible with UNIX :-) However, POSIX is about interfaces alone, and contains nothing about mechanisms. The only semi-public description of a production asynchronous I/O design that I know of is in the MVT manuals, and there are a lot of less-than-obvious details. Some of these affect the specification, especially in the areas that POSIX leaves as implementation-defined or undefined. Part of the trouble about POSIX is that some of its components standardise things that UNIX traditionally didn't have, or got completely wrong. This often leads to very poor or unimplementable specifications. There were some right royal messes in 1003.4a (threads), to do with signal handling, but I don't know if they have been fixed. Nick Maclaren University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm@cl.cam.ac.uk Tel.: +44 223 334761 Fax: +44 223 334679 ------------------------------ From: een6njb@sun.leeds.ac.uk (N J Bailey) Subject: Re: LINUX port to a TRANSPUTER Reply-To: een6njb@sun.leeds.ac.uk Date: Tue, 29 Mar 1994 09:16:27 GMT In article GEp@si.hhs.nl, Antoni.Baranski@si.hhs.nl writes: > The idea was that it would be possible to open a window under LINUX with X11 and have > the Transputer running in there. Doing some number crunching in parallel with the 486. And > there for a part of the LINUX code would be needed to run on the Transputer. > Be prepared for a shock. 486s are quite a bit faster than one Transputer, you know! > The port wouldn't be written in OCCAM 2 because that would give me a HUGE pain in the BUM!!!! > Because of the way how OCCAM 2 is written. But in C and compiled with a 3L-C Compiler. If you're thinking C, read "a lot faster" above. C uses stacks and dynamic memory allocation. Transputers are very bad at both. Occam is only a mild irritant to the backside, and I would say that it's good for you to run around mentally exercising yourself in parallel programming rather than sitting down all day. So perhaps a sore bottom has its advantages! =============================================================================== Nick Bailey Telephone: +44 532 332057 Lecturer in Electronic Engineering Facsimile: +44 532 332032 University of Leeds Woodhouse Lane Leeds LS2 9JT United Kingdom =============================================================================== ------------------------------ From: arnold@sienna.dstc.edu.au (David Arnold) Subject: Re: LINUX port to a transputer system Date: 28 Mar 1994 23:52:08 GMT In article 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 :-) While I wouldn't like to discourage your creative efforts, there's a few things you should know before you start. From my limited understanding of the internal structure of the Linux kernel and also based on what it provides to the programmer, I don't think that it will be possible to port the kernel to the T4/8 series transputer architecture. The T4/8 series transputers do not have the hardware to support virtual memory. Nor do they have the ability to protect areas of memory from other processes. Since these are the fundamental assumptions made in the Linux kernel, I think this is where you luck out ... 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. Yes, it is possible to send signals to the Intel CPU, depending on what protocol you use between the T80x and the x86. However, assuming that you are going to be using standard transputer boards, the major problem is the bandwidth available between the two CPUs. However, it might be possible to come up with a reasonable way to pass system calls back to the x86. The difficulty will be that the kernel will not have access to the memory of the processes. Memory mapping is not possible with standard hardware. Not much of the Linux kernel is written in assembler, check with the header files in /usr/include/asm. Non-assembler versions of the string routines as found in /usr/include/linux/strings.h are found in the GNU C-Library for example. But you may have to learn about your Transputer's assembly to get things rolling. Yep - I'd think so too. And once you've done that, you might want to reconsider. Transputer assembly reflectes the CPU architecture, and it's a long way from that of the x86 ! Overall, the best approach may be to look at Minix instead. For one thing, there is already someone working on a port to the T4/8 CPUs which is always a good thing. The major advantage though is that Minix does not (in the base 1.6 version) provide virtual memory. It allocates fixed size memory areas to processes - which should suit the transputer very well. You could then allocate a guard area at the end of the stack, and check it sometimes to make sure that the stack hasn't overflowed. The kernel structure of Minix is also suitable for transputers. It is composed of a number of independant processes that communicate using small messages. I would think that with some hacking you should be able to put a memory manager and scheduler on each processor, and get them to cooperate in executing processes. The filesystem could run either on the x86 or the root transputer. Another thing that might be fun - I think that the original Minix filesystem is single threaded. It would make sense to rewrite this as a multi-threaded server. In my opinion, this project would provide a similar amount of 'fun' but with a much lower frustration potential that attempting to port Linux. Who knows, it might even be working by the end of your holidays ? davida -- David Arnold ================================================================== CRC for Distributed Systems Technology arnold@dstc.edu.au University of Queensland voice +617 3654367 Australia fax +617 3654311 -- David Arnold ================================================================== CRC for Distributed Systems Technology arnold@dstc.edu.au University of Queensland voice +617 3654367 Australia fax +617 3654311 ------------------------------ From: jgeorge@nbi.com (Joe George) Subject: Re: program to watch IRQs Date: Tue, 29 Mar 1994 00:50:27 GMT phil@zeus.fasttax.com (Phil Howard) writes: >soup@penrij.UUCP (John R. Campbell) writes: >>dmarcher@acsu.buffalo.edu (dave archer) writes: >> >>>does anyone have a program to watch IRQs? is it even >>>possible to do such a thing at the user level? >> >>There have been times I would've liked to get this information. >> >>Perhaps a /proc device with one entry per IRQ, 16 counters in the >>Interrupt dispatch logic? >Once I get upgraded to 1.0 I plan to dive into some kernel developments. >One of the ideas on the drawing board is a special virtual terminal that >would be dedicated to kernel monitoring. Maybe more than one VT could be. There's a patch that was uploaded to sunsite last week that does sort of (I think) what you want -- the program is called 'procinfo' and it takes some misc information from the /proc filesystem and formats it for display. Included is a kernel patch to break down the number of interrrupts by IRQ and display individial IRQ stats, they display could use a little prettying up but it does suffice. It also has the ability to run in a full-screen updated mode, kinda like 'top', but I cant seem to get it to run in an empty VC right, but not a major issue. Look and see if this is along the lines of what you want, and perhaps contact the author if you want to help expand on it. No sense in duplicating work that someone else has already done. Joe procinfo's author (from the manpage) is: Sander van Malssen and it looks like this: twiglet:~$ procinfo Linux version 1.0.4 (root@twiglet) #1 Sat Mar 26 18:12:22 EST 1994 Memory: Total Used Free Shared Buffers Mem: 11484 8984 2500 4232 3284 Swap: 6236 0 6236 Bootup: Mon Mar 28 18:18:57 1994 Load average: 1.13 0.83 0.60 user : 0:16:58 page in : 4865 nice : 0:00:00 page out: 8641 system: 0:13:36 swap in : 1 idle : 0:59:34 swap out: 0 uptime: 1:30:09 Interrupts: Context switches: 1037890 540957 13314 0 417116 133 0 1 0 0 0 0 0 0 1 27020 0 Modules: size twiglet:~$ -- Joe George (jgeorge@crl.com, jgeorge@nbi.com) Great Moments in Usenet news: "Usenet is a cesspool, a dungheap." -Patrick Townson "No." -Tim Pierce ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: A truely non-debugging Kernel? Date: Mon, 28 Mar 1994 23:42:43 GMT In article <1994Mar26.154000.5087@terrabit.uucp> ddb@terrabit.uucp (David Dyer-Bennet) writes: [...] >The distinction between "debugging code" and "self-defense code" is >entirely in the eye of the beholder. I consider Linus' eye's opinion >overwhelmingly more useful than my own at this point. > >I'd be very unhappy if in some future release I got a switch that said >to me "I control some debug code. Maybe I'm not really necessary. Do >whatever you think is right." I'd either have to guess, or spend a >*lot* of time to learn enough to make a reasoned decision. I want >advice from the experts on that sort of issue. I definitely agree. If such an option were in the configuration script, it should probably say something like "Kernel sanity checks (highly recommended unless you *really* know what you're doing)?". And, of course, its default should be "yes" every time, even if the last answer to it was "no". But I do think that such an option should be there, though perhaps not in the configuration script. If not there, then in some header file that you'd have to edit by hand (then you'd have to know a bit more about what you're doing than if you just answered configuration questions before compiling the kernel). -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: TCP/IP-Bug in 1.0 Kernel? Date: Tue, 29 Mar 1994 07:59:24 GMT Reply-To: pe1chl@rabo.nl In <1994Mar28.150321.8736@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes: >In article <1994Mar26.131145.1087@pe1chl.ampr.org> pe1chl@rabo.nl writes: >>Getting Alan's new binaries (ifconfig etc) broke it for me. It worked >>fine before... >> >Every copy of this problem I've checked out so far has been old version of >dip that don't know the new route syntax. So if you have a problem keep the >old route binary around or upgrade to dip337uri Then I'm afraid this is the first one that is not caused by that... I have used dip337uri, and have patched it further to solve some problems with route handling. (I think you have received these patches via the NET mailing list) The problem does not seem to be in DIP but in ifconfig. Or does ifconfig use a new syntax as well? Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ ** 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 ******************************