557 lines
23 KiB
Plaintext
557 lines
23 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: 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 <Mar.26.12.49.36.1994.2876@farside.rutgers.edu> 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.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 :-)
|
|
|
|
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 <svm@kozmix.hacktic.nl>
|
|
|
|
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
|
|
******************************
|